12 ms·
Why FPGA manufacturers keep their bitstream formats secret
- fuzzieozzie 11y agoIt's simple economics --- lock in customers to buy your chips. Just like razor blades and razors.
- Qantourisc 11y agoI don't know if they realize this, but imo all they cause it having less people working with FPGA's. As a result it's not a tool people will reach to when it could be used.
- buserror 11y agoYeah, what stops me usualy plonking one in my project is the 20GB of IDE I'll have to install to have the pleasure of seeing it take /forever/ to do it's thing. However this has just changed. There is an excellent project at http://www.clifford.at/icestorm/ http://www.clifford.at/icestorm/ that has reversed the format for a series of the Lattice FPGA and provide an open source end-to-end solution... And AFAIK they haven't been told off for doing so. I therefore have one of their USB stick evaluation board on my desk to have a play with as soon as I can. They also have 'hacker friendly' packages.
- swiley 11y agoI bought one and definitely recommend it. I played around writing a brainfuck machine in verilog to learn it and it's very different.
- coderdude 11y agoIt's not the bitstream format that is stopping you. It's the comprehensive tooling in this field that is not open which holds you back. Bitstream formats are nothing. It's like not having access to GCC but complaining to Intel about their microcode. There is so much more to the process of creating something useful with an fpga. Worrying about open bitstream formats is like worrying about Intel not disclosing how their microcode affected a single chip. It's not useful for much beyond a single chip, in the same way that many cpus in a family have different microarchitectures. The most useful tools in fpga dev have little to do with the part of translating the Verilog/Vhdl into something the fpga understands. Just going to add this: I had to install VMware (on OS X) and load an Ubuntu ISO just to play with Xilinx's tooling. I dev on win, Ubuntu, and OS X. Primarily Ubuntu. But just a heads up to anyone reading this that can positively affect this: if even I am on a Mac, it's time to expand your offering.
- sklogic 11y agoYou need a synthesis tool - and there are open source alternatives. You need a cell library - a direct derivative of knowing a bitstream format. You need a place and route tool - as soon as format is known such tools would appear (as it happened with ice40). You need timing analysis, probably the hardest piece for community to produce without having an insider knowledge enjoyed by the vendors. All this stuff, including the libraries, can be pretty compact. There is no justification whatsoever for the ISE and Vivado bloat. The essential tools should be very compact. There are multiple copies of a microblaze toolchain, for example. WTF? I need none exactly. Zero. Nil. Stop bundling all the crap, please! Put it in a separate package so everybody could happily ignore it.
- coderdude 11y agoMany of the tools are command line. A few do require Gui to be useful. I absolutely agree that there is no need for the 8-10-20gb downloads that people endure to get this functionality. It's great to hear an experienced dev add to this discussion.
- nickpsecurity 11y ago"There is no justification whatsoever for the ISE and Vivado bloat. The essential tools should be very compact. There are multiple copies of a microblaze toolchain, for example. WTF? " That they were trying to include or support most of their devices or use cases in one distribution was my guess as to the reason for the bloat. Thanks for confirming it. I'll add that they'd do even better writing it in a LISP or ML-like language with macro's plus efficient compiler. The code would be readable, robust, efficient, and take no more space than necessary.
- sklogic 11y agoThey already wrote all of their GUI in a nice and compact Tcl. Still such a bloat. Cadence is using Lisp extensively, and their distributions are also not very small and are hard to maintain.
- CamperBob2 11y ago"Customers will damage their FPGAs with invalid bitstreams, and blame us for selling unreliable products." This used to be true when FPGAs had internal tristate resources (so you could drive the same net from competing sources); this is no longer the case for modern devices. I agree that this is a bogus argument -- nobody would blame the chip vendor for damage caused by a third-party bitstream -- but I don't see what it has to do with tristate logic. The only thing keeping me from shorting out two (or two thousand) ordinary CMOS drivers with an assign statement is the toolchain, isn't it?
- duskwuff 11y agoSome older FPGAs, such as the Virtex 2 Pro series, had internal buses driven by tristate buffers. The responsibility was on the designer to avoid enabling multiple drivers at a time. This is no longer true of modern FPGAs. There is no way to create a signal that is driven by multiple sources; the structure of the FPGA guarantees that any net will have exactly one driver.
- DigitalJack 11y agono virtex fpga had internal tristates. they had tbufs which were muxes that emulated a tristate bus.
- duskwuff 11y agoAh, you're right. I believe that was put in place to emulate the behavior of real tristates in some older devices, though?
- michaelt 11y agothe structure of the FPGA guarantees that any net will have exactly one driver. Interesting - I didn't know that! Could you link to a schematic so we can understand how the gates are connected to achieve that?
- pjc50 11y ago
- c3534l 11y agoSo then if none of those things are true, wht do FPGA manufacturers keep their bitstream formulas secret?
- Aissen 11y agoLawyers. Semiconductor/IP vendors are afraid of anything weakening their IP and patents. This is most of the time not true, but they'd do anything to protect their IP, even if it undermines the business.
- StringyBob 11y agoSadly true. Security by obscurity doesn't work for encryption, but a bit of obfuscation is very good at fending off opportunistic patent trolls. I expect the potential lawyer cost is more than any lost business (see also binary blobs vs open source).
- nickpsecurity 11y agoA hardware guru I know practically specialized in this where they were constantly obfuscating products and R.E.'ing 3rd party stuff they needed to make sure it worked right. He also said his company, in Asia, refused to do business in U.S. due to patent suits. There was plenty money to be made elsewhere with less legal liability past people cloning their products. Hence, his obfuscations.
- sobkas 11y agoVendor lock-in? Because there is no better(sarcasm) strategy in business, than chaining your clients to your toolchain?
- userbinator 11y agoBitstream formats are probably the worst-kept secret in the industry. FPGAs are inherently very regular in structure, so figuring out which bit goes where is pretty trivial. Try to disclose what you find in public, however, and they'll quickly send their lawyers after you... From what I know, this is the only public effort that's remained up so far: http://www.clifford.at/icestorm/ http://www.clifford.at/icestorm/
- rkangel 11y ago> FPGAs are inherently very regular in structure, so figuring out which bit goes where is pretty trivial. That is ignoring all the complexity that makes modern FPGAs what they are. Three different variants of LUTs, on board block RAMs, Hard IP blocks, or even a whole ARM subsystem. Even your quoted article says that the reverse engineering was possible because "There are not many different kinds of tiles or special function units". The interfaces to all of these are complex and change regularly as they release new variants. You might, with the right team, and after many many months of effort work out most of what you need to program one of the simpler Altera/Xilinx devices. But they're a moving target. The best analogy I can think of is that every month ARM releases a processor with some changes to the instruction set. Tracking that with an open source compiler if you DID have documentation would be hard enough.
- sklogic 11y agoLuckily, there is an ARMARM, which can be parsed and translated into a plausible compiler backend automatically. Pity that FPGA vendors do not have a similarly regular documentation format.
- mdaverveldt 11y agoHave you got a source on ARMARM? Google and HN are coming up empty.
- sklogic 11y agoYou must register with ARM in order to get it (it's free, AFAIR). http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.architecture.reference/index.html http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....
- michaelt 11y agoI always assumed it was because, when you make an interface/API public (by documenting it and offering it to your customers) you have a professional obligation to keep it reasonably stable. People get understandably upset when APIs for things like twitter and facebook keep changing under them, making things that worked before stop working. Making the bitstream format a public API would make it harder for them to change/update/improve it without making themselves look like assholes for breaking third party software.
- nickpsecurity 11y ago"Making the bitstream format a public API would make it harder for them to change/update/improve it without making themselves look like assholes for breaking third party software." That's an interesting point. I think you're the first person I've seen make it. Customers work ends at RTL level mostly so I don't see this as a real issue. Especially if customers are told not to depend on bitstream staying same from device to device.
- sklogic 11y agoIf they want to keep the bitstream format closed for some deranged IP reason - ok, fine. Just document all the cells (they do it to an extend anyway) and provide a readable format for a placed and routed layout. This way the entire toolchain can be open source, keeping only the bitstream packer closed. Lawyers are happy, users are happy - win-win.
- sobkas 11y agoBut then you could potentially change fpga supplier by only replacing bitstream packer, why would vendor allowed that?
- sklogic 11y agoCell libraries would still be incompatible. Your only possible portable layer is still RTL (with a lot of effort), exactly the same thing as with entirely closed toolchains.
- nickpsecurity 11y agoGood point. There's still a potential loss for them if that final synthesis phase creates a performance or energy usage advantage for them. I haven't seen any experiments to find out. I do know, outside of device characteristics, they mainly compete on how well their EDA tools utilize them.
- nraynaud 11y agohow far are people in reversing the bitstreams? I'm thinking maybe I should choose an FPGA and try to raise money on kickstarter and spend one year on it.
- plaes 11y agoLattice iCE40 is documented [1] and it has fully open source development tools [2], [3] [1] https://github.com/cliffordwolf/icestorm https://github.com/cliffordwolf/icestorm [2] http://www.clifford.at/yosys/ http://www.clifford.at/yosys/ [3] https://github.com/cseed/arachne-pnr https://github.com/cseed/arachne-pnr
- nickpsecurity 11y agoDo a Spartan-6 and a Virtex-6. Use the tools I linked to in my main comment where possible. Would be very useful given their price, performance, and lots of info on them.
- davexunit 11y agofpgatools is a project for reversing the Xilinx Spartan family FPGAs. https://github.com/Wolfgang-Spraul/fpgatools https://github.com/Wolfgang-Spraul/fpgatools
- jacquesm 11y agoSo, who will set up a transparent FPGA manufacturing company with old tech that will then prove all these companies wrong by capturing the market? FPGA manufacturers keep their bitstreams secret because there is no real demand for openness. The customers are happy with the product, they are applying the chips and they work. Outside of the tinkerer world there exists a vast realm of industry where access to the bitstream format would be a nice-to-have but not a must. If it were then a manufacturer would surely take the lead in this and capture the marketshare of the others. For tinkerers and open source proponents this is of course a less-than-ideal situation, we'd like to see that bitstream documented because then we can make tools operate on them and that generate them. But for the vast majority of the customers (some exceptions do exist) this is not a big issue. The most heard complaint is that the toolchains are cumbersome, slow and too large, not that the bitstreams aren't open (funny though: those toolchains would be fixable if the bistreams were open...).
- tachyonbeam 11y agoWhat's sad is that not only could the tools be made better, an open bitstream would allow applications such as using FPGAs for general-purpose computation. There's a huge market to be had there, currently being completely overtaken by GPGPU. The FPGA vendors are just not realizing the opportunity they're missing. They're more interested in protecting their "IP cores".
- lfowles 11y agoOpenCL implementations exist for FPGAs, I'm not sure what you're getting at?
- nickpsecurity 11y agoThat's like saying for CPU's, "Who needs to code at assembler for performance when Java and its threading model are available?" Two very different levels of abstraction and capabilities. Best results out of FPGA's are done by hardware designers using hardware tools that map to lowest levels.
- loginusername 11y agoTo summarize, there exists at least one person who wants to write their own tools, or at least use open source tools. For at least this one person, downloading closed source software from the chip manufacturer is not satisfactory. The comments also add that these downloads can be on the order of 8-20GB. Has anyone ever wondered what is in those large binaries? Does someone think the larger size somehow offers potentially more IP protection? Does the FPGA utilities world have anything like teensy_loader_cli? It's about 28k. Not limited to MS Windows. Works with both BSD and Linux.
- nickpsecurity 11y agoThey're huge because they have to support a lot of stuff from hardware devices to synthesis to verification. Probably legacy issues in there too. It doesn't help that every part of hardware development is Mega-Hard: http://fpgacomputing.blogspot.com/2008/08/megahard-corp-open-source-eda-as.html http://fpgacomputing.blogspot.com/2008/08/megahard-corp-open... Each aspect of synthesis, equivalence checking, testing, etc has whole MS's and PhD's dedicated to it. I'm sure the result can be a lot smaller than 20GB but it's still going to be incomprehensible by one person except in pieces. And that person has to be an expert on every aspect of hardware development from digital to analog to the wires that make up the gates. Like major OS's or software, you're always going to be taking someone else's word that a huge chunk of it's safe. Might as well plan around that.
- duskwuff 11y agoIn Xilinx's case, the toolchain is huge because it isn't just bitstream synthesis; it also includes: * Simulation and verification tools * Licensed IP cores for a bunch of common tasks * Toolchains for at least three different platforms (ARM, Microblaze, PowerPC) * 32-bit and 64-bit versions of everything * A JRE Bottom line is, there's legitimately a ton of stuff in there.
- nickpsecurity 11y agoScrew the formats: build your own. There's all kinds of bright people doing hardware development in college with top EDA tools and cheap prototyping through eg MOSIS. One already did a FPGA architecture on 45nm: http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-43.pdf http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-43... Anyone wanting to see more projects, info on what developing open HW will take w/ potential paths, and so on can follow my links here: https://news.ycombinator.com/item?id=10468898 https://news.ycombinator.com/item?id=10468898 Anyway, we have most of what we need in terms of tooling. It's just going to be a huge loss getting the initial I.P. built and ASIC-proven on each process node. Best route is academics w/ professional support each doing a piece of key I.P., using grants + discounts to build it, and then public domaining it. So, who knows a near billionaire who wants to change the HW world for the better? And who can fight patent suits?
- dkarchmer 11y agoIt is not the bitstream per say that you want, but the full description of the Device Database (defining every programmable switch in the FPGA). Somebody asked why are FPGA EDA tools so large. Well, this is the number one reason. So, at the end of the day, the real reason why FPGA companies don't open source their bitstream (and as I said, the actual database) is simply because it will be a major undertaking for them to document in any way that will actually make it possible for the community to use. An FPGA is NOT a processors so it not as easy to document as documenting an instruction set. So, very hard to do, and not enough of a business justification to do so (combined with old school management that don't really understand the value of open source). That is it. BTW, it will actually be relatively doable to document the basic Logic Cell, but the problem is that in today's modern FPAGs, the logic portion is a relatively small portion (when considering complexity) compared to the very complex I/O interfaces. I think the best you can hope for (and what I believe both X and A are moving towards) is a more flexible tool flow, and heavy use of technologies like Partial Reconfiguration, which should allow you to build lots of tools and simply use the FPGA tools (mostly P&R and Timing Analysis) as "smaller" black boxes, while allowing open source or third party to build higher level system integration tools (which IMO, is what is more needed today).
- nickpsecurity 11y ago"So, very hard to do, and not enough of a business justification to do so (combined with old school management that don't really understand the value of open source). That is it." I think this is your best argument. I believe one of the Big Two did open-source a large aspect of their FPGA's or software a while back. Maybe the bitstream. Nobody cared and they didn't make more money. So, they have no incentive to do that plus negative results that will probably happen.
- hornd 11y agoWhile I never worked directly with dkarchmer, he was a pretty well respected director at Altera. I value his opinion here highly (not to mention it makes sense).
- gozo 11y ago
- badsock 11y agoHere's my official prediction: there's going to be a sea change in the FPGA market in the next five to ten years. The reason FPGAs are so complex is that more than half of the die space is given over to the routing structures. This means that to be even in the ballpark of ASIC performance they have to have a complicated mish-mash of logic tiles and all sorts of other special-purpose tiles (like arm cores etc.). The die space issue is an artifact of using SRAM to store the configuration (likewise using flash is also too big and cumbersome), not to mention the power usage. However, the new non-volatile memories coming up (like memristors or nano-ram) are absolutely minuscule and will have a dramatic effect on the competitiveness of FPGAs. All the sudden you can have an extremely regular structure, with no specialized tiles, with performance comparable to ASICs. In fact, there's an argument that they will outperform ASICs because as we start getting into quantum effects because of die feature shrink, being able to function despite a relatively high degree of errors (which FPGAs can route around with minimal performance loss) will become a huge advantage. Here's a paper that talks about it: https://www.ece.ucsb.edu/~strukov/papers/2006/Worldcomp2006.pdf https://www.ece.ucsb.edu/~strukov/papers/2006/Worldcomp2006.... [PDF] The very regular structure of the iCE40 is quoted as a reason for its choice as a reverse-engineering target - this helps a great deal with the tooling issue. If the above prediction is true, then FPGAs can potentially be: extremely regular, on par with ASIC performance, and potentially cheaper to produce because of economies of scale. These factors will, I believe, change the dynamics of the market to a point where an open source FPGA is a viable option for crowd-sourcing.
- nickpsecurity 11y ago"The reason FPGAs are so complex is that more than half of the die space is given over to the routing structures. " That premise doesn't seem to be right. The routing adds overhead but that's not the real complexity. FPGA's have always been about trying to get more performance and flexibility at the same time. So, instead of simple structures and symmetry, the FPGA's have all kinds of things on them ranging from complex logic units to MAC's to processors to accelerators. This creates difficulty for both OSS and commercial EDA tools in efficiently handling them. Customers want this stuff, though, because it lets them get more done with less or acceptable amounts of money. The open or simpler alternatives don't. So, the market won't shift to them. If anything, like with OS's and smartphone SOC's, the barrier to entry will only grow with those accepting something open or simple being a niche market. Note: Lattice iCE40 is already serving a niche market. So, it fits my assessment.
- davexunit 11y agoWe really need a fully free FPGA toolchain. I am particularly interested in liberating the Xilinx CSG324 chip that was chosen for the Novena. I have heard that it is possible to fry the chip with a bad bitstream, so this baby step[0] is all I've managed to accomplish. The fpgatools project is messy, but the only project I know of that has figured out the bitstream format for a closely related Xilinx FPGA model. I even wrote some Scheme code that could produce the exact same bitstream as the example fpgatools program using a little domain-specific language... if only it could run on my FPGA. Others note that the bitstream format is only a small piece of the puzzle, and while I agree, I don't yet care about the HDLs and all of the tools built on top. Just figuring out the bitstream format for more FPGAs would be a huge win and would enable a free toolchain to be begin to be written. [0] https://github.com/davexunit/fpgatools/commit/06e95c379cefd9c8e21dad44747109e9095cc5b5 https://github.com/davexunit/fpgatools/commit/06e95c379cefd9...