Backward Up Forward

2.4 Implementation Notes

The SMI libraries support inter-process communication using TCP/IP sockets and CORBA. They also support TF and VPI Verilog programming language interfaces. This section describes these options, how the libraries can be configured to support the options, and how the options may be selected at runtime.

2.4.1 IPC: Sockets vs CORBA

SMI supports two implementations of the inter-process communications layer that connects the hardware simulation to the test processes.

TCP/IP sockets are supported by most operating systems without requiring additional libraries. The communications library provided by sockets is much lower level than CORBA. The sockets implementation requires SMI to do a lot more work and is less portable than the CORBA implementation. However, CORBA is a huge piece of code, has many flavours and does not come as standard with UNIX distributions.

CORBA or Common Object Request Broker Architecture was designed to allow objects to communicate transparently over heterogeneous networks. As such, it is an ideal mechanism for implementing SMI. Functions such as establishing communications, advertising and finding models, and sending and receiving messages are either already built into CORBA or are easily implemented using CORBA.

SMI can be compiled with one or both communications layers. By default, sockets are enabled and CORBA is disabled. The following configuration switches can alter the build.

  --enable-corba=directory
This switch configures SMI to build using the CORBA implementation in directory "directory". This directory should contain "bin", "lib" and "include" sub-directories.
  --disable-socket
This switch configures SMI to build without the socket implementation.

For example, the following configuration command will generate SMI libraries that use a CORBA implementation in directory "/usr/local/corba" and disables the default socket implementation.

  ./configure --enable-corba=/usr/local/corba --disable-socket

When running a hardware simulation and test processes, the inter-process communication method and any additional arguments required by that method must be passed using command line arguments.

For example, a hardware simulation (executable simulation) and test process (executable test_process) are to communicate using the TCP/IP sockets. The hardware simulation is to run on a machine called host and the port chosen for SMI socket communication is number 2345. The following shell commands start the simulation:

  simulation +socket+2345
  test_process -socket host:2345
If the hardware simulation and the test process run on the same machine, the test process argument may omit the host name.

Running a simulation using CORBA is more complicated as CORBA requires additional processes to be running and a more complicated set of switches. The example simulations supplied with the SMI library include scripts that run simulations using both socket and CORBA implementations.

2.4.2 PLI: TF vs VPI

The SMI hardware simulation library can support both TF and VPI Verilog programming language interfaces. The PLI used depends on the target simulator that SMI is used with. SMI supports three widely available Verilog simulators; Icarus Verilog, Synopsys VCS and ModelTech ModelSim SE for Linux.

Simulator Configuration Switch Default Directory H/W Library PLI
Icarus --enable-icarus[=ICARUS_DIR] ICARUS_DIR = /usr/local smi.vpi vpi
VCS --enable-vcs . libsmi_hs.a tf
ModelSim --enable-modeltech[=MTI_DIR] MTI_DIR = /usr/local/modeltech smi.sl tf

The software model library is "libsmi_sm.a", the hardware simulation library is platform specific. For example, take the following build commands:

	./configure --enable-icarus=/usr/icarus --enable-vcs
	make

These commands will build the software model (libsmi_sm.a) and hardware simulation libraries (smi.vpi and libsmi_hs.a) for Icarus and VCS simulators. Atleast one target simulator must be enabled. The user may specify the Icarus and ModelTech home directories if the default paths are incorrect.

The SMI hardware simulation library should be linked with the hardware simulation executable. The method used to perform this task is simulator dependent.

For Icarus Verilog, the hardware simulation library (smi.vpi) is linked as follows:

  iverilog -m smi.vpi -o executable verilog_source_files... -lvpi
For Synopsys VCS, the hardware simulation library (libsmi_hs.a) is linked using the SMI tab file (smi.tab) as follows:
  vcs +cli+2 +acc+2 -o executable verilog_source_files... -P smi.tab libsmi_hs.a -lstdc++
For ModelTech ModelSim SE, the hardware simulation library (smi.sl) is dynamically linked at runtime as follows:
  vsim -pli smi.sl other_switches...

Backward Up Forward
© Copyright 2000-2001 Adrian Lewis