Fundamentals of Simulation-Based Verification 1.Structure of a Testbench - stimulus, checkers, etc. 2.Observation and Assertions - automatic checking of results 3.Testing Strategies - self-checking, transaction-level, etc.

Testbench Structure Testbench code may have several components

Initiator Stimulus Generation Component - This defines the test abstractly Protocol Component - Converts abstract test into bit-level detailed test

Generation vs Protocol Components Generation Component Operation - Place value 64 bit value X in an address Y Protocol Component Operation - Create detailed input signal timing to place X into Y Bus Functional Model - Just the protocol component Transaction-Based Verification - Separating generation from protocol

Responders Responders act approximately like a communicating component before the component is built

Monitors/Checkers Monitors only check adherence to the output protocol - Does not look at data details ex. Data length matches length in header Parity of output data matches parity bit Checkers check the correctness of the output data also - Generally knows the expected output ex. All outputs match predicted values No superfluous output activity

Scoreboard Observes input signals (maybe internal too) and records “interesting” information for later use by the checker It works closely with the checker Scoreboard or checker may contain the reference model

Scoreboard/Checker Example Suppose the stimulus generates a fetch request for location “ ” 1.Scoreboard sees the input request and stores the input data (address, cmd, etc.) 2.Later, the cache issues a fetch request to the main store (a miss) 3.The checker sees the fetch request to the main store 4.The checker asks the scoreboard if the cache has seen a fetch request for address “ ” Cache design property to check: The cache only issues a request to the main store if the cache has first received that request itself

Observable Points Observability refers to the variables/signals that can be evaluated Observability impacts test generation complexity and test time Example: Testing a processor with broken branch prediction Only occasionally impacts execution time May take a long time to observe at the outputs Can be immediately seen in the branch predictor state bits Strongly Taken Weakly Taken N T

Black/White/Grey Box Determines whether or not observability (on controllability) exists on internal lines Advantages of observing internal lines: Faster testing More accurate debugging Disadvantages: Depends on stability of internal lines Depends on understanding of design internals More data must be processed

Assertions A language construct that conveniently enables simple checking Like a checker without a complete reference model Example (in VHDL): assert (buf_overflow /= ‘1’) report “Internal Buffer Overflow” severity ERROR Can observe any variable/signal Great for automatic checking, relatively simple Can be used directly capture aspects of the specification (i.e. “Internal buffer should never overflow”)

Testing Strategies Deterministic Testbenches - Predetermined input data 1.Effective at revealing specific bugs 2.May be very time consuming to generate tests Self-Checking Testbenches - Check results automatically 1.Golden Vectors - Predetermined input/output data Very tedious to maintain 2.Reference Model - Calculates expected output on-the-fly Hard to build, easier to update Transaction-Based Testbenches 1.Use of abstraction in stimulus generation and checking Separating generation from protocol Output protocol recognition confined to scoreboard