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
And
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).
Too often virtual prototypes are limited to being used only by hardware design engineers. So this is good that Jakob is pushing to use this for software design too, especially since it gets the software engineers involved sooner to get their feedback before the hardware design is cast in silicon.
Jakob is right in that my ESC lectures notes are sparse. While in part it is true that, as a consultant, I don’t want to give away the store, it is also in part due to time, space, and copyright limitations that ESC imposes on me. ESC has made one of my courses available online. (They charge a fee but I don’t get any of it – they own the course.) http://www.techonline.com/learning/course/210600291
In addition to the ESC courses and the monthly newsletters, I am writing a book (due late 2009) that will increase the availability of these concepts.
From what I know of the Simics virtual platform vs. the register design tools mentioned, SystemRDL, SpectaReg, Semifore, etc., the register design tools are, by design, limited to simple basics like software and hardware read/write properties. They are not designed to sufficiently model the hardware (which is what Simics is for,) nor are they designed to sufficiently specify the device driver either. However, they can be used along with Simics to provide a more efficient tool chain for register specification and virtual prototyping.
Register management tools like the http://www.Semifore.com compiler are designed to generate the RTL (Verilog/VHDL), documentation (internal and end user), and C firmware related to control and status register definitions.
These register definitions represent a working agreement or contract between hardware design, verification, software, and documentation teams: what is generated is the common subset needed to keep these groups in sync.
In the same way that engineers will still use SPICE to get more accuracy than Simics, register management tools solve a different but no less valuable problem for SOC and FPGA design teams. In fact a tool like Semifore might be extended to generate the register specifications in Simics in the same way that it can generate the address decode logic in Verilog or VHDL.
Thanks for the good comments!
I think that generating register map skeletons from a representation like a register-design tool and using them in a virtual platform implementation language like DML is definitely feasible. One thing that could make it slightly interesting, though, is the fact that register design tools specify a few select (and seemingly random) aspects of functionality. For example, r/w settings on registers, and in the case of SystemRDL, counters and interrupts. The challenge is likely to generate code that takes this into account and can still be cleanly extended, which might require some work on the part of the virtual platform as well. It leads to all kinds of interesting issues around how you mix auto-generated code with manually written code, especially when the autocoded parts change.
Also, note that Virtutech DML is also designed to tackle the different task of modeling hardware that happens to already exist. In fact, in my experience, the vast majority of a software-development platform is going to be “old” hardware — existing SoCs, processors, ASICs, PCI devices, etc., that you also have to model just to get the OS booted and drivers running. That is essentially the take in my teaching setup: extending a complete computer system with a new device or two.
So there are many ways to skin a cat (or whatever that saying is).
/jakob
http://www.semifore.com/ compiler input can accept Spirit, SystemRDL, and CSRSpec. CSRSpec has a number of modeling extensions that go well beyond SystemRDL. It might be worth a further discussion. The demark is typically at the address decode logic so you have a reasonably clean boundary for mixing “autogenerated code with manually written code.” I would assume the autocoded parts are changing in response to a specification change and would therefore need to be modified in any event. I agree that register management tools are less useful for adding new device drivers to an existing system, but if you have a customer who wants to cut time to market on a new system that has both new and hardware and software (although likely building on legacy design elements) it’s probably worth a further conversation. I would encourage you to contact Herb Winsted at Semifore.
Thanks! I will pass that on.
I am more and more liking the idea of the register design tools, as they address an issue with clean interfaces towards software and hardware. As to updating the autocoded parts, I think that is perfectly manageable by regenerating the address map bits that are then included by the actual implementation. The idea of header file + implementation file works very well for this kind of work, as long as we do not change the names of registers, as that is the crucial glue holding things together.
/jakob
Aloha!
Interesting topic this.
It is also good to see both industry wide specification standards as well as good tools for generating the API design and documentation.
Based on the Soc designs (for ASIC and big FPGAs) I’ve been involved in, it seems that everybody has developed their own register specification language – be it XML, Perl(!), CSV or SystemRDL lookalikes.
Doing the API specification/design and implementation manually takes a lot of time – time wasted since it is so easily automated. A project doing it manually 2008 have missed what has happened in the EDA and chip industry.
But 2008 focusing on developing your own API tools should also be questioned.
What I’m missing from the tools I’ve looked at is flexibility in terms of standard busses supported. That is, the API registers is what is seen by SW/Firmware as well as the application logic. But it highly likely that the connection between the IP-core and the CPU will be a standardized bus. AMBA, CoreConnect, Wishbone. The ability to easily select (and change) bus types would be the next step.
Finally I would say that finding HW-engineers that talk to the SW-engineers about how a good API looks like is waay to uncommon. It is both a question about having simple models to reason about and a question about culture. We still haven’t been able to pull down the HW/SW brick wall. Esp at larger companies where the HW and SW engineers work at different departments.
Interesting note — and I think that what we have here is a matter of a series of point solutions that do not quite add up. In my understanding, what you get is something along these lines:
So SystemRDL et al assume that you get the bus interface as well as the backend implementation from “somewhere else”. Basically, that the bus in some way manages to send some kind of addresses and data into the register decoder. But I do not work on that level, so I could be completely wrong there…
Depending on how far the tools want to get into the hw design, the type of bus it is sitting on may not be important. From a FW point of view, the type of bus is generally unneeded information. FW puts out an address and the HW does the right thing. There are cases where FW does need to concern itself with the bus but it is generally just a small portion of the FW, not something all device drivers need to worry about. So these tools should not need flexibility in bus selections but should be ignorant of bus selection.
Many of these tools provide flexibility in the type and format of files it puts out. So it could be set up to create a custom decoder file for the bus you are using.
And not just large companies, but also cases where the HW and SW teams are in different companies. One HW-only company told me about a bad experience they had because they changed the HW design without talking with their third-party FW engineer and they had to provide lots of help and support to work around it. Here is a newsletter I wrote about this subject. http://www.garystringham.com/newsletter.shtml?nid=024
Great discussion — wish I had arrived upon this party earlier.
http://SpectaReg.com, which is available over the web for immediate evaluation, goes beyond “some simple basics like software and hardware read/write properties.” SpectaReg does generate a fully expressive and Synthesizable model of the registers in VHDL and Verilog. SystemVerilog verification models for abstracting and regression testing the registers in a VMM or OVM verification environment. The SpectaReg SystemVerilog Register Abstraction (SVRA) for OVM was featured in the Q3 editions of Mentor’s Verification Horizons (see article at http://www.productive-eda.com/pdf/SystemVerilog-Register-Abstraction.pdf).
SpectaReg makes it really easy to capture the specs using a rich and collaborative web-browser based UI, so no new language needs to be learned. The details of IP-XACT are abstracted. The key is that the registers are specified based on pre-defined types that have a know behavior and are modeled in a pre-defined way in the hardware (like self clearing types, FIFO types, interrupt trees and types, RAM types, trigger types, shadow types, counters and all sorts of possibilities). With SpectaReg Onsite users can extend the types by coding a bit of Python.
For virtual prototyping SpectaReg can be configured to generate a model of the register interface (same as it does in VHDL/Verilog, but with less detail. This can target the Open Virtual Platform (OVP), Synopsys Virtio, Simics, or other similar virtual prototyping tools. Then SpectaReg’s generated register abstraction (not just a simple offset header file) can be used on the virtual processor so each register and field is accessed using methods, functions, or macros. SpectaReg’s auto-generated C register tests can be run on the virtual processor to ensure the validity of the virtual prototype’s register interface.
Since SpectaReg supports generation of different protocols from the same register spec, one can indeed switch between different protocols with SpectaReg as Joachim was mentioning (including AMBA, CoreConnect and Altera Avalon). In fact, this was done by SpectaReg.com customer Icron Technologies who moved from a CoreConnect protocol (on FPGA) to an ARM AMBA protocol (on ASIC). Read about Icron’s SpectaReg success story at at http://www.mentor.com/products/fv/success/upload/Icron-CSS-11-08_final.pdf.
Like other similar tools, SpectaReg can parse other formats too, like FrameMaker, Spreasheets, SystemRDL, and different shapes and sizes of XML using a smart data converter that is extended using some Python.
A bit of a sales pitch this, but no problem 🙂 My spam filter actually caught it for moderation. But you have some very good points to make, and I appreciate the information on SpectaReg. And I sometimes do similar things on other blogs, it is all a result of having a favorite tool that we want the world to know.
Anyhow, some comments on the comment:
There are two problems being addressed in this thread:
1. How to enter a new design
2. How to build a virtual platform of any design, old or new
I for problem #2 this set of predefined types is the main problem — we need a general programming language that also captures the actual machinery behind the facade, not just the properties of the registers. So while certainly powerful (sounds pretty close to the SystemRDL version being looked at in SPIRIT) it does not go all the way.
Note that this does not impinge on the usefulness for purpose #1, which is in many ways a nicer world to be in as you can limit the crazy things that the hardware designers are free to do else
Now this is quite interesting — how do you actually tie semantics and functionality to this? Some callback functions? For example, say you have a PCI controller that should remap memory as a result of a write to a config register: how do I get to my code that juggles memory maps on the virtual target?
Parsing these non-programming-language formats is pretty cool I think 🙂
Sorry if it comes across that way. I noticed other posters affiliated with Semifore giving sale pitches too. Register automation is something I’m very passionate about and do want to tell the world about. I believe tools like SpectaReg can really help a lot of engineering teams.
So you mean a new programming language for virtual prototyping? We’ve already got VHDL and Verilog which do a fine job for defining this at the RT level, but they are too detailed, too parallel, and simulate too slow for virtual prototyping.
I don’t see pre-defined types as a problem but more of a solution. These allow us to decouple the register specs from all implementation languages. Pre-defined types make it easy to define a contract for how the software interfaces to the hardware in a way that all stakeholders understand. All dynamic, temporal aspects of the interface are encapsulated into the register type/class. With specs defined in terms of the register types, you can generate the implementation in whatever language you desire… with whatever level of detail you desire.
Allow me to explain how I see SpectaReg contributing to virtual prototyping by way of a clarifying example.
Most systems will have some processor that is connected to a bus, with peripheral IP cores connected thereto. Let’s ignore the bus, then we can break the system into the following custom elements:
1. Software that runs on the processor (sequential)
2. Application specific logic of each peripheral (parallel)
3. Register interfaces, that sit between 1 and 2 (sequential to parallel converter)
So let’s say you are developing a virtual platform using C++ (since you want it to run lightning fast) and that your software (that runs on the processor) is done in C. You are using an ARM processor and have a C++ model of that. You choose SpectaReg for automating the registers. Given this, your development would progress as follows, with steps 1 and 2 not necessarily required if the default SpectaReg outputs suit your fancy. If they don’t then PDTi and/or customer can do steps 1 and 2.
1. define the different sub-classes of AddressBlocks, Registers, and BitField memory elements that will be used in specifying the register interfaces (or just use the defaults that SpectaReg provides)
2. define the way each of these classes are represented in your target output languages via SpectaReg code-generation templates. For virutal platform purposes, relevant outputs would be:
a) C abstraction of the registers so you can work in terms of sequences of transactions from the firmware rather than worrying about addresses and bits.
b) C++ model of the registers for peripheral modeling purposes, including access profiling, diagnostics, and debugging aspects. For each register field, this would store state and model dynamic run time behavior. There would be a well defined interface of methods and relevant callbacks for connecting the register interface to the custom C++ model of each peripherals’ application specific logic.
c) Register access tests in C, for running on the processor to ensure that a) and b) work as expected from the programmers view.
3. Collaboratively capture the specs for the register interface using SpectaReg’s web-browser UI (or parse specs in from a file), then auto-generate the dependent C and C++ code. At the same time, from the same single source, other deliverable are generated for purposes other than virtual prototyping (like VHDL, Verilog, SystemVerilog, and docs).
4. For each peripheral, write the application specific C++ to model the relevant behavior of each peripheral. This interfaces with the auto-generated C++ register interface.
5. Integrate everthing together. You now have a virtual platform for developing system software.
6. Pass the application specific peripheral models to the hardware designers, as a reference design. These can also used as a reference models for hw verification purposes.
7. Iteratively make changes to the registers as the design evolves by looping back to step 3. If the register types or register coding styles change you would loop back to step 2.
If you are using different modelling language like SystemC or DML, then just replace all mention of C++ with the name of that language.
The real value with these register automation tools is that different teams working on different parts of the overall system development, working at different levels of detail, and working in different languages can maintain synchronization with the ever-changing register specification. They can easily auto-generate their related work whenever the specs change. The coding style or bus protocol (like AMBA or CoreConnect) can eaily be change consistently across all outputs by changing the generation templates, and keeping the same spec.
@Jeremy Ralph
Sure, no problem, I work the same way.