Transcript The Verilog Hardware Description Language - IUMA

332:437 Lecture 11
Verilog Event-Driven Simulation







Structure vs. Behavior
Timing Model and Event-Driven Simulation
Delays
Instantiation
Procedural Models
Scheduling
Summary
Material from The Verilog Hardware Description Language,
By Thomas and Moorby, Kluwer Academic Publishers
7/20/2015
Thomas: Digital Systems Design
Lecture 11
1
Structure Vs. Behavior
 Structure — Look at it from the module (adder) ports

Strong physical connotations

The internal structure of a system includes its state and state
transition mechanism as well as the state to output mapping
 Behavior — again from the module ports

Outer manifestation of a system

The external behavior of a system is the relationship it imposes
between its input time histories and output time histories
module adder
(output carryOut, sum,
input
aInput, bInput, carryIn);
xor
or
and
(sum, aInput, bInput, carryIn);
(carryOut, ab, bc, ac);
(ab, aInput, bInput),
(bc, bInput, carryIn),
(ac, aInput, carryIn);
endmodule
module adder
(output
input
assign
carryOut, sum,
aInput, bInput, carryIn);
sum = aInput ^ bInput ^ carryIn,
carryOut = (aInput & bInput) |
(bInput & carryIn) |
(aInput & carryIn);
endmodule
Structural model
Behavioral model
Where is the state in these models?
7/20/2015
Thomas: Digital Systems Design
Lecture 11
2
Verilog Structure Vs. Behavior
 Structure

gate level — built-in models for AND, OR, …

modules and instantiations

wires
 Behavior

C-like programs or Boolean algebra (but with a few extra
operators)

assign statements

always blocks — procedural statements (next time)
 Hmm…

If a module has an assign statement in it, is it behavior or
structure?
 On the outside, it appears as structure — it’s wired in, takes up space
(it’s physical) — maybe it is an ALU slice
 On the inside, it appears as behavior — we only know the translation
of inputs to outputs, but without physical connotations
7/20/2015
Thomas: Digital Systems Design
Lecture 11
3
Mixing Levels
 Generally there is a mix of levels in a model

e.g. part of the system is at the gate level and another part is at
the behavioral level.

Why?
 Early in design process you might not have fully-detailed models —
you don’t actually know all the gate implementations of the
multipliers, adders, register files
 You might want to think of the design at a conceptual level before
doing all the work to obtain the gate implementations
 There might be a family of implementations planned
 Finer grain of distinction

Levels — switch, gate, functional block (e.g. ALUs), registertransfer, behavioral

for now, we’ll deal with gate and behavioral models
7/20/2015
Thomas: Digital Systems Design
Lecture 11
4
An Execution Model for Gates/Assigns
 Execution model

“Execution” (sometimes “timing”) model — how time is advanced,
what triggers new processing and the generation of new state in the
model

State is held on wires, gates and continuous assigns advance state
 Definition —

when an input changes, the simulator will evaluate the gate or
continuous assign, calculating a new output

if the output value is different, it is propagated to elements on the
fanout
module nandLatch
(output q, qBar,
input
set, reset);
nand #2
g1 (q, qBar, set),
g2 (qBar, q, reset);
endmodule
7/20/2015
Thomas: Digital Systems Design
Lecture 11
5
Gate Level Timing Model
 For gates and continuous assigns…

What’s an input?

What’s an output?

What’s state?
Gate inputs and RHS of assign equation
Gate outputs and LHS of assign equation
Wires
 Outputs on this “side” of the language are all …
Wires

…

no registers are latched/loaded, no need to know about a clock
event
7/20/2015
Thomas: Digital Systems Design
Lecture 11
6
Gate Level Timing Model
 Contrast

At the gate level, there’s nothing special about two cross-coupled
gates
R
Q
S
Q’

A register is an abstraction above this “side” of the language

The left-hand sides on the behavioral “side” of the language are
all registers
7/20/2015
Thomas: Digital Systems Design
Lecture 11
7
Approach to Simulating a System
 Two pieces of a simulation

The model — an executable specification including timing,
interconnect, and input vectors
 Written in a language like Verilog or VHDL
 What’s a VHDL?

The simulation scheduler —
 keeps track of when events occur,
 communicates events to appropriate parts of the model,
 executes the model of those parts, and
 as a result, possibly schedules more events for a future time.
 it maintains “simulated time” (sometimes “virtual time”) and the
event list.

7/20/2015
Parts of the scheduler function define the language
Thomas: Digital Systems Design
Lecture 11
8
How Does the Simulator Work?
 A gate level model doesn’t look like a program

No if’s or loops — what get’s executed?
 Here’s how gate-level Verilog is executed —

You specify a bunch of primitive gates that are interconnected

When an input of a gate changes, the simulator will evaluate the
gate primitive and calculate a new output

If the output value is different from the current, it is scheduled to
propagate at some time in the future (or possibly now).

After the specified time delay (possibly zero), the new value is
propagated along wires to other gate-primitive inputs
 Simulator keeps track of time

… and what has been scheduled to happen at any time
 Inputs and Outputs?

7/20/2015
An input to a gate primitive, the output of a gate primitive
Thomas: Digital Systems Design
Lecture 11
9
Are These Two Modules the Same?
module muxA
(output f,
input
a, b, sel);
module muxB
(output f,
input
a, b, sel);
or #5 g3 (f, f1, f2);
not
g4 (nsel, sel);
and #5 g1 (f1, a, nsel),
g2 (f2, b, sel);
endmodule
and #5 g1 (f1, a, nsel),
g2 (f2, b, sel);
or #5 g3 (f, f1, f2);
not
g4 (nsel, sel);
endmodule
a
a
f
f
b
b
sel
Alternate drawings of a mux
7/20/2015
Thomas: Digital Systems Design
Lecture 11
sel
10
Inside the Simulator
 A time-ordered list of events is maintained

Event — a value-change scheduled to occur at a given time

All events for a given time are kept together
 The scheduler removes events for a given time…

…propagates values, and executes gate models, creates new events…
time-ordered
event list
remove current
events
•••
ti tj tk
all the events
for time tj
7/20/2015
tn
updates
Gate
Outputs
schedules
new event
Scheduler
looks
at
Network Connections
(fanouts)
Thomas: Digital Systems Design
Lecture 11
executes
Gate
Models
11
Event-Driven Simulation
while (something in time-ordered event list) {
advance simulation time to soonest event’s time
retrieve all events e for this time
e
For each event e in arbitrary order {
update the value specified
follow fanout
evaluate the model(s)
schedule resulting events
}
evaluate these
}
One traversal of the while loop is a simulation cycle.
In 1 cycle, we remove all events for a time & execute them.
New events may be scheduled for the current time —
they are put in the event list and retrieved in the next sim. cycle.
7/20/2015
Thomas: Digital Systems Design
Lecture 11
New
event
12
Event-Driven Simulation
the event list
initial
A=1 at values as
25
shown
1
1
A=0
g1 #2
0
Eval g1
B=0 at
27
initial
A=1 at values as
25
shown
(at 27)
1
g1 #2
Thomas: Digital Systems Design
Lecture 11
B=1
C=0
g2 #3
B=0
1
1
g1 #2
A=1
D=1
g3 #5
0
(at 30)
D=1
g3 #5
A=1
0
7/20/2015
g2 #3
1
Eval g2, g3
C=1 at B=0 at A=1 at
initial
25
30
values as
27
shown
C=0
C=1
g2 #3
B=0
D=1
g3 #5
final
13
How Does It Keep Track of Time?
 … Explicitly

Events are stored in an event list (actually a 2-D list) ordered by
time

Events execute at a time and possibly schedule their output to
change at a later time (a new event)

When no more events for the current time, move to the next

Events within a time are executed in arbitrary order
time a
event
event
time a + 2
event
event
event
Let’s say A
changes to 0
here. B and C
have delay 2.
1
B
A
time a+75
time a+75492
7/20/2015
event
event
Events to
event update B and
C are added.
Thomas: Digital Systems Design
Lecture 11
1
C
14
Two Types of Events
 Update events —

Action: update state and propagate new values along a fanout.

Possibly produces new events
 Evaluation events —

Action: evaluate, or execute, a model.

Possibly produces new events
 Plan

Will deal with update events now

Evaluation events come in with behavioral models
7/20/2015
Thomas: Digital Systems Design
Lecture 11
15
Event-Driven Simulation
while something in time-ordered event list {
1
advance simulation time to top event’s time
B=0
#2
A= 1
0
retrieve all events for this time
C=0
update
1
#2
For each event in arbitrary order {
If it’s an update event {
1
update the value specified
B= 01
#2
A= 0
C= 01
follow fanout, evaluate gates there
If an output changes
1
#2
schedule update event for it
}
update
else // it’s an evaluation event
evaluate the model
}
}
7/20/2015
time 
A=0
time  + 2
B=1
Thomas: Digital Systems Design
Lecture 11
C=1
16
What about Zero Delay Events?
while something in time-ordered event list {
advance simulation time to top event’s time
retrieve all events for this time
But it’s not
retrieved and
executed until the
next sim cycle
For each event in arbitrary order {
If it’s an update event {
update the value specified
follow fanout, evaluate gates there
A gate with #0
delay gets
scheduled for the
current time
If an output changes
schedule update event for it
Ain
}
#0
Aout
else // it’s an evaluation event
evaluate the model
}
time 
Ain
Aout
==
01
} The simulator can spend several iterations at the same simulation time
7/20/2015
Thomas: Digital Systems Design
Lecture 11
17
Verilog Gate Level Timing Model
 What if an update event is already scheduled for an primitive
gate output?

If the value being scheduled is different, the currently scheduled
value is removed from the event list; the new event is not
scheduled
Called inertial delay — oddly named, how wide must an input
spike be to be seen?
Deviation from
pure discrete
a
event simulation.
a=1
c
b

nand #5 (c, a, b);
b=1
update scheduled
c
propagation
delay = 5
7/20/2015
update removed,
final value
Thomas: Digital Systems Design
Lecture 11
a
b
c
alternate
18
Instantiation — Hierarchy
module above (out, …);
output [2:0] out;
wire
[2:0] h, I, j;
module r(o1,i1, i2, i3);
input
i1, i2, i3;
output o1;
assign o1 = i1 | i2 | i3;
endmodule
r
a(out[0], h[0], I[0], j[0]),
b(out[1], h[1], I[1], j[1]),
c(out[2], h[2], I[2], j[2]);
endmodule
out[2:0]
a
r
r
r
above
out[2]
b
c
o1
Not all connections shown
 Hierarchical name
7/20/2015

o1 is really … above_inst.c.o1

Used for debugging… why just debugging?
Thomas: Digital Systems Design
Lecture 11
19
Hierarchy
 Why?

Hides detail

Supports alternate implementations

Encapsulates — side effects understood
 Observations

Hardware resources allocated (instantiated) to perform a function
exclusively

No other function will use it

Thus, physical concurrency and structure are established
module r
(output o1,
input
i1, i2, i3);
module r
(output o1,
input
i1, i2, i3);
assign o1 = i1 | i2 | i3;
endmodule
7/20/2015
or #(2, 5) (first, i1, i2),
(o1, first, i3);
endmodule
Thomas: Digital Systems Design
Lecture 11
20
Summary of Gate Evaluation
 Simulation languages — concurrent

Maintain explicit notion of time

Describe models with physically concurrent activity

Interconnection of models allows for data-driven activity
 Timing model

Timing-execution model
 How time is advanced and new state created

Any gate input or assign righthand-side change causes the model
to be evaluated during the time step
 This is not the case for behavioral models

Fanout list is static — design never changes
 What if you don’t like Verilog’s gates?

e.g., inertial delays?

Use behavioral models (or user defined primitives…?)
7/20/2015
Thomas: Digital Systems Design
Lecture 11
21
Procedural Models: What’s Needed?
 Obvious things like operator set that matches hardware
functionality

Bit hacking, etc. a = { b[3], b[1], c[4] };
 Concurrent operators

Similar to what you’d find in other “threaded” languages

… plus hardware functionality — such as:
 Edge triggering
 Concurrent/buffered state update
 Control of time
…

…minus a few — such as:
 Support for critical sections — P,V
7/20/2015
Thomas: Digital Systems Design
Lecture 11
22
Procedural Models
 This is the “other side” of the language

Always and initial statements are
concurrent
 They start when the simulation starts, in
arbitrary order

Assignments are made to registers
 Everything on left hand side is a register



Statements execute sequentially
Atomicity — only one element (gate,
always, initial) executing at a time. No preemption — continues executing until done.
Stuff between concurrent statements
executes in zero time
Because statements execute in zero
time and are atomic, it looks like lots of
parallel stuff is happening
7/20/2015
Thomas: Digital Systems Design
Lecture 11
always begin
@ (posedge clock)
h = f + k;
g = f * g;
@ (posedge clock)
f = g;
q = f * s;
…
Why is this
important?
23
At First Look, It Is a Lot Like C
 Most of the operators are the same as C

^ is XOR, etc.

Makes it easy to read
 But there are major differences (quick list, we’ll get to these)

Concurrent statements like #delay, @event, wait(level)

Four-valued logic (1, 0, x, z) and the operators to go with them

Arbitrary bit width operations

There are a couple of procedural assignments (=, <=) with subtle
differences

A different timing model — in fact, C doesn’t have one
 It has a sequencing model — sequence being a more abstract view of
time.
 Hmm, do we even know if the program sequencing holds?
7/20/2015
Thomas: Digital Systems Design
Lecture 11
24
Review from Before
 Behavior vs. Structure

These two models are functionally interchangable — either could
have been instantiated into a register
 ports in same order
 same delay from clock to q
 one is abstract, clear
 one is structurally specific
 there are subtle differences
module d_type_FF
(output reg q,
input
clock, data);
always
@(negedge clock) q = #10 data;
endmodule
Behavioral
7/20/2015
module d_type_FF
(output q,
input
clock, data);
nor #10
a (q, qBar, r);
nor
b (qBar, q, s),
c (s, r, clock, s1),
d (s1, s, data),
e (r, r1, clock),
f (r1, s1, r);
endmodule
Structural
Thomas: Digital Systems Design
Lecture 11
25
Procedural Timing Model
 How does the procedural model advance
time?

# — delaying a specific amount of time

@ — delaying until an event occurs
 “posedge”, “negedge”, or any change
 this is edge-sensitive behavior
 When the statement is encountered, the
value v is sampled. When v changes in the
specified way, execution continues.

always begin
#5 q = w;
@ (negedge v)
q = y;
wait (c == 0)
q = 3;
end
wait — possibly delaying until an event
occurs
 this is level sensitive behavior

While one model is waiting for one of the
above reasons, other models execute —
values change, time marches on
7/20/2015
Thomas: Digital Systems Design
Lecture 11
Everything executes in
zero time — time
advances when you’re
not executing!
26
An Example of Wait
 Semantics


wait (expression) statement;
—
e.g. wait (a == 35) q = q + 4;
if the expression is FALSE,
the process is stopped
 when a becomes 35, it
resumes with q = q + 4

if the expression is TRUE,
the process is not stopped
 it continues executing
module handshake (ready, dataOut, …);
(input
ready,
output reg
[7:0]
dataOut);
reg
[7:0] someValueWeCalculated;
always begin
…
wait (ready);
…
dataOut = someValueWeCalculated;
wait (~ready) …
end…
ready
No. Not if ready is already true
when the first wait is executed.
You’re not guaranteed to get
the value at the edge
7/20/2015
Do you always get the value at
the edge when ready goes from 0
to 1? Isn’t this edge behavior?
Thomas: Digital Systems Design
Lecture 11
27
Wait Vs. While
 Are these equivalent?

No: The left example is correct, the right one isn’t — it won’t work

Wait is used to wait for an expression to become TRUE
 the expression eventually becomes TRUE because a variable in the
expression is changed by another process

While is used in the normal programming sense
 in the case shown, if the expression is TRUE, the simulator will
continuously execute the loop. Another process will never have the
chance to change “in”. Infinite loop!
 while can’t be used to wait for a change on an input to the process. Need
other variable in loop, or # or @ in loop.
module yes
(input in);
…
wait (in == 1);
…
endmodule
7/20/2015
module no
(input in);
…
while (in != 1);
…
endmodule
Thomas: Digital Systems Design
Lecture 11
28
Blocking Assignments and #
 We’ve seen #delay

Delay for specified time
 … and blocking assignments — they use =

Options for specifying delay
Wait #10, then do the statement
#10 a = b + c;
a = #10 b + c;

Note the action of the second one:
Calculate b+c, wait 10,
then do assignment
 an intra-assignment time delay
 The event list is used for temporary storage!

The differences:
• #10 a = b + c; Values b and c are from time (now + 10)
• a = #10 b + c; Values b and c are from time (now)
7/20/2015
Thomas: Digital Systems Design
Lecture 11
29
Blocking — What’s It Mean?
 Blocking — the always or initial block stops (blocks) for some
reason

#, @, wait(FALSE)
always begin
q = blahblah;
r = q - someInput;
It blocks (stops) here, other
things (always, gates, assigns)
execute. Finally at t+10, this
continues executing
a = #10 q + r;
t = a - someOtherInput;
…
7/20/2015
end
Intra assignment delay –
delay within an assignment.
Thomas: Digital Systems Design
Lecture 11
30
Events — @Something
 Action

when first encountered, sample the expression

wait for expression to change in the indicated fashion

This always blocks — you never execute straight through —
guaranteed edge sensitivity
 Examples
always @(posedge ck)
q <= d;
always @(hello)
a = b;
always
a = @(hello) b;
7/20/2015
always @(coke or cola)
a = b;
always begin
yadda = yadda;
@(posedge hello or negedge goodbye)
a = b;
…
end
Thomas: Digital Systems Design
Lecture 11
31
Sensitivity Lists
 In the gate level timing model…

model execution was sensitive to any change on any of the inputs
at any time.

sensitivity list — a list of inputs that a model is sensitive to
 a change on any of them
will cause execution of
the model


In the gate level timing model,
the lists don’t change.
Ditto with continuous assign
 In procedural models …

the sensitivity list changes as
as function of time and
execution
module d_type_FF
(output q,
input
clock, data);
nor #10
a (q, qBar, r);
nor
b (qBar, q, s),
c (s, r, clock, s1),
d (s1, s, data),
e (r, r1, clock),
f (r1, s1, r);
endmodule
Structural
7/20/2015
Thomas: Digital Systems Design
Lecture 11
32
Procedural Timing Model
 What is the behavioral model sensitive to?

The behavioral statements execute in sequence

Therefore, a behavioral model is sensitive to its context
 i.e. it is only sensitive to what it is currently waiting for
 time, edge, level — (#, @, wait)

The following model is not sensitive to a change on y or w.
always begin
@ (negedge clock1)
q = y;
@ (negedge clock2)
q = w;
@ (posedge clock1)
/*nothing*/ ;
@ (posedge clock2)
q = 3;
end
7/20/2015
Here, it is only sensitive to clock1
Here, it is only sensitive to
clock2. A posedge on
clock1 will have no effect
when waiting here.
Thomas: Digital Systems Design
Lecture 11
33
Fanout Lists
 Outputs of things are connected to inputs of other things

No surprise

The simulator maintains a fanout list of inputs driven by each
“output”
 Why maintain a fanout list?

When the output changes, it’s easy to figure out what other
models need (to be) evaluated

Because of procedural models …

…Sensitivity lists change

Fanout lists change
 Sensitivity lists <—> Fanout lists
 What’s an “output” in a behavioral model?
7/20/2015
Thomas: Digital Systems Design
Lecture 11
34
List Changes
 Change in sensitivity lists in procedural models cause
fanout lists to change
clock1 fanout is A, B, D;
clock2 fanout is C.
clock1
A
B
clock2
C
always begin:D
@ (negedge clock1)
q = y;
@ (negedge clock2)
q = w;
…
end
clock1 fanout is A, B;
clock2 fanout is C, D.
7/20/2015
Thomas: Digital Systems Design
Lecture 11
35
Scheduling #, @, and Wait
 How are #, @, and wait tied into the event list?

# delay
 schedule the resumption of the process — put it in the event queue delay
units into the future. Essentially an evaluation event scheduled in the future

@ change
 when suspended for an @v, the behavioral model is put on the fanout list of
the variable v. i.e., the behavioral model is now sensitive to v.
 When an update event for v occurs, (e.g. posedge), then the behavioral
model resumes at the current time.

Wait (exp)
 if exp is TRUE, don’t stop
 if exp is FALSE, then the behavioral model is put on the fanout list(s) of the
variable(s) in exp. (it’s now sensitive to the variable(s))
 When there is an update event for any of the variables in exp , exp is
evaluated. If exp is TRUE, resume executing in the current time , else go
back to sleep
7/20/2015
Thomas: Digital Systems Design
Lecture 11
36
Procedural Model Sensitivity?
 Quick example

Gate A changes its output

What models get executed?
B
Yes
A
C
always @(A)
begin
R = ~A;
end
always @(posedge clock)
Q <= A;
7/20/2015
No
Thomas: Digital Systems Design
Lecture 11
Maybe
always begin
@(A) R = ~A;
@(D) R = ~B;
end
37
Order of Execution
B
 Assume A changes.


In what order do these
models execute?
A
Arbitrary, don’t count on
any specific order
The simulator will try to
make them look like they
all occur at the same time
— how?
C
always @(A)
begin
R = ~A;
end
always @(posedge clock)
Q <= A;
By controlling virtual time.
7/20/2015
Thomas: Digital Systems Design
Lecture 11
38
Arbitrary Order? Oops!
 Sometimes you need to
exert some control

Consider the
interconnections of this DFF

At the positive edge of c,
what models are ready to
execute?

Does it matter which one is
done first?
shiftin
Oops — The order of
execution can matter!
7/20/2015
module dff(q, d, c);
…
always @(posedge c)
q = d;
endmodule
module sreg (…);
…
dff
e (q0, shiftin, clock),
f (q1, q0, clock),
g (shiftout, q1, clock);
endmodule
D
Q
D
Q
D
Q
shiftout
clock
Thomas: Digital Systems Design
Lecture 11
39
Non-blocking Concurrent Assignments
module fsm
(output reg Q1, Q0,
input
clock, in);
Q0
always @(posedge clock) begin
Q1 <= in & Q0;
Q0 <= in | Q1;
end
endmodule
Q
Q1
D
Q
Q0
in
Q1
clock
Values after the clock edge (t+)
— calculated in response to
the clock edge, using values at
the clock edge
D
Values at the
clock edge.
(At t -)
 Concurrent Assignment — primary use of <=

The assignment is “guarded” by an edge

All assignments guarded by the edge happen concurrently
7/20/2015
Thomas: Digital Systems Design
Lecture 11
40
Summary







Structure vs. Behavior
Timing Model and Event-Driven Simulation
Delays
Instantiation
Procedural Models
Scheduling
Summary
7/20/2015
Thomas: Digital Systems Design
Lecture 11
41