Download Macro Block Verification Techniques: Bottom-Up Testing, Inspection & More and more Slides Computer Science in PDF only on Docsity!
Verification Techniques for Macro
Blocks (IP)
- Overview
- Inspection as Verification
- Adversarial Testing
- Testbench Design
- Timing Verification
Overview of Macro Verification
- Overall verification plan
- Strategies
- Sub-block simulation
- Macro simulation
- Prototyping
- Limited production
Strategy: Bottom Up Testing
- Verify individual sublocks
- Focus on coverage of data values and internal states
- Verify complete macro (block)
- Focus on interfaces and timing among sub-blocks
- Test I/O timing and “corner cases”
- Perform prototyping
- Proto-board
- PC board
- FPGA
- Platform based design*
Verification vs. Validation
- In the hardware world:
- Verification means testing
- Validation means “formal proof”
- In the software world:
- Verification means “formal proof”
- Validation means testing
Don’t be confused…
Fundamental Ideas
- Controllability
- Can you wiggle every wire?
- Can you set every bit?
- Observability
- Can you see the state of every bit?
- Can you see the value on every wire?
During validation, we can do this in the simulator – especially in a bottom-up mode
(In manufacturing test this is not so easy)
Types of Verification Tests
- Compliance Testing
- Against specifications and/or standards
- Corner Case Testing
- Try to break the design with complex scenarios
- “Answer Yes or No [Y]?” > fred
- Random Testing
- Use statistical models to generate data patterns
- Real Code Testing
- Work with the software team, use real data
- Regression Testing
- Keep all tests in a suite and add to them
Verification Tools
- Simulation
- functional, cycle, RTL, gate level, circuit level
- Testbench automation tools
- Verisity (and others) testing language
- Code coverage tools
- Measurements of what got wiggled
- Hardware Modeling
- Comparison against / with real hardware
- Emulation
- High speed hardware boxes interfaced to simulator
- Prototyping
“Static” Tools
- Static timing analysis tools
- “Lint-like” tools
- Formal verification tools
- Model checking
- Build abstract model of design and environment
- Uses “smart” exhaustive methods for safety and liveness tests
- Liveness: something good will eventually happen
- Safety: nothing bad will ever happen
- Theorem proving
- Uses automatic theorem provers to verify assertions about the design
Prototyping
- Use Prototyping when:
- You can afford it
- You can not wait for the time it takes to find bugs using available simulation techniques - The prototype is just a fast simulator for the device itself
Adversarial Testing
The designer’s tests have the goal to show that the
system will work…
- Adversarial Testing uses a verification team of
experts in testing all kinds of designs
- Goal: develop tests to show that the system will
fail
- Report failures, and test cases to design team
Testbench
- The testbench For each component
- Is the model of its external world
- Must generate (all) legal input sequences
- Must check output sequences
- Must alert the designer and log discrepancies between expected and actual results
- The testbench is often more complex than
component itself
Sub-block Testbench Design
- Input transaction data types, sequences
- Output transaction data types, sequences
Input Transaction Generator
Output Transaction Checker
Device Under Test (DUT)
Assume simple I/O relationships
Output Checking
- Check for legal sequences of outputs
- Look at functionality of DUT
- Check corner cases
- Check input/output relationships
- Ideally each sub-block has
- Simple Functionality
- Simple I/O
Getting ready for integration
- Timing checks
- Timing plan for each sub-block
- Clocking, handshaking
- Timing budgets, per-cycle latency budget
- Area and power checks
- Are the sub-blocks within their bugets