Chapter 3 Testbench, Dataflow and Behavioral Verilog

CHAPTER 3: Testbench, Dataflow and
Behavioral Verilog
pail.phenikaa-uni.edu.vn thuan.levan@phenikaa-uni.edu.vn
Syllabus
Week Content Notes

1 Chapter 0: Course Introduction (1)
Chapter 1: Introduction of Verilog and FPGA (2)
2 Chapter 2: Verilog Syntax, Structural Verilog and Timing (3)
3, 4 Chapter 3: Testbench, Dataflow and Behavioral Verilog (6)
5 Chapter 4: Counters, Shifters/Rotators, Parameters (3)
6 Chapter 5: Handy Testbench Constructs (3)
7 Midterm Exam Practice (3)
8 Midterm Exam (3)
9, 10 Chapter 6: Finite State Machine (FSM) in Verilog (6)
Content
1.Simulator Mechanics
2.Testbench Basics
3.Dataflow Verilog
4.Behavior Verilog
5.Blocking and Non-blocking
6.Conditional statements
1. Simulation Mechanics
 Analog Simulation
• Divide “time” into slices
• Update information in whole circuit at each slice
• Used by LTSPICE
• Allows detailed modeling of current and voltage
• Computationally intensive and slow
• Don’t need this level of detail for most digital logic simulation
 Digital Simulation
• Could update every signal on an input change
• Could update just the full path on input change
• Don’t even need to do that much work!

5
 Event-Driven Simulation
• When an input to the simulating circuit changes, put it on a
“changed” list
• Loop while the “changed” list isn’t empty:
 Remove a signal from the “changed” list
 For each sink of the signal, recomputes its new output(s). For any
output(s) that have changed value, add that signal to the “changed” list
• When the “changed” list is empty:
 Keep simulation results
 Event-Driven Simulation
• Update only if changed
• Some circuits are very large

 Update every signal very slow simulation
 Event-driven simulation is much faster!
2. Testbench Basics
 Need to verify your design
• “Design Under Test” (DUT)
 Use a “testbench”
• Special Verilog module without input/output ports
• Generates out routes inputs to the DUT
• For now, we will monitor outputs via human interface
2. Testbench Basics
2. Testbench Basics (Requirements)
 Instantiate the unit being tested (DUT)
 Provide input to that unit
• Usually a number of different input combinations!
 Watch the “results” (outputs of the DUT)
• Can watch ModelSim Wave window …
• Can print out information to the screen or to the file
 This way of monitoring outputs (human interface) is dangerous &
incomplete
• Subject to human error
• Cannot be automated into batch jobs
• Self checking testbenches will be covered later
10
2. Testbench Basics (Output Test
Info)
 Several different system calls to output info
• $monitor
 Output the given values whenever one changes
 Can use when simulating Structural, RTL, and/or Behavioral
• $display, $strobe
 Output specific information like a printf in a C program
 Used in Behavioral Verilog
 Can use formatting strings with these commands
 Only means anything in simulation
 Ignored by synthesizer
11
2. Testbench Basics (Output Format
Strings)
12
2. Testbench Basics (Output Format
Strings)
 Formatting string
• %h, %H hex
• %d, %D decimal
• %o, %O octal
• %b, %B binary
• %t time
 $monitor(“%t: %b %h %h %h %b\n”,
$time, c_out, sum, a, b, c_in);
 Can get more details from Verilog standard

13
2. Testbench Basics (Exhaustive
Testing)
 For combination designs with up to 8 or 9 inputs
• Test ALL combinations of inputs to verify output
• Could enumerate all test vectors, but don’t …
• Generate them using a “for” loop!
 Need to use “reg” type for loop variable? Why?

14
2. Testbench Basics (Exhaustive
Testing)
 Why does loop vector has extra bit?
 If you want to test all vectors 0000 to 1111
 If is 4 bits, it only gets up to 1111 15.

• 1100 1101 1110 1111 0000 0001
 is never >= 16 … so loop goes forever!
15
2. Testbench Basics (DUT Example)
16
 Step 1: Declare module testbench
• Usually add _tb to the testbench module name
 Step 2: Declare the signals that are connected to the inputs/outputs

of DUT
• Type reg for the signals that are connected to the inputs
• Type wire for the signals that are connected to the outputs
 Step 3: Instantiate the DUT with the declared signal

• Two kinds of module connection (by name or by order)
17
 Step 4: Monitor the signals that are connected to the outputs of the DUT
and stop/finish simulation
• Use the system task $monitor with time stamp
• Stop/finish with $stop/$finish (what is the different between them?)
 Step 5: Generate the signals that are connected to the inputs of the DUT
• Usually use exhaustive test to cover all input combinations
18
19
20
 Let do more ModelSim example here!
 Example of 3-bit wide adder block
21
22
23
2. Testbench Basics (Generating
Clocks)
 Wrong way:
 Right way:
 LESS TYPING
 Easier to read, harder to make mistake 24
2. Testbench Basics (FSM Testing)
 Response to input vector depends on state
 For each state:

• Check all transitions
• For Moore, check output at each state
• For Mealy, check output for each transition
• This includes any transitions back to same state!
 Can be time consuming to traverse FSM repeatedly …
25
 Write a testbench to test a gray code counter
module gray_counter(out, clk, rst);
 rst in this case is a synchronous reset

• It does not directly asynchronously reset the flops
• It is an input to the combination logic that set the next state to all 0’s.
 Initially reset the counter and then test all states, but do not test reset
in each state.
26
 Solution for gray code counter – Test 1
27
28
2. Testbench Basics (Force/Release)
 Example
29
2. Testbench Basics (Force/Release)
 Allows you to “override” value FOR SIMULATION
 Does not do anything in “real life”
 How does this help testing?

• Can help to pinpoint bug
• Can use with FSMs to override state
 Force to a state
 Test all edges/outputs for that state
 Force the next state to be tested, and repeat
 Can help achieve code coverage (later)
30
 Write a testbench to test a gray code counter example above
module gray_counter(out, clk, rst);
 Initially reset the counter and then test all states, then test reset in
each state
 Remember that in this example, rst is treated as an input to the

combination logic.
31
32
33
3. Dataflow Verilog
 This continuous assign statement
• It is the main construct of Dataflow Verilog
• It is deceptively powerful & useful
 Generic form:
34
3. Dataflow Verilog
 Simplest form:
// out is a net, a & b are also nets
assign out = a & b; // and gate functionality
 Using vectors
wire [15:0] results, src1, src2; // 3 16-bit wide vectors
assign results = src1 ^ src2; // 16-bit wide XOR
 Can you implement a 32-bit adder in a single line?
35
Vector Concatenation
 Can build vectors using smaller vectors and/or scalar values
 Use the {} operator
 Example 1
36
 Example 2
 Vector concatenation is not limited to assign statements. In this

example, it is done in a port connection of a module instantiation.
37
 Replication with concatenation
 Sometimes it is useful to replicate a bit (or vector) within the
concatenation of another vector.
• This is done with a replication constant (number) in front of the {}
• Example of signing extend an 8-bit value to a 16-bit bus
 Recall, to sign extend a 2’complement number, you just replicate

the MSB.
• The MSB of the 8-bit offset term has to be replicated 8 times
38
3. Dataflow Verilog
 More basic generic form
assign <LHS> = <RHS expression>;
 If RHS result changes, LHS is updated with the new value
• Constantly operating
• It’s hardware!
• RHS can use operators (i.e. +, -, &, |, ^, ~, >>, …)
39
Operators: Arithmetic
 Much easier than structural!
 Some of these don’t synthesis

 Also have unary operators +/- (pos/neg)
 Understand bitsize!
• Can affect sign of result
• Is affected by bitwidth of BOTH sides?
40
Operators
 Shift (<<, >>, <<<, >>>)
• <<<, >>> shift bit while keeping the sign bit
 Relational (<, >, <=, >=)
 Equality (==, !=, ===, !===)
• ===, !== test x’s, z’s! ONLY USE FOR SIMULATION!
 Logical Operators (&&, ||, !)
• Build clause for if statement or conditional expression
• Return single bit values
 Bitwise Operators (&, |, ^, ~)
• Applies bit-by-bit
 Watch ~ vs. !, | vs. ||, and & vs. &&
41
Reduction Operators
 Reduction operators are reduce all the bits of a vector to a
single bit by performing an operation across all bits.
• Reduction AND
 assign all_ones = &accumulator; // are all bits set?
• Reduction OR
 assign not_zero = |accumulator; // are any bits set?
• Reduction XOR
 assign parity = data_out; // even parity bit
42
Conditional Operators
 The functionality of a 2:1 MUX
 assign out = conditional_expr ? true_expr : false_expr;
43
Conditional Operators
44
Operators: Precedence
Operators Operator Symbols Precedence
Reduction !~&| Highest Precedence
~& ~| ^ ~^
Unary + -
Multiply, Divide, Modulus * / %
Add, Subtract + -
Shift << >>
Relational < <= > >=
Equality == != === !==
Bitwise & ^ ~^ |
Logical && ||
Conditional ?: Lowest Precedence
45
3. Dataflow Verilog (Latches)
 What does the following statement imply/do?
assign q_out = enable ? data_in : q_out;
• It acts as a latch. If enable is high, new data goes to q_out. Otherwise,
q_out maintains its previous value.
• How does it synthesize??
46
4. Behavioral Verilog
 initial and always form basis of all behavioral Verilog
• All other behavioral statements occur within these
• initial and always blocks cannot be nested
• All <LHS> assignments must be to type reg
 initial statements start at time 0 and execute once
• If there are multiple initial blocks, they all start at time 0 and execute
independently. They may finish independently.
 If multiple behavioral statements are needed within the initial
statement then the initial statement can be made compound with use
of begin/end
 Initial statement very useful for testbenches.
47
4. Behavioral Verilog (initial Blocks)
48
4. Behavioral Verilog (initial Blocks)
49
4. Behavioral Verilog (always)
 Behavioral block operates CONTINUOUSLY
• Executes at time zero but loop continuously
• Can use a trigger list (or sensitivity list) to control operation; @(a, b, c)
• In absence of a trigger list, it will re-evaluate when the last <LHS>
assignment completes.
50
4. Behavioral Verilog (always vs initial)
 What values does each block produce?

• Let’s take our best guess
• Then let’s try it in simulator
51
4. Behavioral Verilog (always vs initial)
52
4. Behavioral Verilog (Trigger lists)
 Conditionally “execute” inside of always block
• Any change on trigger (sensitivity) list, triggers block
 Original way to specify trigger list

always @ (X1 or X2 or X3)
 In Verilog, you can use this, instead of or
always @ (X1, X2, X3)
 Verilog also has * for combinational only
always @ (*)
53
4. Behavioral Verilog (Example)
 Let’s design a 4-bit wide Comparator
54
4. Behavioral Verilog (FlipFlops)
 A negedge is on the transitions
• 1 x, z, 0
• x, z 0
 A posedge is on the transitions
• 0 x, z, 1
• x, z 1
 Used for clocked (synchronous) logic
55
56
57
58
59
Know your cell library
 What type of flops are available
• + (posedge) or – (negedge) edge triggered (most are positive)
• Is the asynchronous reset active high or active low?
• Is a synchronous reset available?
 Code to what is available

• You want synthesis to be able to pick the least number of cells to
implement what you code.
• If your library has active low asynchronous reset flops then don’t code
active high reset flops.
60
4. Behavioral Verilog (Combinational
vs. Sequential)
 Combinational
• Not edge-triggered
• All “input” (RHS nets/variables) are triggers
• Does not depend on clock
 Sequential
• Edge-triggered by clock signal
• Only clock (and possibly reset) appear in trigger list
• Can include combinational logic that feeds a FF or register
61
5. Blocking and non-Blocking
 Blocking “Evaluated” sequentially
 Used for combinational logic
62
 Non blocking “updated” simultaneously if no delays given
 Used for sequential logic
 Use <= operator
63
 Swapping if done in Blocking
 Need a “temp” variable
64
 Called blocking because …
• The evaluation of subsequent statements <RHS> are blocked, until
<LHS> assignment of the current statement is completed.
65
 With non-blocking statements, the <RHS> of subsequent
statements are not blocked.
 They are all evaluated simultaneously.
66
 Why not Non-Blocking for combinational?
 Can we make this example work?
67
 So Blocking is no good and we should always use Non-
Blocking?
 Consider combinational logic
68
6. Conditional Statements (If…else)
 General form
69
 How does and if…else if…else statement synthesize?
• Does not conditionally “execute” block of code!
• Does not conditionally create hardware!
• It makes a multiplexer or selecting logic
• Generally:
 Hardware for both is created
 Both paths “compute” simultaneously
 The result is selected depending on the condition
70
 How does and if…else if…else statement synthesize?
71
 Watch the sensitivity lists…what is missing in this example?
72
6. Conditional Statements (case)
 Verilog has three types of case statements:
• case, casex, and casez
 Performs bitwise match of expression and case item
• Both must have same bitwidth to match!
 case
• Can detect x and z! (good for testbenches)
 casez
• Uses z and ? as “don’t’ care” bits in case items and expression
 casex
 Uses x, z, and ? as “don’t’ care” bits in case items and expression
73
 General form
74
 Using case to detect x and z
 Only use this functionality in a testbenches!
 Example
75
6. Conditional Statements (casex)
 Uses x, z, and ? as single-bit wildcards in case item and
expression
 Uses first match encountered
 What is the output for code = 2’b01?

 What is the output for code = 2’b1x? 76
 Uses z and ? as single-bit wildcards in case item and
expression
 What is the output for code = 2’b01?

 What is the output for code = 2’bzz?
77
 Use of default case vs. casex
 If casex treats x, z, and ? as don’t care then one can create a
case in which all possible alternatives are covered.
• This would prevent unintended latches
• Therefore default branch of case would not be needed
 But …
• The default branch method is typically easier to read/understand
• Sometimes it is good to have a default behavior, especially in next
state assignments of state machines.
78

Chapter 3 Testbench, Dataflow and Behavioral Verilog

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 3 Testbench, Dataflow and Behavioral Verilog

Uploaded by

Copyright:

Available Formats

CHAPTER 3: Testbench, Dataflow and

Week Content Notes

• Could update just the full path on input change

• Don’t even need to do that much work!

• Some circuits are very large

 Can get more details from Verilog standard

 Need to use “reg” type for loop variable? Why?

 If is 4 bits, it only gets up to 1111 15.

 Step 2: Declare the signals that are connected to the inputs/outputs

 Step 3: Instantiate the DUT with the declared signal

 For each state:

 Can be time consuming to traverse FSM repeatedly …

 rst in this case is a synchronous reset

 How does this help testing?

 Can help achieve code coverage (later)

 Remember that in this example, rst is treated as an input to the

 Vector concatenation is not limited to assign statements. In this

 Recall, to sign extend a 2’complement number, you just replicate

 Some of these don’t synthesis

 What values does each block produce?

 Original way to specify trigger list

 Code to what is available

 What is the output for code = 2’b01?

 What is the output for code = 2’b01?

You might also like