HDL Simulation Platforms

The OpenCPI concept of an HDL platform encompasses both physical FPGA-based platforms as well as HDL simulators such as Mentor’s modelsim, and Xilinx isim or xsim.

At build time, simulators are “just another target” when building primitives and workers, and “just another platform” when building assemblies and containers. The names for simulators in both target-related and platform-related XML attribute are modelsim , xsim and isim. E.g.:

$ ocpidev build --hdl-platform=zed --hdl-platform=picoevb --hdl-platform=modelsim

would build for the ZedBoard Zynq-based platform, the Altera Stratix4-based platform, and the modelsim platform. If a worker was intended only for simulators, its OWD XML file would typically contain the attribute setting:

OnlyTargets='isim modelsim xsim'

Similarly, if an assembly was intended only for simulators, its XML file would typically contain the same attribute.

Even though simulators do not perform synthesis, building for simulators tries to elaborate the design at each build level to catch errors as early as possible. To suppress this incremental elaboration for faster build times, the XML attribute NoSimElaboration can be set to 1. Since simulation builds are normally fast anyway, this is rarely worth it, especially for modelsim.

At runtime, an installed simulator is an available HDL platform just like any installed hardware HDL platform. Simulators act as much like a hardware FPGA platform as possible:

Previous versions of OpenCPI used the ocpihdl simulate command to start a simulator container as a server process. This is no longer necessary or supported. For backward compatibility for some test benches, this command does nothing but sleep indefinitely.

The following simulation server behavior is currently disabled, but will be enabled in a future release.

  • A bitstream can be “loaded”, which in fact starts simulation (usually automatically as needed by ocpirun, or explicitly using ocpihdl load)

  • It is persistent, so an application can be executed multiple times, which in fact will occur in the same simulation run

  • It can be queried (e.g. to find the current value of a worker’s properties) using various ocpihdl commands

Execution of Simulation Bitstreams and Containers.

Simulators that are installed for use by OpenCPI are automatically available as containers, similar to HDL hardware platforms or even software containers. When an application is run, these containers are available to be used if artifacts are built and accessible via the OCPI_LIBRARY_PATH environment variable (as described in the Preparing the Bitstream/Executable Artifact File topic). For example, assuming that modelsim and isim simulators are installed for OpenCPI, on a Rocky9 system, the command ocpirun -C would output:

Available containers:
#  Model  Platform    OS    OS-Version  Arch    Name
0  hdl    xsim                                  lsim:xsim
1  hdl    modelsim                              lsim:modelsim
2  rcc    rocky9     linux  r9          x86_64  rcc0

If an application is run, and bitstream files are available to use these simulators, they will be used automatically. To force components in the application to use a particular simulator, the -P option to ocpirun can be used, e.g.:

$ ocpirun -P=modelsim myapp

would run myapp, forcing all components to be executed with modelsim. To force one component in the application to use modelsim, you could say:

$ ocpirun -Pmycomp=modelsim myapp

The ocpirun command normally used to run OpenCPI applications has several options that apply only to simulators:

Table 53: Simulations Options to ocpirun

Name

Letter

Description

sim_dir

none

The name of a directory where simulation outputs will be placed. The default is simulations, relative to where ocpirun itself is running.

sim-ticks

none

The number of simulation clock cycles to execute or until the application is done.

As with execution on any hardware HDL device (FPGA), some of the components in the application may be in software containers running on the host processor. The data connections between workers inside the HDL device (or simulator) and outside the HDL device in software containers work normally. Since HDL execution is much slower in simulators than in real FPGA hardware, the software workers will see data consumed or produced by the HDL simulator device much slower.

When some OpenCPI application (e.g. executed using the ocpirun utility command) decides to run an assembly of workers on this simulator-based device (as it would with any other discovered and available HDL device/FPGA), it would request that the bitstream (executable) be “loaded” and “started” on this device. This would cause this simulated HDL device to run the actual simulator (e.g. modelsim) with that executable.

Each time a simulator is actually run under ocpirun, it will execute in a new subdirectory created for that simulation run, with the name:

<assembly-name>.<sim-platform>.<date-time>

Thus running applications that use simulators will result in one or more subdirectories holding simulation results for each simulation run. No subdirectories are created when the simulator is simply discovered using ocpirun -C or ocpihdl search.

Each simulation execution that is launched by ocpirun when it runs an application will continue until one of the following occurs:

  • The code being simulated explicitly asks for the simulation to terminate via the $finish system task in Verilog or an assert in VHDL.

  • The simulation run exceeds the control-plane clock cycle count provided by the --sim-ticks option to ocpirun.

  • This ocpirun command receives a control-C.

The results of any simulation run can be viewed using the ocpiview command. This command with no arguments opens the most recent simulation run found in the simulations directory, using the simulation viewer associated with the simulator used in that run. If given an argument, it is the directory containing a particular simulation run. The normal pattern of development is to run ocpiview after execution if examining the simulation run in detail is needed.

For Xilinx “isim”, the actual underlying viewing command (in the subdirectory for the simulation run) would be:

isimgui –view sim.wdb

For modelsim, it would be:

vsim -view vsim.wlf

In all cases the log of the simulator’s output for the run is in the sim.out file.