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.

Sure, no problem, I work the same way.

A bit of a sales pitch this, but no problem

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.

…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 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 :Great discussion — wish I had arrived upon this party earlier.

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:

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.

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

For virtual prototyping SpectaReg can be configured to generate a model of the register interface

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?

Like other similar tools, SpectaReg can parse other formats too, like FrameMaker, Spreasheets

Parsing these non-programming-language formats is pretty cool I think

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.

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.

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.

Finally I would say that finding HW-engineers that talk to the SW-engineers about how a good API looks like is waay too 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.

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

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.

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…

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.

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

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

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.

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.