|
|
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.
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:
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:
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.
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:
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:
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].
