Download presentation
Presentation is loading. Please wait.
Published byImogene Brooks Modified over 6 years ago
1
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 11/12/2018 Thomas: Digital Systems Design Lecture 11
2
Thomas: Digital Systems Design Lecture 11
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 Structural model Behavioral model module adder (output carryOut, sum, input aInput, bInput, carryIn); assign sum = aInput ^ bInput ^ carryIn, carryOut = (aInput & bInput) | (bInput & carryIn) | (aInput & carryIn); endmodule xor (sum, aInput, bInput, carryIn); or (carryOut, ab, bc, ac); and (ab, aInput, bInput), (bc, bInput, carryIn), (ac, aInput, carryIn); Where is the state in these models? 11/12/2018 Thomas: Digital Systems Design Lecture 11
3
Verilog Structure Vs. Behavior
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 11/12/2018 Thomas: Digital Systems Design Lecture 11
4
Thomas: Digital Systems Design Lecture 11
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), register-transfer, behavioral for now, we’ll deal with gate and behavioral models 11/12/2018 Thomas: Digital Systems Design Lecture 11
5
An Execution Model for Gates/Assigns
“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 11/12/2018 Thomas: Digital Systems Design Lecture 11
6
Gate Level Timing Model
For gates and continuous assigns… What’s an input? What’s an output? What’s state? Outputs on this “side” of the language are all … … no registers are latched/loaded, no need to know about a clock event Gate inputs and RHS of assign equation Gate outputs and LHS of assign equation Wires Wires 11/12/2018 Thomas: Digital Systems Design Lecture 11
7
Gate Level Timing Model
Contrast At the gate level, there’s nothing special about two cross-coupled gates 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 R S Q Q’ 11/12/2018 Thomas: Digital Systems Design Lecture 11
8
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. Parts of the scheduler function define the language 11/12/2018 Thomas: Digital Systems Design Lecture 11
9
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? An input to a gate primitive, the output of a gate primitive 11/12/2018 Thomas: Digital Systems Design Lecture 11
10
Are These Two Modules the Same?
module muxB (output f, input a, b, sel); and #5 g1 (f1, a, nsel), g2 (f2, b, sel); or #5 g3 (f, f1, f2); not g4 (nsel, sel); endmodule module muxA a b f sel a b sel f Alternate drawings of a mux 11/12/2018 Thomas: Digital Systems Design Lecture 11
11
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 schedules new event remove current events Scheduler ••• ti tj tk tn updates looks at executes all the events for time tj Gate Outputs Network Connections (fanouts) Gate Models 11/12/2018 Thomas: Digital Systems Design Lecture 11
12
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 For each event e in arbitrary order { update the value specified follow fanout evaluate the model(s) schedule resulting events } e evaluate these New event 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. 11/12/2018 Thomas: Digital Systems Design Lecture 11
13
Event-Driven Simulation
the event list C=0 initial values as shown 1 A=1 at 25 g2 #3 1 B=1 g1 #2 D=1 A=0 g3 #5 Eval g1 C=0 initial values as shown A=1 at 25 B=0 at 27 (at 27) 1 g2 #3 1 B=0 g1 #2 D=1 A=1 g3 #5 Eval g2, g3 C=1 initial values as shown B=0 at 27 A=1 at 25 C=1 at 30 (at 30) 1 g2 #3 1 B=0 g1 #2 D=1 A=1 g3 #5 final 11/12/2018 Thomas: Digital Systems Design Lecture 11
14
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 Let’s say A changes to 0 here. B and C have delay 2. time a event event event A B C 1 time a + 2 event Events to update B and C are added. time a+75 event time a+75492 event event 11/12/2018 Thomas: Digital Systems Design Lecture 11
15
Thomas: Digital Systems Design Lecture 11
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. Plan Will deal with update events now Evaluation events come in with behavioral models 11/12/2018 Thomas: Digital Systems Design Lecture 11
16
Event-Driven Simulation
B=0 while something in time-ordered event list { advance simulation time to top event’s time retrieve all events for this time For each event in arbitrary order { If it’s an update event { update the value specified follow fanout, evaluate gates there If an output changes schedule update event for it } else // it’s an evaluation event evaluate the model 1 #2 update A= 1 C=0 #2 1 update 1 B= 0 1 #2 A= 0 C= 0 #2 1 time A = 0 B = 1 C = 1 time + 2 11/12/2018 Thomas: Digital Systems Design Lecture 11
17
What about Zero Delay Events?
But it’s not retrieved and executed until the next sim cycle while something in time-ordered event list { advance simulation time to top event’s time retrieve all events for this time For each event in arbitrary order { If it’s an update event { update the value specified follow fanout, evaluate gates there If an output changes schedule update event for it } else // it’s an evaluation event evaluate the model A gate with #0 delay gets scheduled for the current time #0 Ain Aout time Ain = 0 Aout = 1 The simulator can spend several iterations at the same simulation time 11/12/2018 Thomas: Digital Systems Design Lecture 11
18
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 event simulation. a a=1 c b nand #5 (c, a, b); b=1 update scheduled c a b c propagation delay = 5 update removed, final value alternate 11/12/2018 Thomas: Digital Systems Design Lecture 11
19
Instantiation — Hierarchy
module r(o1,i1, i2, i3); input i1, i2, i3; output o1; assign o1 = i1 | i2 | i3; endmodule module above (out, …); output [2:0] out; wire [2:0] h, I, j; 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 b c out[2] o1 above r Not all connections shown Hierarchical name o1 is really … above_inst.c.o1 Used for debugging… why just debugging? 11/12/2018 Thomas: Digital Systems Design Lecture 11
20
Thomas: Digital Systems Design Lecture 11
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); assign o1 = i1 | i2 | i3; endmodule module r (output o1, input i1, i2, i3); or #(2, 5) (first, i1, i2), (o1, first, i3); endmodule 11/12/2018 Thomas: Digital Systems Design Lecture 11
21
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…?) 11/12/2018 Thomas: Digital Systems Design Lecture 11
22
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 11/12/2018 Thomas: Digital Systems Design Lecture 11
23
Thomas: Digital Systems Design Lecture 11
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 pre-emption — continues executing until done. Stuff between concurrent statements executes in zero time always begin @ (posedge clock) h = f + k; g = f * g; f = g; q = f * s; … Because statements execute in zero time and are atomic, it looks like lots of parallel stuff is happening Why is this important? 11/12/2018 Thomas: Digital Systems Design Lecture 11
24
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 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? 11/12/2018 Thomas: Digital Systems Design Lecture 11
25
Thomas: Digital Systems Design Lecture 11
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 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 module d_type_FF (output reg q, input clock, data); always @(negedge clock) q = #10 data; endmodule Structural Behavioral 11/12/2018 Thomas: Digital Systems Design Lecture 11
26
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. 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 always begin #5 q = w; @ (negedge v) q = y; wait (c == 0) q = 3; end Everything executes in zero time — time advances when you’re not executing! 11/12/2018 Thomas: Digital Systems Design Lecture 11
27
Thomas: Digital Systems Design Lecture 11
An Example of Wait module handshake (ready, dataOut, …); (input ready, output reg [7:0] dataOut); reg [7:0] someValueWeCalculated; always begin … wait (ready); dataOut = someValueWeCalculated; wait (~ready) … end… 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 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 Do you always get the value at the edge when ready goes from 0 to 1? Isn’t this edge behavior? 11/12/2018 Thomas: Digital Systems Design Lecture 11
28
Thomas: Digital Systems Design Lecture 11
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 # in loop. module yes (input in); … wait (in == 1); endmodule module no (input in); … while (in != 1); endmodule 11/12/2018 Thomas: Digital Systems Design Lecture 11
29
Blocking Assignments and #
We’ve seen #delay Delay for specified time … and blocking assignments — they use = Options for specifying delay #10 a = b + c; a = #10 b + c; Note the action of the second one: an intra-assignment time delay The event list is used for temporary storage! The differences: Wait #10, then do the statement Calculate b+c, wait 10, then do assignment #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) 11/12/2018 Thomas: Digital Systems Design Lecture 11
30
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; a = #10 q + r; t = a - someOtherInput; … end It blocks (stops) here, other things (always, gates, assigns) execute. Finally at t+10, this continues executing Intra assignment delay – delay within an assignment. 11/12/2018 Thomas: Digital Systems Design Lecture 11
31
Thomas: Digital Systems Design Lecture 11
Events 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 or cola) a = b; ck) q <= d; always begin yadda = yadda; @(posedge hello or negedge goodbye) a = b; … end a = b; always a b; 11/12/2018 Thomas: Digital Systems Design Lecture 11
32
Thomas: Digital Systems Design Lecture 11
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 11/12/2018 Thomas: Digital Systems Design Lecture 11
33
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 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. 11/12/2018 Thomas: Digital Systems Design Lecture 11
34
Thomas: Digital Systems Design Lecture 11
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? 11/12/2018 Thomas: Digital Systems Design Lecture 11
35
Thomas: Digital Systems Design Lecture 11
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 always begin:D @ (negedge clock1) q = y; @ (negedge clock2) q = w; … end clock2 C clock1 fanout is A, B; clock2 fanout is C, D. 11/12/2018 Thomas: Digital Systems Design Lecture 11
36
Thomas: Digital Systems Design Lecture 11
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 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 11/12/2018 Thomas: Digital Systems Design Lecture 11
37
Procedural Model Sensitivity?
Quick example Gate A changes its output What models get executed? A B C begin R = ~A; end clock) Q <= A; always begin @(A) R = ~A; @(D) R = ~B; Yes Maybe No 11/12/2018 Thomas: Digital Systems Design Lecture 11
38
Order of Execution Assume A changes. B
begin R = ~A; end clock) Q <= A; Assume A changes. In what order do these models execute? The simulator will try to make them look like they all occur at the same time — how? Arbitrary, don’t count on any specific order By controlling virtual time. 11/12/2018 Thomas: Digital Systems Design Lecture 11
39
Oops — The order of execution can matter!
Arbitrary Order? Oops! module dff(q, d, c); … c) q = d; endmodule module sreg (…); dff e (q0, shiftin, clock), f (q1, q0, clock), g (shiftout, q1, clock); Sometimes you need to exert some control Consider the interconnections of this D-FF At the positive edge of c, what models are ready to execute? Does it matter which one is done first? Q D clock shiftin shiftout Oops — The order of execution can matter! 11/12/2018 Thomas: Digital Systems Design Lecture 11
40
Non-blocking Concurrent Assignments
module fsm (output reg Q1, Q0, input clock, in); clock) begin Q1 <= in & Q0; Q0 <= in | Q1; end endmodule Q D in Q1 Q0 clock Values after the clock edge (t+) — calculated in response to the clock edge, using values at the clock edge 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 11/12/2018 Thomas: Digital Systems Design Lecture 11
41
Thomas: Digital Systems Design Lecture 11
Summary Structure vs. Behavior Timing Model and Event-Driven Simulation Delays Instantiation Procedural Models Scheduling Summary 11/12/2018 Thomas: Digital Systems Design Lecture 11
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.