UCF

CDA 4150 Computer Architecture
Verilog Reference Manual

 

Dr. Mark Heinrich
Computer Systems Laboratory
School of Electrical Engineering and Computer Science
University of Central Florida
Orlando, FL 32816
August 19, 2003

Table of Contents

  1. Introduction
  2. On-line Verilog Tutorial
  3. CDA 4150 Verilog Simulator
  4. CDA 4150 Verilog Coding Style
  5. CDA 4150 Verilog->C Extensions
  6. CDA 4150 Verilog->C Interface
  7. Built-In Verilog Features
  8. New Features and Bug Fixes

Introduction

A very good Verilog on-line reference and introduction is a course manual prepared by Dr. Daniel C. Hyde at Bucknell University. It is replicated here for archival purposes (you can read the original here). Be aware that we do not use VeriWell, the simulator described in the Bucknell manual, and the Verilog simulator we use in CDA 4150 does not support all of the Verilog language constructs described in the manual above. This document will describe our Verilog simulator, outline the Verilog coding style we will use in CDA 4150, and document our PLI extensions to Verilog as well as some Verilog directives in the manual above that our simulator does not support.


The CDA 4150 Verilog Simulator

The CDA 4150 Verilog Simulator originates from a freely distributed simulator called vbs (Verilog Behavioral Simulator). vbs supports most major Verilog constructs and operators, but it was lacking support for a few key features and had a few bugs in some others. We have modified and extended vbs to include almost all Verilog behavioral constructs and all the features necessary to do full-blown microprocessor design. The details of what we fixed can be found in the New Features and Bug Fixes section at the end of this manual.

We have also added a PLI (programming language interface) to vbs, similar to the PLI capability that ships with Cadence's Verilog-XL simulator. The extensions that we added are detailed in the CDA 4150 Verilog->C Extensions section later in the manual. One of those commands is $dump which saves all changes to the variables you specify to a file so that they can be later viewed with an external graphical wave viewer called GtkWave. A GtkWave manual is also on-line.

To use the CDA 4150 Simulator, you simply have to run the command:
        vbs -C vbs.conf *.v
In this case, vbs will read in all the Verilog files in your current directory (*.v) and start the simulation. The -C vbs.conf option tells vbs where it can read its configuration file that specifies what Verilog->C extensions are currently supported. For this class, you will simply need to use gmake (GNU make) since we will provide you with a Makefile that will run the vbs -C vbs.conf *.v command as well as do a few other useful things. So simply running gmake will run the CDA 4150 Verilog Simulator. If you have added any $dump commands, then running gmake DUMP=1 will run the Verilog simulator and then bring up GtkWave for viewing the signals when the simulation is finished.

More detailed instructions on the particulars of each lab assignment will be distributed with the labs.


CDA 4150 Verilog Coding Style

One of the nice things about Verilog is that there is more than one way to represent the same underlying circuit. This is also one of the ugly things about Verilog, since it is easy to create confusing code that is difficult to debug and ultimately difficult to synthesize. This section outlines a few tips that you should follow for coding behavioral Verilog for this class.


CDA 4150 Verilog->C Extensions

In addition to several built-in Verilog commands, the CDA 4150 Verilog simulator supports several other useful commands that all begin with the $ sign. These commands are actually implemented as C routines via the CDA 4150 Verilog->C interface described in the next section. The currently supported extensions are:


CDA 4150 Verilog->C Interface

The C extensions to Verilog are loaded into the CDA 4150 verilog simulator at runtime using dynamic linking. The mapping between the C functions and verilog is described by the vbs.conf file. Part of the standard vbs.conf file is shown below: 
# a comment
N1
Llibvbs.so
Tdisasm display_insn
Fload_mm load_mm
The first non-comment line is N1. This specifies that the C routines to be read in at runtime are all in one library. If you have multiple libraries (when you use the system library as well as write your own, for instance) this line will have to be changed to specify the number of libraries to be used.

The line Llibvbs.so specifies the filename for the currently selected library. The library is called libvbs.so, and the dynamic linker will attempt to locate it in the standard library path. If that fails, the linker will look for the file in a path specified by LD_LIBRARY_PATH.

The line Tdisasm display_insn states that the Verilog system task $disasm is mapped to the C function display_insn from the last selected library (in this case, libvbs.so). The T specifies that this mapping is to a task rather than a function. Tasks do not return values, whereas functions return integers. The last line defines a Verilog system function $load_mm that is mapped to the C function load_mm from libvbs.so.

The following shows how the two C functions load_mm and display_insn might be written so as to be able to link them with the Verilog simulator: 

#include <stdio.h>
#include "tf.h"

#ifdef __cplusplus
extern "C" {
#endif

unsigned long load_mm (void);
void display_insn (void);

#ifdef __cplusplus
}
#endif

unsigned long load_mm (void)
{
  unsigned long address;

  if (tf_nump() != 1) {
    printf("Error -- Incorrect number of parameters\n");
    return 0xdeadbeef;
  }
  address = tf_getnump(1);
  return mem[address];
}

void display_insn (void)
{
  unsigned long data;

  if (tf_nump() != 1) {
    printf("Error -- Incorrect number of parameters\n");
    return;
  }
  data = tf_getnump(1);
  printf ("%s", mips_dis_insn (data));
  return;
}
A C function that is mapped to a Verilog task takes no arguments. Arguments are read using the functions tf_getnump(int) and tf_getp(int). The first one interprets its argument as an integer, and the second function returns a string. The function tf_nump(void) returns the number of parameters that were passed to the function by the Verilog code.

To make the C code dynamically linkable, the compiler and linker have to be passed special flags. We will provide you with a Makefile that has the appropriate flags to create shared object libraries.


Built-In Verilog Features

Many of the built-in Verilog commands that start with $ are not supported in the CDA 4150 Verilog Simulator. However, this should not affect your life too much nor restrict the usefulness of the subset of Verilog that you learn in this course. Many of the more useful built-in commands are implemented in the CDA 4150 Verilog Simulator, including the following: There are some built-in constructs described in the Bucknell manual that are not implemented. Many of these however, have functionality that is subsumed by the Verilog->C extensions described earlier in the manual. The set of built-in commands described in the Bucknell manual that are not implemented in the CDA 4150 Verilog Simulator are: $stop, $scope, $cleartrace, $settrace, $showscopes, and $showvars.


New Features and Bug Fixes

This section details the changes we have made to the original vbs simulator (version 1.3.6). These changes converted an essentially unusable free simulator into one that supports the necessary constructs to do complete designs. In particular, we added or fixed the following features:

 UCF