Professional Documents
Culture Documents
Ahb-I2c Verification PDF
Ahb-I2c Verification PDF
Agenda
Observation Verification Testplanning Process Seven Steps of Formal Testplanning AHB-I2C Example
Observation
Successful verification is not ad hoc in nature Success depends on methodical verification planning combined with systematic verification processes. The key to success is the verification testplan.
Verification Testplan
A projects functional verification testplan is the specification for the verification process. Developing this testplan usually involves the entire engineering team
architects, designers, and verification engineers
In general, the verification testplan defines exactly what functionality will be verified, how it will be verified
the verification strategy and resource allocation
Bugs Rate
Testplan critical!
Agenda
Observation Verification Testplanning Process Seven Steps of Formal Testplanning AHB-I2C Example
Our first step is to identify appropriate blocks for formal Prior to creating a formal testplan
Design Block
Cone of Influence Irrelevant Logic Property
Floating point unit Graphics shading unit Convolution unit in a DSP chip MPEG decoder
Common characteristic:
often sequential in nature, potentially involves some type of data transformation (math)
Single, sequential/functional streams 2 bugs per 1000 gates -Ted Scardamalia, IBM
10
Design Verification
Control
Datapath
Data Transport
Data Transform
11
In simulation checkers and stimulus can be tightly coupled In formal verification, properties are defined in terms of:
Generic behavior, independent of particular input scenarios. Minimal correctness criteria Avoid cycle accurate specification when possible
Harry Foster, 2006 12
Compositional Reasoning
The process of reducing an analysis of a larger concurrent system to reasoning about its individual functional pieces
Effective for managing proof complexity and state explosion Transfers the burden of proof from the global level to the local functional component level
assume always !(A & B);
A B
Block A
Block B
assert . . .
Compositional Reasoning
Cone of Influence
Analysis Region
Property
Formal Abstraction
14
Agenda
Observation Verification Testplanning Process Seven Steps of Formal Testplanning AHB-I2C Example
15
1 2 3
describe
English list
Define interface
Requirements checklist
inputs
Requirements
outputs
Block
Formal description
Verification strategy
6 7
assert_never ();
Formal description
Coverage goals
16
Agenda
Observation Verification Testplanning Process Seven Steps of Formal Testplanning AHB-I2C Example
17
identify
1 2 3
-arch
English list
Define interface
Requirements checklist
Requirements
outputs
Block
Formal description
Verification strategy
6 7
assert_never ();
Formal description
Coverage goals
d_ready
Bridge Bridge
I2C I2C
SCL SDA
bridge_ready i2c_data_start
High speed, high bandwidth bus Bridge (with 64 byte write FIFO)
Harry Foster, 2006
18
identify
1 2 3
-arch
English list
Define interface
Requirements checklist
Requirements
outputs
Block
Formal description
Verification strategy
6 7
assert_never ();
Formal description
Coverage goals
19
identify
1 2 3
-arch
English list
Define interface
Requirements checklist
Requirements
outputs
Block
Formal description
Verification strategy
6 7
assert_never ();
Formal description
Coverage goals
20
identify
1 2 3
-arch
English list
Define interface
Requirements checklist
Requirements
outputs
Block
Formal description
Verification strategy
6 7
assert_never ();
Formal description
AMBA AHB-Lite interface requirements. In general, we can partition AMBA AHB-Lite requirements into two categories: master requirements and slave requirements. 1. 2. 3. 4. 1. 2. 3. 4. 1. 2. Slave must assert HREADYOUT after reset
Coverage goals
Slave must provide zero wait-state HREADYOUT=1 response to IDLE transaction Slave must provide zero wait-state HREADYOUT=1 response to BUSY transaction ... SDA should remain stable when SCL is high There should not be another start after a start until an end occurs in the I2C bus. The data between a start and an end should be divisible by 9 (8 bit/transfer + 1-bit ack) ... Data is not dropped, duplicated, or corrupted for a read-cycle Data is not dropped, duplicated, or corrupted for a write-cycle 21
End-to-end requirements.
identify
1 2 3
-arch
English list
To demonstrate the formal specification process, we convert the following I2C requirement into both PSL and SVA: There should not be another start after a start until an end occurs in the I2C bus.
NOTE: In this example, i2c_s tar tand i2c_end represent modeling code associated with the assertion, composed of SCL and SDA.
Define interface
Requirements checklist
inputs
Requirements
outputs
Block
Formal description
Verification strategy
6 7
assert_never ();
Formal description
Coverage goals
default clock = HCLK; PSL A_no_start: assert (always i2c_start -> next(~i2c_start until i2c_end)) abort (~RESETn); property P_no_start; @(posedge HCLK) disable iff (~HRESETn) i2c_start |=> ~i2c_start[*0:$] ##1 i2c_end; endproperty A_no_start: assert property (P_no_start);
Harry Foster, 2006 22
SVA
Step 6. Strategy
inputs
identify
1 2 3
-arch
English list
Define interface
Requirements checklist
Requirements
outputs
Block
Formal description
Verification strategy
6 7
assert_never ();
Formal description
Coverage goals
In this step, you will define the verification plan and proof strategy. For example, you might choose to prove certain requirements by initially applying a set of restrictions
Add constraints to restrict the explored behavior to only read-mode transaction, or only write-mode transactions. This approach lets you focus the verification on specific modes of operation, and simplifies the verification process. Once the various modes function correctly, the restrictions are removed and the IP is verified under all modes of operation.
23
Step 6. Strategy
inputs
identify
1 2 3
-arch
English list
Define interface
Requirements checklist
Requirements
outputs
Block
Formal description
Verification strategy
6 7
assert_never ();
Formal description
Coverage goals
Compositional Reasoning Partitioning Strict Mode Applying restrictions initially, and then loosening them over a sequence of steps Abstraction
24
Step 7. Coverage
inputs
identify
1 2 3
-arch
English list
Define interface
Requirements checklist
Requirements
outputs
Block
Formal description
Verification strategy
6 7
assert_never ();
Formal description
Coverage goals
Define a set of coverage goals that must be met during the verification process.
To ensure that you are verifying what you think you are verifying, check that constraints on specific states in your requirements model have not over-constrained the states. For formal verification, you can check to see if specific states in your requirement model are reachable. For simulation-based approaches, you can apply functional coverage to various states or sequences of states in the requirements model.
25
Step 7. Coverage
inputs
identify
1 2 3
-arch
English list
Define interface
Requirements checklist
Requirements
outputs
Block
Formal description
Verification strategy
6 7
assert_never ();
Formal description
Coverage goals
Set 1: Input coverage Read/write access with different burst types, sizes, and lengths, and with HREADYOUT asserted and deasserted. Set 2: Output coverage Read/write with acknowledgment, no acknowledgement. Set 3: Internal main state-machines I2C state-machines, AHB state-machines where they can enter and exit each state.
26
1 2 3
describe
English list
Define interface
Requirements checklist
inputs
Requirements
outputs
Block
Formal description
Verification strategy
6 7
assert_never ();
Formal description
Coverage goals
27