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

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


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-


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.


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


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:

create_clock -name mclk -period 10 [get_ports clkin]

create_generated_clock -name mclkby2 -master_clock mclk -divide_by 2 -

source [get_ports clkin] [get_ports {clkby2}]





The waveforms implied by these clock definitions are shown below:

Figure 4: Verification of generated clock alignment.

The way the waveforms have been specified, mclkby4 is expected to rise along with

mclkby2 and mclkby8 is expected to rise along with mclkby4. What, if however, the

logic that creates these generated clocks results in the waveform shown on mclkby8’.

The periods of the generated clocks have been correctly specified, but mclkby8 actually

rises when mclkby4 falls, and not when mclkby4 rises. Confirm will flag this issue. The

impact of such a mistake can be significant. With the waveforms specified by the user,

STA will provide 4 cycles of mclk for a timing path that is launched by mclkby4 and

captured by mclkby8. However, after accounting for the correct alignment among the


generated clocks there are actually only 2 cycles of mclk available for the path from

mclkby4 to mclkby8. The impact of this mistake is the same as specifying an incorrect

two cycle MCP between mclkby4 and mclkby8.

In addition to checking the waveform specified on the pin on which a generated clock is

created, Confirm examines if the clock gating logic that shapes the waveform on a

generated clock as it propagates along the clock network, changes the way the clock is

aligned relative to the pin on which it is created. If the alignment changes, the issue is

flagged because it means that the clock waveform that propagates to the clock pins is

inconsistent with the waveform specified on the generated clock definition point.

Logically Exclusive Clock Group Verification

Figure 5: Logically exclusive clock group verification.

For the design shown in Figure 5, assume that the following constraints have been

defined:

create_clock –period 5.0 clk

create_generated_clock –source clk –divide_by 2 genclk

set_false_path –from clk –to genclk

Confirm will report that the path between FF3 and FF4 is correctly constrained because

the propagation requirement for clk to reach the clock pins on these flops is “!sel” and

the propagation requirement for genclk to reach the same clock pins is “sel”. As the

propagation requirements are exclusive to each other, the two clocks are logically

exclusive in the way they propagate to flops FF3 and FF4. Confirm, however, will also

report that the path between FF1 and FF2 is incorrectly constrained because both clk and

genclk unconditionally reach the clock pins on these flops. For this reason, clocks clk

and genclk are not exclusive in the way they propagate to FF1 and FF2.


Confirm provides a nuanced assessment of clock crossing issues. Instead of complaining

about a clock-to-clock exception simply based on the fact that two clocks share the same

master clock, Confirm analyzes the design to establish if the clocks are logically

exclusive to each other and only complains if they are not. As a result, a designer only

needs to review the real clock crossing issues on a design.

Physically Exclusive Clock Group Verification

Figure 6: Physically exclusive clock group verification.

For the design shown in Figure 6, assume that the following constraints have been

defined:

create_clock –period 5.0 clk

create_generated_clock FF1/Q –source clk –divide_by 2 –name genclk1

create_generated_clock FF2/Q –source clk –divide_by 2 –name genclk2

set_clock_group –physically_exclusive –group genclk1 –group genclk2

Confirm establishes that the propagation requirement for the master clock clk to

genclk1 is “sel”. Similarly, the propagation requirement for the master clock clk to

genclk2 is “!sel”. As a result, the condition under which generated clock genclk1

exists on the design is “sel” and the condition under which genclk2 exists in the design

is “!sel”. As these conditions are exclusive the two generated clocks are physically

exclusive – when one exists, the other does not. Confirm does not flag any issue with the

clock group constraint and the benefit of this is less noise in the warnings reported by the

tool - this is key to maintaining the attention span of a seasoned designer.

Case Analysis Verification

For the design show in Figure 7 assume that the following constraints are in place:

set_case_analysis 0 U1/S

set_case_analysis 0 U2/S


Figure 7: Case analysis verification.

STA will flag no issue with these constraints because there is no conflict with the

specified constant values when they are propagated forward in the design. Confirm, on

the other hand, will establish that the case analysis of 0 on U1/S requires flops FF1 and

FF2 to both be high. The case analysis of 0 on U2/S requires flops FF1 and FF2 to both be

low. These requirements conflict and so the specified case analysis is cumulatively illegal.

On complex designs it is easy to specify case analysis values that are in conflict with each

other. These values will be honored without complaint by STA and could easily result in

a silicon issue because timing signoff will be performed with the design placed in a bogus

state – the actual analysis that is meant to take place will never be performed.

False Path Verification

Figure 8: False path verification

For the design show in Figure 8 assume that the following constraints are in place:

create_clock –period 5.0 CLKA

create_clock –period 10.0 CLKB

set_false_path –from FF1/CP –to CLKB

set_false_path –from FF2/CP –to CLKA


STA will not help establish whether the specified false paths are correct or incorrect. At

best STA will tell a designer that the specified paths do apply to real paths on a design.

Whether they are meant to apply or not, is not something STA helps address. Confirm

verifies these false paths by establishing that the propagation requirement for the path

from FF1 to FF3 is “!sel” and the propagation requirement for FF2 to FF3 is “sel”. Also,

the propagation requirement for clock CLKA to FF3 is “!sel” and the propagation

requirement for clock CLKB to FF3 is “sel”. Since the propagation requirement of “!sel”

from FF1 to FF3 conflicts with the propagation requirement of “sel” for CLKB to

propagate to FF3 the false-path definition from FF1 to CLKB is correct. Similarly, the

false-path definition from FF2 to CLKA is also correct. Confirm will not complain about

either of these false paths.

In general, as long as the RTL provided to the tool supports the constraint, regardless of

the complexity of the logic cones, Confirm will formally prove a timing exception as

correct. If the exception fails formal verification an assertion is generated for it and

verified using functional simulation. As long as a timing exception is supported by the

logic or architecture of the design there is value in verifying it using Confirm. If, however,

the only justification for a false or multi-cycle path is to mask the timing on a path,

because it does not need to be met, then there is no value in verifying such exceptions

using Confirm. An example of such a false path, for example, is one specified from test

ports in the functional mode of the design – these paths are not really false, but the

designer has decided that their timing is irrelevant in the functional mode. Such

exceptions can and should be waived up-front from verification.

Multi-Cycle Path Verification

Figure 9: Multi-cycle path verification

For the design show in Figure 9, assume the following constraints are in place:

create_clock –period 5.0 CLK

set_multicycle_path –from FF1/CP –to FF2/D

To prove this multi-cycle path Confirm establishes that for the FF1/Q pin to transition in

the current clock cycle valid must be high in the previous clock cycle. Also, for clk to


propagate to FF2, valid must be high. The signal valid has a periodic relationship and

toggles from high to low every clock cycle. For this reason, if valid is high in the current

clock cycle, causing FF1/Q to transition in the next cycle, then valid is also low in the

next cycle thereby preventing clk from propagating to FF2. This ensures multi-cycle

behavior and the specified multi-cycle path from FF1 to FF2 is correct. MCP verification

requires a sequential formal analysis of the design, working back several clock cycles

until a multi-cycle property is proven. If Confirm is unable to formally prove an MCP it

generates an assertion, such as that shown in Figure 10.

module u_mcp97_1 (input bit clk, input logic [15:0]

from_reg, input logic [15:0] to_reg, input bit [1:0] v39);

wire path_propagation_condition = ( (v39[1:0] == 2'b01) );

property e_mcp97_1;

@(posedge clk) `FT_DISABLE

(`FT_TRANSITIONS_AND_NOT_UNKNOWN(from_reg[15:0]))

|-> ((##0 (!path_propagation_condition)) or

(##1 (`FT_NO_TRANSITION_OR_UNKNOWN(to_reg[15:0]))));

endproperty

mcp97_1: assert property(e_mcp97_1);

endmodule

bind top u_mcp97_1 sva_u_mcp97_1(.clk(blk3.fast_clk),

.from_reg(blk3.sp), .to_reg(blk3.ep), .v39(uCounter.count));

Figure 10: Example assertion for failing MCP.

This assertion checks that when the startpoint (from_reg) transitions then, either in that

cycle the condition required to propagate the change from the startpoint to the endpoint

(path_propagation_condition) should not be true, or in the next cycle the endpoint

(to_reg) should not transition. The assertion is bound to the original RTL using bind

statements. The assertion file generated by Confirm is a standalone file that is added to

the list of files that are compiled by the simulator. Assuming the design has a good

regression suite, the validity of the exception can be tested with a high degree of

confidence by importing the assertion file into RTL functional simulation.

Glitch Verification

It is imperative that asynchronous resets are safe from glitches that momentarily reset a

sequential element on a design. Approaches that attempt to prove that resets are glitch

safe do not work effectively with RTL input and require significant hand-holding to

confirm an expected result. Confirm offers a significantly differentiated approach to

verifying that asynchronous resets on a design are glitch safe. Confirm identifies all the

asynchronous resets on a design and their assertion level (i.e. is the reset active low or

active high). Confirm then uses a combination of formal and assertion-based verification


to prove that an active low reset cannot glitch low and an active high reset cannot glitch

high.

Confirm does this by analyzing the cone of logic leading to a reset and identifying the

multi-input gates (MIG) in this logic. A MIG is where a glitch could occur and then

propagate to the reset pin. If Confirm is able to formally prove that it is impossible for a

glitch of the appropriate polarity to occur on the MIG output, or even if the MIG could

glitch it is impossible for the glitch to propagate to the reset pin, then the reset pin is safe

from a glitch as far as that specific MIG is concerned. If, on the other hand, Confirm

cannot rule out the possibility of a glitch at the MIG and the subsequent propagation of

the glitch to the reset pin then it writes out an assertion that captures what it would take

for a glitch to be generated at the output of the MIG and then propagate to the reset pin.

Functional simulation can be used to establish that the assertion never fails. Confirm

repeats this approach for each MIG in the cone of logic leading to an asynchronous reset.

Figure 11: Glitch verification of asynchronous resets.

For example, consider the design in Figure 11, where it is important that the clrz pin not

glitch low. The MIGs in the fanin cone of clrz are U13, U33, U243 etc. At some of these

cells, U13 and U33 for example, it is trivial to prove that the desired glitch cannot happen

(a NAND-gate cannot glitch high, for example, nor can a NOR-gate glitch low). At

others, U246, for example, an active low glitch could occur and propagate to the clrz pin

depending on how the cone of logic for this signal is driven. Rather than require the user

to provide architectural input to formally establish that this is impossible, Confirm

generates an assertion that can be checked during functional simulation. The assertion for

U246 is shown in Figure 12. The assertion checks if it is possible for the inputs on U246 to

transition in a way that a glitch could occur at the output of U246, and if this can happen

the assertion further checks that this glitch cannot propagate to clrz.


@(posedge clk)

(($rose(poken10_1p8) && `FT_IS_HI(pok10_1p8) && $fell(pok10_out_1p8))

||

($fell(poken10_1p8) && `FT_IS_HI(pok10_1p8) && $rose(pok10_out_1p8)))

|->

(!(`FT_IS_HI(reset_tamper_extended.q) && `FT_IS_LO(U240.y) &&

`FT_IS_LO(U34.y) && `FT_IS_HI(U244.y) && `FT_IS_HI(u245.y)));

Figure 12: Example glitch assertion.

Confirm’s approach to glitch verification does not require an engineer to provide

architectural input to nudge the tool along and help it prove that a cone of logic is glitch

safe. That’s because the objective is not to prove everything formally, only what can be

done so conclusively based on design description. For the rest, Confirm generates

assertions and functional simulation establishes whether the assertions pass or fail. No

delay information is required to prove that a timing endpoint is glitch safe. The validity of

our approach holds for any and all circuit delays. The exercise can be repeat once the

RTL is synthesized if an engineer is concerned about the impact of synthesis

transformations on glitch generation and propagation.

Documents

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