1 / 20

Lect 11 - Stimulus & Response

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. Verifying Output.

Download Presentation

Lect 11 - Stimulus & Response

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.


Presentation Transcript

  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

More Related