Joachim Schlosser: Development and Verification of fast C/C++ Simulation Models for the Star12 Microcontroller

The following two sections are based on the SLD DWG document [VSI99], section 2.1.

A model first of all can be viewed from two different positions: internal and external. While the internal view describes all of the structure and behavior that actually takes place within the model, the external view only sees the interface, its interaction with other models. This is a major difference, as the interface mostly is part of some sort of protocol. An interface can be described as looking at the pins of a IC package. It is well known what the purpose of each pin is, but not how the pins are processed. To get implementation details you could remove the lid off the package and look inside. This would be the internal view. You see how the interface is wired.

The most important fact to recognize in model taxonomy is that a model cannot be categorized only in respect of a single aspect, or that all aspects can be merged. The view has to be split up into several taxonomy axes, each for internal and external view.

For each internal and external there are four characteristics a model can be classified on:

The relationship between temporal and data axes is orthogonal, and so is the relationship between these two and the functional and structural. Functional and structural, although viewing from the same direction, are better to be considered on their own.

The invented eight axes – four axes each for internal and external view – do not cover the software programming aspect of a model, the appearance of the hardware model to software is undefined so far. Therefore, the set of axes is augmented with a ninth aspect, characterizing the software programming detail. This axis does exist only once, as the programming does not differentiate between internal and external view, it only sees the whole system. A complete overview of the axes and their abstraction levels can be seen in Figure 2.3 on page 32.

The figure shows there are different numbers of levels in each axis. The detailed meaning is explained in the subsequent sections.

A model now can be categorized by specifying for each axis the level of abstraction. A textual description for the content of a particular RTL model could look like this:

Internal ( | temporal=Gate Propagation, |

data=Bit, | |

function=Digital Logic | |

structure=register), | |

External ( | temporal=Clock Accurate, |

data=Bit, | |

function=Digital Logic | |

structure=I/O Pins), | |

SW-Program ( | programming-level=none) |

Easier to read is a visualization of this information. The VSIA Model Taxonomy uses a chart with all axes drawn in a matrix.

To mark where a model is located within this taxonomy, some easy symbol keys are used.

An example for resolving partial information could be control but not data values or functionality. Containing no information is also important to know, this means that the model’s purpose is not the simulation of the axis on which the X occurs.

The following sections will explain the different precision items for each axis, with the items ordered by descending abstraction level.

Temporal Resolution Axis Different models aim at different purposes in respect of temporal precision. Each model has some information about time, let it be that one thing occurs after the other by an unspecified time, or one thing occurs exactly n seconds after another one.

- Partially ordered event accurate.
- The order of events is ordered completely or partially. There is no precise information in temporal units about when events start or finish. This level is common in dataflow analysis.
- System event accurate.
- Start and end times of major system functions are measured in thousands or millions of clock cycles.
- Token cycle accurate.
- Duration for the transfer or processing of data frames is specified.
- Instruction cycle accurate.
- Information is gathered about how many instructions are needed for certain data processing steps.
- Cycle-approximate accurate.
- A system clock is invented, and it is now known how many cycle counts an instruction approximately takes. Pipeline effects and cache is not considered, therefore the numbers may differ from the correct values.
- Cycle-accurate.
- For all instructions there are accurate cycle counts present. All sub-instructions are defined within which cycle they occur.
- Gate propagation accurate
- . All events are defined in time units within clock cycles like ns or ps. The degree of accuracy of the circuit level limits the accuracy of the event timings.

Data Resolution Axis The representation format of data values specifies the position on the data resolution axis. A value could be binary 0b111, signed integer –1 or enumeration blue, the same data represented in different precision items, which are:

- Token.
- The highest abstraction level for data representation contains no implementation details. The data format is unspecified.
- Property.
- Enumerations are invented and only the values defined by the enumerations are allowed.
- Value.
- Still there are no implementation details. Values may be integer or real, but the exact representation is not specified.
- Processor-like.
- Exact data formats are invented. Values are represented in certain data formats, like the IEEE 754 for real numbers.
- Bit Logical.
- The lowest abstraction level. No data formats are present any more, the values are only 1, 0, X, Z representing high, low, tri-state or undefined.

The term *Composite* means a representation that is formed by a combination of the
above types.

Functional Resolution Axis The function of a model can be described in the following ways:

- Mathematical Relationships.
- The functionality is specified as a set of mathematical equations. No sequencing is done.
- Algorithmic Processes.
- Sequencing is introduced, to allow ordering of operations. No implementation details of the algorithms are considered, although the algorithmic processes can be decomposed to smaller portions.
- (Algorithm Implementation).
- I personally would invent this category to provide an intermediate step towards the next one. Here, implementation details of the algorithms would take place, how a certain algorithm is implemented. As this precision item is not present in the taxonomy, I will not use it to prevent from confusion.
- Digital Logic.
- Basic Boolean operators (AND, OR, NOT, etc.) represent the whole functionality. The amount of information in this level will probably be very high.

Structural Resolution Axis The information on how a component is constructed from its constituent parts can be different in detail level, which is represented by this axis.

- Single Black Box.
- No implementation information is given. The component occurs as one large block.
- Block Diagram.
- Some implementation information is given, but only the connections of large sub-blocks and those of computer networks.
- Structural.
- The full implementation information is available. All connections of simple units, of composite units and of complex units are specified. A complex unit may be an adder, multiplier, shifter, etc., whereas composite units are e. g. flip-flops and simple units only logic gates or registers.

Resolution on the structural axis is not limited, it can be as precise as wanted.

Software Programming Resolution Axis The granularity level of software instructions, a model of a hardware component interprets, defines the item on the Software Programming Resolution axis. A model could interpret data flow instructions, like vector operations or complete Fourier transforms, usually consisting of multiple lines of code. Therefore the model would be very abstract, whereas a model that interprets opcode hast a much higher resolution. The items on the axis are:

- Major Modes.
- The software to be interpreted exists in terms of major working modes, such as searching, tracking, initialization, etc.
- DSP Primitive block-oriented.
- This level can be seen as parameterized calls to complex functions.
- High Level Language.
- A model interprets software written in a high level language, e. g. C, C++, ADA or...
- Assembly Code.
- Processor specific assembly code is the base for this sort of interpretation. Usually this software level is compiled from the above.
- Micro code.
- Code in form of a set of control signals active in a certain clock
- Object Code.
- The binary form of code. This is the final representation of a program, the model takes the same input as a real processor would do.

The Software axis is important in that way that a model has to accept some sort of input to be useful. What input it interprets does affect its implementation extensively.

We have seen different aspects in abstraction of models and their nuances. Referring to this basic taxonomy, we now can classify models. Some concepts of modeling occur again and again, therefore they can be named and grouped. There are three groups:

- Primary Model Classes:
- Functional Model
- Behavioral Model
- Structural
- Interface Model

- Specialized Model
- Performance Model
- Hybrid (Mixed Level) Model

- Computational Model
- Data Flow Graph Model
- Other Models

Knowing what these model classes mean is essential to understand the benefits of the taxonomy. Therefore I will shortly summarize the properties of the model classes in the subsequent sections, pursuant to [VSI99], chapter 3.

A functional model specifies the general function of a system or VC, but does not cater for a specific implementation. For this reason it is possible to create a functional model at any level of abstraction, depending on the precision of implementation details. It is also possible to define separate input and output functional models, or models in terms of mathematical functions. The temporal axis is completely ignored, same applies for the internal structural axis. A functional model basically is a model without timing information

A behavioral model adds information about timing; the rest seems to be the same as for the functional model. But the addition of the temporal axis changes the purpose of a model dramatically. With temporal information the order of functions can be specified, constituting a flow.

A structural model is interested in the interconnections of the constituent sub-components of a system or component. The sub-components can be functional, behavioral or structural, too. With this type model a hierarchy can be created, reflecting the organization or the communication topology of components. The structural model requires behavioral of functional models in the leaf branches of the hierarchy. The leafs control the effective resolution of the temporal, data value and functional axis. Structural models are possible at any level of abstraction.

As stated through its name, the interface model only models the external view of a component for partial information on all axes. The internal view is not addressed in any way. Other terms for this model are “bus functional” and “interface behavior”. The former one can easily lead to misunderstandings because usually a bus represents a lower level of abstraction. An interface model provides the external connective points as ports or parameters as well as timing details and functional constraints. A complete interface model acts as a black box without data values and constraints, whereas partial interface models usually do not contain external data values.

In general, an interface model should implement all features of a certain level of interface specification, but not more. This includes that an interface model may also encapsulate other model aspects of the internal view. So it is even possible that the level of external abstraction is totally different from the internal one. In this case the interface model acts as an adapter between the environment and the functional models of a component, only transferring information between different levels of abstraction. One could also think of nesting interface models allowing to plug in different models, regardless of their abstraction level.

The first of the two models in Specialized Model Classes is the performance model. This so-called uninterpreted model implements internally only the temporal axis and for the external view additionally a high abstraction of data values and maybe the interface structure at some level. The only purpose of a performance model is to allow measures regarding the timeline of a system, which means the answer times when reacting to stimuli. So performance here means timing and delay characteristics.

A mixed-level model combines models of differing descriptive paradigms and therefore differing abstraction levels, so this class is sort of a wildcard for models.

The last group is the Computation Model Classes. Within this group we have the Dataflow Graph Model, considering only data values and software programming and internal function, all with high levels of abstraction. In center of interest are the inherent data dependencies of mathematical operations in an algorithm. Far away from being a normal model that can be implemented, it is a directed graph, consisting of nodes and arcs, representing mathematical transformations, respective their data dependencies and queues. The Data Flow Graph is architecture independent, as it is a formal notation supporting analytical methods, it can be decomposed, aggregated, transformed and of course analyzed. Data Flow Graphs are widely used within compilers that produce opcode for pipelined or parallel processors.

Other Computational Models Beside the introduced models there are of course a whole bunch of models that can be used. For the sake of completeness a few of them should be mentioned: Communicating sequential processes, Discrete Events, Hierarchical communicating finite state machines, Petri-Nets, Process Networks, and many others.

There are many other common models which of course all can be categorized with this taxonomy, e. g. an executable specification, mathematical equation model, token-based performance model, abstract-behavioral model, ISA model, RTL model or power model, only to mention some of them. To see all special model examples in detail, refer to chapters 4–8 of [VSI99].