Assertion-Based Design Partition
Xiushan Feng*
ShaunF@nvidia.com
ASIC Verification
Nvidia Corporation
Jayanta Bhadra,
Ross Patterson
{JayantaBhadra,
RossPatterson}@freescale.com
Freescale Semiconductor
TM
*The work is done when the author worked at Freescale
1
Docket – MT11774TS
Problem Statement – Assertion-Based Design Verification Challenges
►
Assertion-Based Verification is broadly used in circuit verification
•
•
•
►
For large designs, simulation speed is slow and may blow up formal
verification due to exponential state space.
•
•
►
Increase the visibility of internal signals
Use assertions as checkers. Pass of assertions == pass of verification
Verify the correctness of design – improve the quality
Slow down verification process – more resource, longer design cycles.
For certain cases, it is not feasible to verify certain assertions.
Most time, partial design is good enough to verify assertions.
•
For example, for SOC PAD connectivity check, assertions are written to verify that signals
can propagate from source to target under certain conditions. We don’t need logic that
drives sources, loads values from targets.
• Unneeded logic usually is VERY big, removing them can achieve huge gains
►
However, manually identifying and removing unneeded logic is very hard.
•
Need to understand assertions and the design indent
• Failing to include logic can cause false verification results.
►
An automatic solution is possible using Assertion-Based Partition
2
Docket – MT11774TS
The Current Verification Environment
RTL
Assertions
Constraints
RTL Compile
• Compiled database is huge.
• Verification is slowed down
• More resources needed (licenses,
engineering hours, computing
machines)
•This technique attempts to reduce
verification cycles and improve
verification quality
Verification (simulation
or formal verification)
Pass/Fail & Circuit Debug
3
Docket – MT11774TS
The Proposed Verification Environment
RTL
Assertions
1.
Constraints
Signal propagation
Signal reachability
Assertions1
2.
Get boundary signals in ABV
RTL(partitioned)
RTL(partitioned)
RTL(partitioned)
LEGEND:
Yellow: NEW
White: Prior Art
3. Condition-base design
partition with formal prove
RTL Compile
Assertions2
Verification (simulation
or formal verification)
4
Pass/Fail &
Circuit Debug
Docket – MT11774TS
Definition of Signal Propagation and Reachability
foo
a
A
bar
B
C
Signal Propagation:
a is directly connected by
wires to a’. i.e.,
a and a’ are interchangeable
inside the assertions,
a'
D
X
assign B = A;
assign D = C;
assertion: assert property (condition |->a == ….)
update assertion: assert property (condition |->a’ == …)
RTL:
FOO foo (.A(a), .B(X)…);
BAR bar (.C(X),.D(a’)…);
partially ordered graph
A
B
C
E
D
E
C
D
A
Signal Reachability:
If signal S1 is inside fan-in
logic cone of signal S2, then
S2 is reachable by S1. D is
reachable by A, B, but not C.
B
5
Docket – MT11774TS
Signal Propagation and Reachability Computation
assertions
RTL
Compute state stage graph
with all signals of assertions
state stage
For each assertion, compute the boundary points
For each pair of signals x, y of the assertion, compute
whether y can be (forward/backward) reached by x.
Y
X tied to z && z is on
the path from x to y
Reachable?
N
Y
replace x by z in
assertions.
Build directed edge from z to y
partially ordered graph
6
Docket – MT11774TS
Example
state stage
inputs
partially ordered graph
State points
(Latch/Flop)
ast0
inputs
ast0
Signal propagation
and reachability
output
output
7
Docket – MT11774TS
Get Boundary Signals
partially ordered graph
Keep lower bound and upper
bounds
inputs
ast0
output
Boundary signals
inputs
State points
(Latch/Flop)
ast0
output
8
Docket – MT11774TS
Conditional RTL Partition with Formal Prove
Boundary signals
RTL
lower bounds  inputs (IN)
upper bounds  outputs (OUT)
inputs
ast0
Conditional compute cone of
influence for all OUT
Assertions1
Constraints
ast1
RTL
(partitioned)
output
Assertions2
(Optimized)
9
Docket – MT11774TS
Conditional RTL Partition with Formal Prove – Cont.
For each OUT, backward partition RTL.
When hit a condition, build symbolic
expression for condition and prove the
condition
RTL
Assertions1
Formal prove engine
Constraints
prove?
N
compute cone of influence
for both cases
RTL
(partitioned)
Partition RTL only for proven
case. Update assertion
based proven results
Assertions2
(Optimized)
10
Docket – MT11774TS
Build Symbolic Expression for Conditions and Prove
get fan-ins (f_ins) of cond
expr(cond) = f (f_ins)
Constraints
Recursively build expression for each fan-in
cond
R
Light-weight
No expression blow up
f_in is
R/IN?
N
Y
Constraints
R: Register
IN: Input
Terminate from the recursive procedure
Formal prove engine
symbolic expression
True/False
11
Docket – MT11774TS
Example
cond
R
a
b
A
B
C
D
b'
assign B = A;
For example:
Input X, Y;
b’ = (cond)? b : C
…
If we can prove cond is always true, then we don’t need to trace
path for signal C. we know b’ = b, and use it to update assertions
and propagate signal.
If we can prove cond is always false, then, we just need to trace
signal C and propagate signals if feasible.
12
Docket – MT11774TS
Assertion Grouping and Parallel
►
Concept of assertion groups
•
Assertions have hidden “locations”

Logic regions
 Assertion types
•
►
Assertion-based partition can be done on assertion groups
Assertion groups can be verified in parallel with design partitions

Groups are verified independently.
 Verification results inside one region can be re-used by others. E.g., verified
proves can be assumptions for others, etc.
►
Assume-and-guarantee is done at the boundary of groups.
•
•
One assertion can be re-written into multiple ones that belong to
different groups.
Abstraction techniques are done differently for groups.

E.g., Assertions of analog behavior models are verified inside analog
groups. Verification of digital groups has analog blackboxed and analog
drivers properly constrained, which will be proven by analog assertions.
13
Docket – MT11774TS
Assertion Grouping Example
R2
inputs
►
R3
Several groups of assertions that verify a few logic regions
•
•
Logic needed to prove a group may not be necessary for another
Inputs of a region can be outputs of another

►
R1
output
cutpoints can force internal wires as inputs
One assertion can be broken down into multiple assertions.
•
•
For example, enable and reg  R1; foo, bar, A, B  R1
ast: enable && reg[19] && bar |-> A == B can be replaced by

ast1: enable && reg[19] |-> foo
 ast2: foo && bar -> A ==B
14
Docket – MT11774TS
Results
►
We applied the ideas on Freescale PAD IO verification.
► Without the ideas, original formal verification ran weeks and
required VERY large machines (>100GB)
•
•
A smaller and simpler design took >1week on large machines but
didn’t get good coverage.
This highlighted the need for this work
►
With ABP, we are able to prove 25+K assertions within 2.5 hours.
► Critical SOC-level bugs were caught !
With this disclosure
Without this disclosure
Memory Usage
<4G (normal machine is enough) > 100G
Licenses used
<30
100
Simulation Runtime
Reduced Significantly – 2.5
hours (> 100X reduction)
Could be several weeks
Debug
Debugging is possible and easier GUI Debugging is not
(therefore quicker)
feasible
15