Many engineers today have Linux on Desktop as main-OS. Many engineers today use Open Source products because of their quality, stability, and configurability.
Today I see no alternative to use Xilinx or Alteras Web Packs. Both are in a very sad state. As Linux or PowerPC user you cannot develop your FPGA design with this tools. On x86 or on Windows they are very buggy, slow, and unproductive as well.
So, any idea, how can we change this situation? Will we meet the time of Open Source development tools for programmable logic devices?
Hmm, yes, but your many is still a tiny %. Other are more pragmatic: as long as windows does not get in the way, they tolerate it.
Full end to end flow tools, probably never. Xilinx and Altera's engineers are not inept nor incompetent (tho yes, sometimes users can wonder..) - a large part of their problem is the continually moving target of their silicon.
Now, if large teams of SW designers, working with in-house correlation between the Silicon designers, and the SW crew, struggle to achieve quality, how are OpenSource teams, without that link, going to achieve - well, much at all ?.
That said, there is plenty of scope for opensouce+FPGA. opencores / Lattice Mico8 / Mico32 are all examples.
Others are working on various HDL/Sim alternatives, but back end tools like Map/P&R ? - rather less likely, until the pace of change slows down.
Plus, the vendors give free tools, so there is not the price, or sponsored, incentive other open-source targets have.
There probably is scope for users to co-operate more with the vendors, in raising Sw quality.
Yes... free tools... with large minimum quantity provisioning contract for anything besides economy/entry-level parts - Quartus Web/ISE Webpack only support Cyclone/Spartan FPGAs and small Stratix/Virtex devices. For small customers, the full Quartus/ISE usually costs a few grands.
While it would certainly be nice to have open-source tools to support FPGA development (more options is almost always good for those days where ISE&all keep on crashing and burning), the rather small world-wide pool of FPGA people with both the programming knowledge and motivation to build and maintain this sort of project as volunteers is, unfortunately, almost certainly far too small.
There are incentives to having independent tools such as avoiding XST/PAR/MAP bugs by replacing the whole tool chain... but the magnitude and complexity of such a project goes beyond what I believe can be expected from volunteer work. Whether or not the gains would offset the effort is a subjective matter but odds are mostly against it for the foreseeable future as you said.
Who knows, maybe some FPGA vendor will open-source their tools some day and get the ball rolling.
True, but I did notice Altera is has decided to make the Entire Cyclone III for free :
PR: "Quartus II software version 7.0 provides industry-leading performance and productivity features to support the new Cyclone III family, including the EP3C120 device with 120,000 LEs, 4 Mbits of memory and 288 multipliers?the highest-device density available in any FPGA vendor?s free software package."
Q: So how many NIOS cores could fit in this device ?
Strange... last time I looked, Xilinx provided full support for Linux as a host environment, even with the free WebPack software. True, it's only on x86. But if there was a great demand for e.g. Mac software for FPGA development, I'm sure FPGA vendors would at least think about providing it.
Personally I can't see FPGA vendors going completely open-source with their tool development - they have too much "secret sauce" tied up in their back-end algorithms. Still, it's not hard to imagine a more open approach than what we have at the moment...
This is a mix of two different things - running tools in an open source environment, and open-source tools.
For a number of reasons, it is unlikely that we will see open source toolsets that cover the whole range of FPGA design. In particular, placing, routing and timing are so tied in with the hardware, and so specialised, that there are few people in the world who are capable of writing such software that are not already working for an FPGA company. Open source is not an appropriate development model for such software.
Other parts of the toolset are a different matter. There are a number of open source HDLs, such as MyHDL or confluence, which are at a level above Verilog or VHDL. There are open source synthesisers, compilers, interpreters and simulators (such as Icarus and GHDL). There are also, of course, open source hardware designs (look at
formatting link
for examples).
When it comes to running closed source fpga software in open source environments, however, it's a different matter. Both X and A toolkits rely very heavily on open source software. As far as I can see (and I'm sure I'll be corrected if I've got it wrong), Quartus is build around a few closed source binaries, a gui, a large collection of open source glue such as cygwin, perl, and tcl/tk, and scripts written in these languages. For the binaries doing the hard work, it should make little difference which OS they run on. The infrastructure, written in perl and tcl (and perhaps other languages too), Linux or another *nix would be a far more natural OS than windows. About the only part that is actually tied to windows is the gui.
What is needed for a more open-source friendly Quartus (and presumably the same applies to ISE), is two things. First, drop the proprietary closed-source kit used to run the win32 gui on linux (this is, I believe, the main reason why there is no free version of Q on Linux). Either re-write the gui using one of the many cross-platform toolkits available (such as Qt, GTK, or wxWidgets), or make the gui run with wine or winelib on Linux (that would avoid major re-writing). Secondly, drop the requirement for particular distributions, and replace it with a simple requirements for minimum versions of the infrastructure like perl and tcl. In these days of virtual machines, it should be a simple matter to set up automated testing on a dozen different distributions, and if your code works on Red Hat, Suse, Debian, and Ubuntu, then it will work on almost anything.
Personally, I don't think there would be any benefit in the critical tools themselves being open source, and have no problem with the idea of a free version supporting the low-end families and paying for support for the high-end families. I don't do much fpga work at the moment - I do mostly embedded software development. As with most professionals in the field, I am happy to pay for quality tools - but I would prefer greater choice in how I run these tools.
I guess if more people donate more of their own time and effort to the FOSS effort for FPGAs, the situation might change. I'm curious as to how much effort you have contributed. ;-) Cheers, Syms.
I had a different impression. In the ASIC EDA world until a few years ago the Windows market share was about 0%. It is a little higher now but most of the tools still do not support windows.
Of course there are a lot more FPGA designs done than ASIC designs and the number of licenses sold/given away for FPGA tools outnumbers the ASIC licenses by orders of magnitude, but a lot of the algorithms used in FPGA tools are developed with ASIC EDA money. As an example Magma Design Automation paid something like 150 developers having less than a hundred customers. (Very inaccurate and old numbers, but you get the point.)
I soubt that the EDA user community is large enough to spin off a enough developers to get anything useful done. See for example how hard it is to get a working open source IP community together and that should be a lot easier. Other successfull Open Source projects are either a lot easier than EDA or have a marge larger user base to draw developers from.
However what can be done, is the development of additional vendor independant tools that complement the major tools as well as replacing parts of the tool chain. One example on the fringe of EDA is Octave as a replacement for Matlab. Antoher one is a recent paper on a GI workshop that show how easy it is to extend the synthesizable subset of VHDL. They presented a VHDL to VHDL preprocessor that allowed you to use more constructs in your synthesizable code than Synopsys supports. Yet another example are timing diagram editors for documentation.
Smaller projects like these are much more likely to yield high quality results than aiming for a complete toolchain. Also, they remain useful once they are not developed actively anymore. A backend tool would become useless as soon as development can not match the pace of the introduction of new architectures.
I am sure it works (I have not tried it - as I say, I haven't done much fpga work for a while), but the only "official" Altera way to run Quartus on Linux is the paid version, running on a few specific choices of distribution. Since your experience proves that Quartus runs fine under wine, what is needed is for Altera to say so, and to provide instructions and relevant install scripts for their web edition.
I have heard that the Xilinx Linux webpack uses the same commercial win32 wrapper, and that Xilinx in fact have to pay a royalty fee for each Linux webpack that is downloaded. I don't know whether this is fact or rumour - again, I hope someone will correct me if I'm wrong.
In news: snipped-for-privacy@e65g2000hsc.googlegroups.com timestamped 26 Mar 2007 03:14:11 -0700, Kolja Sulimma posted: "[..]
[..] Antoher one is a recent paper on a GI workshop that show how easy it is to extend the synthesizable subset of VHDL. They presented a VHDL to VHDL preprocessor that allowed you to use more constructs in your synthesizable code than Synopsys supports. [..]
[..]
Kolja Sulimma (I did EDA research for years)"
Hello,
Could you provide more details on this please? How does it compare to the behavioral VHDL synthesizer advertised in Petru Eles & Krzysztof Kuchcinski & Zebo Peng, "System Synthesis with VHDL", Kluwer Academic Publishers, 1998?
I'm using the Xilinx tools on Linux (but on x86, not PowerPC), and they seem to work fine for me. I haven't yet used the Altera tools on Linux, but I've been told that they work fine also.
On Linux x86 they don't seem buggy, slow, or unproductive. Well, maybe slow, but that's a subjective thing. What's the basis for comparison?
I doubt that you're going to see tools natively hosted on PowerPC, especially now that Apple has gone to x86. But Xilinx seems to take bugs and performance very seriously.
Maybe someday, but not soon. Even if Xilinx and/or Altera did make the details of the internal architecture and bitstreams public, developing a complete FPGA tool chain appears to be a task at least three orders of magnitude larger than building a C++ tool chain, and there aren't that many open source C++ tool chains.
I don't want to single out anyone in particular, but there seems to be a whole lot of relatively unfounded criticism of the Xilinx software in this newsgroup. It's true that I've found bugs in it from time to time, but I've been able to work around them, and Xilinx support has been quite helpful. I'm not aware of any other comparably sized piece of software that is particularly more robust.
I think constructive criticism of the software is worthwhile, but just saying that it is too slow and buggy to use is clearly both unhelpful and factually incorrect.
Since code compilers are relatively linear, the primary difficulties are properly parsing the code and recognizing optimizable patterns, somewhat like synthesis and mapping for programmable logic. Place&Route on the other hand is very chaotic with many startup parameters defined as random values just like neural networks... the amount of work and back-pedaling that happens behind the scene to produce the post-PAR design is impressive and there probably are only a few handfuls of people world-wide who are capable of designing such algorithms yet retain their sanity.
The ISE Navigator is a simple text editor with a few tree-views and miscellaneous eye-candy but it still manages to crash a few times per week. The Schematic editor is rather plain as well yet it crashes quite readily so I completely gave up on schematics after ISE 7.1. XST appears to have some severe syntax error intolerance and readily crashes instead of reporting the said syntax or malformed construct errors, leaving the user oblivious to the actual cause. My main complaint about PAR is extremely inconsistent runtimes for a given design... anywhere from 5 to 30+ minutes for one of my smallest projects.
ISE tools crashing instead of reporting errors (like declaring an entity inside an entity because I forgot to swap 'entity' for 'component' in a black box component declaration) is the most obscure and annoying time waster in my book, inconsistent runtimes is a close second. Most other obscure crashes I have encountered were cleared by rebuilding everything, this makes design partitioning very much pointless.
I have not played with Quartus much but building a 95% full EP2C8 on a
2.4GHz Celeron took a steady 10-12 minutes while building a 15% full V2P30 on a 3GHz P4 takes a random amount of time over 20 minutes and sometimes would not even complete overnight. Given the much higher vacancy rate and lower system clock target on the V2P along with the faster computer, I would have expected ISE to complete faster for a similarly sized design. I have tried tweaking ISE options to make builds quicker but ~20 minutes is pretty much the best I have ever been able to get for that build.
Quartus and its back-end tools have never crashed on me for any reason whatsoever over the few months I used them while ISE still crashes on me for random reasons even though I have been learning to work around its shortcomings for the last three years. If I had to pick FPGAs based on vendor tools alone, I would seriously consider focusing on Altera's... but I generally prefer Xilinx's architectures so I really wish Xilinx would catch up in back-end maturity/stability... without sacrificing even more wall-clock performance.
I haven't had a crash in Navigator in perhaps 1000 hours of using various releases. I have had other ISE tools abort with internal errors.
I've never used the Schematic Editor, so I can't comment on its quality (or lack thereof). It's clear that HDL support is a higher priority for Xilinx than schematic entry.
I used to see that in 7.x, but haven't seen it much in 8.x and 9.1. Maybe 7.x trained me not to do things that it didn't like.
Although it is obviously desirable for a tool to provide a good report of a syntax error rather than crashing, I'm much more concerned about ensuring that the tool does not crash for valid input.
I haven't experienced that much variation; I've only seen about a 2:1 range. However, I'm not convinced that expecting consistent timing is realistic; a small change to your input may cause a siginficant difference in the routing difficulty, especially if you have tight timing constraints.
The bulk of these crashes happened when I (mostly accidentally) click ERROR or WARNING links that cause PN to open a browser tab... and when these tabs do not crash PN, I usually get no answer record for the error or warning in question.
Back then, I used schematics only to avoid having to code boring top-level VHDL port maps... but the frequent crashes and other annoyances (like zero portability) quickly convinced me that I would be better off wrapping everything up in VHDL.
An extra semicolumn at the wrong place can crash XST but these are often hard to spot since any other programming language would silently accept them. Over the last two or three years, I wasted over a month hunting down syntax-induced crashes, about a week of it last summer because XST got confused while processing BRAM inferences... it took me a few days to figure out the link between crashes and memory inferences and many more tweaking the inference until I got what I wanted without crashing XST or MAP.
The last time I ran into simple syntax errors I was unable to spot within
2-3 minutes, I simply ran the thing through ModelSim's compiler... both a fair bit faster and much more reliable.
I have two ~15% designs targeted to the same 2VP30, one has ~100ps slack on a 5ns timespec while the other has ~1ns slack on a 10ns timespec. In both cases I get similarly volatile 5-30 minutes PAR runtimes even if I simply "Rerun All" - the only thing that changes between runs in this case is random initialization values within the PAR algorithms.
Thankfully, computers get faster and the C2D-E6850 is only a few months away... that would be a substantial improvement over my current P4-3G.
My primary OS is WinXP... but for all my boring regexable copy-paste jobs, I started using remote-X'd Nedit sessions about a year ago. Regex replace is definitely a godsend for portmaps and batch portmap signal declaration.
It depends on what I am doing and why.
Until my larger designs are sufficiently advanced to start producing meaningful simulation results (I call this the approximation phase), I am more interested in tracking resource utilization and static timing evolution than correctness: achieving absolute correctness in the first pass (the one most susceptible to typos and syntax errors) is useless if the implementation fails to meet target timings or exceeds the logic budget. It is during these passes that XST&all die on me the most and Modelsim as a simulation tool is irrelevant - that's why it took me so long to think of using it as a syntax checker.
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.