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