Lect 11 Stimulus Response Checking the response of

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 EE 694 v-Verification-Lect 11 1

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 EE 694 v-Verification-Lect 11 2

Signal Value Listing • Allows for visual inspection of results • Without listing of expected value is very prone to errors EE 694 v-Verification-Lect 11 3

Signal Waveforms • Also allow visual inspection of results • Without showing expected value of signal, can be very hard to find errors EE 694 v-Verification-Lect 11 4

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 EE 694 v-Verification-Lect 11 5

Sampling Signals • One method of monitoring is to just add the signal – to those captured by the listing file – to those displayed on 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 EE 694 v-Verification-Lect 11 6

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 EE 694 v-Verification-Lect 11 7

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 EE 694 v-Verification-Lect 11 8

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 EE 694 v-Verification-Lect 11 9

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 EE 694 v-Verification-Lect 11 10

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 highimpedance (Z) prior to a signal value, the signal value is then applied and held until the bus again returns to high-impedance. EE 694 v-Verification-Lect 11 11

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. EE 694 v-Verification-Lect 11 12

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!! EE 694 v-Verification-Lect 11 13

Deadlock Recovery • If deadlock is possible must make sure simulation halts or at least identifies what has occurred. EE 694 v-Verification-Lect 11 14

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 EE 694 v-Verification-Lect 11 15

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. EE 694 v-Verification-Lect 11 16

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 EE 694 v-Verification-Lect 11 17

Data Formatters (2) EE 694 v-Verification-Lect 11 18

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 EE 694 v-Verification-Lect 11 19

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++) EE 694 v-Verification-Lect 11 20