This content is translated with AI. Please refer to the original Traditional Chinese version (zh-TW) for accuracy.

Here’s how the story goes: In the early days when I wrote verilog articles , and until recently when I wanted to do simple simulations, I was using iverilog as an example. However, it had the following two fatal flaws:

  1. Poor performance. I heard that since it transitioned to a compiled model in recent years, it has significantly accelerated, but I believe it’s still a notch slower compared to verilator and commercial software.
  2. Does not support SystemVerilog and VHDL. Writing pure Verilog these days is really painful, and using iverilog can’t simulate when implementing with SystemVerilog.

Common Commercial Simulation Tools

In the industry, spending a fortune on hardware certainly can’t just rely on iverilog for simulation verification. Companies use commercial EDA software ; currently, the tools I know include the following:

  • Synopsys VCS: The tool introduced today can output .fsdb waveforms and is deeply integrated with Novas’ Verdi (acquired by Synopsys), combined with kdb debugging method. From what I’ve seen colleagues use, it’s still the fastest and most efficient I’ve come across.
  • Cadence NCSim: The simulation engine in Cadence Incisive tool set. I used its ncverilog simulator when I was in school, but in recent years as I relearned, it has been replaced by the next item, Xcelium.
  • Cadence Xcelium: The new generation simulation engine replacing NCSim in Cadence Incisive. From my experience, there are two remarks,
    1. The simulation speed is good, not losing and sometimes winning Synopsys VCS.
    2. Second is Cadence’s standard .tcf format, which is needed when using Innovus for static power simulation.
  • Mentor Graphics: ModelSim, which I haven’t used, so I won’t mention it here.
  • Xilinx Vivado: This has a built-in Verilog simulator too, but I hardly use it since Vivado’s purpose is for FPGA synthesis, not for running simulation. Vivado is too bloated, and setting up a project just for simulation is really cumbersome.

If we only compare the few mentioned earlier (Wikipedia used the term big 3 XD), Synopsys VCS is an unignorable presence, especially since Synopsys itself is the main designer of SystemVerilog. VCS should offer the best support for SystemVerilog and ABV (Assertion-based verification), VMM (Verification Methodology Manual).

Recently, due to some reasons, I used VCS functions for a period. Below, I’ll introduce how to use this set of commercial simulation tools.

VCS Environment Setup

First is the VCS environment setup. In the working directory, create a file named synopsys_sim.setup.

  1. This step is not necessary. If the design is simple and you don’t build a library (mentioned below), you can run it directly; but if you want to build a library, failing to set it will result in understandable errors.
  2. Note that this time it is not a hidden file, it’s really puzzling why Design Compiler and PrimeTime are hidden files while VCS is not…

Related settings can be found in the VCS User Manual. When using VCS, it’s similar to a C function library where hardware implementations can be translated and distributed into different libraries, then linked together during simulations. synopsys_sim.setup records: what logical libraries are present here and which physical libraries they are mapped to; as long as the same logical library is used, modifying synopsys_sim.setup to point to different physical libraries can swap implementations for simulation.

The minimal synopsys_sim.setup is the following two lines:

WORK > DEFAULT
DEFAULT : ./WORK

This means the default library is called DEFAULT, and the files generated by DEFAULT will exist in the WORK folder. Another interesting design here is that logical libraries are case insensitive, but physical libraries are case sensitive because they point to actual addressesSynopsys, this isn’t surprising.

If you don’t know the current library settings, you can use

show_setup -lib

to view them.

2-step

VCS has two execution methods, generally referred to as 2-step or 3-step, depending on the simplicity or complexity of the simulation target. Below we introduce two-stage and three-stage simulations. Two-stage simulation comprises Compilation and Simulation phases. Compilation loads all hardware designs into VCS to generate the simv executable. Simulation executes simv to perform the simulations. Behind the scenes, this likely involves calling vlogan to compile Verilog/SystemVerilog files and store them in the default library.

vcs [verilog files]
./simv

3-step flow

Three-stage simulation is divided into analyze, elaboration, and Simulation. The design of three stages is to handle different tools and languages for hardware design, such as those listed in the VCS document support for three common hardware design languages:

  • Verilog (IEEE 1364)
  • VHDL (IEEE VHDL 1076-1993)
  • SystemVerilog (IEEE 1800 - 2012) Others include SystemC, DVE, etc., for co-simulation.

Verilog and SystemVerilog can be analyzed using vlogan; VHDL uses vhdlan for analysis.

vlogan *.v
vlogan -sverilog *.sv
vhdlan *.vhd

These files will be converted to intermediate files and exist in specified libraries; typically, I provide the following vlogan options:

  • -full64: Simulate using 64 bits (Really, are there still people using 32-bit computers for EDA?)
  • -kdb: Generate information for Synopsys Verdi debugging
  • -work [logical lib]: If you want to specify which library to put the generated files in, use this line
  • -f filelist: Provide a filelist for analyzing files; helpful for large projects

If you specify -work but the name after it doesn’t exist in synopsys_sim.setup, you will get the following error (again, reminder: the configuration file is not a hidden file, Synopsys, what flight are you planning), in which case, remember to add corresponding logical libraries in synopsys_sim.setup:

vlogan -sverilog -full64 -kdb -work MYGO -f filelist.f

Error-[ILWOR] Incorrect Logical Worklib or Reflib
  The incorrect logical lib is "MYGO".  
  Please check your Synopsys setup file.

During the elaborate phase, previously analyzed intermediate files are converted to simv. The top module can be specified as a logical library like MYGO.test_chip_top or directly using test_chip_top. Both methods worked during my tests to find implementations and simulate.

vcs -kdb -full64 -top test_chip_top

Simulation, like 2-step, simply runs the simv executable.

Using VCS Encryption

Apart from simulations, VCS also includes encryption, although it’s separate from its simulation feature. The process involves first converting files from source code to encrypted files, then sending encrypted files to VCS for simulation. Note the encryption introduced here is specific to VCS and is not the standard defined by IEEE1735 . After encryption, the files can only be sent to others for running VCS simulation, not for synthesis or other purposes.

VCS encryption options include four types:

  • autoprotect: Encrypts the entire file, leaving only module names
  • auto2protect: Doesn’t encrypt the port part
  • auto3protect: Doesn’t encrypt the ports and any parameters defined before them
  • protect: Encrypts only the content between protect and endprotect.

General operation is as follows: Encrypt each file fully using autoprotect; the top uses auto2protect to retain the interface so users know how to drive signals.

Options use +putprotect and +deleteprotected to allow VCS to gather encrypted files in one folder and overwrite existing files. Note that encryption doesn’t hide the file hierarchy, so users might still derive your design architecture from filenames. Using cat to combine files into one can also be a feasible approach if you really don’t want them to be viewed.

vcs +autoprotect +putprotect+mygo +deleteprotected -f filelist.f
vcs +auto2protect +putprotect+mygo +deleteprotected chip_top.sv

After encryption, simulation is still possible, but the content of encrypted files won’t appear in the waveform files. The auto2protect file will only show the interface.

TL;DR

With so much said, like last time, I include the Makefile used for encryption and simulation. After encryption, the filenames will change from .sv to .svp, so you will need to prepare filelist.f and encrypted.f as two sets of file lists. Of course, when going offline, I personally don’t encrypt; I directly run the 2-step simulations.


VLOGANOPTS = -sverilog -full64 -kdb -work MYGO

encrypt:
    mkdir -p mygo
    vcs +autoprotect +putprotect+mygo +deleteprotected -f filelist.f
    vcs +auto2protect +putprotect+mygo +deleteprotected chip_top.sv

analyze:
    vlogan ${VLOGANOPTS} -f encrypted.fp

elaborate:
    vcs -full64 test_chip_top -debug_access+all

simv:
    ./simv