Overcoming AXI Asynchronous Bridge
Verification Challenges with AXI AssertionBased Verification IP (ABVIP) and Formal
Datapath Scoreboards
Bochra El-Meray, ST-Ericsson
Jörg Müller, Cadence
About the Authors
∙ Bochra Elmeray
∙ Jörg Müller
∙ Verification Engineer at
ST-Ericsson Rabat
∙ Solutions Engineer at Cadence
Design Systems Munich
∙ 5 years experience in IP
verification
∙ 15 years experience in ASIC
Design and Verification
∙ Expert in Formal Verification
∙ Expert in Formal Verification
∙ Supported ST-Ericsson for
advanced verification
2
Agenda
∙ Overview GALS Design Verification
∙ Environments
∙ Formal Protocol Checking
∙ Formal Functional Checking
∙ Technology
∙ Results
∙ Conclusion
3
Overview GALS Design Verification
∙ Definition: GALS
∙ Globally Asynchronous Locally Synchronous design techniques used for
SoC
∙ Solve physical implementation problems (power, timing, etc)
∙ Requires synchronization between clock domains with different
frequencies
∙ 2 clock domains
∙ AXI Master
∙ AXI Slave
∙ Verification Challenges
∙ Protocol Compliance
∙ Datapath Integrity
4
AXI Master Clock
Domain
∙ DUT: AXI2AXI bridge
AXI Slave Clock Domain
∙ Synchronizer between domains: Asynchronous Bridges
Verification Environments
∙ Traditional
∙ Constrained Random Simulation (SpecMan)
∙ Metric-Driven Analysis (Coverage and Fault)
∙ Applied on sub system level only, not on IP level
∙ Focus on known application scenarios only, missed bugs
∙ Initial Formal Environment
∙ IP-level, only protocol compliance checking
∙ Many inconclusive results due to complexity of design
∙ Debbugging failures on signal level is difficult
∙ No verification plan or progress metrics
∙ Improved Formal Environment
∙ Adding methodology and technology to fill holes
∙ Replace simulation efforts for IP level features
5
New Formal Verification Strategy
∙ Add 2 new components in the environment
∙ New AXI3 Assertion-Based Verification IP optimized for protocol checking
∙ New methodology for verifying asynchronous datapaths for functional
checking
∙ Leverage formal-aware metric-driven verification and regression
environment
∙ Orchestrate and distribute formal environments on server farms
∙ Collect results and provide global view of overall verification state
∙ Enables tracking of progress and assessment of completenss
∙ Take advantage of new debugging capabilities
∙ Transaction-level representation of AXI protocol activity
∙ Leverage latest formal technology available
6
Protocol Verification
∙ Goal: Guarantee protocol compliance against AXI specification
∙ Technology used: Formal and Assertion-Based VIP (ABVIP)
∙ Optimized properties for formal validation of interface protocol
Cadence
AXI ABVIP
Interface
Protocol
properties
Interface
7
STEricsson
Async
AXI2AXI
bridge
Interface
Cadence
AXI ABVIP
Protocol
properties
Interface
Data Path Functional Verification
∙ Goal: Guarantee core functionality of the bridge – data transport
∙ Methodology introduced: Formal ScoreBoard
Cadence
Scoreboard
ABVIP
Functional
properties
Cadence
AXI ABVIP
Interface
Protocol
properties
constraints
Interface
8
STEricsson
Async
AXI2AXI
bridge
Interface
Cadence
AXI ABVIP
Protocol
properties
constraints
Interface
Formal Scoreboard Background
∙ Utilizes symbolic sequences (refers to Wolper, Stangier, Mueller)
∙ Formally verifies data integrity (specifically data transport)
∙ Implemented as formal scoreboard (provided by Cadence)
vld_in
data_in
constrain
sequence
9
vld_out
DUT
data_out
check
sequence
Symbolic Sequences
∙ Using Symbol in Formal Verification
∙ Declare a non-deterministic constant that represents all possible values
1.
2.
3.
4.
5.
6.
7.
always symbol
never symbol
first symbol
one symbol only
two consecutive symbol
two symbol only
two consecutive symbol
only*
* Stangier‘s approach
10
SSSSSSSSSSSSSSSSSSSS
....................
S???????????????????
...S................
...SS???????????????
...S...S............
...SS...............
Definition:
S: Symbol
.: Anything but symbol
?: Anything
Implementation of Symbolic Sequences
∙ Symbol implemented as non-deterministic constant
wire [31:0] symbol; // uninitialized
assert property($stable(symbol));
Value chosen by
the formal tool to
trigger failures!
∙ For every such sequence there is an associated set of a constraint
and an assertion
∙ Example sequence „one symbol only“
...S................
∙ Symbol used to constrain unique value in input domain sequence
assume property (@(posedge in_clk)
in_symbol_seen && in_dvalid |-> in_data != symbol);
∙ Symbol used to check for matching same value in the output domain
sequence
assert property (@(posedge out_clk)
out_symbol_seen && out_dvalid |-> out_data != symbol);
11
Error Types Detected by Formal Scoreboard
1.
2.
3.
4.
5.
6.
7.
8.
loss
(arbitrary item)
loss all (items of particular value C)
creation (arbitrary value)
XXXXX
creation (illegal value only)
duplication (same value only)
XXXCX
manipulation (to arbitrary value) XXXCX
manipulation (to illegal value only)
reordering (arbitrary items)
XXCCX  XXCX
XXCCX  XXX
 XXXXEX
XXXXX  XXXXYX
 XXCCXX
 XXXEX
XXXCX  XXXYX
XBCXX  XCBXX
∙ Different sequences can detect different type of errors
∙ All sequences overlay to full coverage of error types
12
Datapaths in the Async AXI Bridge
∙ For our AXI bridge we identified a total of 7 data transport paths
1. Write Address ID
2. Write Data ID
Cadence
Scoreboard
ABVIP
3. Write Response ID
Functional
properties
4. Write Data
5. Read Address ID
Cadence
Interface
AXI ABVIP
6. Read Response ID
Protocol
properties
constraints
7. Read Data
Interface
STEricsson
Async
AXI2AXI
bridge
Interface
Cadence
AXI ABVIP
Protocol
properties
constraints
Interface
∙ Each receive a formal scoreboard instance to test the functional
datapath across the DUT
13
Instantiating Formal Scoreboard
Cadence
Scoreboard
ABVIP
Functional
properties
Cadence
AXI ABVIP
awids
Interface
Protocol
properties
constraints
Interface
STEricsson
Async
AXI2AXI
bridge
awidm
Interface
Cadence
AXI ABVIP
Protocol
properties
constraints
Interface
if_scoreboard #(
// Parameters
.DBUS_WIDTH
(ID_WIDTH),
// Size of the external datapath vector
.CHECK_WIDTH (CHECK_WIDTH)
// Size of the internal datapath check
) sb_awid (
// Ports
.rst_n
(rst),
// active low reset
.in_clk
(aclks),
// input clock
.in_data
(awids),
// input data vector
.in_dvalid
(awvalids && awreadys), // input valid indicator
.out_clk
(aclkm),
// output clock
.out_data
(awidm),
// output data vector
.out_dvalid
(awvalidm && awreadym) // output valid indicator
);
14
Technology in New Formal Environment
∙ Latest Engines in Incisive Enterprise Verifier
∙ Addition and improvements of formal engines and running them all in
parallel
∙ Contributes to faster runtime and overall improved results
∙ Assertion-Driven Simulation (ADS)
∙ ADS runs simulation using PSL/SVA constraints as testbench
∙ Allows fast design exploration and provides instant feedback on
constraints
∙ Replay
∙ Using traces obtained by formal engine to guide ADS activating other
properties
∙ Contributed additional failures on previously explored properties
∙ Constraint Minimization
∙ Patent pending algorithm to identify minimized set of constraint required
for proof
15
∙ Contributed additional Fail and Pass results on previously Explored
Debugging
16
Regression Suite
17
Comparing Formal Environments
Config 1
Config2
Old
New
Old
New
Total
115
144
108
141
Pass
75
(65%)
8
(7%)
32
(28%)
108
(75%)
9
(6%)
27
(19%)
74
(68%)
3
(3%)
31
(29%)
109
(77%)
9
(6%)
23
(16%)
Fail
Explored*
* The explored results were obtained with 1 hour tool effort per property
18
Finding Critical Bugs
∙ Failure Detected: ID values across locked access do not match!
∙ Scenario: Normal data without request enters bridge before lock
∙ Impact: Potentially blocking entire SoC
DUT
outputs
IDs must be
same for
locked
transaction
DUT
inputs
Cause
19
Summary
∙ Pro:
∙ Positive experience with with formal verification, scoreboarding and
ABVIP
∙ Effort to create formal environment ~1/3 the effort to create simulation
environment
∙ Overall quality of results improved tremendously
∙ Found corner case bug missed by simulation
∙ Con:
∙ Some bounded proofs remained (although depth increased)
∙ Not a push button flow (but that was not expected either)
∙ Formal environment was a good replacement for sim environment except
clock domain crossing checks (was never tried with formal)
∙ Conclusion
∙ We count on mixed formal and simulation (ADS) in future projects of that
type
20
∙ Completeness of setup (protocol + functional) gives confidence to sign
THANK YOU