I just read an interesting paper from the 2004 Embedded System’s Conference (ESC) written by Gary Stringham. It is called “ASIC Design Practices from a Firmware Perspective” and straddles the boundary between hardware design and driver software development. It was good to see someone take the viewpoint of “how you actually program a hardware device is as important as what it does”. Gary seems to understand both the hardware design and implementation view of things, as well as that of the embedded software engineer. To me, that seems to be a fairly rare combination of skills, to the detriment of our entire economy of computer system development.
Gary Stringham’s lists a number of tips on how to create hardware-software interfaces. Some of them are echoed on his monthly newsletter, which is worth a read (even if it is a bit short on detail). Unfortunately, there seems to be no publicly available version of the text. Gary has definitely kept lecturing on the topic since, at venues like the ESC and DVCon it seems, but more recent lecture notes that I have found in the ESC proceedings are pretty sparse. I guess being a consultant teaching people to do these things for a fee makes you a bit hesitant to share all your knowledge freely with the world… I can understand that position.
Anyway. Some of the comments in the text indicate to me the great value that virtual platforms can bring to the actual design of hardware up front, not just as an execution vehicle for the final design, used by a software engineer who has to take whatever is given.
In particular, the issue of getting ASIC and Firmware designers to collaborate on the same thing at the same time. Quote:
The key to designing an ASIC is to get the firmware engineers involved early. They are the customers that will be using the ASIC. Unfortunately, getting them involved early is often difficult to do because the ASIC design has to start several months before the firmware engineers will get parts
When the parts do arrive, the roles are reversed. The firmware engineers are trying to work with
it while the ASIC engineers have mainly forgotten it and have moved on to new projects.
The proposed solution to this problem is to involve the firmware people in the hardware design review process, which is a good idea.
It would be even better, however, if the firmware people could have the hardware interface to try as a live thing rather than just reading the documents. This is exactly what virtual platforms offer: quickly build a fast simple prototype of the interface, and hand it over to the software engineers to try.
This is something that I am currently exploring in some detail with Simics, and that I wrote a piece about in Chip Design earlier this year. Fundamentally, I think this is feasible, provided that hardware designers do not fret too much about timing details and the precise performance of the final implementation, and focus more on the programming interface design first — and then later go on and make sure the timing and performance is right.
It is just like software development is supposed to be done: start by designing a useful interface to a piece of functionality, and then add in the details and optimize performance within the boundary of that interface. Of course, the interface might need some adjustments to support certain optimizations, but it is quick and easy to provide a new virtual platform with a new behavior to the software engineer. Much faster than providing a new piece of silicon or even new documentation.
Register design tools like SystemRDL (now being standardized by SPIRIT), Spectareg, Semifore, etc. all touch on this, but all seem to be lacking the ability to actually describe what a device does beyond some simple basics like software and hardware read/write properties. You really need a full expressive language to write a truly executable model of the hardware (and I like DML for this).