| Backward | Up | Forward |
|---|
The Software Model Interface (SMI) provides a user friendly environment for modeling hardware components using a combination of C++ and Verilog. Using SMI, each hardware component is divided into two parts, a hardware model (Verilog module) and a software model (C++ class). An instance of an SMI model consists of two objects, a hardware model instance (Verilog module instance) and a software model instance (C++ object), which co-operate to implement the model instance. In order to co-operate, the hardware and software model instances communicate with each other by transmitting and receiving data structures known as messages.
Figure 1(a): Structure of an SMI model
SMI not only splits models into two parts, it splits the simulation into two parts, the Verilog hardware simulation and software test processes. The hardware simulation, which includes the design under test and all the hardware model instances, runs in a single UNIX process. The software model instances run in one or more separate UNIX processes called test processes. A hardware model instance can communicate with it's corresponding software model instance using a small set of system tasks provided by the SMI hardware simulation library (libsmi_hs.a or smi.vpi). The software model instance receives, decodes and replies to messages sent by it's corresponding hardware model instance using a small set of classes provided by the SMI software model library (libsmi_sm.a). SMI uses standard UNIX sockets or CORBA to perform message communication between hardware and software model instances and hence between the hardware simulation and the test processes. SMI also provides facilities for establishing and terminating communication between the hardware simulation and the test processes and between the hardware and the corresponding software model instances.
Figure 1(b): Inter-process communications
At this point you may be wondering why SMI goes to all the trouble of creating a separate test process for the software model instances. After all, the use of multiple processes introduces the overhead of inter-process communication. The use of test processes can be justified if we expand the role an SMI model plays in the simulation environment.
Models are not just simplified implementations of hardware components. Models may also be used to apply input stimuli and collect the output responses of the design over the course of a simulation. For example, a processor model connected to the design under test via a processor bus may replace a gate level implementation to speed up simulation. It may also be used to apply test specific stimuli by generating a sequence of bus operations which interact with the design during the course of the simulation. Furthermore, the designs response may be summarized by the data output by the design during bus read operations. A complex simulation may contain many models, all independently applying stimuli and collecting responses as the simulation progresses. Some models actively apply stimuli and collect responses, such as the processor model, others may function more passively. For example, a memory model may be initialized with test specific data at the beginning of the simulation. The memory model provides test specific stimuli when it is read by the design and collects response data when it is written to by the design. However, if a model encapsulates the test specific stimulus and response data, then each verification test would require a custom implementation of the model. On the other hand, if the test process supplied test specific stimulus and response data to the software model, then the software model could maintain a uniform implementation.
A test process is responsible for co-ordinating the operation of the software model instances it supports. For example, the test process may provide a sequence of bus operations to the processor model instance or initialize the memory model. Each software model provides an interface to the test code used to communicate stimulus and response data. The test process may also compare the response data collected from the design with sets of valid responses to determine whether the design is functioning correctly.
SMI promotes a simulation environment where the hardware simulation contains no test specific code; all test specific code is written in C++ and run by the test processes. This approach reduces compilation time, disk space, and the time spent debugging the hardware simulation.
The remainder of this document in divided into three chapters. Chapter 2 provides a detailed description of the SMI libraries, their interfaces and usage. Chapter 3 presents three examples of modeling using SMI; a memory, a device and a processor model. Chapter 4 shows how SMI models can be incorporated into a simulation and used to verify an example design.
| Backward | Up | Forward |
|---|