Preserving The Intent Of Timing Constraints

As the complexity of designs has scaled, the need to provide accurate physical constraints like timing, area, power and port locations has become very important. Of these, timing constraints are the most difficult to provide since they depend on many external factors like floor planning, routing and integration with other blocks. Properly created timing constraints not only reduce the total effort to achieve timing closure, but also reduce the number of iterations to achieve that goal. These constraints undergo several refinements as they are pushed through the design flow from RTL to post layout. This requires that constraints be managed at each step and properly handed off to the next step to ensure that design intent is preserved. If constraints are not managed properly, unnecessary iterations between front-end and back-end groups occur, and time to market and end unit cost is impacted.

The landscape becomes more complicated when handoff has to happen between tools from different vendors. This results in the need to manage constraints in different formats. The challenge is to check that these constraints model the same timing behavior and produce the same timing results irrespective of the format that has been used to specify them. The goal of the designer is simple " to carefully monitor the changes in his timing constraints throughout the design flow and check at each step that constraints from the previous step are in sync with the current step. With different ways to model the same timing behavior, the designer needs to manage these constraints to ensure faster timing closure and reduced iterations to make design schedules more predictable.

Design Perspective

In a typical design environment, SDC (Synopsys Design Constraints) or Magma-tcl files are used for specifying timing constraints. These constraints files are modified at each step of the design flow from RTL to post layout to make them more efficient, complete and/or concise. This kind of cleanup and modification necessitates a check to ensure that constraints are equivalent after every transformation. When a design completes a particular stage and graduates to the next stage, a new constraints file is typically created either manually or automatically, to set constraints more appropriate for that stage.

1a. Equivalence between two constraints files for the same design.

Hence, at each stage, it is imperative the constraints retain the original timing behavior that has already been verified in the previous stage. Changes might also be needed in order to accommodate engineering change orders (ECOs). In the absence of precise information on what has changed in constraints, any time a new version of constraints arrives, designers don't have a good idea on what follow-up actions to take that will minimize the design closure time. They usually play it safe and iterate large implementation steps.

1b. Equivalence between constraints files for chip vs. block.

If constraints changes are minimal, the designer may want to re-do only in-place optimization (IPO), but if the change is larger, the designer may want to re-floorplan and re-do place and route altogether.

Figures 1(a, b and c) show how constraints files could get used at each step of the design flow and how the equivalence can be checked between two constraints files under multiple scenarios. When timing constraints are being consumed extensively during various design stages, it is important to analyze them for correctness, completeness and consistency and check the equivalence between them for the following cases: a) same design; b) chip vs. block; c) two designs at two different stages (e.g., RTL vs. gates, pre-layout vs. post-layout gates).

1b. Equivalence between two constraints files for RTL vs. netlist.

The remainder of this white paper provides a deeper insight into equivalence between timing constraints adhering to the SDC format.

Constraints Equivalence Overview

a) Two SDC files for the same design

This kind of use model is typically observed when a designer cleans up SDC at any design stage to make it more efficient or concise for synthesis or static timing analysis (STA) (Figure 1a). These changes could include:

• Removing constraints that are not applicable or redundant
• Replacing constraints with similar ones. E.g., replacing disable_timing with false_path
• Clustering constraints that are similar. E.g., expanded constraints may be replaced by wildcards
• Possibly expanding wildcards, so that different constraints can be applied to each path

First, the SDC equivalence capability will need to report all such differences between the two files being compared. Next, the SDC equivalence will need to check that the SDC before and after the transformation are equivalent, i.e., if the intent of the constraints is preserved between newer and older version of SDC. It is key is to recognize that the constraints may be different but result in the same effect.

For example, if a feed-through path is constrained using set_input_delay and set_output_delay with respect to a virtual clock in one SDC and constrained using set_max_delay and set_min_delay in the second SDC, then both the constraints will be considered as equivalent as long as they result in the same effect.

Another example is when the constraints are applied at equivalent points in the design. E.g., clock constraints set on a pin in one SDC versus set on its driver in the other.

The example in Figure 2 illustrates how equivalence can be used to check the difference between versions of an SDC file for the same design.

2. Example of equivalence of clocks and set_input_delay.

Click here for a larger version

b) Equivalence between chip vs. block SDC

This kind of use model is typically observed when a designer creates block level SDC from top level SDC using a timing budget tool or vice-versa, where a top level SDC is created by merging and promoting block level constraints (Figure 3).

3. Equivalence between constraints files for chip vs. block consistency.

The Idea behind doing an equivalence check between SDC files of the top level and block level is that these SDC files are typically generated from each other depending on the top-down or bottom-up flow. In a bottom-up flow, if a block meets timing when analyzed independently, and doesn't meet timing when integrated into the top level, it is because there is some inconsistency in the way constrains get applied at the top level. Equivalence checking will ensure that constraints at the block level will result in the same timing at the top level. The same argument holds for a top-down flow.

Consider the following example (Figure 4). If any constant (applied using a set_case_analysis) reaches the block's output port, and if the fan-out of this port is connected to glue logic at the top level, then there should be a corresponding set_case_analysis on the next logic level in the top. If no such set_case_analysis is found, then it should be flagged by the equivalence tool. If the set_case_analysis is found but the values are conflicting, then that should be flagged, too.

4. Inconsistent case analysis between top and block levels..

Consider the following example in Figure 5 and the corresponding SDC files in Figure 6 for each block and the top level sub-system.

5. A sub-system with two blocks, B1 and B2.

Click here for a larger version

The SDC file indicates how clocks and I/O delays in B1 and B2 get mapped to equivalent clocks and I/O delays at the subsystem level. For example., the clock ck1 in Block B2 is equivalent to the generated clock clock_gen at the sub-system level. This is because it has the same characteristics (period, same source, etc.). Similarly, the input delay on datain is equivalent to input delay at in1 of Block B1. Note that the input delay value on in1 is greater than the input delay value of datain. Even though delay values are different, the input delays could still be equivalent, since there could be additional latency when the input reaches B1. Hence the delay on input in1 of Block B1 must be equal or greater then the input delay on datain.

6. SDC files for the sub-system and blocks as depicted in figure 5.

Click here for a larger version

c) Equivalence between SDCs that are associated with different designs

This kind of use model is typically observed when a designer is trying to compare SDC for an RTL design with SDC for a synthesized netlist or when comparing pre-layout and post-layout SDC (Figure 7).

7. Equivalence between constraints files for different designs.

In the back-end flow, prototyping tools typically modify the physical partition of designs and generate the constraints for the physical partitions (Figure 8). It becomes quite important to do equivalence checking between timing constraints for this case too, since equivalence between designs can be established using a logic equivalence checking tool. This kind of equivalence requires that the designs being compared are logically equivalent.

8. Equivalence between constraints for re-partitioned designs.

This kind of equivalence could have many variations:

• Designs are equivalent in terms of gates but restructured hierarchically.
• Designs are equivalent hierarchically and have the same functionality, but different combinational logic.
• Designs are equivalent hierarchically and have the same functionality for logic, but different sequential logic (that is, the design is re-timed).

During checking, each constraint being considered for equivalence can be applied on a port, physical pin, register in the design or path (as in exceptions), which will have a start, end and possibly a through point. For the equivalence, it will be required to establish equivalence between these points where the constraints are being applied. This information is typically available from logic equivalence checking tools.