Ece5950 Tut4 Vcs GL
Ece5950 Tut4 Vcs GL
Ece5950 Tut4 Vcs GL
Contents
1 2 3 4 5 6 Introduction . . . . . . . . . . . . . . . . . Getting The Tutorial Code . . . . . . . . Manual VCS Build Process . . . . . . . . Automated VCS Build Process . . . . . . Viewing Trace Output With GTKWave Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 3 4 5 5
Introduction
In this tutorial you will gain experience compiling Gate-Level Netlists generated by Synopsys Design Compiler and IC Compiler into cycle-accurate executable simulators using Synopsys VCS. Figure 1 illustrates the basic gate-level simulation toolow and how it ts into the larger ECE5950 ow. Performing gate-level simulation gives us the opportunity to check that our circuit still works properly after being Synthesized and Placed and Routed. Additionally, we use the gate-level simulations to obtain switching activies for each gate in the design. This will allow us to estimate power and energy. For this tutorial we will be performing gate-level simulation on the netlist of the synthesized, placed, and routed greatest common divisor (GCD) circuit, which you should have generated in Tutorial 3. While we will be focusing on Post-Place-and-Route gate-level simulation in this tutorial, the same principles apply to Post-Synthesis gate-level simulation. Typically we are only ever interested in Post-Synthesis gate-level simulation for debugging purposes. Note that this tutorial is by no means comprehensive. Should you nd yourself wanting to refer to more authoritative sources on VCS, GTKWave, and Verilog, you can nd the following relevant documents on the BRG servers at /ufs/brg/courses/ece5950/docs: vcs.pdf - VCS User Guide ucli ug.pdf - Unied Command Line Interface User Guide gtkwave.pdf - GTKWave Documentation
All of the ECE5950 tutorials should be run on the BRG compute servers brg-01.csl.cornell.edu and brg-02.csl.cornell.edu. Before proceeding further, please log into one of these machines. You should follow along through the tutorial yourself by typing in the commands marked with a % symbol at the shell prompt. To cut and paste commands from this tutorial into your bash shell (and make sure bash ignores the % character) use an alias to undene the % character: % alias %="" Once you have logged into a BRG machine you will need to setup the ECE5950 toolow with the following commands:
Constraints (.tcl)
iverilog
VCS
Design Compiler
IC Compiler
Floor Plan
./a.out
./simv
VCS
IC Compiler
Layout
GTKWave
./simv
VCS
IC Compiler GUI
Waveform (.vcd)
GTKWave
./simv
Technology Library (.db) Milkyway Reference DB (.fr) Technology File (.tf) Mapping File (.map) Waveform (.vcd)
RTL Simulation Synthesis Place & Route Gate-Level Simulation Power Estimation (Optional Flow Elements)
GTKWave
VCD2SAIF
PrimeTime
Power Estimates
% source setup-brg.sh % source setup-ece5950.sh For this tutorial you will be using a GCD circuit as your example design. If you dont already have the source les from the previous tutorials, create a work directory and clone the tutorial les from the git repository: % % % % % mkdir -p /tmp/$USER/vc cd /tmp/$USER/vc git clone /ufs/brg/courses/ece5950/ece5950-tutorial cd ece5950-tutorial/tutorial TUTROOT=$PWD
Before starting, take a look at the subdirectories in the project directory. Note that there are directories for your RTL source (src) and for generated content (build). The build directory has subdirectories for each major step in the ECE5950 toolow, these subdirectories contain scripts and conguration les necessary for running the tools. For this tutorial you will work exclusively in the vcs-sim-gl-par subdirectory.
We will rst manually go through the steps for performing gate-level simulation with VCS using the commandline. Since this process is tedious we will only do it once, later we will use scripts to automate the steps in this portion of the ow for us. For now, you should be able to cut and paste the commands below into your terminal: % cd $TUTROOT/build/vcs-sim-gl-par % vcs -full64 -notice +lint=all,noVCDE,noTFIPC,noIWU,noOUDPE +v2k -timescale=1ns/1ps \ -P ../icc-par/current-icc/access.tab -debug +neg_tchk \ +define+CLOCK_PERIOD=0.5 +incdir+../../../vclib/src \ -v ../../../vclib/src/vcQueues.v \ -v ../../../vclib/src/vcStateElements.v \ -v ../../../vclib/src/vcTest.v \ -v ../../../vclib/src/vcTestSource.v \ -v ../../../vclib/src/vcTestSink.v \ ../../src/gcdTestHarness_rtl.v \ ../icc-par/current-icc/results/gcdGCDUnit_rtl.output.v \ /ufs/brg/home/lockhart/vc/git-brg/personal-lockhart/saed90nm-simplecells/cells_simple.v The parameters passed to VCS to generate the gate-level simulator are a bit dierent than those used to compile the RTL simulator. A few additional runtime ags are used (these ags are discussed in a bit more detail below), but more importantly, the Verilog les provided for compilation are quite dierent. Although the test harness and vc library les used by the harness remain the same, we replace the Verilog RTL les with the gate-level netlist generated by IC Compiler (gcdGCDUnit rtl.output.v) and a cell model le that describes the behavior of each gate (cells simple.v). If you look at the gate-level netlist, you should see that it is an entirely structural description that merely wires together instances of the gates dened in the cell model le. Typically the cell model le is provided by the same vendor as your standard cells and has additional functionality beyond just basic behavioral gate descriptions. This additional functionality includes realistic (non-ideal) transition dependent delays for state elements, as well as hooks for annotating each gate in the design with IC Compiler generated delay information (the .sdf le). Unfortunately, these additional facilities, which are meant to more accurately model real chip behavior, can make it extremely dicult to get gate-level simulation to work properly. For the sake of simplicity, we are using our own standard cell behavioral models that do not include this extra timing information. Our simple cells are enough to accurately model the circuit for behavioral and
power analysis purposes, although it will not include glitching eects and the power consumption due to those eects. When fabricating an actual chip, you will denitely want to use the vendor provided cells and ensure all tests pass without any setup or hold time violations. Important runtime ags: -notice enables verbose diagnostic messages. +lint=all,noVCDE,noTFIPC,noIWU,noOUDPE turns on Verilog warnings except the following warnings: VCDE - Verilog compiler directive encountered. TFIPC - Too few instance port connections. IWU - Implicit wire used. OUDPE - UDP entries overlap. -P <file.tab> load a PLI table le. The the access.tab table le is used to give write access to certain registers in our design so that we can we can initialize them to a known value during simulation. For more info, see below. After running the VCS command from above, you should see text output indicating that VCS is parsing the Verilog les and compiling the modules. Once compilation has completed, go ahead an execute the simulator: % ./simv -ucli -do run.tcl +verbose=1 Running the simv executable with the verbose ag should show you that the simulation executes and successfully passes all tests. You should notice that there are a few extra parameters passed to the gate-level simulator compared to the RTL simulator discussed in Tutorial 1. The -ucli -do run.tcl parameters tell the Synopsys Unied Command Line Interface to execute the run.tcl script at the beginning of the VCS simulation. If you look at this script, youll see that it sources and executes the force regs.ucli script generated by IC Compiler. According to Synopsys documentation, unitialized register values can result in x pessimism, and this same x pessimism can cause gate-level simulation to fail even if your design is correct. The purpose of the force regs.ucli script (and also the access.tab le passed to VCS during compilation) is to avoid this problem by initializing all state elements to a known value at simulation time. Typically reset signals are used to set critical state (usually control logic) to known values at startup, but non-critical state (usually datapath registers) will often omit reset signals in order to save area.
Typing each command via the commandline is a tedious and error-prone process, and should typically be avoided. Instead, we make use of scripts to automate the process of building our tools for us. The following commands will rst delete the simulator you previously built, and then regenerate it using the makele. % cd $TUTROOT/build/vcs-sim-gl-par % make check % make run Some of the labs will include a build directory for Post-Synthesis gate-level simulation called vcs-sim-gl-syn in addition to the Post-Place-and-Route simulator vcs-sim-gl-par. Because the Post-Synthesis gate-level models arent as accurate as the Post-Place-and-Route ones, they will not be used for obtaining power estimates. However, should your Post-Place-and-Route gate-level simulations fail, it may be useful to use the Post-Synthesis simulation to aid in debugging and help determine if the errors are being introduced in synthesis or in place and route.
To try running the Post-Synthesis simulator, you can execute the following commands in your Lab 1 build directory: % cd $LABROOT/build/vcs-sim-gl-syn % make check % make run
You can view the results of the gate-level simulation by opening the generated vcd le in GTKWave, similar to what was described in Tutorial 1. You may notice that some of the signals in your design do not behave as expected, and additional signals which you did not use in your design are present. This is due to optimizations done during synthesis, place, and route which will get rid of signals and add new ones in order to improve performance or reduce area. For more information on using GTKWave, see Tutorial 1: RTL Simulation using Synopsys VCS.
Acknowledgements
Many sources have contributed to the content of this tutorial. The original material for this tutorial was developed as a lab for the CS250 VLSI Systems Design course at University of California at Berkeley by Yunsup Lee. Contributors include: Krste Asanovi, Christopher Batten, John Lazzaro, and John Wawrzynek. c Versions of that lab have been used in the following courses: CS250 VLSI Systems Design (2009-2011) - University of California at Berkeley CSE291 Manycore System Design (2009) - University of California at San Diego