digital system verification. verification outline purpose of verification –verification effort and...
TRANSCRIPT
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;
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;beginclk <= not clk after 50 ns; --100 ns period clock
• Deterministic waveformss <= ‘0’, ‘1’ after 100 ns, ’0’ after 200 ns, ‘1’ after 240 ns;
• Modeling of synchronous signalssync_data_gen: process(clk)beginif clk = ’0’ thendata <= ... 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 fileprocess (clk)variable L: line;beginif clk’event and clk = ’0’ thenwrite(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 <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
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
ASSERTION statementassert 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 EXAMPLEprocessvariable 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";
beginwhile 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