DrFPGA wrote: I think the issue is really the complexity in documenting the architecture and answering the many questions that would come up. If the FPGA guys thought that the support cost would generate any return I think they would happily make the investment in supporting a more open source policy...
Thank you for your reply.
If that's the issue, all a vendor needs to do is to give the community permission to reverse-engineer the FPGA architecture using the vendor's tools. The vendor doesn't have to document anything or answer any questions -- all it has to do is allow the community to do the work and publish it. For at least two architectures I've looked at, it's actually quite tractable to reverse-engineer the architecture, but you've got to use the vendor's tools to do so which is usually a violation of the EULA.
Except for an old Atmel architecture, everything I've read so far indicates that vendors do not want this to happen and are ready to sue anyone who tries. If that's not the case, I'd be extremely grateful for some links because this closed architecture nonsense has been a pet peeve of mine for decades.
Actually, there is a very significant amount of FPGA research going at the university level. They use some open source FPGA architectures to look at different algorithms and have, in the past, been included in some manufacturers architectures.
I think the issue is really the complexity in documenting the architecture and answering the many questions that would come up. If the FPGA guys thought that the support cost would generate any return I think they would happily make the investment in supporting a more open source policy...
Susan asked: Do you think it's a bad business move not to document the FPGA bit streams?
Absolutely. I've been complaining about this for decades. By keeping the bit streams closed, there's no point in anyone doing research in improving FPGA tools and languages, and the use of FPGAs for a high-performance reconfigurable computer is impractical, as described in this Geek Times article from 2007.
The excuse given by FPGA vendors is that FPGA customers are afraid that someone will steal their products, yet people ship millions of computer-based products with open machine languages. Besides, all the latest FPGA chips have bit-stream encryption or have the FPGA embedded with the configuration storage so you can't easily watch the bit stream. Are the FPGA vendors saying that this encryption is not effective?
My opinion is that closed bit-streams -- and therefore closed design tools -- have prevented FPGAs from having the success enjoyed by microprocessors. Where would Intel be if the 8080 and x86 had closed instruction sets and you could only program them in PL/M?
Maybe this will change soon. After all, GPU vendors are starting to document their architectures -- even Broadcom! A chip-maker needs to sell silicon. Preventing people from using your chips by keeping documentation closed does the opposite IMO.
Do you think it's a bad business move not to document the FPGA bit streams? Seems like a good opportunity for students to get good foundation in FPGA, as you suggest. If you get them when they're young, maybe a loyal customer is born?
Susan asked: Max, are you going to let Altera and Xilinx fall behind in the STEM Impact Award contest?
IMO, Altera and Xilinx are disqualified by refusing to document their FPGA bit streams, which prevents STEM students from really learning about FPGAs by producing their own FPGA tools or adapting open-source ones. The essence of science and engineering is looking "under the hood" to see how things really work. Where would STEM be if Intel, Motorola (now Freescale), IBM, and ARM had refused to release their machine-language instruction sets?
@Susan: ...are you going to let Altera and Xilinx fall behind in the STEM Impact Award contest?
That's unfair -- it's like asking me to choose between a bacon sandwich and a bacon surprise -- I can't vote for one without feeling guilty about not voting for the other -- I'm sitting on a horny dilemma the horns of a dilemma and it's not very comfortable, let me tell you.
NASA's Orion Flight Software Production Systems Manager Darrel G. Raines joins Planet Analog Editor Steve Taranovich and Embedded.com Editor Max Maxfield to talk about embedded flight software used in Orion Spacecraft, part of NASA's Mars mission. Live radio show and live chat. Get your questions ready.
Brought to you by