Fundamentals of Simulation-Based Verification

1
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.

2
Testbench Structure

• Testbench code may have several components

3
Initiator Stimulus
Generation Component - This defines the test
abstractly Protocol Component - Converts abstract
test into bit-level detailed test
4
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

5
Responders

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

6
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
7
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

8
Scoreboard/Checker Example
Cache design property to check The cache only
issues a request to the main store if the cache
has first received that request itself
Suppose the stimulus generates a fetch request
for location 01234500

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 01234500

9
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

10
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

11
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)

12
Testing Strategies

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