FishTail Design Automation Inc. Constraint Verification Constraint verification refers to the verification of the contents of an SDC file to flag situations where the specified constraints are either incorrect, or incomplete, both of which, if not addressed, could result in silicon failure. The key to constraint verification is the ability to flag real issues without swamping an engineer with noise: issues that upon designer review result in no change to the design or constraints. A constraint verification solution plays the role of a devil’s advocate, and is effective when it brings to the attention of engineers sophisticated design/constraints issues that are not flagged by other tools in the implementation/verification flow. A constraint verification solution that inundates an engineer with warnings is, in effect, abdicating the role it was asked to perform and telling the engineer that he needs to manually review his constraints. The key to an effective constraint verification solution is the use of powerful formal technology that only flags issues when the collateral provided to the tool (design, architectural input) simply does not support a constraint. A tool that flags issues because the formal engine underlying the verification is unable to deal with design complexity is inherently noisy and so of limited value. Powerful formal technology by itself, however, is insufficient in eliminating noise. Often the support for a constraint such as a false or multi-cycle path is based on the way the design will be used. For example, some registers are expected to be static and programmed to a subset of the possible values. The behavior on the input ports of a design is expected to adhere to a bus protocol. Even the most powerful formal tool is unable to deal with information it is unaware about. It is in these situations that assertions play a hugely important role in reducing the issues that an engineer needs to review. Figure 1: Constraint verification flow. The FishTail constraint verification flow, shown in Figure 1, takes as input the RTL or netlist description of a design along with its associated constraints (in Tcl format). The constraints are first mapped to the design description using Refocus. The constraint mapping process is used to sort out basic issues with the collateral; black-boxed modules, syntax issues with the constraints, constraints that refer to objects that do not exist, setup multi-cycle paths (MCPs) specified without accompanying hold MCPs, etc. Refocus is
12
Embed
The Formal Verification of Design Constraints Design Automation Inc. Constraint Verification Constraint verification refers to the verification of the contents of an SDC file to flag
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
FishTail Design Automation Inc.
Constraint Verification
Constraint verification refers to the verification of the contents of an SDC file to flag
situations where the specified constraints are either incorrect, or incomplete, both of
which, if not addressed, could result in silicon failure. The key to constraint verification
is the ability to flag real issues without swamping an engineer with noise: issues that
upon designer review result in no change to the design or constraints. A constraint
verification solution plays the role of a devil’s advocate, and is effective when it brings to
the attention of engineers sophisticated design/constraints issues that are not flagged by
other tools in the implementation/verification flow. A constraint verification solution that
inundates an engineer with warnings is, in effect, abdicating the role it was asked to
perform and telling the engineer that he needs to manually review his constraints.
The key to an effective constraint verification solution is the use of powerful formal
technology that only flags issues when the collateral provided to the tool (design,
architectural input) simply does not support a constraint. A tool that flags issues because
the formal engine underlying the verification is unable to deal with design complexity is
inherently noisy and so of limited value. Powerful formal technology by itself, however,
is insufficient in eliminating noise. Often the support for a constraint such as a false or
multi-cycle path is based on the way the design will be used. For example, some registers
are expected to be static and programmed to a subset of the possible values. The behavior
on the input ports of a design is expected to adhere to a bus protocol. Even the most
powerful formal tool is unable to deal with information it is unaware about. It is in these
situations that assertions play a hugely important role in reducing the issues that an
engineer needs to review.
Figure 1: Constraint verification flow.
The FishTail constraint verification flow, shown in Figure 1, takes as input the RTL or
netlist description of a design along with its associated constraints (in Tcl format). The
constraints are first mapped to the design description using Refocus. The constraint
mapping process is used to sort out basic issues with the collateral; black-boxed modules,
syntax issues with the constraints, constraints that refer to objects that do not exist, setup
multi-cycle paths (MCPs) specified without accompanying hold MCPs, etc. Refocus is
FishTail Design Automation Inc.
able to map netlist constraints to RTL, allowing constraint verification to be performed
with RTL input (this is preferable for designer review, assertion integration into RTL
functional simulation) even when STA signoff constraints need to be verified.
Once constraint mapping is clean, engineers proceed with verifying their constraints
using Confirm. Confirm is built on a proprietary formal engine that was developed
specifically for constraint verification. This engine allows Confirm to scale, perform fast
formal verification, without being humbled by complex cones of logic. The formal
technology used by Confirm does not synthesize the input RTL, but instead performs
verification at a higher-level of the design than traditional formal tools. When false or
multi-cycle paths fail formal proof, engineers are not asked to review these failures, or
provide architectural input to the tool to get these failures to change to passes. Instead,
Confirm generates assertions for failing timing exceptions. Assertions capture the
functional behavior of the design that must be satisfied for the exceptions they are
associated with to be correct. Since the RTL provided as input to Confirm was not
synthesized the generated assertions are compact, refer to RTL nets that a simulator has
visibility into, and are easily integrated into any simulator. The assertions check all paths
constrained by timing exceptions but do not significantly impact simulation runtime.
Next, engineers run their existing regressions for a design with the generated assertions.
Once the regression run is complete, engineers run a utility that extracts status on the
Confirm generated assertions from their simulation run. This utility reports exceptions
whose assertions failed, the paths that are impacted by these failures, and the tests in
which the failures occurred. These failures need to be reviewed closely by designers,
because the flow is pointing out real-world situations where the specified FP/MCP
behavior does not hold. Reviewing a failure simply requires bringing up the simulation
waveform and analyzing the failure – something engineers are already comfortable with.
For assertions that are not covered by existing regressions the flow reports a list of
registers that never transitioned. If these registers are truly static then nothing further
needs to be done; the impacted exceptions are legitimate because they apply to static
startpoints. If these registers are not static, then the flow has pointed out a gap in the
existing functional coverage of the design that needs to be addressed by adding new
testcases to the regressions.
The value of the FishTail constraint verification flow is that by using a powerful
proprietary formal engine, coupled with the ability to generate accurate, complete and
compact assertions for failing exceptions, engineers only review real issues with their
constraints. The flow does not waste designer time reviewing noise and so plays an
effective devil’s advocate regarding the correctness of their constraints. For example,
consider the data we gathered from the verification of timing exceptions using Confirm
on a CPU. The SDC had 31 false-paths that applied to 7137 paths on the design (a path is
a unique start/end pair). Of these, 25% of the paths were formally proven to be correct
and a further 74% were proven using assertion-based verification – leaving only 97
failing paths (out of a total of 7137) to be reviewed by the designer. The SDC also had
336 multi-cycle paths that applied to 14238 paths on the design. Of these 58% of the
paths were formally proven, and a further 39% of the paths were proven using assertion-
FishTail Design Automation Inc.
based verification – leaving 460 failing paths (out of a total of 14238) for designer review.
These results are not unique to this specific design. Typically, less than 2-3% of the paths
constrained by timing exceptions require designer review using Confirm’s formal and
assertion-based approach to constraint verification.
The rest of this document discusses types of constraint related issues that are flagged by
the flow – issues that other tools do not catch. These issues relate to the verification of:
1) Clock propagation
2) Generated clock waveforms
3) Generated clock alignment
4) Logically exclusive clock groups
5) Physically exclusive clock groups
6) Case analysis
7) False paths
8) Multi-cycle paths
9) Glitches on asynchronous resets
Clock-Propagation Verification
Figure 2: Verification of clock propagation.
For the design shown in Figure 2, assume the following constraints are in place:
create_clock –period 5.0 CLKA
create_clock –period 3.0 TCLK
create_clock –period 10.0 CLKB
STA simply establishes whether a clock propagates to a pin or not. Case analysis and
disable timing commands are the only reasons for the propagation of a clock along a
combinational path to stop. Confirm’s constraint verification, on the other hand,
establishes not only the pins that a clock propagates to but the condition under which a
clock propagates to that pin.
FishTail Design Automation Inc.
For example, in Figure 2, Confirm establishes that for the clock TCLK to propagate to
U1/Y, TEST must be 1 (note that there is no case analysis specified on TEST). As the
requirement for TCLK to propagate to U3/Y is that TEST must be 0 it is impossible for
TCLK to propagate through U1/Y and then also through U3/Y. As a result, the propagation
of TCLK will halt at U3/A. Confirm flags this as an issue - the impact of which is that the
flop FF2 will not be clocked by TCLK. This issue could be the result of a design bug where
instead of an or-gate driving the select line of the clock mux U3, a nor-gate was intended.
STA will completely miss this issue and instead indicate that flop FF2 is clocked by TCLK.
This provides a false assurance to a design engineer and misses an important bug in the
clock-generation logic. If the designer decides that the propagation of TCLK was
intentionally stopped at U3/A, then the constraints are missing a set_clock_sense –
stop_propagation constraint that communicates this to STA. Without this constraint
STA results will be pessimistic, potentially reporting timing issues that are not real.
Verification of Generated Clock Waveforms
Figure 3: Verification of generated clock waveforms.
Generated clock definitions specify a periodic waveform on a pin. The complexities
associated with the different options used to create a generated clock coupled with design
complexities result in the risk that an engineer specifies an incorrect waveform. Such a
mistake is serious because it impacts the static timing analysis of all the registers clocked
by the generated clock. STA checks that an engineer has correctly specified the edges of
the master clock at which a generated clock transitions. For the generated clock specified
in Figure 3, STA will not report any issue since it is indeed correct that the generated
clock transitions at rising edges of the master clock. STA does not, however, verify that
the low-pulse, high-pulse and period of the generated clock is correctly specified and so
does not issue any error message for the situation shown in Figure 3. The engineer has
specified a divide-by 3 waveform relative to the master clock when, in fact, the logic of
FishTail Design Automation Inc.
the design results in a divide-by 4 generated clock. Confirm flags this issue and proves
whether the low-pulse, high-pulse and period on a generated clock are correctly specified
based on the clock-division logic.
Generated-Clock Alignment Verification In addition to verifying the period and pulse-width on generated clocks Confirm verifies
the alignment of generated clocks that are derived from a common master clock.
Alignment verification requires checking to see whether the specified separation between
rising edges on generated clocks is actually exhibited by the circuit. For example,
consider the following clock definitions in a constraint file: