A hierarchical approach towards system level static timing verification of SoCs

Abstract

The high complexity and the core diversities make timing verification of an entire flattened SoC design a tedious process. In this paper, at first the various timing issues related to modular SoC verification have been investigated and then a bottom-up hierarchical approach of verifying the system level timing of an SoC, is presented. The timing abstractions of the cores are assumed to be provided by the core vendors. The interconnection delays of the SoC may be extracted from the SDF file generated after post layout simulation. The hierarchical approach provides a fast and systematic way of timing verification, as opposed to the flattened approach. Experiments were conducted on synthetic SoCs, using ISCAS benchmark circuits as cores. Results validate the claim of the proposed approach.

Full text

Page 1

A Hierarchical Approach Towards System Level Static Timing
Verification of SoCs
Rupsa Chakraborty and Dipanwita Roy Chowdhury
Department of Computer Science and Engineering
Indian Institute of Technology Kharagpur, INDIA - 721302
rupsac@cse.iitkgp.ernet.in, drc@cse.iitkgp.ernet.in
Abstract—The high complexity and the core diversities make
timing verification of an entire flattened SoC design a tedious
process. In this paper, at first the various timing issues related
to modular SoC verification have been investigated and then a
bottom-up hierarchical approach of verifying the system level
timing of an SoC, is presented. The timing abstractions of the
cores are assumed to be provided by the core vendors. The
interconnection delays of the SoC may be extracted from the
SDF file generated after post layout simulation. The hierar-
chical approach provides a fast and systematic way of timing
verification, as opposed to the flattened approach. Experiments
were conducted on synthetic SoCs, using ISCAS benchmark
circuits as cores. Results validate the claim of the proposed
approach.
I. INTRODUCTION
In a system-on-chip (SoC) technology, the time to design
sign-off is reduced by using pre-designed, pre-verified re-
usable IP-blocks called cores [1]. The cores may be designed
either in-house or externally by various commercial vendors.
The cores are pre-verified by the core-vendors, on timing
constraints in accordance with the core specification. How-
ever, since the SoC environment in which the cores are to
be integrated varies, and also since the cores are designed at
various abstraction levels, the integrated system still remains
to be validated. In fact, it is the task of the SoC integrator
to verify that the complete SoC, after integration of all the
cores, meets its timing closure in accordance with the SoC
specification.
One way of tackling this problem is by completely flat-
tening the final SoC design and then running the standard,
commercially available, static timing analysis (STA) tools.
Another approach is by conserving the core level hierarchy,
inherent in SoC designs, through using efficient timing mod-
els or abstractions of the corresponding cores. Fortunately,
today, there already exists a number of quality works on
the generation of timing abstraction of IP blocks or macros.
Some notable works are reported in [2]-[8].
The timing abstraction of a core contains a highly reduced
information set with respect to the original model, as the
structural information is removed and replaced by timing
arcs corresponding to the ports around the core boundaries.
A black-box timing model for a flip-flop based synchronous
sequential core is shown in Fig. 1. Additionally, by hiding the
internal details, the black-box model provides IP protection.
A disadvantage with the black-box model is that it cannot
Combinational delay
Input 1
Input 2
Output 1
Output 2
Clock 1
Clock2
Setup/Hold
clock-to-output
Fig. 1. A black-box model [2] of timing abstraction.
effectively model the complete latch behavior. It can do
so only for a given clock waveform. Once the waveform
changes, the model needs to be changed. Alternatively, a
gray-box model may be used to tackle latch-based macros.
A gray-box model extraction by graph reduction method has
been proposed by Moon et al. in
sometimes need re-verification of the cores after integration.
Recently, an advanced black box model has been proposed
by Do et al. in [2], which can effectively model the timing of
latch controlled systems without the need for re-verification
after integration.
Given a valid timing model for the IP blocks, the next
stride would be to find an efficient method of validating
the timing closure for the complete system. A system level
timing verification method, using the timing models of the
IP cores, has been recently proposed in [10]. In this method,
the SoC has been transformed into a timing graph, where
the nodes represents the cores and edges represents the
critical path between the cores. The back-annotated delays
in the interconnects, obtained after post-layout synthesis, are
validated with the specified waveform to check the timing. A
problem with this approach is that the complexity increases
for SoCs having a large number of cores. The method also
uses a highly simplified SoC environment, with very small
number of core boundary timing issues.
In order to tackle the complexity problem, a hierarchical
approach may be employed. It is a divide and conquer
approach which often leads to a much faster system level
validation. Scheffer, in [11], has shown that if proper
grouping can be made, then the complexity of a timing
verification algorithm can be brought down to O(N), from
the complexity of at least O(NlogN), where N is the size
of the flattened hierarchy. Moreover, hierarchical timing
[6]. This method may
978-1-4244-5028-2/09/$25.00 ©2009 IEEE201

Page 2

D Q
F1
CLK1
D Q
F2
D Q
F3
CLK1
D Q
F4
D Q
F5
CLK1
D Q
F6
Combinational Logic
C7
CLK2
IP-core
CLK2
CLK2
CLK1CLK2
C1
C2
C3
C4
C5
I1
I2
I3
I5
I6
Op1
Op2
Op3
Op4
Op5
Op6
Op7
C6
I4
Fig. 2.IP core internal - registers and combinational paths.
analysis of combinational circuits has been shown to be faster
than gate-level analysis in some previous works [9].
In this paper, at first, the requirements for a hierarchical
system level timing verification of a core-based design −
such as an SoC − have been explored, and then an algorithm
for hierarchical timing verification is proposed. The timing
abstractions of the cores are assumed to be given by core
vendors. The interconnection delays of the SoC may be
extracted from the timing information file generated after
post layout simulation. In the lowest level of the hierarchy
are the cores and the glue logic. The glue logic is broken
down into one or more modules according to mutual data
propagation distance. Timing abstractions are generated for
each such module. The cores and glue-logic modules are
then considered to be black boxes and are further clustered
according to data-propagation distance. Each of these clusters
are timing verified concurrently. This continues till clustering
results in a single module. This is the top level module.
Verifying this top level module for timing results in the verifi-
cation of the entire SoC for timing closure. Such concurrent
verification approach results in a reduction of verification
time by factors, as has been shown by experimental results.
The organization of the paper is as follows. Section II
discusses the motivation and the timing issues related to
system level timing verification of SoC. In Section III,
the problem of timing verification in SoC is formulated.
Section IV discusses the method of forming the clusters for
hierarchical verification. Section V presents the timing veri-
fication algorithm. Experimental results have been provided
in Section VI. Section VII concludes the paper.
II. MOTIVATION AND THE SOC TIMING ISSUES
In hierarchical timing verification of SoCs, the timing
abstractions in the first level of the hierarchy, clearly, cor-
responds to that of the IP cores and glue logic. Glue logic
is the user defined logic added to the SoC design by the
SoC integrator, and not imported as cores. Assuming that
the black-box timing models for each IP-core are provided,
it now remain to be checked if, using the given models,
the entire SoC design can be timing verified correctly. In
other words, the results of timing verification of a completely
flattened SoC should be equivalent to that of the results of
hierarchical timing verification of the SoC using the timing
models of the cores.
CLK1
Delay(I1-F1)
CLK1
Delay(I2-F2)
CLK2
Delay(I3-F3)
CLK2
Delay(I4-F4)
CLK2
Delay(I5-F4)
CLK1
Delay(F2-Op1)
Delay(F3-Op2)
Delay(F6-Op3)
CLK2
Delay(F4-Op4)
Critical Delay from Inputs (I5,I6)
to Outputs (I5,I6,I7)
CLK2
CLK2
Timing Model
Fig. 3.Black-box timing model for the IP-core of Fig. 2.
Clk1Clk2
Clk1 Clk2
Clk1Clk2
Clk1Clk2
A
B
C
D
SoC
PO
PI
Fig. 4.Integration of cores in an SoC.
Fig. 2 shows the paths between the input pins, output pins
and the registers within an IP-core. The flip-flops are driven
by two clocks, CLK1 and CLK2. The irregular blobs denote
combinational circuitry. Noticeably, there are the following
kinds of paths (PT denotes path type) from input pins to
the output pins of the IP core. PT1 : Directly from input
pin to register, without passing through any combinational
circuitry (eg. I1 to F1). PT2 : Input pin to register, with
intermediate combinational path (eg. the path I2−C1−F2).
PT3: Directly from register to output pins, without passing
through any combinational circuitry (eg. F3 to Op2). PT4 :
Register to output pin, with intermediate combinational path
(eg. the path F4−C5−Op4). PT5: Register to register, with
or without passing through any combinational circuitry (eg.
F5 to F6). PT6 : Pure combinational paths from the input
pin to the output pin (eg. I5 to Op7).
Fig. 3 shows the information contained in a viable black-
box timing model for the IP-core of Fig. 2. The model
accommodates all the pin-to-register, register-to-pin delays,
and also the critical path delay of the purely combinational
paths through C7. If there are wires connecting the input
pins directly to the output pins, without passing through
any combinational or sequential circuitry, then the estimated
interconnection delays of each such wire would be provided
in the model. Associated with the delay information of each
register, is the clock waveform; since there may be more
than a single clock driving the different registers. It is to be
noted that there are no information related to the intermediate
register-to-register paths, having no direct or combinational
connectivity with the pins at the boundary (eg. path F5 to
F6).
202

Page 3

Fig. 4 shows an example SoC with four cores (A,B,C,D)
and their interconnections. It is time, now, to investigate the
timing issues related to the connectivity of the cores in the
SoC with relation to their timing models. A timing verifier
checks if signals reach the destinations in the desired time,
so that the functionality of the circuit remains intact. Usually,
the timing check-points are at the registers. At every register
it is checked if the correct signal reaches the register in the
right time. In case of an SoC too, this must be true for all its
registers, during either flattened or hierarchical verification
modes. Since, at the time of hierarchical verification, the
register-to-register paths internal to the cores are already
verified, the checking is left only for registers present at the
boundary of the cores.
D
Q
D
Q
FA
FB
Core 1
Core 2
CLK2
CLK1
D
Q
FC
C1
C2
CLK3
CLK2D
Q
C3
Core 3
FD
ςC
CLK2
CLK1
Pi
Pj
Pk
Pl
a
b
c
def
g
h
δPi
δPj
Pi
t1
t2
ςC
CLK3
ηFC
t3
tarrival
tnochange
Fig. 5.Integration of cores in an SoC.
Fig. 5 shows a connectivity among four boundary flip-
flops in three cores within an SoC. The flip-flops have
three different clocks, CLK1, CLK2 and CLK3. From the
waveforms shown in the figure, the clocks visibly hold the
following properties:
• Three clocks are in three separate phases with respect
to each other.
• Clocks CLK1 and CLK3 are positive edge triggered,
while CLK2 is negative edge triggered.
• The clocks should be synchronized so that there is no
setup or hold violations (discussed later in detail).
The timing models of all the three cores are assumed to be
provided. In such case, the following information are known.
FROM THE GIVEN TIMING MODEL OF CORE1:
delay δ, associated with output pin Pi, δPi, is provided. This is
the time a valid data takes to reach pin Pifrom the immediate
registers FAand FB.
δPi= Max.{δa
Notations:
δa
of combinational circuit CA.
δb
of combinational circuit CA.
δPi
delay from the output c of combinational circuit CA
to the pin Pi.
δC1
t2−t1:phase difference between clocks CLK1 and CLK2.
QFA,δb
QFB}+δC1
critical+δPi
c+(t2−t1)
(1)
QFA: delay from the Q output of flip-flop FAto input a
QFB: delay from the Q output of flip-flop FBto input b
c :
critical: Critical delay of the combinational path in C1.
FROM THE GIVEN TIMING MODEL OF CORE2:
delay,δFC,associated with the input D of flip-flop FC. It is
the time taken by valid data to enter the D-input, DFC, from
the input pins, Pjand Pk.
δFC= Max.{δd
Pj,δe
Pk}+δC2
critical+δ
DFC
f
+ςC
(2)
Notations:
δ
f
DFC
: delay from output f of combinational path at C2to
the D input of flip-flop FC.
the rated setup time of flip-flop FC.
Rest have similar meaning as mentioned for Equation 1.
ςC:
FROM THE GIVEN TIMING MODEL OF CORE3:
delay δ, associated with output pin Pl, δPl, is provided.
This is the time a valid data takes to reach pin Plfrom its
immediate register FD. Notations have similar meaning as in
Equations 1 and 2.
δPl= δg
QFD+δC3
critical+δPl
h
(3)
Now, it is required to be validated if valid data reaches
the D input of flip-flop FCat each rising edge of the clock
CLK3. Clearly, after integration, the delay at the D input of
FCchanges from, δFC, which is given in the model for Core2.
After integration, the following points need to be considered
as well.
• The external delay just behind the core input pins,
leading to the objective flip-flop. In this case, it is the
delay up to the pins Pjand Pkfor the flip-flop FC.
• Phase differences between the clocks in different cores
from which there is a path to the objective flip-flop.
In this case, we need to consider the phase differences
between the clocks CLK1, CLK2, and CLK3.
Validation of Data Arrival Time. In order to have the
valid data reach DFCat the right time, the following relation
should hold:
Max.{t1+δPi+δPj
+ δC2
Pi+δPd
j, t2+δPl+δPk
Pl+δe
Pk}
critical+δ
DFC
f
≤ t3−ςC
(4)
Validation of Data Hold Time. The data arriving at DFC
should be held there for until the arrival of the rising edge
of CLK3 plus the rated hold time, ηFC, of the flip-flop.
203

Page 4

Combo
Combo
register
(a)
A
N
δA1
δAn
δN1
δNm
δP1
δP2
δPr
Supernode
Type II node
node
Type I
(b)
PI
a
PI PI
PI
PO PO
PO
b
c
d
e
f
gh
(c)
Fig. 6.
graph at Level-1.
(a) A single core data. (b) A supernode, (c) The directed acyclic
Therefore, synchronization should be guaranteed such that
data do not change within this time. If data should remain
unchanged for time tnochange, and tarrival is the data arrival
time at DFCthen,
tnochange ≥ t3 − tarrival + ηFC
So long verification of timing for only FCwas dealt with.
For a complete SoC timing verification, similar timing check
is required at every flip-flop inputs at the core boundaries,
and matched with the given SoC timing specification. Any
violation must be reported. The timing verification algorithm
proposed in this paper, takes care of the above criteria on all
the receiving flip-flops at the core boundaries. For this, the
entire SoC is modeled as a graph, and timing checks are
done at the input of each node of the graph.
(5)
III. PROBLEM FORMULATION
The least information that could be useful from the timing
model of each core is when the core consists entirely of com-
binational circuits. In such case, only the delays associated
with the core outputs will be required. The core model in
Fig. 6(a) illustrates it by showing that the register information
at the core input boundary may or may not exist, but there
must exist at least one output port delay information.
In the proposed method, the SoC is modeled as a directed
acyclic graph (DAG), G = {S,E,W}, as shown in Fig. 6(c).
Acyclic, since, feedback paths among cores have not been
considered. The graph G consists of a set of supernodes S,
a set of edges E, and a set of weights W associated with the
edges and node, and also the primary input nodes PI and
the primary output nodes PO. A supernode, further, consists
of two sets of node, TypeI nodes, and TypeII nodes (see,
Fig. 6(b)). Thus, S = {TypeI,TypeII}. The elements of the
TypeI set are the receiving registers at the core input. The
elements of the TypeII set are the ports at the output of
each core. The TypeI set can be empty, but the TypeII set is
never empty. The set PI consists of the nodes denoting the
primary inputs of the SoC. The set PO consists of the nodes
denoting the primary outputs of the SoC. The set W further
consists of two sets, WEand WN, i.e., W = {WE,WNI,WNII}.
The set elements of the set WE are delays associated with
each edge starting from a core output port and leading to
the combinational circuitry present before the receiving flip-
flop − if there is one; otherwise leading to the D-input of
the receiving flip-flop. For TypeI category of nodes (flip-
flops), the associated delays are contained in the set WNI.
If the D-input to the corresponding flip-flop is driven by a
combinational logic then the delay in WNI for the flip-flop
is a summation of the critical delay of the logic, the delay
of the wire leading to the D-input and the rated setup time
of the flip-flop. If there is no combinational logic before
the D−input then the delay value is just the rated setup
time of the flip-flop. The delays associated with the TypeII
category of nodes (output ports) are contained in the set
WNII. This delay is the delay a valid data takes to reach the
output port either from the input port of the core (for purely
combinational cores), or from one or more registers driving
that port. Each element in WNI and WNIIalso contains the
clock information of flip-flops associated with those nodes.
After the DAG has been built, the problem of timing
verification of the entire SoC reduces to checking if every
edge in the graph meets the timing requirement of the SoC
timing specification. Any mismatch has to be reported as an
error.
At this point, it should be noted that all the TypeI
nodes can be verified concurrently. The purely combinational
edges, that is, edges connected by TypeII nodes must be
verified together, since there is time dependencies between
these edges. For instance, in Fig. 6(c), the edges {ab, bc, cd}
have to be verified together since the delay from each edge
is added up with the next edge to get the final delay. Other
edges for sequential verification are {ef, fg}, {ef, fh}. The
rest of the edges can be tested in parallel. Because parallel
testing is possible, as a step towards further reduction of the
verification time, the graph may be divided into clusters and
each such cluster may be verified concurrently.
IV. BUILDING THE HIERARCHY
The proposed hierarchical verification method proceeds as
follows:
• Construct a DAG, namely Level-1 graph, storing the
timing models corresponding each IP-core, intercon-
necting lines, and any feedbackless combinational or
sequential path between them, see Fig. 6(c).
• If there is an input-to-output combinational path in any
IP-core timing module, then a separate edge is added
for the input-to-output line; and this delay is removed
from the original timing model. The weight of the new
edge is a summation of the preceding and following
edge delays, and also the input-to-output combinational
delay.
• Remove the supersets and construct a weighted forest,
namely Level-2 forest, representing the SoC with nodes
corresponding to flip-flops and edges corresponding to
critical delay paths leading to the flip-flops from a
driving flip-flop (attached to an output port) or a primary
input. The critical delay, in the form of weight, is
associated with each edge.
• Form various clusters out of the trees in the forest.
204

Page 5

– All trees residing in the in the same cluster will be
verified sequentially.
– Trees residing in different clusters will be verified
in parallel.
– There is a constraint on the number of clusters that
can be formed.
– The motive is to reduce the number of modules
to be verified sequentially and, in effect, the total
verification time.
• Do timing verification.
A. Transformation of the Glue Logic
The components of an SoC just before constructing the
Level-0 graph are as follows:
1. Timing abstraction of each IP-core.
2. Interconnections between the IP-cores.
3. Glue logic. This is the extra logic circuitry added into
the SoC by the SoC integrator for completeness of SoC
functionality.
In order to have a completely hierarchical verification, the
glue logic is processed separately and its timing model is
extracted. Then this logic is replaced by the corresponding
timing model in the Level-0 graph, as shown in Fig. 7.
Glue Logic 1
Glue
Logic 2
Core A
Core A
Glue
Logic 2
Glue
Logic 1
Core B
Core CCore C
Core B
Core D
Core E
Core ECore D
Fig. 7.Conversion of glue logic to a timing abstraction.
B. Construction of Level-1 Graph
The SoC is modeled as a directed acyclic graph G =
{S,E,W}, as shown in Fig. 6(c). Each of S, E, and W has
been defined explicitly in the previous section of problem
formulation. A weight is associated with each edge denoting
its delay. The delay of the edges have been generated by
extracting circuit information from the post-layout timing
information. The post-layout synthesis of the SoC design can
be done using a commercial front-end and back-end synthesis
tool. Each core during synthesis have been kept ‘untouched’
so that their modular properties are retained. The post-layout
timing information file produces all the pin-to-pin delays.
The delays from the core boundaries were used to construct
the black-box timing models of the cores. The delays at the
core interconnects were used in forming the delay associated
with edges.
C. Clustering - Formation of the Hierarchy
At any level in the hierarchy, there is a fixed constraint, Nc,
on the number of clusters to be made, denoting the degree
of parallelism in the algorithm. This constraint can be due
to restriction in the number of threads of the verification
software. At the same time, the target should be to maximize
PI
a
PI PI
PI
PO
POPO
b
c
d
e
f
gh
CLUSTER2
CLUSTER3
CLUSTER4
CLUSTER5
CLUSTER6
CLUSTER7
CLUSTER1
(a)
PI
a
PI PI
PI
PO
PO PO
b
c
d
e
f
gh
CLUSTER3
CLUSTER1
CLUSTER2
(b)
Fig. 8.
clustering the Level-2 forest, restricted to three clusters.
(a) After pass-1 of clustering the Level-2 forest (b) After pass-2
the number of clusters within this constraint. By increasing
the number of clusters, the timing verification process could
be made faster. The clustering process tries to equalize the
number of timing paths to be verified in each cluster. This is
to guarantee that each process needs to utilize similar amount
of time in verification; and no process needs to wait too long
for another process to finish. Once clustering is completed,
the clusters are scheduled for verification, concurrently.
Fig. 8(a) shows a clustering on the DAG of Fig. 6(c).
Clustering algorithm works in two passes. In the first pass,
all the connected modules are kept in the same cluster. So,
each cluster, in the first round, consists of a single connected
module. The connected clusters may be obtained just by
removing the boundary created by the core modules (supern-
odes, shown in Fig. 6(b) as the supernode box). Each module
is a tree. Thus what remains after the superset boundaries are
removed is a forest. This leads to the formation of the Level-
2 forest.
Since there is a constraint on the number of clusters, in
the second pass of the algorithm, the trees in the Level-2
forest are merged together into a single module. The merging
is done in such a fashion that the total number of edges in
each cluster is almost the same. The merging is done until the
number of clusters equals the given constraint, see Fig. 8(b).
V. THE HIERARCHICAL TIMING VERIFICATION
ALGORITHM
Once the cluster formation is complete, now its turn for
the timing verification of the entire SoC. This is done by
concurrently validating each of the clusters. The validation
process for each cluster is the same, and hence the following
discussion will proceed by taking into account a general
cluster. The pseudo-code explaining the process of timing
verification is given in Algorithm TimingVerfication.
For each TypeI node (flip-flops in the inputs), all edges
converging to it is found. Each TypeI node has a delay
associated with it, stored in its corresponding element in
WNI. This edge is the summation of the combinational path
delay combinational block input to its D-input, plus its rated
setup time delay. The maximum delay of all lines leading
205