|
|
Joachim Schlosser: Development and Verification of fast C/C++ Simulation Models for the Star12 Microcontroller
Note, that there are several differences in the internal, versus the external resolution. The disparity is a result from the wide range of possibilities to implement models and of Octopus to provide access to the models. The internal view here means the models as well as their interaction with Octopus, so it covers the model manager and the models. The external view means the interaction between Octopus and the simulator application. The subsequent sections will show the reasons for the particular classifications in each axis, both for internal and external view.
As mentioned before, Octopus provides cycle accurate simulation of hardware. All events are usually modeled on a cycle-base. If a CPU is modeled, the actions of an instruction are split up into their cycle components. These actions can be monitored from the outside, from the application, too. So the left boundary for the temporal axis is clear: cycle-accurate. For Octopus it is not possible to achieve a gate propagation resolution, because the time-driving value within Octopus is the clock. Although the current simulation time can be obtained using the motGetSimulationTime function, which returns hours and seconds. But the time is only a calculation from cycles and the clock frequency that was specified in the elaboration session.
The right boundary reaches to cycle-approximate accuracy. Our classification has to include this level of abstraction, because it is well possible to develop a CPU model in a way, that its state is only accurate at instruction boundaries. An implementation could be, that a 3-cycle instruction does all it has to do in the first cycle and then waits another two cycles, instead of fetching information in the first, processing in the second and writing back in the third cycle. Of course the external resolution cannot be higher, so the ranks for internal and external view are exactly the same on the temporal axis.
On the data resolution axis the internal implementation has all possibilities of abstraction, except token, so is a composite. Register values are usually stored processor-like with in defined data types, like UINT08 or UINT16. For signals we are more flexible. Of course, bit signals use the bit logical abstraction, in MVL4LogicData format. But the concept of the type-token combination allows further possibilities in data resolution. Signals can contain numbers, either processor-like, or as general values. And even properties are possible, a module could send a token in enumeration format to another module, where the enumerated property then is interpreted. In this case, the signal is no exact model of the reality, but a general communication channel. This could be used in a stage of development, where the specification already defines basic flows, but still lacks refinement. The abstraction does not reach up to token precision level, because in a software tool, like Octopus, some storage information has to be specified, software completely without storage information is impossible.
The external view’s range of abstraction levels is basically the same as the internal view’s one, but without the property precision level. A property is difficult to pass across programming language borders, there will always emerge the need to convert the property on the sending side and reconvert it on the receiving one. The actual passing will take place in a data format that is either a value or processor-like. Therefore, the external view’s lowest resolution is the value level.
The rank in the level of functional resolution in the internal view is ambivalent. Here it would be quite good to split up the internal view into another scheme, where the internal view describes a single model, while the external view describes the inter-model and model/model manager action, so the one at model interface boundary.
The internal implementation of an algorithm does not have to be the same as it will be in the end hardware, only the results have to be the same, so it can use the algorithmic processes level of abstraction. We will later see an A/D converter, where the actual value is determined mathematically, instead of approximating it step by step, like the real hardware does. Although this freedom for implementation, the model has to implement functionality in a way, that if the algorithm needs interaction with other models, that communication has to model the way it will finally be. Therefore, the external functional resolution here is set to the digital logic level. This does not mean that the external view knows the actual model implementation, but it can assume the functionality to strictly follow the specification.
The application view of the functional resolution may see functional details, but does not have to know all features on each level, therefore only partial information is provided on the algorithmic processes and digital logic level.
Octopus and the attached models describe a system either completely or partially in terms of connection of large blocks, such as ALU and register files, of a CPU and its peripherals. The interaction of all the components is well described, but the structure is not described on the full implementation level, because a model simply does not contain any information on how registers or, one level below, flip-flops are connected. Here again the situation is ambivalent. A model, internally, contains no structural information. The components are well known, but their connection is left out. From model manager view, there is some implementation information: There are the different modules and the net list describing the signals between them.
Externally, the model manager and its models may show some implementation information, like a block diagram would do, so one can obtain the netlist and the memory map, and the system can also be seen as one large block. Of course no full implementation information is available, as it simply does not exist in the models.
The level of software programming resolution depends on the kind of models. Software programming of course requires a CPU to be present. This CPU model has to support object code by nature; it may further support micro code or even assembly code for debugging. But for sure micro or assembly code requires much more intelligence in the CPU model.
Another kind of software is a stimulus file, which can be used to feed data in some signals that are attached to input ports. The stimulus can be seen as software, because models may react differently on different input data. So the data format of the stimulus file has to be ranked. For ranking let’s take a VCD file, as this is very common as file format for saving signals. The file contains several header sections: a date, a version, a comment, and information on the signals, the file monitors. The body is a series of time stamps, accompanied with information on which signals change their value at this point in time. The file is not binary, which excludes micro and object code. There are plain text sections as well as the ASCII-coded body, which can be read but not like plain text C programming language statements. So the probable rank for stimulus file is the assembly code abstraction level.
This section proved that the VSI Model Taxonomy can be applied to real model implementations to classify their level of abstraction.
