1. Digital System Verification

2. VERIFICATION OUTLINE Purpose of Verification Verification Tools
Verification effort and cost
Verification Tools
Linting tools
Code Coverage
Simulation
Equivalence Checking
Rapid Prototyping
Verification Strategy
Verification plan
Directed Testing
Constrained-Random Testing
Coverage-driven verification
Verification Techniques
Text I/O
Self-checking Testbench
OOP in Testbenches

3. VERIFICATION (1/2)
The process of demonstrating the functional correctness of a design
For multi-million gate ASICs, SoCs and reusable IP:
70% of design effort goes to verification
More (twice as many) verification engineers than designers
Testbench code is 4 times more than RTL code

4. VERIFICATION (2/2)
It is impossible to prove that a design meets the intent of its specification.
Specification documents are open to interpretation
Functional verification can show that a design meets the intent of its specification, but it cannot prove it.
It can prove that the design does not implement the intended function by identifying a single discrepancy.

5. LINTING TOOLS (1/2) Input: HDL source
Output: Warning and error messages
They do not require stimulus, or a description of the expected output.
They perform checks that are entirely static, with the expectations built into the linting tool itself.
The warning messages should be filtered

6. LINTING TOOLS (2/2) module my_module (my_output, my_input);
output my_output;
reg s1;
assign s1 = my_input;
assign s1 = ~my_input;
endmodule;
Linting tool output
Warning: file my_module.v: Signal "s1" is
multiply driven.

7. SIMULATION Input: HDL with stimulus Output: Waveform
Simulation requires stimulus
The simulation outputs are validated externally (the simulator cannot check them itself)
Event-driven simulation
Change in values (events) drive the simulation process.
Necessary in combinational circuits
Slow
Cycle-based simulation
Clock events drive the simulation process
Used in sequential circuits
Faster, timing information is lost
Transaction-based simulation

8. CODE COVERAGE
Shows if all functions and statements are executed during a simulation run
If coverage is low, then the testbench is poor

9. CODE COVERAGE

10. EQUIVALENCE CHECKING Input: HDL, post-synthesis netlist
Checks if the RTL description and the post-synthesis gate-level netlist have the same functionality
If yes, post-synthesis simulation is not necessary

11. RAPID PROTOTYPING
Using FPGAs to create a prototype of the final design
Faster than simulation
The prototype doesn’t have to meet final product constraints (speed, area, power)
Important: Write reusable HDL code to re-use it for the final ASIC product

12. VERIFICATION PLAN
The verification plan is a specification document for the verification effort
Ad-hoc approaches are inefficient
Define first-time success
Which features are critical and which optional
Define a verification schedule
Specify the features that must be verified
The RTL design team must contribute
Plan how to verify the response
Some responses are difficult to verify visually

13. VERIFICATION PLAN
A definition of what the design does shall be specified.
input patterns it can handle,
errors it can sustain
based on functional specification document of the design agreed upon by the design and verification teams.
A definition of what the design must not do shall be specified.
The verification requirements must outline which errors to look for.
Any functionality not covered by the verification process shall be defined
The conditions considered to be outside the usage space of the design must be outlined
Each verification requirement must have a unique identifier.
Requirements should be ranked and ordered
Stimulus requirements shall be identified.

14. ETHERNET CORE VERIFICATION PLAN SAMPLE
R3.1/14/0 Packets are limited to MAXFL bytes SHOULD
R3.1/13/0 Does not append a CRC SHOULD
R3.1/13/1 Appends a valid CRC MUST
R3.1/9/0 Frames are lost only if attempt limit is reached SHOULD

15. VERIFICATION STRATEGIES
Directed verification
Writing specific testbenches to test specific specification features
Easy to perform, slow coverage
Only covers the bugs the designer can think of
Constrained Random Verification
Not random ones and zeroes, but valid operations in random sequence and with random data
They provide stimuli the designer didn’t think of
Harder to perform, faster coverage
Hard to predict the output

16. VERIFICATION STRATEGIES
Realistic Verification
Provide realistic inputs (e.g. packet traces, etc)
Design for verification
Add datapath bypass circuits
Add observability through memory-mapped registers

17. TESTBENCHES Non-synthesizable code is allowed and, in fact, essential
Do not use RTL code in testbenches

18. COMMENTS Code should be thoroughly commented.
Comments should provide information not state the obvious.
Example (bad)
addr=addr+1 //incrementing addr
Example (good)
addr=addr+1 //the FIFO is written in consecutive addresses, so the address is incremented by one

19. STIMULUS Clocks Deterministic waveforms
reg clk;
initial begin
clk = 0;
always begin
#50 assign clk = ~clk; ns period clock
Deterministic waveforms
assign s = 0,
#100 assign s = 1;
#100 assign s = 0;
Modeling of synchronous signals
(posedge clk)
begin
if (clk = 0)
# 1 data =;
end if;
end;

20. Display functions
$display("<format>", exp1, exp2, ...); // formatted write to display
Formats:
%b %B binary
%c %C character (low 8 bits)
%d %D decimal
%h %H hexadecimal
%o %O octal
%s %S string, 8 bits per character

21. Reading stimulus from file
reg [3:0] stim [0:5]
initial begin
$readmemh("counter_in.vec", stim); //reading from file
for(index=0; index<6; index=index+1)
begin
@(posedge clk)
preload = stim[index]; //assigning to input
$display("%d:%h",index,stim[index]);
end

22. RESPONSE VERIFICATION
Visual inspection (waveform or list)
Too difficult for large designs with complex responses
Writing to a file
integer fo;
initial begin
fo = $fopen("alu_test.vec");
clk) //every clock edge
$fdisplayh(fo, output1, output2, …);
end

23. SELF-CHECKING TESTBENCH
A testbench that besides the input vectors also checks the response
The designer must accurately predict output
Simple for RAM, FIFOs, networks etc.
Complex for DSP, voice, image, video applications

24. EXAMPLE
Use the previous Verilog features to automatically check the following condition:
If signal sel=“01”, output =“0010”
Apply the above to create a self-checking decoder testbench

25. TEXT I/O EXAMPLE 2
Write a testbench that writes a counter output to a text file