Lect 11 - Stimulus & Response

1. Lect 11 - Stimulus & Response • Checking the response of a design • Verifying output – using listings and waveforms • Signal Sampling • Automating output verification • Golden vectors and output timing • Deadlock and deadlock recovery • Predicting the output EE694v-Verification-Lect11

2. Verifying Output • Generating stimulus is only half of the job. Actually, it is about only 30% of the job. You control the value and timing of the stimulus. • Knowing the value and timing of the output given an input, or a sequence of inputs, is key to performing verification • Verifying that the output is as expected • is more time consuming • is more error prone • Specific points in time that are significant differ from design to design EE694v-Verification-Lect11

3. Signal Value Listing • Allows for visual inspection of results • Without listing of expected value is very prone to errors EE694v-Verification-Lect11

4. Signal Waveforms • Also allow visual inspection of results • Without showing expected value of signal, can be very hard to find errors EE694v-Verification-Lect11

5. Listings and Waveforms • Should log significant signals • Should log signals at appropriate times • The signals which are significant, and the times at which they are important, changes as the simulation progresses • Should always list/display the expected value of the significant signals EE694v-Verification-Lect11

6. Sampling Signals • One method of monitoring is to just add the signal • to those captured by the listing file • to those displayed on the the waveform • To maximize to speed of simulation, need to minimize the amount of simulation output. Use Text I/O to save certain signal values to a file EE694v-Verification-Lect11

7. When to Sample? • Simplest technique: sample relevant signals at regular intervals • Interval can be • Periodic, i.e., simply time • Based on a reference signal such as a clock • Based on whenever one signal in a set of signals changes EE694v-Verification-Lect11

8. Inspection of Waveform • Visual inspection, without the expected result, is prone to error. Even with the expected result, visual inspection can allow for errors being missed • How long would it take to notice error? And this is for a D F/F with a 2-to-1 mux on the data inputs EE694v-Verification-Lect11

9. Automating Output Verification • The first step to automating output verification is to know and include the expected result along with the input stimulus. • A problem with outputs is that you need to know not only the value, but also the time at which the output value will be present. • Interfaces that pose difficulty are • Asynchronous interfaces • Out or order execution • Variable output sequences given the same set of inputs • Different clock domains EE694v-Verification-Lect11

10. Golden Vectors • A set of reference output results determined to be correct. • May be used in HDL simulations • May be used in/with other tools to check for the validity of the result • Can become invalid and no longer help if the design specification changes EE694v-Verification-Lect11

11. Output Timing • To properly and completely verify the functionality of a design, • must also verify the output stays stable as specified, • the value of the output is as specified, • the timing of the output is as specified • For busses may need to insure bus is at high-impedance (Z) prior to a signal value, the signal value is then applied and held until the bus again returns to high-impedance. EE694v-Verification-Lect11

12. Complex Stimulus/Response • Applying stimulus to simple inputs, such as a clock, is straightforward. The verification engineer determines the value and timing of the signal. • If the signals being interfaced contain handshaking or flow control, the testbench must cooperate with the design under test. • Problems in handshaking can occur in both the design under test and the testbench. EE694v-Verification-Lect11

13. Deadlock • If feedback from the design under test is used to apply the test(s) then deadlock becomes possible. • If the design under test does not provide the feedback as expected, stimulus generation may be halted. • If deadlocked, you are waiting on a condition that will never occur. • If deadlocked, the simulation may still be running and the logging of some signals may still be taking place, but anything useful is not!! EE694v-Verification-Lect11

14. Deadlock Recovery • If deadlock is possible must make sure simulation halts or at least identifies what has occurred. EE694v-Verification-Lect11

15. Complex Response • Complex responses are • Responses that cannot be checked at one point in time • Responses that have long delays from application of the stimulus until the response • Responses that result from out of order execution of the inputs • Definitely not verifiable using visual inspection. • A complex response cannot be verified in the same process that generates the stimulus EE694v-Verification-Lect11

16. Predicting (Knowing) the Output • Unstated assumption of self-checking testbenches is that you know the output to be produced, given the inputs. • Sometimes output prediction is • Easy – RAM, ROM, adders, … • Hard – Video compressor, speech synthesizer, … • Knowing the response is key to verification. EE694v-Verification-Lect11

17. Classes of Designs – Data Formatters • Predicting the output is dependent on the device/system/ sub-system/… being verified. • Data Formatters – class of designs where the input information is not transformed, simply reformatted EE694v-Verification-Lect11

18. Data Formatters (2) EE694v-Verification-Lect11

19. Classes of Designs –Packet Processors • Family of designs that use some of the input information for processing, sometimes transforming it. The remainder is untouched and sent to the output. • Examples – Ethernet hubs, ATM switches, etc. Output monitors assure the packet is correctly processed EE694v-Verification-Lect11

20. Classes of Designs –Complex Transformations • Design processes and transforms the input data completely and thoroughly to produce outputs that may differ in both data, timing, and the number of outputs per input. • Must either hand compute output(s) or use an alternative model (may even be written in another language, such as C or C++) EE694v-Verification-Lect11