Using VCS in CS310H
Before running VCS the tool environment file must be source. If you have not done this please go back to the environment setup page. Steps 1 through 5 may be done on in a telnet window from anywhere to any department linux machine. Steps 6 on require the user be seated at a departement linux machine.

  1. Write verilog file. For the purposes of this tutorial you may use the following example:

    module mux2_1 ( out, in0, in1, sel ) ;
    
       input  [3:0] in0, in1;
       input  sel;
    
       output [3:0] out;
    
    
       // All the real work gets done here in the assign.
       assign       out = sel ? in1 : in0;
    
    
    endmodule // mux2_1
    
    As you can see this is a very simple four bit 2 to 1 mux. You may also copy the file from here.
    Note: we use the naming convention that the basename of the file and the module name will be the same. In this case the module name is "mux2_1" therefore the file name for it will be "mux2_1.v". There will also only be one module per file.

  2. Write a test bench for the verilog file. Here is an example testbench file:
    // This stuff just sets up the proper time scale and format for the
    // simulation, for now do not modify.
    `timescale 1ns/10ps
    module timeunit;
       initial $timeformat(-9,1," ns",9);
    endmodule
    
    
    // Here is the testbench proper:
    module mux2_1_testbench ( ) ;
    
       // Test bench gets wires for all dut outputs:
       wire [3:0]		out;			// From dut of mux2_1.v
    
       // Regs for all dut inputs:
       reg [3:0]		in0;			// To dut of mux2_1.v
       reg [3:0]		in1;			// To dut of mux2_1.v
       reg			sel;			// To dut of mux2_1.v
    
    
       mux2_1 dut (// (dut means device under test)
    	       // Outputs
    	       .out			(out[3:0]),
    	       // Inputs
    	       .in0			(in0[3:0]),
    	       .in1			(in1[3:0]),
    	       .sel			(sel));
    
       
       initial
         begin
    
            // First setup up to monitor all inputs and outputs
            $monitor ("time=%5d ns, in0=%b, in1=%b, sel=%b, out=%b", $time, in0, in1, sel, out);
    
    	// First initialize all registers
    	in0 = 4'b0;
    	in1 = 4'b0;
    	sel = 1'b0;
    	
    
            #10;  // space things out on 10ns boundaries to see
    	            // results easier in VirSim
    	
    	// At this point we should have a 4'b0 coming out out because
    	// it is selecting in0 and in0 is 0b0	
    	if (out != 4'b0) begin
    	   $display("ERROR 1: Out is not equal to 0'b0");
    	   $finish;
    	end
    
            #10;
    	in0 = 4'b0110;
    	in1 = 4'b1001;
    	sel = 1'b0;
    	
            #10;
    
    	// We should now have 0110 on the output
    	if (out != 4'b0110) begin
    	   $display("ERROR 2: Output is not equal to 4'b0110");
    	   $finish;
    	end
    
            #10;
    	sel = 1'b1;
    	
            #10;
    		
    	// Now we are selecting in1 so we should see its value on the
    	// output
    	if (out != 4'b1001) begin
    	   $display("ERROR 3: Output is not equal to 4'b1001");
    	   $finish;
    	end
    	
            #10;
    	
    	sel = 1'b0; // This is only there to force a space in the
    	            // output so the wave trace is more easily read.
    	
    	
    
    	// We got this far so all tests passed.
    	$display("All tests completed successfully\n\n");
    	
    	$finish;
         end
    
    
       // This is to create a dump file for offline viewing.
       initial
         begin
            $dumpfile ("mux2_1.dump");
            $dumpvars (0, mux2_1_testbench);
         end // initial begin
       
       
    endmodule // mux2_1_testbench
    
    

    As can be seen, the test bench instantiates the mux and assigns each of its inputs to a reg.  It then asserts various different values on those inputs and tests the output for the proper value. If the output is incorrect it will print an error message and quit.  The final section creates a value change dump file that can be used for off line analysis of the test run (see step 5 below).  You may download a copy of the testbench from here.

  3. In order to use the test bench we must use VCS to build an executable model of it. To do this first we must make a list of the files we are building. The list of files must be in a top down heirarchical order. In this case we will make a text file called "filelist" which has the following contents:
    mux2_1_testbench.v
    mux2_1.v
      
    You may download a copy of this file from here .
  4. The next step is to compile the verilog with vcs. For this example issue the command below (shown in red):

    pgratz@desk workingdir $ vcs -o mux2_1 -Mupdate -f filelist
                             Chronologic VCS (TM)
              Version X-2005.06-SP2 -- Mon Sep 11 10:05:14 2006
                   Copyright (c) 1991-2005 by Synopsys Inc.
                             ALL RIGHTS RESERVED
    
    This program is proprietary and confidential information of Synopsys Inc.
    and may be used and disclosed only as authorized in a license agreement
    controlling such use and disclosure.
    
    Parsing design file 'mux2_1_testbench.v'
    Parsing design file 'mux2_1.v'
    Top Level Modules:
           timeunit
           mux2_1_testbench
    TimeScale is 1 ns / 10 ps
    Starting vcs inline pass...
    2 modules and 0 UDP read.
    recompiling module timeunit
    recompiling module mux2_1_testbench
    Both modules done.
    if [ -x ../mux2_1 ]; then chmod -x ../mux2_1; fi
    g++  -o ../mux2_1  5NrI_d.o 5NrIB_d.o IV5q_1_d.o D3ka_1_d.o SIM_l.o   /projects/cad/synopsys/vcs/vcs-mx_vX-2005.06-SP2/redhat30/lib/libvirsim.a     /projects/cad/synopsys/vcs/vcs-mx_vX-2005.06-SP2/redhat30/lib/libvcsnew.so     /projects/cad/synopsys/vcs/vcs-mx_vX-2005.06-SP2/redhat30/lib/ctype-stubs_32.a -ldl  -lc -lm -ldl
    ../mux2_1 up to date
    CPU time: .120 seconds to compile + 5.640 seconds to link
    

    When the command is complete there will be an executable in the current directory that is the model for the testbench:

    pgratz@desk workingdir $ ls -l

    total 520
    drwxr-xr-x  2 pgratz guest   4096 Sep 11 10:12 csrc
    -rw-r--r--  1 pgratz guest     27 Sep 11 10:00 filelist
    -rwxr-xr-x  1 pgratz guest 509960 Sep 11 10:12 mux2_1
    drwxr-xr-x  2 pgratz guest   4096 Sep 11 10:12 mux2_1.daidir
    -rw-r--r--  1 pgratz guest    238 Sep 11 09:59 mux2_1.v
    -rw-r--r--  1 pgratz guest   2357 Sep 11 09:59 mux2_1_testbench.v
    


  5. Now that the model has been built the next step is to execute it to find out if the tests written in the testbench pass or not:

    pgratz@desk workingdir $ ./mux2_1
    Chronologic VCS simulator copyright 1991-2005
    Contains Synopsys proprietary information.
    Compiler version X-2005.06-SP2; Runtime version X-2005.06-SP2;  Sep 14 12:32 2006
    
    time=    0 ns, in0=0000, in1=0000, sel=0, out=0000
    time=   20 ns, in0=0110, in1=1001, sel=0, out=0110
    time=   40 ns, in0=0110, in1=1001, sel=1, out=1001
    All tests completed successfully
    
    
    $finish at simulation time   60.0 ns
               V C S   S i m u l a t i o n   R e p o r t
    Time: 60000 ps
    CPU Time:      0.040 seconds;       Data structure size:   0.0Mb
    Thu Sep 14 12:33:00 2006
    

    As can be seen in this output the "All tests completed successfully" has been printed so each of the tests written in the testbench must have passed. Also note that the $monitor command causes the values of all the variables to be printed when ever any of them have changed.

  6. For more extensive analysis of the device under test it can be useful to visually see the signals and their transitions, similar to a logic analyzer.  VCS has the VirSim tool for just this purpose.  Because of the $dumpfile statements at the end of the testbench, when the model is executed a trace of all the signals is saved in a .dump file in the local directory, VirSim is able to read this file and display the results. To start VirSim, once the test has been run once, execute the following command:

    pgratz@desk workingdir $ vcs -RPP -f filelist


    At this point the VirSim "Hierarchy Browser" will appear:
    Hierarchy Browser

    To open the dumpfile select "open" under the File menu to bring up the "Open File Dialog" window. On that window make sure that the "type" is "VCD" (not "VCD+"):
    Open file

    You should now see "mux2_1.dump" as one of the options under "Files", select it and hit OK. This will load the dump file and the Hierarchy Window will show it, next select "mux2_1_testbench" under the "Hierarchy" box of the Hierarchy Window. This will cause the signals available at that level in the hierarchy to show up under signal select:
    Signals

    Now select the "Waveform" under the Window menu on the Hierarchy Browser and the Waveform window will appear:
    Empty Waveform

    As can be seen here there are no signals in the Waveform window.  The easiest way to look at signals is to first select the "mux2_1_testbench" under "Heirarchy" in the Heirarchy Browser. Then select all the signals shown in the "Signal Select" box on the Hierarchy Browser and drag them using the middle mouse button (chord left and right together on 2 button mice) over to the black area on the Waveform window. This will make the signals appear in the  Waveform window, at this point select "Zoom Percent/Zoom %100" under the Zoom menu to show the entire test. It should look like this:
    waves

    Note that the scale along the top is in ps. It may be adjusted with the "Time Scale.." option under Display.  Also it is possible to zoom in on areas by dragging the left mouse button across the desired section.

This concludes the tutorial on the use of VCS. More extensive documentation may be found on the main CAD page.

Modified by Paul Gratz, pgratz@cs.utexas.edu