Timing Check Tasks

Formal Definition

Timing Check Tasks are for verification of timing properties of designs and for reporting timing violations.

Simplified Syntax

$setup (data_event, reference_event, limit[, notifier]) ;

$skew (reference_event, data_event, limit[,notifier]) ;

$hold (reference_event, data_event, limit[,notifier]) ;

$recovery (reference_event, data_event, limit, [notifier]) ;

$setuphold (reference_event, data_event, setup_limit, hold_limit, [notifier]) ;

$width (reference_event, limit, threshold [,notifier]) ;

$period (reference_event, limit[,notifier]) ;

$nochange (reference_event, data_event, start_edge_offset, end_edge_offset [,notifier]) ;

Description

Timing check tasks are invoked every time critical events occur within given time limits. See the table below with descriptions of all arguments:

Argument	Description	Type
Reference_event	The transition at a control signal that establishes the reference time for tracking timing violations on the data_event	Module input or inout that is scalar or vector net
Data_event	The signal change that initiates the timing check and is monitored for violations.	Module input or inout that is scalar or vector net
Limit	A time limit used to detect timing violations on the data_event	Constant expression or specparam
Threshold	The largest pulse width that is ignored by the timing check $width	Constant expression or specparam
Setup_limit	A time limit used to detect timing violations on the data_event for $setup.	Constant expression or specparam
Hold_limit	A time limit used to detect timing violations on the data_event for $hold.	Constant expression or specparam
Notifier	An optional argument that "notifies" the simulator when a timing violation occurs	Register

$setup checks setup time. When modeling synchronous circuits, flip-flops need time to force a correct value. Data cannot change within the setup time because flip-flops cannot detect the new value. If data changes within a given time limit, $setup reports a timing violation. If a data event and reference event occur at the same time there is no violation. The$setup first checks timing data then records a new data value. The formula to report a timing violation is as shown below:

(time of reference event) - (time of data event) < limit

Notice that the limit argument has to be a positive number.

$skew checks the following:

(time of data event) - (time of reference event) > limit

$skew can be used to check synchronicity of clocks inside a circuit. If different clocks are used in a design and are synchronized, $skew will report a timing violation when the active edge of one of them occurs outside the time limit allowed for the other clock to occur.

When the data event and the reference event occur at the same time, $skew will not report a timing violation.

$hold will report a timing violation if the following formula is true:

(time of data event) - (time of reference event) < limit

$hold simply checks that data is stable in the specified interval of time after the edge of the clock. In flip-flops, data should remain stable for a given time after the active edge of the clock to allow for propagation of data.

Also, a violation will be reported if the data event and the reference event occur at the same time.

$recovery responds when the following formula is true:

(time of data event) - (time of reference event) < limit

The 'reference_event' must be an edge-triggered event: posedge or negedge. A timing violation occurs if the time interval between an edge-triggered reference event and a data event exceeds the 'limit'. If a reference event and data event occur at the same time, a timing violation is reported. If a 'reference_event' argument is specified without edge specification, an error is reported.

$setuphold checks setup and hold timing violations. This task combines the functionality of $setup and $hold in one task. The following formula has to be applied:

setup_limit + hold_limit > 0

'reference_event' have to be one of the following:

1. $hold lower bound event
2. $setup upper bound event

'data_event' have to be one of the following:

1. $hold upper bound event
2. $setup lower bound event

In $width both limit and threshold have to be positive numbers. The 'reference_event' must be the edge specification, otherwise an error will be reported. The 'data_event' is not specified directly, but by default means 'reference_event' with opposite edge. A timing violation occurs with the following formula:

threshold < (time of data event) - (time of reference event) < limit

$width reports when width of the active-edge is too small. In FF case it is very important to ensure that the width of an active-edge is sufficient and FF will work properly.

The $period checks that a period of signal is sufficiently long. The reference_event has to be an edge specification. The data_event is not specified directly and by default, is the same as a reference_event. The $period reports a timing violation when the following formula comes true:

(time of data event) - (time of reference event) < limit

The $nochange checks if the data signal is stable in an interval of start_edge_offset and end_edge_offset. If the signal has changed, a timing violation is reported. The reference_event argument can be posedge or negedge but the edge control specifiers are disallowed.

Examples

Example 1

module setup (data1, data2, q);
input data1, data2;
output q;
and (q, data1, data2);
specify
specparam tsetup = 7, delay = 10 ;
(data1 => q) = 10 ;
$setup(data1, posedge data2, tsetup);
endspecify
endmodule

Example 2

module two_clocks (clk1, clk2, q);
input clk1, clk2;
output q;
specify
  specparam tskew = 7;
  $skew(posedge clk1, posedge clk2, tskew);
endspecify
endmodule

Example 3

module hold (data1, data2, q);
input data1, data2;
output q;
and (q, data1, data2);
specify
specparam thold = 7, delay = 10 ;
(data1 => q) = 10 ;
$hold(posedge data2, data1, thold);
endspecify
endmodule

Example 4

module recovery (in1, out1);
input in1 ;
output out1 ;
assign out1 = in1 ? 1'b1 : 1'bz ;
specify
  specparam trecovery = 10;
  $recovery(posedge in1, out1, trecovery);
endspecify
endmodule

Example 5

module setuphold (data1, data2, q);
input data1, data2;
output q;
and (q, data1, data2);
specify
specparam tsetup = 7,
thold = 7,
delay = 10 ;
(data1 => q) = 10 ;
$setuphold(posedge data2, data1, tsetup, thold);
endspecify
endmodule

Example 6

module width (data1, data2, q);
input data1, data2;
output q;
and (q, data1, data2);
specify
specparam twidth = 10,
delay = 10 ;
(data2 => q) = 10 ;
$width(posedge data2, twidth);
endspecify
endmodule

Example 7

module dff (clk, q);
input clk;
output q;
buf (q, clk);
specify
  specparam tperiod = 100 ;
  $period(posedge clk, tperiod);
endspecify
endmodule

Example 8

module nochange (data1, data2, q);
input data1, data2;
output q;
and (q, data1, data2);
specify
specparam tstart = -5,
tend = 5 ;
$nochange(posedge data2, data1, tstart, tend);
endspecify
endmodule

Important Notes

• All timing check system tasks should be invoked within specify blocks.

Timescale System Tasks

Formal Definition

Timescale system tasks provide a means of setting and printing timescale information.

Simplified Syntax

$printtimescale [(hierarchical_path)] ;

$timeformat [(unit_number, precision, suffix, min_width )] ;

Description

The $printtimeformat system task is used when information about time units and precision is needed. An argument is optional. When the $printtimescale system task is invoked without an argument, the time unit and precision of the current modules are displayed. If an argument is specified, then the time unit and precision of the module specified is displayed in a hierarchical path. The following format is used to display this information:

Time scale of (module) is unit / precision

The $timeformat system task has double functionality.

First, when any delays are entered interactively, it specifies the time unit. Second, it specifies the %t format specification. These format specifications are used in $display, $fdisplay, $write, $fwrite, $strobe, $fstrobe and $monitor, $fmonitor system tasks.

The first argument of $timeformat system task should be an integer.

Unit	Time	Unit	Time
0	1 s	-8	10 ns
-1	100 ms	-9	1 ns
-2	10 ms	-10	100 ps
-3	1 ms	-11	10 ps
-4	100 us	-12	1 ps
-5	10 us	-13	100 fs
-6	1 us	-14	10 fs
-7	100 ns	-15	1 fs

Default argument values are given in the following table:

Argument	Value
Unit	The smallest time precision argument of all the `timescale compiler directives in the source description
Precision	0
Suffix	Null
Minimum width	20

Examples

Example 1

`timescale 1 ns / 100 ps
module a (y, a, b);
  output y;
  input a, b;
  assign y = a & b;
endmodule
`timescale 1 s / 10 fs
module top;
  wire y, a, b;
  a u(y, a, b);
  initial $printtimescale(top.u);
endmodule

Important Notes

• The $timeformat system task specifies the %t format specification until the next `timescale compiler directive occurs.

initial $timeformat(-9, 5, " ns", 10);
/* $timeformat [ ( n, p, suffix , min_field_width ) ] ;
units = 1 second ** (-n), n = 0->15, e.g. for n = 9, units = ns
p = digits after decimal point for %t e.g. p = 5 gives 0.00000
suffix for %t (despite timescale directive)
min_field_width is number of character positions for %t */

Tasks

Formal Definition

Tasks provide a means of splitting code into small parts. Often tasks consist of frequently used functionalities.

Simplified Syntax

task identifier;

  parameter_declaration;

  input_declaration;

  output_declaration;

  inout_declaration;

  register_declaration;

  event_declaration;

  statement;

endtask

Description

Task definition begins with the keyword task and ends with the keyword endtask. A task should be followed by a task identifier and end with a semicolon. A task can contain a declaration of parameters, input arguments, output arguments, inout arguments, registers and events (these declarations are similar to module items declaration) but they are not required. Net declaration is illegal.

A task can contain zero or more behavioral statements, e.g. case statement, if statement. A begin-end block is required for bracketing multiple statements.

The task enabling statement should be made up of a task identifier and the list of comma-separated task arguments. The list of task arguments should be enclosed in parenthesis. If the task does not contain any argument declarations, then it should be enabled by specifying its identifier followed by a semicolon (Example 2).

The list of task enabling arguments should correspond exactly to the list of task arguments. If a task argument is declared as an input, then a corresponding argument of the task enabling statement can be any expression. If a task argument is declared as an output or an inout then the corresponding argument of the task enabling statement should be one of the following items:

• Register data types
• Memory references
• Concatenations of registers or memory references
• Bit-selects and part-selects of reg, integer and time registers

Only the last assignment to an output or an inout argument is passed to the corresponding task enabling arguments. If a task has assignments to global variables, then all changes of these variables are effective immediately.

Tasks can enable others tasks (Example 3) and functions. A task may be enabled several times in a module. If one task is enabled concurrently, then all registers and events declared in that task should be static, i.e., one variable for all instances.

A task can contain time-controlling statements. A task does not return a value by its name.

Examples

Example 1

task first_task;
  parameter size = 4;
  input a;
  integer a;
  inout [size-1:0] b;
  output c;
  reg [size-1:0] d;
  event e;
begin
  d = b;
  c = |d;
  b = ~b;
if (!a) -> e;
  end
endtask

This is an example of using parameters, input arguments, inout arguments, output arguments, registers and events within tasks. The 'a' argument is declared as an input and as an integer data type.

'First_task' can be enabled as follows:

integer x;
reg a, b, y;
reg [3:0] z;
reg [7:0] w;
first_task(x, z, y);
first_task(x, w[7:4], w[1]);
first_task(1, {a, b, w[3], x[0]}, y);

When being enabled, the first argument of the 'first_task' should be an integer data type expression, the second should be a 4-bit register expression, and the last argument should be 1-bit register expression.

Example 2

reg a, b;
task my_task; // task definition
begin
  a = 1'b1;
  b = 1'bx;
end
endtask
my_task; // task enabling

If 'my_task' is enabled then it will change the value of global variables 'a' and 'b'.

Example 3

task negation;
  inout data;
  data = ~data;
endtask
task my_nor;
  input a, b;
  output c;
  begin
  negation(a);
  negation(b);
  c = a & b;
  end
endtask

The 'my_nor' task enables negation tasks.

Important Notes

• A task can contain time-controlling statements
• A task does not return any value by its name

Structured Procedures

Formal Definition

Structured procedures provide a means of modeling blocks of procedural statements.

Simplified Syntax

always statement

initial statement

function

task

Description

Functions and tasks are described in the section: Task and Functions.

The initial statement (Example 1) is executed only during a simulation run. The always procedural block statement (Example 2) is executed continuously during simulation, i.e. when the flow of program reaches the last statement in the block, the flow continues with the first statement in the block.

The always statement should contain at least one procedural timing control because otherwise it may hang the simulation.

Module definition can contain more than one initial or always statement.

Care must be taken when same reg type variables are used in multiple procedural blocks, initial or always. This is because these blocks run in parallel and changing or assigning to one variable affects the same variable in another parallel block.

Examples

Example 1

initial out = 1'b0;
initial begin
  #10;
  a = 1'b0;
  #10;
  a = 1'b1;
  #10;
  a = 1'bz;
end

Example 2

always @(posedge clk)
q = d;
always #10 clk = ~clk;
initial clk = 0;
initial repeat(20)#\10 clk=~clk;

The first initial statement sets clk to 0 at time 0, and the second initial block toggles the clk 20 times every 10 time units.

Important Notes

· The always statement should contain at least one procedural timing control.

Strings

Formal Definition

The strings are sequences of 8-bit ASCII characters enclosed within quotation marks.

Simplified Syntax

"This is a string"

reg [8*number_of_characters:1] string_variable;

Description

The string should be given in one line. Strings can contain special characters (Example 1).

Character	Meaning
\n	New line character
\t	Tab character
\\	\ character
\”	" character
\ddd	A character specified by octal digit

Table 24: Summary of special characters

String variables should be declared as reg type vectors (Example 2). Each character needs 8 bits.

If a string variable is used in an expression, it should be treated as an unsigned value. If the size of a string assigned to a string variable is smaller than the declared size of the variable, then it will be left-padded with zeros.

The null string "” should be treated same as "\0”.

Concatenations of string variables preserve left-padded zeros of these variables (Example 3).

Examples

Example 1

"\n This is the first line\n This is the second line"
"\t Line\t with\t tab\t characters"

Example 2

reg [8*12:1] message;

The message variable can contain 12 characters.

Example 3

reg [10*8:1] s1, s2;
s1 = "Verilog";
s2 = "-HDL";
{s1, s2} <> {"Verilog", "-HDL"}

These expressions are not equal because {s1, s2} has 0s between "Verilog” and "-HDL” and {"Verilog”, "-HDL”} does not have any 0s between words.

Important Notes

• Concatenation of string variables preserves left-padded zeros of these variables.

Strengths

Formal Definition

The strength declaration construct is used for modeling net type variables for a close correspondence with physical wires.

Simplified Syntax

(Strength1, Strength0)
(Strength0, Strength1)
Strength1:
supply1, strong1, pull1, large1, weak1, medium1, small1, highz1
Strength0:
supply0, strong0, pull0, large0, weak0, medium0, small0, highz0

Description

Strengths can be used to resolve which value should appear on a net or gate output.

There are two types of strengths: drive strengths (Example 1) and charge strengths (Example 2). The drive strengths can be used for nets (except trireg net), gates, and UDPs. The charge strengths can be used only for trireg nets. The drive strength types are supply, strong, pull, weak, and highz strengths. The charge strength types are large, mediumand small strengths.

All strengths can be ordered by their value. The supply strength is the strongest and the highz strength is the weakest strength level. Strength value can be displayed by system tasks ($display, $monitor - by using of the %v characters - see Display tasks for more explanation).

Strength	Value	Value displayed by display tasks
supply	7	Su
strong	6	St
pull	5	Pu
large	4	La
weak	3	We
medium	2	Me
small	1	Sm
highz	0	HiZ

Table 23 Strengths ordered by value

If two or more drivers drive a signal then it will have the value of the strongest driver (Example 3).

If two drivers of a net have the same strength and value, then the net result will have the same value and strength (Example 4).

If two drivers of a net have the same strength but different values then signal value will be unknown and it will have the same strength as both drivers (Example 5).

If one of the drivers of a net has an H or L value, then signal value will be n1n2X, where n1 is the strength value of the driver that has the smaller strength, and n2 is strength value of driver that has the larger strength (Example 6).

The combinations (highz0, highz1) and (highz1, highz0) are illegal.

Examples

Example 1

and (strong1, weak0) b(o, i1, i2);

Instance of and gate with strong1 strength and weak0 strength specified.

Example 2

trireg (medium) t;

The charge strength declaration for trireg net.

Example 3

buf (strong1, weak0) g1 (y, a);
buf (pull1, supply0) g2 (y, b);

If a = 0 and b = 0 then y will be 0 with supply strength because both gates will set y to 0 and supply (7) strength has bigger value than weak (3) strength.

If a = 0 and b = 1 then y will be 1 with pull strength because g1 will set y to 0 with weak (3) strength and g2 will set y to 1 with pull (5) strength (pull strength is stronger than the weak strength).

If a = 1 and b = 0 then y will be 0 with supply strength because g1 will set y to 1 with strong (6) strength and g2 will set y to 0 with supply (7) strength (supply strength is stronger than the strong strength).

If a = 1 and b = 1 then y will be 1 with strong strength because g1 will set y to 1 with strong (6) strength and g2 will set y to 1 with pull (5) strength.

Example 4

buf (strong1, weak0) g1 (y, a);
buf (strong1, weak0) g1 (y, b);

If a = 0 and b = 0 then y will be 0 with weak strength.

If a = 1 and b = 1 then y will be 1 with strong strength.

Example 5

buf (strong1, weak0) g1 (y, a);
buf (weak1, strong0) g1 (y, b);

If a = 1 and b = 0 then y will be x with strong strength.

Example 6

bufif0 (strong1, weak0) g1 (y, i1, ctrl);
bufif0 (strong1, weak0) g2 (y, i2, ctrl);

If ctrl = x, i1 = 0, and i2 = 1 then y will be x with 36X strength, because g1 will set y to L with strong strength (StL - 6) and g2 will set y to H with weak strength (WeH - 3).

Important Notes

• If one of the drivers has an H or L value, then the output value will be X.

Module Instantiation