Verilog language reference manual LRM

Verilog was started initially as a proprietary hardware modeling language by Gateway Design Automation Inc. around 1984. It is rumored that the original language was designed by taking features from the most popular HDL language of the time, called HiLo, as well as from traditional computer languages such as C. At that time, Verilog was not standardized and the language modified itself in almost all the revisions that came out within 1984 to 1990.

Verilog simulator was first used beginning in 1985 and was extended substantially through 1987. The implementation was the Verilog simulator sold by Gateway. The first major extension was Verilog-XL, which added a few features and implemented the infamous "XL algorithm" which was a very efficient method for doing gate-level simulation.

The time was late 1990. Cadence Design System, whose primary product at that time included Thin film process simulator, decided to acquire Gateway Automation System. Along with other Gateway products, Cadence now became the owner of the Verilog language, and continued to market Verilog as both a language and a simulator. At the same time, Synopsys was marketing the top-down design methodology, using Verilog. This was a powerful combination.

In 1990, Cadence recognized that if Verilog remained a closed language, the pressures of standardization would eventually cause the industry to shift to VHDL. Consequently, Cadence organized the Open Verilog International (OVI), and in 1991 gave it the documentation for the Verilog Hardware Description Language. This was the event which "opened" the language.

OVI did a considerable amount of work to improve the Language Reference Manual (LRM), clarifying things and making the language specification as vendor-independent as possible.

Soon it was realized that if there were too many companies in the market for Verilog, potentially everybody would like to do what Gateway had done so far - changing the language for their own benefit. This would defeat the main purpose of releasing the language to public domain. As a result in 1994, the IEEE 1364 working group was formed to turn the OVI LRM into an IEEE standard. This effort was concluded with a successful ballot in 1995, and Verilog became an IEEE standard in December 1995.

When Cadence gave OVI the LRM, several companies began working on Verilog simulators. In 1992, the first of these were announced, and by 1993 there were several Verilog simulators available from companies other than Cadence. The most successful of these was VCS, the Verilog Compiled Simulator, from Chronologic Simulation. This was a true compiler as opposed to an interpreter, which is what Verilog-XL was. As a result, compile time was substantial, but simulation execution speed was much faster.

In the meantime, the popularity of Verilog and PLI was rising exponentially. Verilog as a HDL found more admirers than well-formed and federally funded VHDL. It was only a matter of time before people in OVI realized the need of a more universally accepted standard. Accordingly, the board of directors of OVI requested IEEE to form a working committee for establishing Verilog as an IEEE standard. The working committee 1364 was formed in mid 1993 and on October 14, 1993, it had its first meeting.

The standard, which combined both the Verilog language syntax and the PLI in a single volume, was passed in May 1995 and now known as IEEE Std. 1364-1995.

After many years, new features have been added to Verilog, and the new version is called Verilog 2001. This version seems to have fixed a lot of problems that Verilog 1995 had. This version is called 1364-2001.

Timeline:

1984 Verilog-XL simulator and language developed by Gateway Design Automation
1987 Synopsys introduced a Verilog based synthesis tool.
1989 Cadence Design Systems acquired Gateway, and Verilog.
1990 Cadence placed the Verilog language in the public domain.
1995 Verilog HDL became (IEEE Std 1364-1995).
1997 Verilog VCS bought by Viewlogic
1997 Viewlogic bought by Synopsys
1998 Synopsys issues Verilog VCS
2001 A significantly revised version was published in 2001.

DOWNLOAD VERIOG LRM

Intel Is Cooling Entire Servers By Submerging Them in Oil

Air cooled computers are for wimps. But while the idea of keeping temperatures in check using water might be a step in the right direction, Intel is doing something even more radical: it's dunking entire servers—the whole lot—into oil to keep them chill.

Don't panic, though: they're using mineral oil, which doesn't conduct electricity. It's a pretty wacky idea, but it seems to be working. After a year of testing with Green Revolution Cooling, Intel has observed some of the best efficiency ratings it's ever seen. Probably most impressive is that immersion in the oil doesn't seem to affect hardware reliability.

All up, it's extremely promising: completely immersing components in liquid means you can pack components in more tightly as the cooling is so much more efficient. For now, though, it's probably best to avoid filling your computer case with liquid of any kind.

Get free daily email updates!

Follow us!

Vectors

Formal Definition

Vectors are multiple bit widths net or reg data type variables that can be declared by specifying their range.

Simplified Syntax

net_type [msb:lsb] list_of_net_identifiers;

reg [msb:lsb] list_of_register_identifiers;

Description

Vector range specification contains two constant expressions: the msb (most significant bit) constant expression, which is the left-hand value of the range and the lsb (least significant bit) constant expression, which is the right-hand value of the range. The msb and lsb constant expressions should be separated by a colon.

Both the msb constant expression and the lsb constant expression can be any value - positive, negative, or zero. The lsb constant expression can be greater, equal or less than the msb constant expression.

Vectors can be declared for all types of net data types and for reg data types. Specifying vectors for integer, real, realtime, and time data types is illegal.

Vector nets and registers are treated as unsigned values (see: Arithmetic expressions with registers and integers for more explanations).

Examples

Example 1

reg [3:0] addr;

The 'addr' variable is a 4-bit vector register made up of addr[3] (the most significant bit), addr[2], addr[1], and addr[0] (the least significant bit).

Example 2

wire [-3:4] d;

The d variable is 8-bit vector net made up of d[-3] (msb), d[-2], d[-1], d[0], d[1], d[2], d[3], d[4] (lsb).

Example 3

tri [5:0] x, y, z;

The above line declares three 6-bit vectors.

Important Notes

• Both the msb and the lsb expressions should be constant expressions.
• The msb and the lsb constant expressions may be positive, negative, or zero.
• The lsb constant expression may be greater, equal or less than the msb constant expression.
• Vectors can be declared only for nets and reg data types.
• Vector declaration for integer, real, realtime, and time data types are illegal.

Value Change Dump (VCD) File

Formal Definition

The Value change dump (VCD) file contains information about any value changes on the selected variables.

Simplified Syntax

$dumpfile(name)

$dumpvars

$dumpvars(level, list_of_variables_or_modules)

$dumpoff

$dumpon

$dumpall

$dumplimit

$dumpflush

Description

$dumpfile(filename)

This task is used to specify the VCD file name. The filename parameter is optional. If it is not given, then the file will be named "Verilog.dump”.

$dumpvars(level, list_of_variables_or_modules)

This task is used to specify which variables should be dumped. Both parameters are optional and if none are used, then all variables will be dumped.

If level = 0, then all variables within the modules from the list will be dumped. If any module from the list contains module instances, then all variables from these modules will also be dumped.

If level = 1, then only listed variables and variables of listed modules will be dumped.

$dumpoff

This task stops the dumping of variables. All variables are dumped with x value and all next changes of variables will not be dumped.

$dumpon

This task starts previously stopped dumping of variables.

$dumpall

When this task is used, then the current value of all dumped variables will be written to file.

$dumplimit(filesize)

This task can set the maximum size of the VCD file.

$dumpflush

This task can be used to make sure that all changes of dumped variables are written to file.

Examples

module top;
reg a, b;
wire y;
assign y = a & b;
always begin
  a = 1'b0;
  #10;
  a = 1'b1;
  #10;
  a = 1'bx;
  #10;
end
always begin
  b = 1'b0;
  #30;
  b = 1'b1;
  #30;
  b = 1'bx;
  #30;
end
initial begin
  $dumpfile("test.txt");
  $dumpvars(1,a,y);
  #200;
  $dumpoff;
  #200;
  $dumpon;
  #20;
  $dumpall;
  #10;
  $dumpflush;
end
endmodule

The dumpfile will contain only changes of 'a' and 'y' variables. After 200 time units, dumping will be suspended for 200 time units. Next, dumping will start again and after 20 time units, all variables will be dumped.

Important Notes

• Value change dump file can be used for hierarchical monitoring of all signal changes within design modules.

UDP State Table

Formal Definition

A UDP state table defines the behavior of UDP.

Simplified Syntax

table

  comb_input comb_input ... comb_input : output;

  seq_input seq_input ... seq_input : current_state : next_state;

endtable

Description

Each row of the state table defines the behavior of the UDP for a specific input combination. Each combination of inputs can be given only one time. It is illegal to define the same combination of inputs for different outputs.

The number of input values must match the number of UDP inputs in a port declaration.

The UDP state table for combinational and sequential UDPs is different. The combinational UDPs (Example 1) contain two fields: an input field and an output field. The sequential UDPs (Example 2) contain three fields: an input, a current state, and the next state (output) field.

The input field should contain a list of values (separated by white spaces), which should match the number of UDP input ports. The order of these ports is highly important. The first input port on the UDP port list matches the first input value in each row.

The rows of the state table can contain only 0, 1, unknown (x) value, and special characters. The high-impedance (z) value cannot be specified. The special characters are provided to increase readability of a description and to make it easier (Example 3).

Symbol	Interpretation	Comments
0	Logic 0
1	Logic 1
x	Unknown value	Not permitted in output field.
b	Substitute for 0 and 1	Not permitted in output field.
?	Substitute for 0, 1, and x	Not permitted in output field.
-	No change	Permitted only in output field of sequential UDPs.
(vw)	Transition from v to w value	Permitted only in input field of sequential UDPs. v and w can be 0, 1, x, b, and ?
*	Same as (??)	Any value change on input. Permitted only in input field of sequential UDPs.
r	Same as (01)	Rising edge on input. Permitted only in input field of sequential UDPs.
f	Same as (10)	Falling edge on input. Permitted only in input field of sequential UDPs.
p	Same as (01), (0x), (x1)	Positive edge on input. Permitted only in input field of sequential UDPs.
n	Same as (10), (1x), (x0)	Negative edge on input. Permitted only in input field of sequential UDPs.

Table 25: Summary of symbols

If some combinations of input signal values are not specified in a UDP state tables then the output value will be unknown (x).

Only one transition can appear in each row of sequential UDPs.

Examples

Example 1

primitive mux (o, i3, i2, i1, i0, a1, a0);

output o;
input i3, i2, i1, i0, a1, a0;
table
// i3 i2 i1 i0 a1 a0 : o;
0 ? ? ? 1 1 : 0;
1 ? ? ? 1 1 : 1;
? 0 ? ? 1 0 : 0;
? 1 ? ? 1 0 : 1;
? ? 0 ? 0 1 : 0;
? ? 1 ? 0 1 : 1;
? ? ? 0 0 0 : 0;
? ? ? 1 0 0 : 1;
endtable
endprimitive

If any address bit (a1, a0) is unknown, then the output value will be unknown (because there is no row which describes the output value for this combination of address signals).

If a1 = 0 and a0 = 0 then the signal from input i0 is driven to output (value of others inputs does not matter).

If a1 = 0 and a0 = 1 then signal from input i1 is driven to the output.

If a1 = 1 and a0 = 0 then signal from input i2 is driven to the output.

If a1 = 1 and a0 = 1 then signal from input i3 is driven to the output.

Example 2

primitive special_d_ff (q, clk, m, d, rst, set);
output q;
reg q;
input clk, m, d, rst, set;
table
// clk m d rst set : current : next;
// positive edge on clk and normal mode (m = 0)
(01) 0 0 0 0 : ? : 0 ; // line 1
(0x) 0 0 0 0 : ? : 0 ; // line 2
(x1) 0 0 0 0 : ? : 0 ; // line 3
(01) 0 1 0 0 : ? : 1 ; // line 4
(0x) 0 1 0 0 : ? : 1 ; // line 5
(x1) 0 1 0 0 : ? : 1 ; // line 6
// positive edge on clk and negation mode (m = 1)
p 1 ? 0 0 : 0 : 1 ; // line 7
p 1 ? 0 0 : 1 : 0 ; // line 8
// negative edge on clk and any mode (m = 0 or m = 1)
n ? ? 0 0 : ? : - ; // line 9
// reset
? ? ? 1 ? : ? : 0 ; // line 10
// preset
? ? ? 0 1 : ? : 1 ; // line 11
// any changes on inputs with no changes on clk
? * ? ? ? : ? : - ; // line 12
? ? * ? ? : ? : - ; // line 13
? ? ? * ? : ? : - ; // line 14
? ? ? ? * : ? : - ; // line 15
endtable
endprimitive

This is 'd' flip-flop with an additional input, which can convert it into a modulo 2 counter.

If m = 0 then this UDP works as a normal 'd' flip-flop (lines 1-6), but if m = 1 then it negates its current value (lines 7 and 8). If any falling edge occurs on the clk input, then it will not change the output (line 9). If rst is 1, then the output will go to 0 (line 10). If the rst is 0 and set is 1, then the output will go to 1 (line 11 - it means that rst has higher priority than set).

Any changes on the data input will not cause any changes on output (lines 12-15).

Example 3

primitive circuit_1 (o, i1, i2, i3);
output o;
input i1, i2, i3;
table
0 0 0 : 1 ;
0 0 1 : 1 ;
0 0 x : 1 ;
0 1 0 : 1 ;
0 1 1 : 1 ;
0 1 x : 1 ;
1 0 0 : 0 ;
1 0 1 : 0 ;
1 0 x : 0 ;
1 1 0 : 1 ;
1 1 1 : 1 ;
1 1 x : 1 ;
x 0 0 : 0 ;
x 0 1 : 0 ;
x 0 x : 0 ;
x 1 0 : 0 ;
x 1 1 : 0 ;
x 1 x : 0 ;
endtable
endprimitive
primitive circuit_2 (o, i1, i2, i3);
output o;
input i1, i2, i3;
table
0 ? ? : 1 ;
1 0 ? : 0 ;
1 1 ? : 1 ;
x b ? : 0 ;
endtable
endprimitive

'Circuit_1' and 'circit_2' are the same circuit, but the behavior of the 'circuit_1' was specified without special characters.

Important Notes

• Each row of sequential UDPs can contain only one transition.
• Special characters can make the UDP state table easier to read and write.
• Any undefined combination of inputs will set the output to x value.

UDP Instantiation

Formal Definition

The UDP instantiation provides a means of using UDP in modules.

Simplified Syntax

udp_name (strengths) #(delays) instance_name[range] (list of ports);

Description

UDPs can be instantiated only within modules.

The name of an instance is optional (Example 1). A UDP instantiation can contain strength and delays declarations (Example 2). UDPs do not support high-impedance (z) values, therefore only two delays are permitted. Signals connected to input ports can be any net or reg data type. Only net data type variables can be connected to the output port. The strength declaration can contain only drive strength.

It is possible to specify an array of UDP instances by using a range (Example 3).

Examples

Example 1

primitive d_ff (q, clk, d);
...
endprimitive
d_ff (q, clk, d);

The name of an instance is optional.

Example 2

d_ff (weak1, strong0) #5 d1 (q, clk, d);

UDP instance with strength and delay declaration.

Example 3

wire [3:0] q;
reg [3:0] d;
reg clk;
d_ff flips[3:0] (q, clk, d);

Important Notes

· UDP instantiation can contain up to two delay values.

UDP Declaration

Formal Definition

User Defined Primitives (UDP) provide a means of expanding a set of built-in primitives.

Simplified Syntax

primitive udp_name ( port_list );

output output_port;

input list_of_imputs;

initial output_port = value;

table

  combinational_input_list : output_value;

  sequential_input_list : current_state : next_state;

endtable

endprimitive

Description

User Defined Primitives can describe both combinational (Example 1) and sequential (Example 2) circuits. The behavioral description is provided as a truth table.

The UDP declaration starts with the keyword primitive and ends with the keyword endprimitive. A port list, an output port declaration and input ports declaration are similar to their equivalents in a module declaration.

Port list

The port list contains a comma-separated list of primitive ports. There can be only one output port and several input ports. The inout ports are illegal. The first port on the list should be the output port. There are some restrictions concerning the number of input ports. The combinational UDPs list of ports should not contain more than 10 inputs, and the sequential UDPs port list should not contain more than 9 inputs. If the port list contains more inputs, then a warning will be issued. These restrictions are caused by illegibility of written UDPs.

Port declaration

Input and output port declarations should match the port list of the UDP they are enclosed in. If the described UDP is sequential, then reg declaration for output port should be provided. All ports of the UDP should be of scalar type (1-bit wide). Vectors are illegal.

Initial statement

Sequential UDPs can contain an initial statement for an output port. This statement begins with the keyword initial, followed by an assignment to the output port. Assigned values should be 1-bit wide and there must not be any delays.

State table

The state table starts with the keyword table and ends with the keyword endtable. The state tables for combinational and sequential UDPs are different. The state table is comprised of rows each of which ended with a the semicolon. Table row describes the behavior of UDP for a particular combination of inputs. The combinational UDPs have two fields separated by a colon. One field is for the inputs and one for the outputs. The sequential UDPs have three fields: one for the inputs, one for the current output state, and one for the next output state. If any combination of input signals, is not explicitly specified in the UDP declaration, the output value will be unknown (x). A particular combination of inputs can be specified only one time.

Examples

Example 1

primitive and_gate (o, in1, in2);
output o;
input in1, in2;
table
  // in1 in2 : o
  0 0 : 0;
  0 1 : 0;
  1 0 : 0;
  1 1 : 1;
endtable
endprimitive

Example of simple combinational UDP based on the and gate truth table.

Example 2

primitive d_ff (q, d, clk);
output q;
reg q;
input d, clk;
table
  // d clk : q : q+
  0 p : ? : 0;
  1 p : ? : 1;
  ? n : ? : -;
endtable
endprimitive

Example of sequential UDP based on a D flip-flop.

Important Notes

· UDP can have only one output.

· Inout ports are illegal.

· Combinational UDP should not have more than 10 inputs.

· Sequential UDP should not have more than 9 inputs.

· Vector declaration for UDP ports is illegal.