Digital System Verification. VERIFICATION OUTLINE Purpose of Verification –Verification effort and cost Verification Tools –Linting tools –Code Coverage

  • View

  • Download

Embed Size (px)

Text of Digital System Verification. VERIFICATION OUTLINE Purpose of Verification...

  • Digital System Verification

  • VERIFICATION OUTLINEPurpose of VerificationVerification effort and costVerification ToolsLinting toolsCode CoverageSimulationEquivalence CheckingRapid PrototypingVerification StrategyVerification planDirected TestingConstrained-Random TestingCoverage-driven verificationVerification TechniquesText I/OSelf-checking TestbenchOOP in Testbenches

  • VERIFICATION (1/2)The process of demonstrating the functional correctness of a designFor multi-million gate ASICs, SoCs and reusable IP:70% of design effort goes to verificationMore (twice as many) verification engineers than designersTestbench 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 interpretationFunctional 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 sourceOutput: Warning and error messagesThey 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 isport (my_input: in std_logic);end my_entity;architecture sample of my_entity issignal s1: std_logic;signal s1: std_logic;beginstatement1: s1
  • SIMULATIONInput: HDL with stimulusOutput: WaveformSimulation requires stimulusThe simulation outputs are validated externally (the simulator cannot check them itself)Event-driven simulationChange in values (events) drive the simulation process.Necessary in combinational circuitsSlowCycle-based simulationClock events drive the simulation processUsed in sequential circuitsFaster, timing information is lostTransaction-based simulation

  • CODE COVERAGEShows if all functions and statements are executed during a simulation runIf coverage is low, then the testbench is poor

  • EQUIVALENCE CHECKINGInput: HDL, post-synthesis netlistChecks if the RTL description and the post-synthesis gate-level netlist have the same functionalityIf yes, post-synthesis simulation is not necessary

  • RAPID PROTOTYPINGUsing FPGAs to create a prototype of the final designFaster than simulationThe prototype doesnt have to meet final product constraints (speed, area, power)Important: Write reusable HDL code to re-use it for the final ASIC product

  • VERIFICATION PLANThe verification plan is a specification document for the verification effortAd-hoc approaches are inefficientDefine first-time successWhich features are critical and which optionalDefine a verification scheduleSpecify the features that must be verifiedThe RTL design team must contributePlan how to verify the responseSome responses are difficult to verify visually

  • VERIFICATION PLANA 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 definedThe 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 orderedStimulus requirements shall be identified.

  • ETHERNET CORE VERIFICATION PLAN SAMPLER3.1/14/0 Packets are limited to MAXFL bytes SHOULDR3.1/13/0 Does not append a CRC SHOULDR3.1/13/1 Appends a valid CRC MUSTR3.1/9/0 Frames are lost only if attempt limit is reached SHOULD

  • VERIFICATION STRATEGIESDirected verificationWriting specific testbenches to test specific specification featuresEasy to perform, slow coverageOnly covers the bugs the designer can think ofConstrained Random VerificationNot random ones and zeroes, but valid operations in random sequence and with random dataThey provide stimuli the designer didnt think ofHarder to perform, faster coverageHard to predict the output

  • VERIFICATION STRATEGIESRealistic VerificationProvide realistic inputs (e.g. packet traces, etc)Design for verificationAdd datapath bypass circuitsAdd observability through memory-mapped registers

  • TESTBENCHESNon-synthesizable code is allowed and, in fact, essentialDo not use RTL code in testbenches

  • STIMULUSClockssignal clk: std_logic:=0;beginclk
  • RESPONSE VERIFICATIONVisual inspection (waveform or list)Too difficult for large designs with complex responsesWriting to a fileprocess (clk)variable L: line;beginif clkevent and clk = 0 thenwrite(L, ...);writeline(output, L);end if;end process;

  • SELF-CHECKING TESTBENCHA testbench that besides the input vectors also checks the responseThe designer must accurately predict outputSimple for RAM, FIFOs, networks etc.Complex for DSP, voice, image, video applications

  • ATTRIBUTESData attributes(all synthesizable)dLOW --returns lower indexdHIGH--returns higher indexdLEFT --returns leftmost indexdRIGHT--returns rightmost indexdLENGTH --returns vector sizedRANGE--returns vector rangedREVERSE_RANGE--returns reverse vector rangeSignal attributes(first two synthesizable)sEVENT--returns true when event on ssSTABLE--returns true when no event on ssACTIVE--returns true when s=1sQUIET--returns true when no event on s for specified timesLAST_EVENT--returns time since last event on ssLAST_ACTIVE--returns time since s = 1sLAST_VALUE--returns value of s before last event

  • WAIT STATEMENTwait for --simulation onlywait for 5 ns;wait on --both simulation and RTLwait on clk, rst_n --instead of sensitivity listwait until --both simulation and RTLwait until clkevent 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 dSTABLE(setup_time) report "Setup Time Violation" severity error; wait for hold_time; assert dSTABLE(hold_time) report "Hold Time Violation" severity error; end process check;

  • EXAMPLEUse the previous VHDL features to automatically check the following condition:If signal sel=01, output =0010Apply the above to create a self-checking decoder testbench

  • TEXT I/OA standard package for text file input and outputlibrary std;use std.textio.all;A variable of line type is used for I/Oreadline(L,k) --reads line from fileread(k,v) --reads value from kwrite(k,v) --writes value to kwriteline(L,k) --writes k to fileThe text file must be definedfile 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

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