Hardware Modelling with Verilog HDL

The Verilog Hardware Description Language can be used to model a digital circuit during the design stage. Such a design may be simulated using the Xcelium digital simulator in order to make early descisions on the viability of a design. The design may then be further refined at this stage before any circuit is implemented. The final Verilog HDL model may then be used as a base for circuit design or directly synthesized to produce a circuit implementation.

This page describes creation and refinement of Verilog HDL model files. It also touches on their simulataion and synthesis. The details of simulation and synthesis are discussed elsewhere.

The Verilog Hardware Description Language offers many more features than I could hope to cover in these pages. This page attempts to choose the most useful parts of the Verilog HDL and illustrate their use with simple examples.

A definitive description of the Verilog constructs used may be found in the Cadence Help on-line manual.

Structural Models

Verilog HDL supports a number of built in logic gates from which larger systems can be constructed. The basic gates are:

A simple strucural model is a netlist describing the interconnection of gates to create a module definition.

Structural Model of a D type flip-flop

The following file, dtype.v, is a structural model for the D type flip-flop:

`timescale 1ns / 100ps

// structural model of edge triggered D type

module dtype(Q, nQ, D, Clk, nRst);

output Q, nQ;
input D, Clk, nRst;

wire Q, nQ, D, Clk, nRst, net1, net2, net3, net4;

   nand #1 nand1 ( net1, net3, D, nRst );
   nand #1 nand2 ( net2, net1, net4 );
   nand #1 nand3 ( net3, Clk, net1, net4 );
   nand #1 nand4 ( net4, Clk, net2, nRst );
   nand #1 nand5 ( nQ, nRst, net3, Q );
   nand #1 nand6 ( Q, nQ, net4 );

endmodule

Major Features

This should exist at the top of each Verilog file. It declares the units for time delays within the file and also the maximum resolution for such delays.

The module...endmodule construct delimits the module definition.

The module line defines the name of the module and gives an ordered port list of the inputs and ouptuts. By convention the outputs are listed first.

Subsequent input and output statements are used to distiguish inputs from outputs.

Here all signals which will be used are declared as single bit wires. This section is optional since an undeclared signal is assumed to be a single bit wire.

Each gate instance line consists of a gate type, a gate delay parameter (in this case #1 indicating 1ns), a unique instance name by which we can distiguish the different gates and an ordered list of wires to be connected to the gate instance. The ordering of these wires should correspond exactly with the ordering of the ports of the gate; for all these gates the only requirement is that the output is listed before the inputs.

Simulation

The stimulus file for this HDL model is dtype_stim.v. The corresponding SimVision command script is dtype.tcl.

To simulate this design using the Xcelium simulator, copy the relevant files (dtype.v, dtype_stim.v & dtype.tcl.) to a suitable directory (e.g. ~/design/verilog/labs/model) and type the following at the unix command prompt:

xmverilog  +gui +access+r  dtype_stim.v  dtype.v  +tcl+dtype.tcl

If all goes well a waveform window should open:

The simulation can then be run by typing "run" at the ncsim> prompt in the simulator console window or by pressing the play button: in any of the SimVision windows. Finally select the full view icon, , to see the complete waveforms.

Structural Model of a 4-bit Counter

The following file, count.v, is a structural model for the counter:

`timescale 1ns / 100ps

// structural model of an "up only" counter

module count(count, up, clock, not_reset);

output [3:0] count;
input up, clock, not_reset;

   dtype dtype0 (count[0], nq0, d0, clock, not_reset);
   dtype dtype1 (count[1], nq1, d1, clock, not_reset);
   dtype dtype2 (count[2], nq2, d2, clock, not_reset);
   dtype dtype3 (count[3], nq3, d3, clock, not_reset);
   xor #1 xor0 (d0, count[0], up);
   xor #1 xor1 (d1, count[1], en1);
   and #1 and1 (en1, count[0], up);
   xor #1 xor2 (d2, count[2], en2);
   and #1 and2 (en2, count[1], en1);
   xor #1 xor3 (d3, count[3], en3);
   and #1 and3 (en3, count[2], en2);

endmodule

Major Features

More complex designs employ a hierarchy of structural models. This design defines a counter module in terms of basic gates and the d-type flipflop, which is a sub-module defined in the file dtype.v.

Thus we can redefine the stuctural model as a netlist describing the interconnection of gates and sub-modules to create a module definition.

Simulation

The stimulus file for this HDL model is count_stim.v and the corresponding SimVision command script is count.tcl.

Type the following at the unix command prompt:

    xmverilog  +gui +access+r  count_stim.v  count.v  dtype.v  +tcl+count.tcl

Then run the simulation ().

Behavioural Models

Verilog HDL supports a number of operators from which expressions can be constructed. The basic operators are:

Expressions can be used along with continuous assignment statements to provide behavioural models of combinational logic circuits.

More complex behavioural models, in particular those describing sequential circuits, will employ procedural assignments and more complex procedural statements. Such statements include descision statements such as if...else and case and even looping statements such as while and for.

Behavioural Model of a Window Comparator

The following file, window.v, is a behavioural model of a digital window comparator:

`timescale 1ns / 100ps

// behavioural model of a digital window comparator

module window(Too_High, OK, Too_Low,
                            Top_Limit, Value, Bottom_Limit);

output Too_High, OK, Too_Low;
input [3:0] Top_Limit, Value, Bottom_Limit;

wire Too_High, OK, Too_Low;
wire [3:0] Top_Limit, Value, Bottom_Limit;

   assign Too_High  =  Value >=  Top_Limit;
   assign  Too_Low  =  Value <=  Bottom_Limit;
   assign       OK  =  !Too_High && !Too_Low;

endmodule

Major Features

A single or multi-bit wire may have its value determined as the output of an expression using a continuous assignment statement. The assignment is described as continuous since the expression on the right hand side is continuously monitored allowing any changes to be propagated to the wire on the left hand side of the assignment.

Simulation

The stimulus file for this HDL model is window_stim.v and the corresponding SimVision command script is window.tcl.

Type the following at the unix command prompt:

xmverilog  +gui +access+r  window_stim.v  window.v  +tcl+window.tcl

Then run the simulation ().

Behavioural Model of a D type flip-flop

The following file, dff.v, is a behavioural model of a D type flip-flop:

`timescale 1ns / 100ps

// behavioural model of edge triggered D type

module dff(Q, D, Clk);

output Q;
input D, Clk;

reg Q;

   // action on clock rising edge
   always @(posedge Clk)
      Q = D;

endmodule

Major Features

Q is defined as a register. A register is assigned values at regular or irregular intervals. The register will remember the value assigned until the next time an assignment takes place.

All assignments to registers are procedural and hence must occur within an always or an initial procedure.

@(posedge Clk) is a event control. In this example we see that every time we have a rising edge on the Clk signal we will assign the value of D to the register Q. Between rising clock edges, Q remains unchanged regardless of any changes in the value of D.

This is the normal method for the description of a synchronous sequential system.

Simulation

The stimulus file for this HDL model is dff_stim.v and the corresponding SimVision command script is dff.tcl.

Type the following at the unix command prompt:

    xmverilog  +gui +access+r  dff_stim.v  dff.v  +tcl+dff.tcl

Then run the simulation ().

Behavioural Model of an Up/Down Counter

The following file, up_down_count.v, is a behavioural model of a 4-bit up/down counter:

`timescale 1ns / 100ps

// behavioural model of an up/down counter

module up_down_count(count, up, down, clock, not_reset);

output [3:0] count;
input up, down, clock, not_reset;

reg [3:0] count;

   always @(posedge clock or negedge not_reset)

      if (!not_reset)
         // asynchronous reset overrides synchronous action
         begin
            count <= 0;
         end
      else
         // action on clock rising edge
         begin
            if (up & ~down) count <= count + 1;
            if (down & ~up) count <= count - 1;
            if (up & down) count <= 0;
         end


endmodule

Major Features

The begin...end construct groups a number of statements that will be evaluated in sequence.

Note that an alternative construct fork...join which groups statements that will be evaluated in parallel is seldom used since it is unsynthesizable.

Note that it is usual to use a non-blocking procedural assignment, X <= Y, rather than a blocking procedural assignment, X = Y within a clock controlled begin...end construct (synthesis is of the former is much simpler). The non-blocking version evaluates all right hand side expressions in the sequence before assigning values to any of the left hand side registers.

The difference is indicated by the following piece of code which swaps the values of A and B:

begin
   A <= B;
   B <= A;
end

begin
   A = B;
   B = A;
end

Here we see that the event control, @(posedge clock or negedge not_reset), will wait for either a rising edge on clock or a falling edge on not_reset.

The subsequent code gives reset priority such that when reset is active, count is held at zero regardless of the clock or other inputs.

This is the normal strategy for the description of an asynchronous reset within a synchronous sequential system.

Simulation

The stimulus file for this HDL model is up_down_count_stim.v and the corresponding SimVision command script is up_down_count.tcl.

Type the following at the unix command prompt:

    xmverilog  +gui +access+r  up_down_count_stim.v  up_down_count.v  +tcl+up_down_count.tcl

Then run the simulation ( ).

Behavioural Model of a Microprocessor

The microprocessor is described in the following verilog files:

• processor.v
  • control.v
  • datapath.v
    • alu.v
  • memory.v
  opcodes.v

Major Features

Most complex behavioural models are constructed as a hierarchy of simpler behavioural models.

The Processor module instances the Control, Datapath and Memory modules. It is in fact merely a structural descrition of their interconnection:

control Control ( Data_bus, Address, Function, Mem_Write,
                                   ZFlag, Clock, notReset );
datapath Datapath ( Data_bus, ZFlag,
                                Function, Clock, notReset );
memory Memory ( Data_bus, Address, Mem_Write, Clock );

The Datapath module instances the ALU module but also contains the behavioural description of the Accumulator:

alu ALU ( zflag, ALU_output, Accumulator, data, opcode);

The following construct describes a multiplexor which selects input1 if select is `1' and input0 if select is `0':

assign out = (select) ? input1 : input0;

The Control module includes an address multiplexor based on this construct:

assign address = (state == `fetch_cycle) ?
                                  Program_Counter : operand;

The opcodes.v file declares constants to be used in other modules:

`define AND             4'd7
`define OR              4'd8
`define NOT             4'd9

The alu.v file includes the opcodes.v file and then uses the constants within the alu module:

`include "opcodes.v"
`timescale 1ns / 100ps

module alu( zflag, result, inputA, inputB, func);

         `AND           : result = inputA & inputB;
         `OR            : result = inputA | inputB;
         `NOT           : result = ~inputA;

endmodule

Simulation

The stimulus file for this HDL model is system.v and the corresponding SimVision command script is system.tcl.

Before simulating this design, first copy the stimulus file and the SimVision command script to a suitable directory and then create a sub directory called library into which you should copy the model files for the microprocessor. The appropiate simulation command is:

    xmverilog  +gui +access+r  -y library  +libext+.v  +incdir+library  system.v  +tcl+system.tcl

• The command names the stimulus file, system.v, but none of the microprocessor model files.
• The "-y library" option tells the simulator that other verilog files are located in the directory library.
• The "+libext+.v" option tells the simulator that library verilog files have a .v file extension.
• The "+incdir+library" option tells the simulator that any included files are also located in the directory library (in this example the only included file is opcodes.v).

Execute the simulation command and run the simulation ( ).