I am very impressed. I was reading about Antti's incredibly tiny FPGA project board and saw a mention of a FOSS FPGA toolchain. Not just the compiler, but the entire bitstream generation!
formatting link
Several people have built on each other's work to provide "a fully open source Verilog to bitstream development tool chain for the Lattice iCE40LP with support for more devices in the works."
formatting link
formatting link
I haven't tried any of it yet, but I am very impressed that they are reverse engineering the devices so that they can generate bit streams and not rely on the vendor.
It'll be even more kewl if it shames the vendors into being open with their bitstream specifications. I have no idea why they seem to feel this needs to be held so close to their chests.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
I seriously doubt this will ever happen. They have all done this nearly
100% of the time and I'm sure they are convinced it is the best way to do business. From what they have said their concern is that with open source tools their hardware will be subject to "problems" caused by poor tools. Or maybe they limit access to chip features through the tools which they couldn't do with FOSS tools. I seem to recall someone ranting that a line of Altera parts had some devices which were labeled as smaller chips but would load and run a bitstream for a larger part. I expect this would show up quickly and clearly if the tools were FOSS.
Those who have been in this business long enough may remember the line of parts Xilinx made specifically to support an open bit stream. It was popular with academia and a number of papers were written about researchy things you might do with it. I'm not sure what Xilinx's motive was for producing these chips, but they dropped the line and crushed the molds. I'm pretty sure there is no mention of these parts anywhere on their site now. Or did I only dream all of that?
Excellent! Though I'm not surprised it's Lattice, I vaguely recall looking through an early (pre-2000) toolchain of theirs and thinking the details were closer to the surface than with other vendors.
Indeed you didn't dream the XC6200 series. It wasn't so much that Xilinx developed them, as they bought the company that did (Algotronics or Algotronix I think, based in Edinburgh). Presumably they bought them for tech in general or possibly some key patents rather than the specific device family.
Which was something of a dead end in other respects, too fine grained (I believe' 1 gate, 1FF per CLB). Much simpler and more regular, but wouldn't scale too well to million-CLB devices dominated by routing, where the XC4000 and later devices would give the same capacity with a much smaller and cheaper die.
I think it was that simple regular structure that made opening the bitstream format attractive, as well as killing the device long-term.
You may also recall a company that successfully reverse-engineered the bitstream for Xilinx devices, and started to market their own independent toolchain.
Yup, Xilinx bought them too. But their name lives on in the .ncd (neocad) file extension.
It has been a very long time, but I don't think NeoCAD was spitting out bitstreams for Xilinx parts where they? I may not remember it right, but I thought their claim to fame was their router which did a better job than the Xilinx tools which is why Xilinx bought them. Rather than bury the NeoCAD tools and moving on, they shipped the NeoCAD tools as their main tool. They reverse engineered the routing I know. I guess it wouldn't be so hard to figure out the bit stream too.
I recall that NeoCAD was supporting other companies because they realized what a large job it was to write their own tools. So other new entries to the market used NeoCAD as their only tool. There were clauses in place to give them rights to the software if NeoCAD was bought by a competitor, which is what happened. I'm not sure that was much solace since they all ended up having to support their own software at that point which is what they were trying to get away from.
I seem to recall having the NeoCAD tools for some product other than Xilinx. It may be the ORCA devices which Lucent produced with their license from Xilinx. Not an XC4000 clone, but used Xilinx patents with similar functionality. I seem to recall they had the first CLBs where all components were not equivalent. Lattice does that in several of their FPGA lines now that they have the Lucent FPGA products and Xilinx licenses.
I recall that Altera has terms in their software to limit what you can do with the bit stream. If you want to make an ASIC you *have* to come to them. That killed a company who was providing exactly that service, bit stream to ASIC. Do all the FPGA makers do that? I would think that alone would be reason enough to reverse engineer the bit stream. That company could then produce the bit stream themselves which would retain the 1:1 relation between your verified FPGA design and the ASIC.
Maybe that is why FPGA companies don't want FOSS tools? It would take away their ASIC business. Is that very popular anymore? I haven't seen it promoted in years.
synthesis -f "spi12_impl1_lattice.synproj" synthesis: version Diamond (64-bit) 3.4.0.80
Copyright (c) 1991-1994 by NeoCAD Inc. All rights reserved. Copyright (c) 1995 AT&T Corp. All rights reserved. Copyright (c) 1995-2001 Lucent Technologies Inc. All rights reserved. Copyright (c) 2001 Agere Systems All rights reserved. Copyright (c) 2002-2014 Lattice Semiconductor Corporation, All rights reserved. Tue Jul 28 19:53:33 2015
Jan Coombs
--
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk
The Microsemi "IGLOO nano Low Power Flash" FPGAs are very similar in size and capability to the Lattice iCE40 range, except:
The basic building block is either a flop or a LUT3 equivalent circuit, and these are then grouped into 8x8 blocks. [1]
Innovation seems to come from smaller companies: as Lattice inherited the iCE40 series from SiliconBlue, Microsemi got the IGLOO parts from Actel, and the technology seen even earlier with ConcurrentLogic.
An open-source toolchain for the IGLOO parts could be an unusually powerful tool in the hands of a creative designer.
Jan Coombs
--
[1] pg 73 of
http://www.microsemi.com/document-portal/doc_view/130695-igloo-nano-low-power-flash-fpgas-datasheet
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk
I wouldn't say Lattice "inherited" the iCE40 family. That was what they bought, the rest of the SiBlue company came for free.
I don't think Concurrent Logic ended up in the hands of Actel. I know they were bought by Atmel and died a very slow death of being unfunded. I received training from the guy at Atmel who was the champion of that line. They never made an effort to keep up with process technology advances to reduce the costs. That said, I expect they knew the way to go was something more like the Xilinx/Altera routes. The fine grained architecture without routing resources just won't work for larger designs. As Xilinx used to say, "We sell you the routing and give you the logic for free."
I have looked at the Igloo parts but never been impressed. Why would an open source tool chain improve them or any other part?
Because open source tools allow exploration of techniques which are restricted using regular tools.
a) iCE40 - see rest of thread. (Note suggestion to buy 3 iCE40 sticks if using IceStorm, one or more parts might die during (mal?)practice)
b) IGLOO - because you would then be able to create complex logic without the noise or random signal states inherent in using lookup tables. One possibility might be asynchronous logic.
c) [others] no idea, unless they are close relatives of the above parts. (like ProASIC3)
Jan Coombs
--
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk
I'm not sure what this means. What "techniques" are restricted by the vendor's tools? Are we talking about techniques that are useful in a design environment or research?
I thoought I had read the thread. What did I miss? All I've seen is that there are alternative tools available that may or may not be as good as the vendor's tools. Other than not having to fight the licensing, what improvement do the alternative tools provide?
??? What logic won't the Igloo tools create? Sounds like I clearly need to avoid the Microsemi parts.
Hackability. If you have an itch, you can scratch it yourself with FOSS tools. If you discover a bug, you can fix it yourself. If you want to repurpose, optimize or otherwise change the tool, you can do it with FOSS.
That's great. But only important to a small few. I use tools to get work done. I have zero interest in digging into the code of the tools without a real need. I have not found any bugs in the vendor's tools that would make me want to spend weeks learning how they work in the, most likely, vain hope that I could fix them.
I think FOSS is great and I am very happy to see that finally happen in an end to end toolchain for an FPGA. But it is statements like this that I don't understand, "An open-source toolchain for the IGLOO parts could be an unusually powerful tool in the hands of a creative designer", or this "Because open source tools allow exploration of techniques which are restricted using regular tools."
Not trying to give anyone grief. I'd just like to understand what people expect to happen with FOSS that isn't happening with the vendor's closed, but free tools.
Same thing that's happening with compilers all the time.
Just a personal example: A log time ago I decided to make a few games for the ColecoVision console. The ColecoVision uses a Z80, and at the tie all the other homebrew game developers used an old DOS eval version of IAR within Windows. I used the free sdcc compiler. Not always being happy with the generated code I started improving it, ad later became the maintainer of the Z80 port. A few years ago I joined the group for theory of computer science at the univesity in Frankfurt as a PhD student. I found that I could apply graph structure theory in compiler construction. This resulted in some quite unusual optimizations in SDCC currently not found in any other compiler.
I think this is the point some are making. The examples of the utility of FOSS often point to more obscure examples which impact a relatively small number of users. I appreciate the fact that being able to tinker with the tools can be very useful to a few. But those few must have the need as well as the ability. With hardware development both are less likely to happen.
I think C-compilers are the piece of software were open source works best, as there is a big user base, many of them are skilled programmers. So there is both the skill and motivation to improve the product.
For software not targeted to programmers, the user base must be very large to have sufficient contributors, IMHO.
For FPGA design, the user base is much smaller than for a C compiler. How m uch of them would really use the open source alternatives when there are ve ry advanced free vendor tools? And how much of them are really skilled soft ware gurus? And have enough spare time? Of course you would find some stude nts which are contributing (e.g. for their thesis), but I doubt that it wil l be enough to get a competitve product and to maintain it. New devices sho uld be supported with short delay, otherwise the tool would not be very use ful.
Of course it could be a good playfield for students, to have a reference fo r future "real" jobs in the EDA field, but then the tool would not aim to b e really used by the average FPGA designer...
BTW: Thanks for your contribution to SDCC, we have ported it to our ERIC5 s oft-core many years ago. We also found quite some bugs at that time...
It used to be that unix always came with a C compiler, as one was required to sysgen a kernel. At one point, Sun changed to a bundled minimal C compiler, and charge for a better one. That opened a door for gcc that might otherwise not have been there.
Again, consider before gcc. I suspect that there are many times more C programmers now than in the 1980s, yet there were enough to cause gcc to exist.
People use gcc because it works well, and it works well because people use it, and want it to work well.
But one reason we have free HDL tools (from Xilinx and Altera) now is related to the competition between them. With only one FPGA company, there would be no need for competition, tools could be expensive, and there could be a significant advantage to FOSS tools.
I'm not sure the price of the tools is so much related to the competition between the companies. Hypothesizing only one FPGA company is not very realistic and it is certainly far down my list of concerns. I expect the price of tools is much more related to promoting the "exploration" of the use of FPGAs. If you even have to spend $100, that makes for a barrier to anyone wanting to start testing the tools. I ran into this myself in jobs where I wanted to try something, but couldn't get one dime spent. I can always find a little free time to spend on ideas, but spending money almost always goes through a review of some sort where they want you to show why and the "why" is what you want to determine.
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.