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, 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

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) entity my_entity is port (my_input: in std_logic); end my_entity; architecture sample of my_entity is signal s1: std_logic; begin statement1: s1 <= my_input; statement2: s1 <= not my_input; end sample; Linting tool output Warning: file my_entity.vhd: Signal "s1" 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 gate- level 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 re- use 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 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

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

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

STIMULUS Clocks signal clk: std_logic:=0; begin clk <= not clk after 50 ns; ns period clock Deterministic waveforms s <= ‘0’, ‘1’ after 100 ns, ’0’ after 200 ns, ‘1’ after 240 ns; Modeling of synchronous signals sync_data_gen: process(clk) begin if clk = ’0’ then data <=... after 1 ns; end if; end process sync_data_gen;

RESPONSE VERIFICATION Visual inspection (waveform or list) –Too difficult for large designs with complex responses Writing to a file process (clk) variable L: line; begin if clk’event and clk = ’0’ then write(L,...); writeline(output, L); end if; end process;

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

ATTRIBUTES Data attributes(all synthesizable) –d’LOW --returns lower index –d’HIGH--returns higher index –d’LEFT --returns leftmost index –d’RIGHT--returns rightmost index –d’LENGTH --returns vector size –d’RANGE--returns vector range –d’REVERSE_RANGE--returns reverse vector range Signal attributes(first two synthesizable) –s’EVENT--returns true when event on s –s’STABLE--returns true when no event on s –s’ACTIVE--returns true when s=‘1’ –s’QUIET --returns true when no event on s for specified time –s’LAST_EVENT--returns time since last event on s –s’LAST_ACTIVE--returns time since s = ‘1’ –s’LAST_VALUE--returns value of s before last event

WAIT STATEMENT wait for --simulation only –wait for 5 ns; wait on --both simulation and RTL –wait on clk, rst_n --instead of sensitivity list wait until --both simulation and RTL –wait until clk’event and clk=‘1’ --instead of if

ASSERTION statement assert boolean-expression report string-expression severity severity-level{note, warning, error, failure }; check: process begin wait until clk'event and clk='1'; assert d’STABLE(setup_time) report "Setup Time Violation" severity error; wait for hold_time; assert d’STABLE(hold_time) report "Hold Time Violation" severity error; end process check;

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

TEXT I/O A standard package for text file input and output –library std; –use std.textio.all; A variable of line type is used for I/O –readline(L,k) --reads line from file –read(k,v) --reads value from k –write(k,v) --writes value to k –writeline(L,k) --writes k to file The text file must be defined –file Prog: text is in "file_name"; --text file "file_name" –variable L: line; -- read lines from file to L

TEXT I/O EXAMPLE process variable text_line1, text_line2: line; variable i, j : integer; file text_in: text open read_mode is "akiyo1.txt"; file text_out: text open write_mode is "akiyo2.txt"; begin while not endfile(text_in) loop if count4(1) = '0' then readline(text_in, text_line1); read(text_line1, i); cword_in <= std_logic_vector(conv_unsigned(i, cword_in'length)); end if; j:= conv_integer('0' & cword_sub2_out); if count4 = "10" then write(text_line2, j); writeline(text_out, text_line2); end if; wait until clk = '1' and rst_n = '1' and en = '1'; end loop; wait; end process;

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