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

[Next] [Previous] [Previous-tail] [Tail] [Up]

1.2.1.  Intent

The same way, a SoC is built out of several IP blocks, a simulator cannot be a monolithic engine. IP blocks have to be reused either unchanged or patched, to match a different specifications of a component of the same type. A simulation component manager that manages the models of the IP blocks and is called the model manager holds all simulation components together. Whoever starts to simulate SoCs, needs a model manager, either a self-developed or an external product. With the whole bunch of different model managers arising from this fact, and the large number of debuggers a new problem arises: A large number of interfaces between debugger and simulator, all with different structures and views, complicate the reuse of a simulator in a different debugger environment or within a different debugger. One level deeper in the simulator, the number of interfaces between model manager and models is also as big as the number of simulators.

The benefit of using Virtual Components is lost if they must be converted regarding interfaces and data formats, when integrating them into a different environment, to make them again compatible with a certain model manager. The problem is pretty much the same as it is with components in personal computer boards – different devices are combined and the function has to be tested. But there is a decisive difference: with PC boards there exists an infrastructure of standard interfaces, integration, verification and tests. So mixing and matching ICs that originate from different vendors is not a big problem at all. With VCs and system chips the situation is quite different. The infrastructure to support development and verifications of such components is not very defined, so mixing VCs from different sources and integrating them into system chips is difficult. And the system-chip industry does not only consist of the VC vendors, there are of course companies which produce the chips, others that deliver the tools, like compiler, debugger and so on. Then other companies do only the chip design without having fabrication facilities, or Electronic Design Automation (EDA) companies.

So there is the “lack of open VC-to-VC interface standards, as a base for VC development and use” [VSI01b]. Standards are needed to give the different vendors a possibility, making their products compatible to each other and if not compatible with the exact calling paths, then at least compatible in respect of structure and data flow.

[Next] [Previous] [Previous-tail] [Front] [Up]