The document discusses various metrics used to verify CPU designs, including:
1. Architectural verification to ensure implementation meets specifications by comparing architecture states to simulators.
2. Microarchitectural verification at the cluster and chip level using checkers, templates, and other techniques.
3. Additional verification of power management, formal techniques, system-level interactions, and design-for-test features.
4. Cobus Valentine- Cybersecurity Threats and Solutions for the Public Sector
CPU Verification Metrics
1. CPU Verification Metrics
Shahram Salamian
CPU Verification Manager
Mobility Group- Texas Design Center
6/27/2006
1
2. CPU Verification
- Architectural Verification (AV)
- Implementation meets Intel architecture definition
- Arch state compared against Architectural simulator
- Split across a few categories
- Done at full chip (FC).
- uArchitecture Verification (uAV)
- Cluster level (Fetch, LD/ST, etc)
- Full chip
- Cluster level checkers, templates, etc
- Power management features Verification
- Formal Verification
- System level Verification
- DFD/DFT feature Verification
2
3. Architecture Verification
- Directed set of directed & semi-random templates generating instruction
set level (assembly) tests
- Accumulated over years. Assumed to have high coverage
- Large test base. Smaller subset with good sampling used first
- Highly scrutinized by mgmt. Needs to be almost perfect by tape out
Legacy Tests Passrate
100
90
80
% passing
70
60
pass_rate
50
goal_line
40
30
20
10
0
work w e ek
3
4. UArchitecture Verification
Coverage
Reset
- Functional coverage conditions jointly specified by verification & design
- Internal tools to specify and measure
- Use random and/or directed-random templates to cover
- Conditions are typically prioritized based on complexity, bugs, etc
- Tape out targets varies by cluster.
- Focusing on raw coverage be misleading
- A few “Easy” to cover set of monitors can skew covered %
- Can be misinterpreted by mgmt as having great or bad coverage
- Have to be looked at in conjunction with bug count, pass rate, etc
`
4
5. Bug Rate
160
140
120
100
80
60
40
20
37_01
41_01
49_01
17_02
21_02
25_02
29_02
33_02
37_02
41_02
45_02
49_02
45_01
13_02
0
5_02
9_02
1_03
1_02
New Bugs (14) Open Bugs (7) Open LT Bugs (0) "Smoke Alarm"
- Many different views of bug data base (Total bugs, open bugs, etc)
- Smoke alarm set based on previous projects bug history
- Exceeding smoke alarm causes scrutiny by design & validation
- Design reviews of areas where bug count jumps up
- At times, it is a sign of better checkers, new tests going on line
5
6. RTL Lines Of Change
- RTL Change rate to measure stability, allowing verification team to
make progress in exercising RTL
- Also measure RTL change request rate & type of request
6
7. Health Of the Model (HOM)
Hea lth of the Model (HOM)
100
90
80
70
Score
60
50
40
30
20
10
0
0
Q tr 5 Q tr 4 Q tr 3 Q tr 2 Q tr 1 Q tr 0
Tim e to Tape out
- Measures functional convergence trend. Informs project on RTL
health is affecting verification team’s progress
- Uses empirical formula using past projects data
- Incorporates new bugs, bugs unresolved, and verification team’s
ability to make progress. Subjective & quantative components
- Low HOM relative to goal drives actions on fixing bugs and issues
affecting verification
7
8. 2nd Tier metrics
- Cycles run each week, licenses, etc
- Bugs caught at full chip vs cluster.
-Used to improve test bench quality
- Bug cause
- New condition hit or as result of timing, other bug fix, etc
- Test bench & other validation collateral bugs
8
