Self Checking Testbenches

1. Self Checking Testbenches • Testbench Form • Simulation Environments • Expected Results Generation • Run Modes • Debug • Quick check • Final Regression • Fourth Lab problem

2. What is a Self checking testbench? • A simulation environment that drives the device under test • AND checks the outputs against expected results Why do you need one? • Visual waveform checking is tedious and error prone • For many designs visual checking is impossible • Checking that design changes don’t break working code • Need a thumbs up/down final design acceptance test

3. Self Checking Testbench Form Python Test Generator Verilog Testbench (non-synthesizable) Stimulus Generator Stim files registers Low Fidelity DUT Model Device under test (synthesizable) Expected Results Capture Results Checker Exp files

4. Why not just write it in Verilog? • No data structures • Limited math (no Sine, Cosine, etc) • Poor string manipulation • Many things easier in other languages (fifos, dictionaries, etc) • Have to pay attention to clocks and simultaneity even if you don’t need to Therefore low fidelity models and test sequences are harder to write

5. Self-Checking DAC Tester

6. This is One of Many Approaches • Easy to get working • Easy to extend • Hard to synchronize with Verilog • Hard to check deep inside DUT Other Tools and Approaches • Specman - a special test generation language • PSL, Sugar – another test generation languauge • Verilog API (PLI) – C talks to verilog • 0-In – random test generator and checker • System Verilog – high level extensions to Verilog

7. How Do You Test This in Simulation?? • Do you test subblocks • Can you test whole device • How to model analog functions • What is done in Python • What goes into test files • What is done in Verilog • How to get simulation speed • How many different tests Slap-Echo Machine