Previous Section Next Section

2.1 Interaction between Specman Elite and the Simulator

Specman Elite and the Simulator are two separate processes that run concurrently and synchronize with each other during the simulation. Specman Elite and the Simulator talk to each other through an interface that includes a special file called a stubs file. The stubs file provides the primary interface for communication between Specman Elite and the Simulator. In addition to the stubs file, Specman Elite and the Simulator also communicate through mechanisms such as Verilog Programming Language Interface (PLI) or the VHDL Foreign Language Interface (FLI). Figure 2-1 shows this interaction.

Figure 2-1. Interaction Between Specman Elite and the Simulator

graphics/02fig01.gif

2.1.1 Components of Specman Elite and the Simulator

There are multiple components in a simulation environment containing e.

Specman Elite

The entire verification environment is modeled in e. This environment contains driver, checkers, coverage objects, data objects, etc., required for the verification of the DUT. All e files are compiled and simulated by Specman Elite.

External Libraries

If any legacy code or models exist in C/C++ or other languages, they can be invoked from e code. For example, if an Motion Picture Experts Group (MPEG) decoder algorithm is already coded in C++, it is easy for e code to simply call that algorithm to make comparisons against expected frames. Such external libraries may or may not be present in an e based simulation.

DUT

The Device Under Test contains the entire hierarchy for the design. For example, if a microprocessor is coded in Verilog, it will have various modules such as Integer Unit (IU), Interface Bus Unit (IBU), Floating Point Unit (FPU), etc. The DUT represents the topmost level of the design hierarchy and is typically written entirely in Verilog or VHDL.

Miscellaneous Simulation Files

These are Verilog or VHDL files that may represent legacy models, bus functional models, etc., required for verification of the DUT. For complex environments, it is recommended that all verification files be coded in e. In these cases, such miscellaneous Verilog or VHDL files will not be present in an e based simulation. However, initially, the verification engineer may choose to leave some legacy verification modules in Verilog or VHDL. Therefore, they need to be included in the simulation.

Top

This module represents the top level of the simulation hierarchy. All files in this hierarchy are coded in Verilog or VHDL. The top module instantiates the DUT and other miscellaneous verification modules. The top module also contains registers that drive the inputs of the DUT and nets that receive the outputs of the DUT. In Figure 2-1 above, the empty squares represent registers and dark squares represent nets.

Stubs File

This is a special Verilog or VHDL file that is automatically created by Specman Elite when a special command is issued by the verification engineer. This file acts as the communication channel between Specman Elite and the Simulator during simulation. The process of creating this file is very simple. All e files are read into Specman Elite. Then, a special Specman Elite command is issued to create this file. The Simulator is not required to be present to create this file. This stubs file is then included in the list of Verilog or VHDL files to be compiled by the Simulator during the simulation. This file needs to be created very infrequently.

Simulator

This is a Verilog or a VHDL simulator that runs concurrently with Specman Elite. The Simulator compiles and simulates all Verilog or VHDL files. At the top-most level, there are two modules—the top module and the module inside the stubs file. The Simulator and Specman Elite communicate through the stubs file.

2.1.2 Flow of Simulation

The following steps summarize the flow of execution between Specman Elite and the Simulator. Although we have not talked about the details of the e language syntax or Specman Elite, these steps will help you understand the basics of the simulation execution flow.

  1. Both Specman Elite and the Simulator are invoked simultaneously. Specman Elite gains control and the Simulator stops at simulation time t=0. The control is explicitly passed to the Simulator and the simulation is started.

  2. The Simulator continues to run until it reaches a trigger point set by Specman Elite on the change in value of a Simulator variable. This trigger point or callback is set by the verification engineer inside the e code. At that callback, the Simulator halts further execution and transfers control to Specman Elite.

  3. Specman Elite does all necessary computations. When all computations are waiting for the next trigger point, Specman Elite has nothing more to do, so it transfers control back to the Simulator. During this entire process, the Simulator is not executing further. Therefore, no simulation time has elapsed.

  4. Simulator continues simulation until it reaches the next trigger point. Then it repeats steps 2 and 3.

  5. Simulation continues with control passing back and forth between Specman Elite and the Simulator until a procedure inside Specman Elite requests to finish the simulation run.

  6. The results may then analyzed. Based on the results a new run can be started.

The following section describes how a verification hierarchy is created using e.

Previous Section Next Section