1. Digital System Verification

2. 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

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 thata design meets the intent of its specification. • Specification documentsare open to interpretation • Functional verification can showthat a design meets the intent of its specification, but it cannot proveit. • It can prove that the design does notimplement 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) entity my_entity is port (my_input: in std_logic); end my_entity; architecture sample of my_entity is signal s1: std_logic; 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.

7. SIMULATION • Input: HDL with stimulus • Output: Waveform • Simulationrequires stimulus • The simulationoutputs 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. 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

10. 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

11. 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

12. 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.

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

14. 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

15. 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

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

17. STIMULUS • Clocks signal clk: std_logic:=0; begin clk <= not clk after 50 ns; --100 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;

18. 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;

19. 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

20. 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’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 <time> --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

21. WAIT STATEMENT • wait for <time> --simulation only • wait for 5 ns; • wait on <signals> --both simulation and RTL • wait on clk, rst_n --instead of sensitivity list • wait until <condition> --both simulation and RTL • wait until clk’event and clk=‘1’ --instead of if

22. 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'; assertd’STABLE(setup_time) report "Setup Time Violation" severity error;     wait for hold_time; assertd’STABLE(hold_time) report "Hold Time Violation" severity error; end process check;

23. 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

24. 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

25. 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;

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