That's the impression I got too, and I believe it's just plain silly. First of all, I paid for my demo board, so in a sense, I'm a paying customer, albiet a tiny, tiny, tiny one.
But, when a tool breaks, it breaks equally for paying and non-paying customers, so it behooves the company to listen to all issues found about a product, as the resolution of those issues, no matter if they come from a paying customer or a freeloader, will make the tools all that much better. And, here's the big secret, when the tools are better, the "paying customers" might be willing to pay even more money for better tools!
That is pretty much what it means and what is written on the XST page from Xilinx's own site, in "marketese" as Austin said. Look elsewhere in this thread to find Austin's link to the relevant Xilinx page.
Go check job postings on monster, workopolis and others. Look for some high-profile FPGA applications and see how many mention Xilinx FPGAs as the target and Synplify as required/asset... nearly 100%. It becomes pretty obvious that very few serious rely on XST.
The reason I'm still using 7.x is that the schematics editor in 8.x and higher uses aliasing which -litteraly- makes me cry because I can't focus on aliased lines (and yes, I have an excellent monitor). Why do they want to fix things that aren't broken?
--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
I believe only paying customers can create webcases...
Having said that I would like to join the chorus of the ones being irritated by the ISE tools (mostly map and par in my case). I've been working on a big V4FX60 design and it's been a nightmare. FATAL errors left and right. You fit a design, then take a big portion of logic OUT of it and it can't fit it anymore. You finally get something with reasonable timing after prolonged fight with the tools, then add one flip-flop or change one net and it breaks everything no matter which guide modes you use. I had to cancel my vacation as I couldn't deliver a working design to a deadline :( It is most frustrating to feel that you have no control over what's going to be generated next time you do a minor change.
If a tool is broken, it's good to know from any source. But how many webcases from "freeloaders" - students or otherwise - are truely tool errors and not a user issue? (I don't consider students as freeloaders but acknowledge that the professor should be better informed as a first resort for problem resolution). It takes time and effort - real cost to Xilinx - to go through every webcase that isn't a case at all but instead an issue of understanding the tool or language capabilities.
Why should I expect even an hour's worth of a Customer Application Engineer's time if the only person benefitting from the time is me? Not some company I work for now or in the future, not Xilinx, but only myself.
If I have a problem with a fireplace insert I bought, I can call up customer service to enquire about getting the fireplace insert replaced. I can't expect extensive help on figuring out how to properly burn wet newspapers. If I already know how to burn wet newspapers or can get the proper information elsewhere, more power to me. If burning wet newspapers means selling hundreds more fireplace inserts, it could be appropriate for the manufacturer to spend some time and resources (money) helping me out. Just because I bought the product doesn't mean I deserve development support.
I do. It's good. But I try to run my stuff through Synplify as well. The code should compile cleanly in XST, ModelSim, and Synplify, just like C++ should compile cleanly in vc, bcc, and gcc.
And if it's a wacky bug I go to Synplify first - it's better at showing me where I have tried to be clever ;-)
Unfortunately, there is no way of not using ISE back-end tools when working with Xilinx devices. You can replace XST synthesis with 3rd party, but not map or par.
Not every part of a business is a money making enterprise, so it's a bit of a false argument to claim that they shouldn't accept reports from 'freeloaders' (my word) because it might cost too much money.
Yes, that happens. There are all sorts of problems like that; at the company where I work, there are countless hours spent tracking down problems which turn out to be bad RAM in the customers computer. There are countless other hours lost tracking down a problem with the software, to have it turn out they supplied the wrong core file.
Generally, it's pretty easy to determine who's reporting a legitimate error, who's trying to get hints on their homework, and who is a newbie, and that doesn't really take much time.
This can also be mitigated by having a good front end for categorizing issues the the product: Select product. Select type of problem. If your problem isn't shown in the selection list, then you're in the wrong place.
But, what I'm talking about is absolutely legitimate errors: internal crashes with assertion failure information, language constructs which are handled incorrectly -- with simple test programs which demonstrate the error. When the 'freeloader' is willing to do all the work for you, except actually fix the issue, it's pretty cheap to listen.
When a legitmate defect is fixed, the whole world benefits.
No, you've lost me - _where_ does it state it is not a 100% complete tool ? and where does it state that you are dreaming if you expect "XYZ to synthesize correctly in XST" ?
What you are saying may well be Xilinx corporate policy, and the WEB merely the PR spin of the nastier reality, but it is hard to believe a company would be that short sighted.
No one from the XST SW team has commented yet - well, at least not on this forum/thread ;)
Reality is that Xilinx tries to be 100% accurate and complete. Even mainstream synthesizers can't guarantee 100% for everything even if they have tried to achieve that goal. XST will probably not produce intustry-best Quality of Results since it's not their focus. They will not support all new language features *as quickly* as mainstream synthesizers because that's not their focus. If you want optimizations based on pipelining in inferred multiplers, chances are they DO have good support because their focus DOES appear to be the support of new technology elements.
I have heart that XST's VHDL is lagging behind Verilog in robustness, probably a main driver behind the extreme opinion of the free tool that started this thread.
I like that XST is available. I use SynplifyPro to have a stable, well supported design flow geared towards solid QoR. If I come across issues using XST - at home, for instance, where I don't have Synplicity tools - I expect to work around those issues as I work around all other bugs. If I came across a synthesis problem in SynplifyPro, I'd feed back to the CAEs what the issues are. For XST I'd tend to work around the issues myself and not bother the company that supplies us with 10s of thousands of FPGAs each year. Yes, the synthesis tool could use improvements. It's just not their focus.
"Q: How extensive is XST language coverage? A: With each release, XST is closing in on the de facto coverage set by other synthesis tools. Xilinx estimates the current language support covers at least 95% of the constructs supported by other synthesis tools. Many of the unsupported constructs are infrequently used or have simple work-arounds. Also, many of these constructs are not handled consistently by each synthesis tool. For example, one tool accepts a construct in one way, another tool accepts the construct in a different way, and a third tool flags a parsing error. In some cases, XST is more precise than other tools, and requires exact, complete descriptions while other tools accept incomplete or vague code. These are common considerations when moving code from one synthesis tool to another."
This was written in 2001, and I am told that we are much better now, but still not 100% of what is covered by the commercial tools.
As for the software group, they have contacted me. And we have talked this over.
They are very proud of their tool, and find this thread troubling. They would not characterize their tool as "experimental," but as a world-class synthesis tool, examining limitations that other tool vendors have. Their tool provides value to many (most), and is probably more widely used to synthesize logic from HDL than any other tool.
In a previous position at Xilinx , I provided customer support for four years. I agree that with enough experience, you get a feel for who is a student, who is coming to you without doing due diligence on their given issue and those who have. Never, do we put less emphasis on an individual using WebPACK as those who have paid. Granted we do not support students, but they do have resources through an MIT forum to obtain assistance. I will even go as far as saying that we take the 'small' guys problems as seriously as the 'big' guys (at least I did).
You are correct that everybody benefits from submitting a case and supplying a simple testcase that exhibits the crash, error, bogus warning, etc. This is the only means that we have to reproduce the problem for SW developers. Sometimes it turns out to be bad RTL and sometimes it is a bug on our end. I used to meet weekly with the FPGA Editor developers and can say that they took bugs very seriously. We were generally able to provide a workaround or tactical patch for a customer.
That said, XST is a much different and a more complex tool. While I have not worked with any of the developers directly, I have been on the sidelines and can say that they take bugs in their tools seriously too. So while you may get frustrated (and perhaps with good reason), I would encourage you to send those Web cases in and keep the test cases coming.
No, this is not the official Xilinx position. XST is critical to our business and we have a strong, dedicated team working on it. In addition, there are tens of thousands of happy customers using XST in real designs. We work very closely with our Synthesis partners (Synplicity and Mentor) and usually recommend that customers have access to more than one synthesis tool because no one tool works the best for all designs.
Yes, we realize that there are some language support issues and we are working on addressing them. Most have pretty easy workarounds and the ones that don't get prioritized higher for being fixed.
The web page Austin refered to is at least 5 years old and I am personally going to make sure it is changed to reflect our current position.
Regarding why students cannot enter webcases, I believe this the main reason: We are using the professors to filter out bad coding techniques and questions like how do I create a state machine or how do I design a chess game in an FPGA.
Thanks Steve, - can you comment on the relative effort/quality of the HDL branches for VHDL/Verilog/Abel(CPLD), and the long term plans for the XST Simulator (relative to Modelsim et al ) ?
I have been a xilinx user for about 16 years and would like to comment on this and the companion threads.
The early xilinx software was beyond awful. You had to reboot the computer after each run--if you were lucky enough for it to finish.
By ISE6.3, the system was pretty good and I was happy with it. Since then, it has been mostly downhill. Version 7 was a major step backwards and whoever did the programming clearly never used the system. It became very slow and very ackward.
For me, versions 8.1, 8.2 and 9.1 are disasters which will not process my designs. I have some legacy schematic designs which I am converting to vhdl. Version 8.1 just blew up on them. Version 8.2 would import the project but the horrible memory leaks blew up the computer before it would finish xst. Version 9.1 was the same. So there were three releases and 10 service packs which did not work.
The software testing now seems to be that if it compiles that is good enough. It is clear that they have not tested a schematic program for around two years. I have been told that they expect things to work in version 10.0 next year.
All of that said, I think xilinx deserves some slack. When it works, ise is really quite good for the price. It is slow and has issues but it lets you do a lot. Xilinx has also been responsive (but generally not useful) on webcases. The suport people seem to care but they do not get the support they should. I will say that, after an earlier thread on sofware issues, they made an attempt to make the schematics work. They sent me some fixes that helped enough on the memory leak to uncover two other fatal bugs. The first is that xst attempts to use the .ucf pin assignments on all the submodules and blows up because, of course, they do not have the pins of the top module. If you get rid of the .ucf file and let it do what it wants, it blows up on the other fatal bug in that it does not know how to find libraries. I do not know what other bugs there are but from this, it is obvious that they never actually tried to process a schematic design.
I am optimistic that things will get better. Perhaps this is a try to get me to convert the designs to vhdl sooner rather than later even though I am an old man who really prefers to see the design than to wade through pages of code which one writes hoping that vhdl will see it your way and instantiate what you want. In schematics, you put in what you want and there it is. All the threads on "why does vhdl give me latches instead of flip-flops or distributed ram instead of blockram etc" seem odd to me.
I also would like to say again that I appreciate the presence of the ever enthusiastic Austin and the ever patient Peter on the newsgroup.
The effort going into VHDL and Verilog is about the same. ABEL is in maintenance mode so only gets attention when serious bugs are reported.
There seems to be an infinite number of things our users can implement in an FPGA so it's impossible to find every bug. However, less than 15% of the map and par bugs are found by customers and we continue to try to lower that number.
In 7.1i, we replaced our database and took a hit for map and par quality. Since then, we have improved considerably, and have made quality the highest priority for 9.1i and future releases. Other priorities for map and par are new device support, QOR, runtime, incremental design and partial reconfiguration.
Would you now be willing to comment on the MAP and PAR quality? To me this is a much bigger problem than XST not supporting certain aspects of VHDL. Based on experience I have learned to write my code using only a small subset of the language, which is supported for sure.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.