Parameter usage(Verilog-2001 VS Verilog-1995)

Let's set an example to indicate these differeces bewtween Verilog-1995 and Verilog-2001.

Example1 :

module myreg (q, d, clk, rst_n);
parameter Trst = 1,
Tckq = 1,
SIZE = 4,
VERSION = "1.1";
output [SIZE-1:0] q;
input [SIZE-1:0] d;
input clk, rst_n;
reg [SIZE-1:0] q;
always @(posedge clk or negedge rst_n)
if (!rst_n) q <= #Trst 0;
else q <= #Tckq d;
endmodule


module bad_wrapper (q, d, clk, rst_n);
output [7:0] q;
input [7:0] d;
input clk, rst_n;
// illegal parameter passing example
myreg #(.,.,8) r1 (.q(q), .d(d),
.clk(clk), .rst_n(rst_n));
endmodule

In order to use the parameter redefinition syntax when instantiating a module, all parameter values up to and including all values that are changed, must be listed in the myreg instantiation. For the module of Example 1, the first two parameter values must be listed, even though they do not change, followed by the new value for the
SIZE parameter, as shown in Example 2.

module good_wrapper (q, d, clk, rst_n);
output [7:0] q;
input [7:0] d;
input clk, rst_n;
// the first two parameters must be
// explicitly passed even though the
// values did not change
myreg #(1,1,8) r1 (.q(q), .d(d),
.clk(clk), .rst_n(rst_n));
endmodule

Aware of this limitation, engineers have frequently rearranged the order of the parameters to make sure that the most frequently used parameters are placed first in a module, similar to the technique described by Thomas and Moorby[4].

Despite the limitations of Verilog-1995 parameter redefinition, it is still the best supported and cleanest method for modifying the parameters of an instantiated
module. Verilog-2001 actually enhances the above parameter redefinition capability by adding the ability to pass the parameters by name, similar to passing port connections by name.

Example 2: to indicate how to instant myreg in Verilog-2001

module demuxreg (q, d, ce, clk, rst_n);
output [15:0] q;
input [ 7:0] d;
input ce, clk, rst_n;
wire [15:0] q;
wire [ 7:0] n1;
not u0 (ce_n, ce);
regblk #(.SIZE( 8)) u1
(.q(n1), .d (d), .ce(ce),
.clk(clk), .rst_n(rst_n));
regblk #(.SIZE(16)) u2
(.q (q), .d({d,n1}), .ce(ce_n)
.clk(clk), .rst_n(rst_n));
endmodule
module regblk (q, d, ce, clk, rst_n);
parameter SIZE = 4;
output [SIZE-1:0] q;
input [SIZE-1:0] d;
input ce, clk, rst_n;
reg [SIZE-1:0] q;
always @(posedge clk or negedge rst_n)
if (!rst_n) q <= 0;
else if (ce) q <= d;
endmodule

Verilog “wait” Statement usage

The wait Statement

Definition

The wait statement is used as a level-sensitive control. The syntax is:

wait (expression) statement

The processor waits when the expression is FALSE. When the expression is TRUE, the statement is executed.

The expression is treated as a Boolean value, therefore wait responds to TRUE and FALSE only. Values '0', 'x' and 'z' are FALSE. Logic '1' is TRUE.

Comparison Between Event and Level Sensitive Processes

An example of an event-driven control is given below as a comparison to the level-sensitive control which will be described later.

always @(start) #10 go = ~go;

This process uses the @(expression) to trigger the process. The statement will be executed whenever there is an event on the start signal.

In comparison the following example illustrates a level-sensitive control:

forever wait(start) #10 go = ~go;

The process waits until start is `1'. When the start expression is TRUE, the go signal toggles after 10 time units. If start continues to stay `1' then go will continue to toggle after every 10 time units due to the forever definition. The toggling statement will only stop when start returns to `0'.

An event sensitive process is triggered by the edge on a control signal, while a level sensitive process is triggered by the value on the control signal.

Applications Of The wait Statement

The wait statement can be used to:

* Synchronise concurrent processes
* Hand shake between concurrent processes

The above example of a wait statement is also an example of synchronising. If more than one process is controlled by the start signal in a similar manner to that above, then when start goes high, several processes will start to run together. Thus they have been synchronised using the start signal.

The following is an example of hand shaking. The waveform below also refers to this example.

Process 1:

always begin
read = 1;
forever begin
wait (write)
// manipulate data
storeddata = datain;
#10;
read = 0;
wait (!write)
read = 1;
end // forever begin
end // always begin

Process 2:

always begin
write = 0;
forever begin
wait (read)
datain = $random;
$display($time, "datain = %b", datain);
// data read in
write = 1;
wait (!read)
write = 0;
end // forever begin
end // always begin

Both the processes run concurrently, so read and write are initialised to '1' and '0' respectively. Process 1 then waits for a '1' on the write signal. Process 2 is waiting for a '1' on the read signal. Because read is initialised to '1', process 2 continues (A). The data coming in is stored in a temporary register called datain. The write signal is then changed to a '1' to signify that the input data has been read (B). Process 2 is now waiting for the read signal to become '0'.

Process 1 is triggered by write being '1'. The data in the temporary register can now be safely manipulated and then written to another register called storeddata. When this process has completed, read is set to '0' to signify that the data has been successfully transferred (C). This triggers process 2 which has been waiting for read to go to '0'. Process 2 changes write to '0' to say it is ready to receive data whenever process 1 is ready (D). This triggers the last wait statement in process 1 to change read to '1'. The two processes are now back in their initial states and waiting to repeat the above procedure.

This hand shaking method avoids process 1 trying to manipulate the incoming data before it has been fully received. It also stops process 2 reading in more data before process 1 has finished with the previously read data.

The Difference Between wait And while

The wait statement should not be confused with the while statement. Two examples are given below:

always begin always begin
wait(start) while(start)
go = 1; go = 1;
stop = 0; stop = 0;
end end

The wait statement will halt the process when start = '0'. The whole process will not procede until the start expression is TRUE. When start = '1', go will be set to '1' and then stop will be set to '0'.

The while statement will not set go to '1' unless start is '1'. If start is '0', the while statement will not set go to '1' but stop will be set to '0'. The while statement does not stop the whole process. It only stops the statement within the while loop from being executed.

Summary

The wait statement can be used for synchronising or hand shaking between concurrent processes as shown in the examples above. The process waits until the expression is true. It then executes the statement.

Differences between Tasks and Functions

Tasks and functions serve different purposes in Verilog. We discuss tasks and functions in greater detail in the following sections. However, first it is important to understand differences between tasks and functions, as outlined in the following.

A function can enable another function but not another task.
A task can enable other tasks and functions.

Functions always execute in 0 simulation time.
Tasks may execute in non-zero simulation time.

Functions must not contain any delay, event, or timing control statements.
Tasks may contain delay, event, or timing control statements.

Functions must have at least one input argument. They can have more than one input.
Tasks may have zero or more arguments of type input, output, or inout.

Functions always return a single value. They cannot have output or inout arguments.
Tasks do not return with a value, but can pass multiple values through output and inout arguments.



Both tasks and functions must be defined in a module and are local to the module. Tasks are used for common Verilog code that contains delays, timing, event constructs, or multiple output arguments. Functions are used when common Verilog code is purely combinational, executes in zero simulation time, and provides exactly one output. Functions are typically used for conversions and commonly used calculations.

Tasks can have input, output, and inout arguments; functions can have input arguments. In addition, they can have local variables, registers, time variables, integers, real, or events. Tasks or functions cannot have wires. Tasks and functions contain behavioral statements only. Tasks and functions do not contain always or initial statements but are called from always blocks, initial blocks, or other tasks and functions.

$test$plusagrs systme function in verilog-2001

Verilog allows users to create new simulation invocation options.

The $test$plusargs system function checks to see if a “plus” option was used when simulation was invoked.

Example : NCverilog test.vchip.v +test2

Pattern file code can be writen as the followings:

initial
begin
if($test$plusargs(“test1”))
$readmemh(“test1.dat”,vectors);
elseif($test$plusargs(“test2”))
$readmemh(“test2.dat”,vectors);
elseif($test$plusargs(“test3”))
$readmemh(“test3.dat”,vectors);
else $display(“Error:notestoptionspecified”);
end