Constraint Verification

Transcription

1 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

2 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 paths on the design. Of these 58% of the paths were formally proven, and a further 39% of the paths were proven using assertion-

3 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.

4 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

5 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}] create_generated_clock -name mclkby4 -master_clock mclk -divide_by 4 - source [get_ports clkin] [get_ports {clkby4}] create_generated_clock -name mclkby8 -master_clock mclk -divide_by 8 - source [get_ports clkin] [get_ports {clkby8}] 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

6 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.

7 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

8 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

9 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

10 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 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

11 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.

12 @(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.