Embedded Muse 116 Copyright 2005 TGG September 20, 2005
You may redistribute this newsletter for noncommercial purposes. For commercial use contact email@example.com.
EDITOR: Jack Ganssle, firstname.lastname@example.org
- Editor’s Notes
- The Shipping News
- Review: The Design Warrior’s Guide to FPGAs
- Joke for the Week
- About The Embedded Muse
Simon Large sent along a much better reference for version control systems than the one I listed in the last issue of the Muse. See
http://better-scm.berlios.de/comparison/comparison.html . It’s a side-by-side comparison of 16 different VCSs.
Want to increase your team’s productivity? Reduce bugs? Meet deadlines? Take my one day Better Firmware Faster seminar. You’ll learn how to estimate a schedule accurately, thwart schedule-killing bugs, manage reuse, build predictable real-time code, better ways to deal with uniquely embedded problems like reentrancy, heaps, stacks, and much, much more.
I’m presenting this on two dates:
- Chicago, IL on December 5
- Irvine, CA on December 7
Want to be your company’s embedded guru? Join us! There’s more info at https://www.ganssle.com/classes.htm, including cheap flights to these cities from around the USA.
If your outfit has a dozen or more engineers who can benefit from this training I can present the seminar on-site. See https://www.ganssle.com/classes.htm .
The Shipping News
In January Australian frigate HMAS Ballarat went backwards onto the rocks due to a software glitch. This, the country’s newest naval vessel, cost some $500m. The glitch caused $2m of damage to the propellers and rudder.
As the Ballarat approached a buoy while under automatic control, crewmembers realized it would pass over another ship’s mooring line. They tried to override the computer and make a three-point turn.
The crew put one prop ahead and one astern to execute the emergency turn. With only one of three engines on-line, this command confused the computer which went full astern on both props. (I imagine the ship uses some sort of diesel-electric drive where a single engine can run both props). Though they did manage to shut down both props, by now the ship was headed astern at a couple of knots. It piled up on the rocks.
The root causes of the software error haven’t been revealed, though this sounds like a classical specification error – an omission, no doubt, the hardest of all problems to find.
But surely, for something so complex, something manned and controlled by teenagers, something that might be shot at, more robust code is needed.
Review: The Design Warrior’s Guide to FPGAs
Clive “Max” Maxfield has done it again, having written a book that’s both technically insightful and a great read. It’s a big, 500 page tome produced with large type that’s easy on middle-aged eyes with ample and clear illustrations.
FPGAs (Field Programmable Gate Arrays) are digital ICs which can be configured by an EE. Packed with thousands of logic elements, a designer creates his own circuit and loads it into the device. Some devices come with built-in microprocessors; others include micros as a sort of software component you link with your custom design.
Once an ASIC is designed and manufactured the design is cast in unmalleable silicon. A respin can cost millions. By contrast an FPGA design can change anytime. Some products even alter their configuration as the device runs.
FPGAs have changed the landscape of hardware design. Since it’s possible to change anything any time, well, in a sense the hardware folks have now inherited all of the evils of software.
The book’s first three chapters offer the 50,000 meter view of the industry, defining and describing the most common technologies. Those pages are nearly devoid of tech-speak and are suitable for the barely-technical manager. They’d make a great article to familiarize non-hardware folks with this important technology.
Max then gets into the structure of different kinds of devices and quite rightly complains about all the varying nomenclature used by different vendors. The book explains who the vendors are, both for devices and for design tools, and how the different devices are structured.
The author consistently provides the history of each development. To some this may seem irrelevant. I found it gave a context that helps explain where we are today. And some snippets are interesting. For instance, Cadence released Verilog to the public domain in 1990. According to Wikipedia the phrase “open source” didn’t surface till 1998, so Cadence’s move was quite prescient. Neat little snippets of tech history litter the margins. In 1883, Max notes, Edison and a colleague discovered the Edison Effect. Not noted is that two decades later Fleming used the effect to create a diode. In 1906 DeForest added another element – the “grid” – to create the vacuum tube, the first active electronics device. When I was a kid a TV set might contain 17 or 20 tubes, roughly equivalent to 25 or so transistors. Today’s televisions use millions.
A number of chapters discuss design flows, or the process of creating the circuit that eventually gets dumped into the FPGA. Verilog, VHDL, RTL, and SystemC get attention, along with a number of less-known approaches. Max claims 95% of the market uses Verilog and VHDL. Though he’s very agnostic to the design flow, and does compare each, more detail is desperately needed.
There are no more than a few lines of code for each approach given. In a book about programming languages, for instance, I’d expect at least a page of C++, of C, etc. This book needs a small sample project implemented in Verilog, VHDL and SystemC. As it stands one gets no real sense of the syntax and structure of the languages.
One of the longest chapters covers simulation, a daunting problem for creators of huge devices. His advice is sound.
I couldn’t understand why the chapters on Gigabit transmission and Linear Feedback Shift Registers were included. The later is one of the best descriptions of the subject extent. And quite surely many people put LFSRs in their FPGAs, But it seems oddly disconnected from the rest of the narrative.
This is a great book for someone needed a detailed *overview* of the world of FPGAs… which is possibly every EE and firmware designer. It plunges into the depths of the technology issues from time to time and then skims along the surf in other places. Don’t expect to learn to use an FPGA. There’s a lot that’s left unsaid. But you’ll get a great view of a very confusing landscape. And the writing style is so enjoyable the book never bogs down.
Recommended not for people who need to design with an FPGA in the near future, but for those who must coexist with these designers and have a sense of what this industry is all about.
Joke for the Week
The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence. (Edsger Dijkstra)
Consistently separating words by spaces became a general custom about the tenth century A.D., and lasted until about 1957, when FORTRAN abandoned the practice. (Sun FORTRAN Reference Manual)
Cobol has almost no fervent enthusiasts. As a programming tool, it has roughly the sex appeal of a wrench. (Charles Petzold)
C++ is the only current language making COBOL look good. (Bertrand Meyer)
C++ has its place in the history of programming languages. Just as Caligula has his place in the history of the Roman Empire. (Robert Firth)
Arguing that Java is better than C++ is like arguing that grasshoppers taste better than tree bark. (Thant Tessman)
Java is, in many ways, C++--. (Michael Feldman)
If Java had true garbage collection, most programs would delete themselves upon execution. (Robert Sewell)
It is practically impossible to teach good programming style to students that have had prior exposure to BASIC; as potential programmers they are mentally mutilated beyond hope of regeneration. (Edsger Dijkstra)
In my egotistical opinion, most people's C programs should be indented six feet downward and covered with dirt. (Blair P. Houghton)
C++ is history repeated as tragedy. Java is history repeated as farce. (Scott McKay)
Unix and C are the ultimate computer viruses. (Richard P Gabriel)