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
The example has two directories:
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.
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
errors: 0, warnings: 0
errors: 0, warnings: 0
Caching library 'worklib' ....... Done
Elaborating the design hierarchy:
Top level design units:
Building instance overlay tables: .................... Done
Generating native compiled code:
streams: 5, words: 5551
streams: 4, words: 940
Building instance specific data structures.
Loading native compiled code: .................... Done
Design hierarchy summary:
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
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;
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.
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:
Just invoke the script to create the model.
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:
// 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.
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.
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.
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.
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.
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