Digital System Verification VERIFICATION OUTLINE Purpose of Verification
- Slides: 23
Digital System Verification
VERIFICATION OUTLINE • Purpose of Verification – 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
VERIFICATION (1/2) • The process of demonstrating the functional correctness of a design • For multi-million gate ASICs, So. Cs 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
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.
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
LINTING TOOLS (2/2) module my_entity (s 1, my_input); output s 1; wire s 1; assign s 1 = my_input; assign s 1 = not my_input; Endmodule ------Linting tool output--------Warning: file my_entity. v: Signal "s 1" is multiply driven.
• • 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
CODE COVERAGE • Shows if all functions and statements are executed during a simulation run • If coverage is low, then the testbench is poor
EQUIVALENCE CHECKING • Input: HDL, post-synthesis netlist • Checks if the RTL description and the post-synthesis gatelevel netlist have the same functionality • If yes, post-synthesis simulation is not necessary
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 reuse it for the final ASIC product
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
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.
ETHERNET CORE VERIFICATION PLAN SAMPLE • R 3. 1/14/0 Packets are limited to MAXFL bytes SHOULD • R 3. 1/13/0 Does not append a CRC SHOULD • R 3. 1/13/1 Appends a valid CRC MUST • R 3. 1/9/0 Frames are lost only if attempt limit is reached SHOULD
VERIFICATION STRATEGIES • Directed verification – Writing specific testbenches to test 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
Example • Calculate the number of input stimulus vectors required to verify a 32 -bit adder. • Assuming simulation requires 1 ns per transition calculate the required simulation time
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
TESTBENCHES • Non-synthesizable code is allowed and, in fact, essential • Do not use RTL code in testbenches
• Clocks STIMULUS reg clk; initial begin clk = 1’b 0; end always begin #50 clk = ~clk //100 ns period clock end • Deterministic waveforms initial s #100 s … end begin //or always begin = 0; = 1; //after 100 ns = 0; //after 200 ns, • Modeling of synchronous signals always @ (posedge clk) begin if (clk ==1) #1 data <=. . . //after 1 ns; end
RESPONSE VERIFICATION • Visual inspection (waveform or list) – Too difficult for large designs with complex responses • Writing to a file integer f; initial begin //also possible with always f = $fopen("output. txt", "w"); //file open $fwrite(f, "%bn", signal); //signal value $fclose(f); end
EXAMPLE 2 • Write a testbench that writes a counter output to a text file module counter(count, clk, rst_n); output [3: 0] count; input clk, rst_n; reg [3: 0] count; always @ (posedge clk or negedge rst_n) begin if (rst_n == 0) count = 0; else count = count + 1; endmodule
Testbench (1/2) module counter_tb(); // Inputs reg clk; reg rst_n; // Outputs wire [3: 0] count; integer f; // Instantiate the Unit Under Test (UUT) counter uut (. count(count), . clk(clk), . rst_n(rst_n) );
Testbench (2/2) initial begin // Initialize Inputs clk = 0; rst_n = 0; // Wait 20 ns for global reset to finish #20 rst_n = 1; f = $fopen("output. txt", "w"); //file open #200 $fclose(f); $finish; end always #10 clk = ~clk; always @ (posedge clk) $fwrite(f, "%bn", count); //signal value endmodule
Reading from a file module rom_using_file ( address , // Address input data , // Data output read_en , // Read Enable ce // Chip Enable ); input [7: 0] address; output [7: 0] data; input read_en; input ce; reg [7: 0] mem [0: 255] ; always @ (ce or read_en) begin if (ce & read_en) data = mem[address]; end initial begin $readmemb("memory. list", mem); // endmodule
- Duties of stock verification officer
- Quotation sandwich example
- The purpose of outlining
- Digital footprint
- Digital topic outline
- Give me a sentence
- General purpose specific purpose central idea
- Purpose of digital graphics
- Thermal cycler temperature verification system
- Asset verification system oregon
- Warga digital adalah...
- E-commerce: digital markets, digital goods
- Digital data digital signals
- Digital data digital signals
- E-commerce: digital markets, digital goods
- Signal encoding techniques in data communication
- "key international"
- Unique features of digital markets
- Lesson 2 muscle storyboard
- Lymphatic system function
- Outline the binomial system of nomenclature
- Open closed and isolated system
- Digestive system respiratory system and circulatory system
- Respiratory system purpose