Most digital designs are done at a higher level of abstraction like RTL, although at times it becomes intuitive to build smaller deterministic circuits at a lower level by using combinational elements like and and or. Modeling done at this level is usually called gate level modeling as it involves gates and has a one to one relation between a hardware schematic and the Verilog code.

Verilog supports a few basic logic gates known as primitives as they can be instantiated like modules since they are already predefined.

## And/Or/Xor Gates

These primitives implement an AND and an OR gate which takes many scalar inputs and provide a single scalar output. The first terminal in the list of arguments to these primitives is the output which gets updated whenever any of the inputs change.

```  ```

module gates (	input a, b,
output c, d, e);

and (c, a, b); 	// c is the output, a and b are inputs
or  (d, a, b);	// d is the output, a and b are inputs
xor (e, a, b); 	// e is the output, a and b are inputs
endmodule

```
```
```  ```

module tb;
reg a, b;
wire c, d, e;
integer i;

gates u0 ( .a(a), .b(b), .c(c), .d(d), .e(e));

initial begin
{a, b} = 0;

\$monitor ("[T=%0t a=%0b b=%0b c(and)=%0b d(or)=%0b e(xor)=%0b", \$time, a, b, c, d, e);

for (i = 0; i < 10; i = i+1) begin
#1 	a <= \$random;
b <= \$random;
end
end
endmodule

```
```
Simulation Log
```ncsim> run
[T=0 a=0 b=0 c(and)=0 d(or)=0 e(xor)=0
[T=1 a=0 b=1 c(and)=0 d(or)=1 e(xor)=1
[T=2 a=1 b=1 c(and)=1 d(or)=1 e(xor)=0
[T=4 a=1 b=0 c(and)=0 d(or)=1 e(xor)=1
[T=5 a=1 b=1 c(and)=1 d(or)=1 e(xor)=0
[T=6 a=0 b=1 c(and)=0 d(or)=1 e(xor)=1
[T=7 a=1 b=0 c(and)=0 d(or)=1 e(xor)=1
[T=10 a=1 b=1 c(and)=1 d(or)=1 e(xor)=0
ncsim: *W,RNQUIE: Simulation is complete.

```

## Nand/Nor/Xnor Gates

The inverse of all the above gates are also available in the forms of `nand`, `nor` and `xnor`. The same design from above is reused with the exception that the primitives are switched with their inverse versions.

```  ```

module gates (	input a, b,
output c, d, e);

// Use nand, nor, xnor instead of and, or and xor
// in this example
nand (c, a, b); 	// c is the output, a and b are inputs
nor  (d, a, b);		// d is the output, a and b are inputs
xnor (e, a, b); 	// e is the output, a and b are inputs
endmodule

```
```
```  ```

module tb;
reg a, b;
wire c, d, e;
integer i;

gates u0 ( .a(a), .b(b), .c(c), .d(d), .e(e));

initial begin
{a, b} = 0;

\$monitor ("[T=%0t a=%0b b=%0b c(nand)=%0b d(nor)=%0b e(xnor)=%0b", \$time, a, b, c, d, e);

for (i = 0; i < 10; i = i+1) begin
#1 	a <= \$random;
b <= \$random;
end
end
endmodule

```
```
Simulation Log
```ncsim> run
[T=0 a=0 b=0 c(nand)=1 d(nor)=1 e(xnor)=1
[T=1 a=0 b=1 c(nand)=1 d(nor)=0 e(xnor)=0
[T=2 a=1 b=1 c(nand)=0 d(nor)=0 e(xnor)=1
[T=4 a=1 b=0 c(nand)=1 d(nor)=0 e(xnor)=0
[T=5 a=1 b=1 c(nand)=0 d(nor)=0 e(xnor)=1
[T=6 a=0 b=1 c(nand)=1 d(nor)=0 e(xnor)=0
[T=7 a=1 b=0 c(nand)=1 d(nor)=0 e(xnor)=0
[T=10 a=1 b=1 c(nand)=0 d(nor)=0 e(xnor)=1
ncsim: *W,RNQUIE: Simulation is complete.

```

These gates can have more than two inputs.

```  ```

module gates (	input a, b, c, d,
output x, y, z);

and (x, a, b, c, d); 	// x is the output, a, b, c, d are inputs
or  (y, a, b, c, d);	// y is the output, a, b, c, d are inputs
nor (z, a, b, c, d); 	// z is the output, a, b, c, d are inputs
endmodule

```
```
```  ```

module tb;
reg a, b, c, d;
wire x, y, z;
integer i;

gates u0 ( .a(a), .b(b), .c(c), .d(d), .x(x), .y(y), .z(z));

initial begin
{a, b, c, d} = 0;

\$monitor ("[T=%0t a=%0b b=%0b c=%0b d=%0b x=%0b y=%0b x=%0b", \$time, a, b, c, d, x, y, z);

for (i = 0; i < 10; i = i+1) begin
#1 	a <= \$random;
b <= \$random;
c <= \$random;
d <= \$random;

end
end
endmodule

```
```
Simulation Log
```ncsim> run
[T=0 a=0 b=0 c=0 d=0 x=0 y=0 x=1
[T=1 a=0 b=1 c=1 d=1 x=0 y=1 x=0
[T=2 a=1 b=1 c=1 d=0 x=0 y=1 x=0
[T=3 a=1 b=1 c=0 d=1 x=0 y=1 x=0
[T=4 a=1 b=0 c=1 d=0 x=0 y=1 x=0
[T=5 a=1 b=0 c=1 d=1 x=0 y=1 x=0
[T=6 a=0 b=1 c=0 d=0 x=0 y=1 x=0
[T=7 a=0 b=1 c=0 d=1 x=0 y=1 x=0
[T=8 a=1 b=1 c=1 d=0 x=0 y=1 x=0
[T=9 a=0 b=0 c=0 d=1 x=0 y=1 x=0
[T=10 a=0 b=1 c=1 d=1 x=0 y=1 x=0
ncsim: *W,RNQUIE: Simulation is complete.

```

## Buf/Not Gates

These gates have only one scalar input and one or more outputs. `buf` stands for a buffer and simply transfer the value from input to the output without any change in polarity. `not` stands for an inverter which inverts the polarity of the signal at its input. So a 0 at its input will yield a 1 and vice versa.

```  ```

module gates (	input a,
output c, d);

buf (c, a); 		// c is the output, a is input
not (d, a);		// d is the output, a is input
endmodule

```
```
```  ```

module tb;
reg a;
wire c, d;
integer i;

gates u0 ( .a(a), .c(c), .d(d));

initial begin
a = 0;

\$monitor ("[T=%0t a=%0b c(buf)=%0b d(not)=%0b", \$time, a, c, d);

for (i = 0; i < 10; i = i+1) begin
#1 	a <= \$random;
end
end
endmodule

```
```
Simulation Log
```xcelium> run
[T=0 a=0 c(buf)=0 d(not)=1
[T=2 a=1 c(buf)=1 d(not)=0
[T=8 a=0 c(buf)=0 d(not)=1
[T=9 a=1 c(buf)=1 d(not)=0
xmsim: *W,RNQUIE: Simulation is complete.

```

The last terminal in the port list connects to the input of the gate and all other terminals connect to the output port of the gate. Here is an example of a multiple output buffer, although it is rarely used.

```  ```

module gates (	input  a,
output c, d);

not (c, d, a); 		// c,d is the output, a is input

endmodule

```
```
Simulation Log
```xcelium> run
[T=0 a=0 c=1 d=1
[T=2 a=1 c=0 d=0
[T=8 a=0 c=1 d=1
[T=9 a=1 c=0 d=0
xmsim: *W,RNQUIE: Simulation is complete.

```

## Bufif/Notif

Buffers and Inverters with an additional control signal to enable the output is available through `bufif` and `notif` primitives. These gates have a valid output only if the control signal is enabled else the output will be in high impedance. There are two versions of these, one with normal polarity of control indicated by a 1 like `bufif1` and `notif1` and second with inverted polarity of control indicated by a 0 like `bufif0` and `notif0`.

## Design

```  ```

module johnson_ctr #(parameter WIDTH=4)
(
input clk,
input rstn,
output reg [WIDTH-1:0] out
);

always @ (posedge clk) begin
if (!rstn)
out <= 1;
else begin
out[WIDTH-1] <= ~out[0];
for (int i = 0; i < WIDTH-1; i=i+1) begin
out[i] <= out[i+1];
end
end
end
endmodule

```
```

## Testbench

```  ```

module tb;
parameter WIDTH = 4;

reg clk;
reg rstn;
wire [WIDTH-1:0] out;

johnson_ctr 	u0 (.clk (clk),
.rstn (rstn),
.out (out));

always #10 clk = ~clk;

initial begin
{clk, rstn} <= 0;

\$monitor ("T=%0t out=%b", \$time, out);
repeat (2) @(posedge clk);
rstn <= 1;
repeat (15) @(posedge clk);
\$finish;
end
endmodule

```
```
Simulation Log
```ncsim> run
T=0 out=xxxx
T=10 out=0001
T=50 out=0000
T=70 out=1000
T=90 out=1100
T=110 out=1110
T=130 out=1111
T=150 out=0111
T=170 out=0011
T=190 out=0001
T=210 out=0000
T=230 out=1000
T=250 out=1100
T=270 out=1110
T=290 out=1111
T=310 out=0111
Simulation complete via \$finish(1) at time 330 NS + 0

```

## Design

```  ```

module gray_ctr
# (parameter N = 4)

(	input 	clk,
input 	rstn,
output reg [N-1:0] out);

reg [N-1:0] q;

always @ (posedge clk) begin
if (!rstn) begin
q <= 0;
out <= 0;
end else begin
q <= q + 1;

`ifdef FOR_LOOP
for (int i = 0; i < N-1; i= i+1) begin
out[i] <= q[i+1] ^ q[i];
end
out[N-1] <= q[N-1];
`else
out <= {q[N-1], q[N-1:1] ^ q[N-2:0]};
`endif
end
end
endmodule

```
```

## Testbench

```  ```

module tb;
parameter N = 4;

reg clk;
reg rstn;
wire [N-1:0] out;

gray_ctr u0 (	.clk(clk),
.rstn(rstn),
.out(out));

always #10 clk = ~clk;

initial begin
{clk, rstn} <= 0;

\$monitor ("T=%0t rstn=%0b out=0x%0h", \$time, rstn, out);

repeat(2) @ (posedge clk);
rstn <= 1;
repeat(20) @ (posedge clk);
\$finish;
end
endmodule

```
```
Simulation Log
```ncsim> run
T=0 rstn=0 out=0xx
T=10 rstn=0 out=0x0
T=30 rstn=1 out=0x0
T=50 rstn=1 out=0x1
T=70 rstn=1 out=0x3
T=90 rstn=1 out=0x2
T=110 rstn=1 out=0x6
T=130 rstn=1 out=0x7
T=150 rstn=1 out=0x5
T=170 rstn=1 out=0x4
T=190 rstn=1 out=0xc
T=210 rstn=1 out=0xd
T=230 rstn=1 out=0xf
T=250 rstn=1 out=0xe
T=270 rstn=1 out=0xa
T=290 rstn=1 out=0xb
T=310 rstn=1 out=0x9
T=330 rstn=1 out=0x8
T=350 rstn=1 out=0x0
T=370 rstn=1 out=0x1
T=390 rstn=1 out=0x3
T=410 rstn=1 out=0x2
Simulation complete via \$finish(1) at time 430 NS + 0

```

Verilog design and testbench typically have many lines of code comprising of `always` or `initial` blocks, continuous assignments and other procedural statements which become active at different times in the course of a simulation.

Every change in value of a signal in the Verilog model is considered an update event. And processes such as `always` and `assign` blocks that are sensitive to these update events are evaluated in an arbitrary order and is called an evaluation event. Since these events can happen at different times, they are better managed and ensured of their correct order of execution by scheduling them into event queues that are arranged by simulation time.

```  ```

module tb;
reg a, b, c;
wire d;

// 'always' is a process that gets evaluated when either 'a' or 'b' is updated.
// When 'a' or 'b' changes in value it is called an 'update event'. When 'always'
// block is triggered because of a change in 'a' or 'b' it is called an evaluation
// event
always @ (a or b) begin
c = a & b;
end

// Here 'assign' is a process which is evaluated when either 'a' or 'b' or 'c'
// gets updated
assign d = a | b ^ c;
endmodule

```
```

## Event Queue

A simulation step can be segmented into four different regions. An active event queue is just a set of processes that need to execute at the current time which can result in more processes to be scheduled into active or other event queues. Events can be added to any of the regions, but always removed from the active region.

• Active events occur at the current simulation time and can be processed in any order.
• Inactive events occur at the current simulation time, but is processed after all active events are processed
• Nonblocking assign events that were evaluated previously will be assigned after all active and inactive events are processed.
• Monitor events are processed after all active, inactive and nonblocking assignments are done.

When all events in the active queue for the current time step has been executed, the simulator advances time to the next time step and executes its active queue.

```  ```

module tb;
reg x, y, z

initial begin
#1 	x = 1;
y = 1;
#1 	z = 0;
end
endmodule

```
```

Simulation starts at time 0, and the first statement is scheduled to be executed when simulation time reaches 1 time unit at which it assigns x and y to 1. This is the active queue for the current time which is 1 time unit. Simulator then schedules the next statement after 1 more time unit at which z is assigned 0.

## What makes simulation nondeterministic ?

There can be race conditions during simulation that end up giving different outputs for the same design and testbench. One of the reasons for nondeterministic behavior is because active events can be removed from the queue and processed in any order.

Verilog simulation depends on how time is defined because the simulator needs to know what a #1 means in terms of time. The ``timescale` compiler directive specifies the time unit and precision for the modules that follow it.

## Syntax

```  ```

`timescale <time_unit>/<time_precision>

// Example
`timescale 1ns/1ps
`timescale 10us/100ns
`timescale 10ns/1ns

```
```

The time_unit is the measurement of delays and simulation time while the time_precision specifies how delay values are rounded before being used in simulation.

Use the following timescale constructs to use different time units in the same design. Remember that delay specifications in the design are not synthesizable and cannot be converted to hardware logic.

• ``timescale` for base unit of measurement and precision of time
• \$printtimescale system task to display time unit and precision
• `\$time` and `\$realtime` system functions return the current time and the default reporting format can be changed with another system task `\$timeformat`.
Character Unit
s seconds
ms milliseconds
us microseconds
ns nanoseconds
ps picoseconds
fs femtoseconds

The integers in these specifications can be either 1, 10 or 100 and the character string that specifies the unit can take any value mentioned in the table above.

## Example #1: 1ns/1ns

```  ```

// Declare the timescale where time_unit is 1ns
// and time_precision is also 1ns
`timescale 1ns/1ns

module tb;
// To understand the effect of timescale, let us
// drive a signal with some values after some delay
reg val;

initial begin
// Initialize the signal to 0 at time 0 units
val <= 0;

// Advance by 1 time unit, display a message and toggle val
#1 		\$display ("T=%0t At time #1", \$realtime);
val <= 1;

// Advance by 0.49 time unit and toggle val
#0.49 	\$display ("T=%0t At time #0.49", \$realtime);
val <= 0;

// Advance by 0.50 time unit and toggle val
#0.50 	\$display ("T=%0t At time #0.50", \$realtime);
val <= 1;

// Advance by 0.51 time unit and toggle val
#0.51 	\$display ("T=%0t At time #0.51", \$realtime);
val <= 0;

// Let simulation run for another 5 time units and exit
#5 \$display ("T=%0t End of simulation", \$realtime);
end
endmodule

```
```

The first delay statement uses #1 which makes the simulator wait for exactly 1 time unit which is specified to be 1ns with ``timescale` directive. The esecond delay statement uses 0.49 which is less than half a time unit. However the time precision is specified to be 1ns and hence the simulator cannot go smaller than 1 ns which makes it to round the given delay statement and yields 0ns. So the second delay fails to advance the simulation time.

The third delay statement uses exactly half the time unit [hl]#0.5[/lh] and again the simulator will round the value to get #1 which represents one whole time unit. So this gets printed at T=2ns.

The fourth delay statement uses a value more than half the time unit and gets rounded as well making the display statement to be printed at T=3ns.

Simulation Log
```ncsim> run
T=1 At time #1
T=1 At time #0.49
T=2 At time #0.50
T=3 At time #0.51
T=8 End of simulation
ncsim: *W,RNQUIE: Simulation is complete.

```

The simulation runs for 8ns as expected, but notice that the waveform does not have smaller divisions between each nanosecond. This is because the precision of time is the same as the time unit.

## Example #2: 10ns/1ns

The only change made in this example compared to the previous one is that the timescale has been changed from 1ns/1ns to 10ns/1ns. So the time unit is 10ns and precision is at 1ns.

```  ```

// Declare the timescale where time_unit is 10ns
// and time_precision is 1ns
`timescale 10ns/1ns

// NOTE: Testbench is the same as in previous example
module tb;
// To understand the effect of timescale, let us
// drive a signal with some values after some delay
reg val;

initial begin
// Initialize the signal to 0 at time 0 units
val <= 0;

// Advance by 1 time unit, display a message and toggle val
#1 		\$display ("T=%0t At time #1", \$realtime);
val <= 1;

// Advance by 0.49 time unit and toggle val
#0.49 	\$display ("T=%0t At time #0.49", \$realtime);
val <= 0;

// Advance by 0.50 time unit and toggle val
#0.50 	\$display ("T=%0t At time #0.50", \$realtime);
val <= 1;

// Advance by 0.51 time unit and toggle val
#0.51 	\$display ("T=%0t At time #0.51", \$realtime);
val <= 0;

// Let simulation run for another 5 time units and exit
#5 \$display ("T=%0t End of simulation", \$realtime);
end
endmodule

```
```

Actual simulation time is obtained by multiplying the delay specified using `#` with the time unit and then it is rounded off based on precision. The first delay statement will then yield 10ns and the second one gives 14.9 which gets rounded to become 15ns.

The third statement similarly adds 5ns (0.5 * 10ns) and the total time becomes 20ns. The fourth one adds another 5ns (0.51 * 10) to advance total time to 25ns.

Simulation Log
```ncsim> run
T=10 At time #1
T=15 At time #0.49
T=20 At time #0.50
T=25 At time #0.51
T=75 End of simulation
ncsim: *W,RNQUIE: Simulation is complete.

```

Note that the base unit in waveform is in tens of nanoseconds with a precision of 1ns.

## Example #3: 1ns/1ps

The only change made in this example compared to the previous one is that the timescale has been changed from 1ns/1ns to 1ns/1ps. So the time unit is 1ns and precision is at 1ps.

```  ```

// Declare the timescale where time_unit is 1ns
// and time_precision is 1ps
`timescale 1ns/1ps

// NOTE: Testbench is the same as in previous example
module tb;
// To understand the effect of timescale, let us
// drive a signal with some values after some delay
reg val;

initial begin
// Initialize the signal to 0 at time 0 units
val <= 0;

// Advance by 1 time unit, display a message and toggle val
#1 		\$display ("T=%0t At time #1", \$realtime);
val <= 1;

// Advance by 0.49 time unit and toggle val
#0.49 	\$display ("T=%0t At time #0.49", \$realtime);
val <= 0;

// Advance by 0.50 time unit and toggle val
#0.50 	\$display ("T=%0t At time #0.50", \$realtime);
val <= 1;

// Advance by 0.51 time unit and toggle val
#0.51 	\$display ("T=%0t At time #0.51", \$realtime);
val <= 0;

// Let simulation run for another 5 time units and exit
#5 \$display ("T=%0t End of simulation", \$realtime);
end
endmodule

```
```

See that the time units scaled to match the new precision value of 1ps. Also note that time is represented in the smallest resolution which in this case is picoseconds.

Simulation Log
```ncsim> run
T=1000 At time #1
T=1490 At time #0.49
T=1990 At time #0.50
T=2500 At time #0.51
T=7500 End of simulation
ncsim: *W,RNQUIE: Simulation is complete.

```