The Federation Needs A Taxonomy

Making sure that everyone speaks the same language is never easy, especially when it comes to models. But without a clear understanding of needs, nothing else makes sense.


While putting together the story about federated simulation, it brought back memories of an earlier part of my career when I spent a lot of time looking at modeling abstractions and simulation frameworks.

In the mid-1990s, the notions of re-using pre-designed blocks of IP started to become popular, but the fledgling industry was in disarray. Every IP block had a different set of deliverables, different interfaces, different levels of verification, different terminology — different everything. The Virtual Socket Interface Alliance was formed to try and bring the industry together, and I was recruited to become part of its system level design working group.

One of the issues we dealt with was terminology, and modeling terminology in particular. We picked up a document that had been produced by the DARPA Rapid-prototyping of Application Specific Signal Processor (RASSP) program, itself being derived from many previous bodies and organizations. They wanted it to define the various types of models that could be written in VHDL, and given that this was to be the mandated language for all military projects, they wanted to ‘concisely and unambiguously define a terminology that describes the models that are used within a RASSP design process.’

The important thing about that document was that it graphically separated various aspects of a model, such as timing accuracy and data accuracy. They also acknowledged that for some models, the internal accuracy and external accuracy could be different. Within VSIA, the programming level was also introduced. The axes, as defined by VSIA, are shown in figure 1.

Fig. 1: Taxonomy axes as defined by VSIA.

For example, the external view of an instruction set simulator (ISS) provides full data accuracy and loose timing accuracy, but the internals of the model bear no correspondence to the actual implementation. SystemC called this the Programmers View with Timing (see figure 2).

Fig. 2: Taxonomic view of SystemC Programmers View with Timing.

The blobs in figure 2 indicate the range or resolution for that particular axis. So for the external temporal resolution, it can be anywhere from fully accurate to instruction cycle accurate. Internally, it could be anything. The X for structural says it bears no correspondence to the actual implementation. It can accept software in the form of object code through to assembly code.

Other groups with VSIA, such as the verification group, the platform group, and the hardware dependent software group saw the success and value in the model taxonomy and created similar documents that defined the terminology associated with their work. The goal was to ensure that all members of the working group used consistent language. In many cases, those discussions served to identify their differences of opinions and future direction for the groups.

When VSIA was closed down, many pieces of the work were distributed to other standards organizations. Grant Martin, Thomas Anderson, and I wanted to ensure that the work within those various groups that dealt with definitional subjects would be preserved. It was also an opportunity to bring a lot of the work up to date and include the work coming out of new standards bodies, such as the Open SystemC Initiative.

The result was a book titled “Taxonomies for the Development and Verification of Electronic Systems“. The royalties from that book have bought me a couple of Big Macs, but digitally it is used and referenced by many students.

I am not attempting to sell more copies of the book with my blog (I think Amazon has had the same 2 copies for more than a decade), but it did fulfill part of the goal, even though it is a shame that nobody took the reins to keep it updated.

Now we are finding that perhaps it does need to be revived in some form to support this federated simulation and modeling effort, but it would certainly need some new axes that include additional aspects that are important today. This was a purely functional view of the problem, and that is not enough today. Perhaps Accellera will see the need to do this work.

Leave a Reply

(Note: This name will be displayed publicly)