Help Predict Robot Apocalypse at EE Live! Alumni/Alumnae Breakfast

Assuming the Robot Apocalypse doesn't kick off until after 8:00 a.m. on Wednesday, April 2, I very much hope to see you at the EE Live! 2104 Alumni/Alumnae Breakfast.

Last week, as you may recall, I mentioned that I will co-host three Gadget Smackdown sessions at EE Live! 2014. The presenters get five minutes in front of a live audience to present a few slides and describe a cool, fun, and interesting project they have finished, are building, or plan to build one day. I'm really looking forward to this, not the least because I'm going to talk about some mega-cool homemade gadgets of my own. If you are interested in presenting yourself, please email me at max.maxfield@ubm.com, and we'll get you added into the schedule. Don't delay, because this will be a first come, first served type of thing.

But we digress. The hot-off-the-press news is that I've also been invited to host the Alumni/Alumnae Breakfast, which will take place from 8:00 a.m. to 9:15 a.m. on Wednesday, April 2, in Salon 3 at the Marriott Hotel next to the Convention Center. This breakfast is for the alumni and alumnae of any previous Embedded Systems Conference (including Design East and Design West) in the US or any other country.

By "alumni/alumnae," I mean those who have paid for a conference pass to attend the formal presentations and sessions. Simply having registered for a free exhibit pass doesn't count (sad face). Also, bearing in mind that the words "alumni" and "alumnae" refer to former students (of the male and female persuasion, respectively), you aren't eligible if you are paying to attend the conference for the first time this year (again, sad face). On the bright side, if you are paying to attend the conference for the first time this year, you will be eligible to attend the alumni/alumnae breakfast at EE Live! 2015 (happy dance).

All of which leads me to the theme of this year's breakfast, which will be a lively, no-holds-barred discussion predicting the date of the forthcoming Robot Apocalypse.

I can't go into too much detail here, because the use of a homemade time machine is frowned upon in certain circles.

Suffice it to say that things look pretty dicey on a certain Wednesday morning around 9:23 a.m. (Shhh. Don't mention this to anyone. A nod's as good as a wink to a blind horse, as the old saying goes. Of course, I have no idea what this means, but it certainly makes you think, doesn't it?)

The bottom line is that, assuming you are an alumnus/alumna in good standing, and assuming you are planning to attend EE Live! 2014, and assuming the Robot Apocalypse doesn't kick off until after 8:00 a.m. on Wednesday, April 2, I very much hope to see you at the EE Live! 2014 Alumni/Alumnae Breakfast.

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?

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.