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

EE694v-Verification-Lect11 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

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

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

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

EE694v-Verification-Lect11 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

EE694v-Verification-Lect11 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

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

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

EE694v-Verification-Lect11 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

EE694v-Verification-Lect11 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

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

EE694v-Verification-Lect11 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

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

EE694v-Verification-Lect11 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

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

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

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

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

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