VHDL Testbench Techniques that Leapfrog SystemVerilog by Jim Lewis VHDL Training Expert at SynthWorks IEEE 1076 Working Group Chair OSVVM Chief Architect [email protected] SynthWorks SynthWorks VHDL Testbench Techniques Copyright © 2013 by SynthWorks Design Inc. Reproduction of this entire document in whole for individual usage is permitted. All other rights reserved. In particular,without express written permission of SynthWorks Design Inc, You may not alter, transform, or build upon this work, You may not use any material from this guide in a group presentation, tutorial, training, or classroom You must include this page in any printed copy of this document. This material is derived from SynthWorks' class, VHDL Testbenches and Verification This material is updated from time to time and the latest copy of this is available at http://www.SynthWorks.com/papers Contact Information Jim Lewis, President SynthWorks Design Inc 11898 SW 128th Avenue Tigard, Oregon 97223 503-590-4787 [email protected] www.SynthWorks.com 2 SynthWorks VHDL Testbench Techniques O Goals: Thorough, Timely, and Readable Testing O Agenda O Testbench Architecture O Transactions O Writing Tests O Randomization O Functional Coverage O Constrained Random is Too Slow! O Intelligent Coverage is More Capable O Coverage Closure is Faster with Intelligent Coverage O Self-Checking & Scoreboards O Scoreboards O Dispelling FUD 3 SynthWorks Testbench Architecture O Historically a separate testbench is written for different levels of testing RTL Stim UartCmd Core Stim UART UartCmd Uart … System Stim Memio CpuIf UART UartCmd Uart … O Each testbench slightly larger than the previous. 4 SynthWorks Testbench Architecture O Many interfaces transport the same information TB_System Stim Model Memio CpuIf UART UartCmd Uart … O Change from RTL to Core to System by: O Separating stimulus from interface signaling (signal wiggling) O Changing the Model (changes signal wiggling) O Changing the connections (via VHDL-2008 external names) O Leave items not used in a test unbound or use a dummy architecture O Reduction in number of testbenches can minimize wasted effort. O But we need to plan from the System level 5 SynthWorks Testbench Architecture TbMemIO TestCtrl TestCtrl Entity Test1 CPU DUT: MemIO UartRx Architecture Model Model Test2 Clock & CpuIf MemIf UartTx Architecture Reset Model IntCtrl UART . Timer SRAM TestN Model Architecture O System / Chip Level Testbench O TLM (transaction level model) implements signaling to DUT O TestCtrl to sequence and/or synchronize models O Each test is a separate architecture of TestCtrl O Plan to pre-use system level models for Core and RTL tests 6 SynthWorks Transactions O Interface Operations, ie: CpuWrite, CpuRead, … O Essential for reuse and pre-use O 2 Aspects: Initiation (stimulus) and Implementation (model) Clk nReset nAds Read Addr Invalid ADDR0 ADDR0 Invalid Data Invalid D1 D1 Inv nRdy CpuWrite CpuRead 7 SynthWorks Transaction Initiation O Writing tests by wiggling signals is slow, error prone, and inhibits reuse -- CPU Write nAds <= '0' after tpd, '1' after tperiod + tpd ; Addr <= ADDR0 after tpd ; Data <= X"A5A5" after tperiod + tpd ; Wr_nRd <= '0' after tpd ; wait until nRdy = '0' and rising_edge(Clk) ; O Transaction initiation using procedures: . CpuWrite(CpuRec, ADDR0, X"A5A5"); CpuRead (CpuRec, ADDR0, DataO); . O Simplifies writing tests. O Increases readability and maintainability 8 SynthWorks Transaction Implementation O Implement transactions using either Subprograms or Entities O Subprograms do both O Transaction initiation by calling the subprogram O Transaction implementation (signal wiggling) internal to subprogram procedure CpuWrite ( signal CpuRec : InOut CpuRecType ; constant AddrI : In std_logic_vector; constant DataI : In std_logic_vector ) is begin CpuRec.nAds <= '0' after tpd, '1' after tperiod + tpd ; CpuRec.Addr <= AddrI after tpd ; CpuRec.Data <= DataI after tperiod + tpd ; CpuRec.Wr_nRd <= '1' after tpd ; wait until CpuRec.nRdy = '0' and rising_edge(CpuRec.Clk); end procedure ; O Use a package to separate the stimulus from implementation (model) 9 SynthWorks Transaction Implementation O Entities + O Transaction initiation by calling the subprogram O Transaction implementation (signal wiggling) done by entity TestCtrl CpuModel DUT CpuRec CpuBus CpuTestProc CpuWrite(...) CpuRead(...) O Advantages of Entity Approach O Model is concurrent O Implement it with either behavioral or RTL code O Keeps functionality, protocol checkers, timing checkers, result loggers in the same model O Ok for some interfaces to use Entity and others to use Subprograms 10 SynthWorks Transaction Interface O Records simplify interface between subprogram and DUT or model O Simplify updates O Can use 1 record with resolved types type Model1RecType is record CmdRdy : std_logic ; CmdAck : std_logic ; UnsignedToModel : unsigned(15 downto 0) ; UnsignedFromModel : unsigned(15 downto 0) ; IntegerToModel : resolved integer ; IntegerFromModel : resolved integer ; TimeToModel : resolved time ; RealToModel : resolved real ; end record ; O Can use 2 records O 1 to the DUT from the model and 1 to the model from the DUT O Increases number of signals on subprogram interface 11 SynthWorks Writing Tests O Tests can be either: O Directed - particularly good for testing registers O Algorithmic - particularly good for math O File Based - large or existing data sets (Images, Matlab, …) O Constrained Random O Intelligent Coverage O Not one approach works for everything. O Use of a transaction based framework simplifies mixing of test types. 12 SynthWorks Writing Tests O TestCtrl specifies transactions for each model O Controls, coordinates, and synchronizes test activities TestCtrl TbMemIO TestCtrlTestCtrl CpuTestProc CpuRec CpuWrite(...) CpuModel CPU Bus CpuRead(...) UartTxRec UartTbTxProc Serial Data UartSend(...) UartTxBfm to DUT UartTbRxProc UartRxRec Serial Data UartCheck() UartRxBfm from DUT 13 SynthWorks Writing Tests architecture Test1 of TestCtrl is begin CpuTestProc : process begin Tests are a separate architecture wait until nReset = '1' ; of TestCtrl (TestCtrl_UartRx1.vhd, CpuWrite(. .) ; TestCtrl_UartRx2.vhd, …) CpuRead(. .) ; . end process ; One or more processes for each UartTbTxProc : process independent source of stimulus begin WayPointBlock(SyncPoint) ; Interface Stimulus is generated UartSend(. .) ; . with one or more procedure calls end process ; UartTbRxProc : process Synchronize processes using begin handshaking UartCheck(. .) ; . end process ; end Test1 ; 1414 SynthWorks OSVVM & Writing Tests O Open Source VHDL Verification Methodology O Packages + Methodology for: O Constrained Random (CR) O Functional Coverage (FC) O Intelligent Coverage - Random test generation using FC holes O Key Benefits O Works in any VHDL testbench O Mixes well with other approaches (directed, algorithmic, file, random) O Recommended to be use with transaction based testbenches O Readable by All (in particular RTL engineers) O Low cost solution to leading edge verification O Packages are FREE O Works with regular VHDL simulators 15 SynthWorks Why Randomize? O Directed test of a FIFO (tracking words in FIFO): O Constrained Random test of a FIFO: O Randomization O Is ideal for large variety of similar items O Modes, processor instructions, … network packets. O Generates realistic stimulus in a timely fashion (to write) O Is more thorough since stimulus is not ordered (not looping) 16 SynthWorks Randomization in OSVVM O Randomize a value in an inclusive range, 0 to 15, except 5 & 11 Data1 := RV.RandInt(Min => 0, Max => 15) ; Data2 := RV.RandInt(0, 15, (5,11) ); -- except 5 & 11 O Randomize a value within the set (1, 2, 3, 5, 7, 11), except 5 & 11 Data3 := RV.RandInt( (1,2,3,5,7,11) ); Data4 := RV.RandInt( (1,2,3,5,7,11), (5,11) ); O Weighted Randomization: Weight, Value = 0 .. N-1 Data5 := RV.DistInt ( (7, 2, 1) ) ; O Weighted Randomization: Value + Weight . -- ((val1, wt1), (val2, wt2), ...) Data6 := RV.DistValInt( ((1,7), (3,2), (5, 1)) ); O By itself, this is not constrained random. 17 SynthWorks Randomization in OSVVM O Code patterns create constraints for CR tests O Randomize values, transactions, and sequences of transactions O Example: Weighted selection of test sequences (CR) variable RV : RandomPType ; . StimGen : while TestActive loop case RV.DistInt( (7, 2, 1) ) is -- Select sequence when 0 => -- Normal Handling -- Selected 70% . when 1 => -- Error Case 1 -- Selected 20% . when 2 => -- Error Case 2 -- Selected 10% . O Still uses transactions, so mixes readily with other test approaches 18 SynthWorks What is Functional Coverage? O Functional Coverage (FC) O Code that correlates and/or bins items O Observes conditions from test plan happening in simulation O In VHDL / OSVVM, implemented using a package O Item Coverage - FC relationships within a single object O Bin transfer sizes: 1, 2, 3, 4-127, 128-252, 253, 254, 255 O Cross Coverage - FC relationships between multiple objects O Has the each pair of registers been used with the ALU? O Why not just use Code Coverage? O Tells us a line was executed, but does not correlate independent items O Not necessarily accurate in combinational logic O Test Done = O 100 % Functional Coverage + 100 % Code Coverage 19 SynthWorks Why Functional Coverage? O Randomization requires functional coverage O Otherwise what did the test do? O "I have written a directed test for each item in the test plan, I am done right?" O For a small design maybe O However, this assumes coverage, but does not verify it O As complexity grows