Using SystemC Cycle Models with HDL Simulation

Arm offers Cycle Models for SystemC simulation. These models can be downloaded from Arm IP Exchange or created by users with Arm Cycle Model Studio (CMS). The models can be run in a SystemC only simulation environment from Accellera or in simulators from EDA partners such as Cadence, Mentor, and Synopsys. In both cases, the Arm Cycle Models require a runtime license, but users are free to select the best fit simulator for SystemC. Running Cycle Models with EDA partner simulators is a common user question, and it's very easy to do for all simulators.

This tutorial explains how to create a simple SystemC model using Cycle Model Studio and run it with a Verilog testbench using EDA partner simulators. This demonstrates how easy it is to use Cycle Models in mixed language simulation. In the past, using Cycle Models with Verilog HDL required the use of the Verilog PLI (Programming Language Interface) or DPI (Direct Programming Interface), but now that all simulators support easy to use mixed-language simulation, PLI and DPI are not required and are no longer recommended for best performance.

The tutorial uses an existing CMS example called twocounter. It’s a simple Verilog module with two independent counters. The attached file, twocounter-cm-hdl.tgz,  has everything needed to create the Cycle Model and simulate the original HDL and the Verilog testbench with the SystemC Cycle Model. A simple script shows all the details to run mixed language simulation on each simulator. This can be used as a reference for integrating SystemC Cycle Models into a larger simulation project.

Untar the file in a new directory. This example has no outside dependencies except the EDA partner simulator setup.

$ tar xvfz twocounter-cm-hdl.tgz

Setup

The example has two directories:

  • The cm/ directory contains the Verilog source code and script to build the Cycle Model for twocounter. The Cycle Model will be generated here using cbuild from CMS.
  • The testbench/ directory has the Verilog testbench and script to compile and run the EDA partner simulators.

Make sure the EDA partner simulator to be used is configured and the license is available. When it comes time to build the SystemC Cycle Model, make sure Cycle Model Studio has been installed and setup.

Confirm the HDL only simulation works

Before starting to use the Cycle Model, a good first step is to confirm the Verilog only version works fine and the simulator to be used is working. This will simulate the Verilog testbench and the Verilog version of the twocounter module. Once that is confirmed working, the Cycle Model can be created and the SystemC Cycle Model will replace the Verilog version.

Go to the testbench/ directory and use the run.sh script to select the simulator to use.

# For Cadence Incisive use:
$ ./run.sh ius-hdl

# For Mentor Questq use:
$ ./run.sh mti-hdl

# For Synopsys VCS use:
$ ./run.sh vcs-hdl

Below is the output from one simulator to confirm what should happen when the simulation is run:

irun(64): 15.20-s005: (c) Copyright 1995-2016 Cadence Design Systems, Inc.
TOOL:   irun(64)        15.20-s005: Started on Jan 26, 2018 at 16:37:26 GMT
irun
        -64bit
        +access+r
        -64bit
        /arm/scratch/jasand01/cm-hdl/cm/twocounter.v
        tb.v
file: /arm/scratch/jasand01/cm-hdl/cm/twocounter.v
        module worklib.twocounter:v
                errors: 0, warnings: 0
file: tb.v
        module worklib.tb:v
                errors: 0, warnings: 0
                Caching library 'worklib' ....... Done
        Elaborating the design hierarchy:
        Top level design units:
                tb
        Building instance overlay tables: .................... Done
        Generating native compiled code:
                worklib.tb:v <0x3c4a7fd1>
                        streams:   5, words:  5551
                worklib.twocounter:v <0x24e01f67>
                        streams:   4, words:   940
        Building instance specific data structures.
        Loading native compiled code:     .................... Done
        Design hierarchy summary:
                                 Instances  Unique
                Modules:                 2       2
                Registers:               6       6
                Scalar wires:            4       -
                Vectored wires:          2       -
                Always blocks:           3       3
                Initial blocks:          3       3
                Simulation timescale:  1ps
        Writing initial simulation snapshot: worklib.tb:v
Loading snapshot worklib.tb:v .................... Done
ncsim> source /arm/tools/cadence/incisive/15.20.005/tools/inca/files/ncsimrc
ncsim> run
t=  0 out1=xxxxxxxx out2=xxxxxxxx
t=  7 out1=00000000 out2=xxxxxxxx
t= 15 out1=00000000 out2=00000000
t= 37 out1=00000001 out2=00000000
t= 45 out1=00000001 out2=00000003
t= 67 out1=00000002 out2=00000003
t= 75 out1=00000002 out2=00000006
t= 97 out1=00000003 out2=00000006
t=105 out1=00000003 out2=00000009
t=127 out1=00000004 out2=00000009
t=135 out1=00000004 out2=0000000c
t=157 out1=00000005 out2=0000000c
t=165 out1=00000005 out2=0000000f
t=187 out1=00000006 out2=0000000f
t=195 out1=00000006 out2=00000012
t=217 out1=00000007 out2=00000012
t=225 out1=00000007 out2=00000015
t=247 out1=00000008 out2=00000015
t=255 out1=00000008 out2=00000018
t=277 out1=00000009 out2=00000018
t=285 out1=00000009 out2=0000001b
t=307 out1=0000000a out2=0000001b
t=315 out1=0000000a out2=0000001e
t=337 out1=0000000b out2=0000001e
t=345 out1=0000000b out2=00000021
t=367 out1=0000000c out2=00000021
t=375 out1=0000000c out2=00000024
t=397 out1=0000000d out2=00000024
t=405 out1=0000000d out2=00000027
t=427 out1=0000000e out2=00000027
t=435 out1=0000000e out2=0000002a
t=457 out1=0000000f out2=0000002a
t=465 out1=0000000f out2=0000002d
t=487 out1=00000010 out2=0000002d
t=495 out1=00000010 out2=00000030
t=517 out1=00000011 out2=00000030
t=525 out1=00000011 out2=00000033
Simulation complete via $finish(1) at time 540 NS + 0
./tb.v:41         #500 $finish;
ncsim> exit
TOOL:   irun(64)        15.20-s005: Exiting on Jan 26, 2018 at 16:37:36 GMT  (total: 00:00:10)

Execute the run.sh script with no arguments to see the options. The targets with “-hdl” indicate to simulate the design with HDL only, no Cycle Model yet.

If this runs fine the output should be the information printed by the $monitor statement in the testbench, tb.v, as shown in the window above.

Now that the all Verilog simulation is confirmed to work, it's time to build the SystemC Cycle Model and use it instead of the twocounter.v file.

Build the Cycle Model

To build the Cycle Model navaigate to the cm/ directory. There is a script build-cm.sh which invokes CMS compiler, cbuild, to compile the model. A few outputs will result:

  • The model is created in the gcc/ directory
  • The SystemC wrappers are created

Just invoke the script to create the model.

$ ./build-cm.sh

The SystemC wrapper is now created. The key files are twocounter.cpp and twocounter.h, which contain the SC_MODULE. The tpp of the code is shown here:

SC_MODULE(twocounter)
{
  #include "carbon/carbon_scmodule.h"
  #include "carbon/carbon_valutil.h"
  #include "carbon/carbon_sctypes.h"


  // CARBON USER CODE [PRE twocounter DECLARATIONS] BEGIN
  // CARBON USER CODE END

  // SytemC Module Ports
  sc_in<bool > clk1;
  sc_in<bool > clk2;
  sc_in<bool > reset1;
  sc_in<bool > reset2;
  sc_out<sc_uint<32> > out1;
  sc_out<sc_uint<32> > out2;

Beyond the wrapper, the files gcc/libtwocounter.a and gcc/libtwocounter.h are also needed for the integration into the EDA partner simulator as these contain the functionality of the model.

The SystemC wrapper is generated using the “carbon systemCWrapper gcc/libtwocounter.io.db” command. It takes the .io.db file of the model and writes out the SystemC wrapper.

Compile and run with the Cycle Model

To run the simulation again, this time with the SystemC Cycle Model, navigate back to the testbench/ directory.

This time use the run.sh script with any of the arguments below to select the simulator. This time the SystemC wrapper is compiled and the same twocounter is instantiated in the testbench, but it’s a SystemC model instead of a Verilog module. No changes are needed to the testbench as each simulator transparently connects the mixed-language design.

Here are the options for each simulator:

# For Cadence Incisive use:
$ ./run.sh ius

# For Mentor Questq use:
$ ./run.sh mti

# For Synopsys VCS use:
$ ./run.sh vcs

The simulation runs the same as before, but this time it’s a SystemC Cycle Model for the twocounter.

Waveform dump and simulator GUI

To dump a waveform add +VCD to the above scripts invocations. For example:

$ ./run.sh vcs +VCD

This will generate a VCD file named dump.vcd which can be viewed with any VCD waveform viewer.

Each simulator can be started in GUI mode also using -gui. For example, to start Mentor Questa with the GUI use:

$ ./run.sh mti -gui

One way to see the difference between all Verliog and the SystemC Cycle Model is using the SimVision GUI. In all Verilog, both the tb and the twocounter modules are grey for Verilog in the Design Browser as shown below.

SimVision GUI showing the twocounter modules for Verilog

With the SystemC Cycle Model the twocounter module is green for SystemC. Sending counter0 to a new Source Browser will show the source in Verilog for the first case, and SystemC for the second.

SimVision GUI Sending counter0 to a new Source browser

SystemC Cycle Model waveform dump

When running in EDA partner simulators only the top-level signals of the SystemC Cycle Model are visible to the simulator. To dump a waveform of the internal signals of the Cycle Model use a directives file to specify which signals should be visible in the waveform dump. For the twocounter design cbuild is run with -directive. This specifies a directives file to pass to the compiler. The directives file contains contains observeSignal *.* which instructs cbuild to make all internal signals in the model visible. The observeSignal controls exactly which parts of the design will be visible and can be used to specify all, some, or none of the design.

To dump a waveform file of the model add -DCARBON_DUMP_VCD=1 to create a VCD file or -DCARBON_DUMP_FSDB=1 to dump an FSDB file. When the simulation is run for VCD dumping a file arm_cm_tb_counter0.vcd will be generated. More information on observeSignal and SystemC waveform dumping can be found in the Cycle Model Studio SystemC User Manual and the Cycle Model Compiler User Manual.

Conclusion

SystemC Cycle Models are a good way to simulate both Arm IP from IP Exchange or user created IP. EDA partner simulators are useful for times when verification is important and existing testbenches written in languages such as System Verilog are needed. SystemC Cycle Models from Arm IP Exchange often have additional features over using all RTL simulation such as PMU counter instrumentation. Some CPU models also have a CADI debug interface for software debugging. The flexibility to mix Verilog and SystemC in EDA partner simulators makes Cycle Models useful for many verification tasks. SystemC Cycle Models can also be used to lock down a sub-set of a design and avoid recompilation of Verilog files that are not going to change during the project.The observeSignal directive gives the model creator full control over the internal design information to be shared with the model user. This tutorial provided a good introduction into the details of SystemC and Verilog mixed-language simulation in EDA partner simulators.

Get Started with Cycle Models Today

twocounter-cm-hdl.tgz
Anonymous