Verification and Generation of Constraints

By Sanjay Churiwala, Sr. Director – Engineering, Atrenta (I) Pvt. Ltd.
Guru S. Shindaghatta, Principal Application Engineer, Atrenta Inc.
Wei Jiang, Senior IC Designer, Texas Instruments
Andrew K. Pua, Senior IC Designer, Texas Instruments

As today’s designs become more complex, so too do their constraints. Design functionality typically gets a lot of attention – through code review, functional verification, etc. However, the constraints themselves usually do not get the same level of attention. This is ironic given that the critical implementation and timing analysis steps are dependent on quality constraints.

The complexity of constraints is further increased by the following design characteristics:

• Low power applications (e.g., handheld devices) require extensive clock gating
• Pad limited designs require a high degree of input multiplexing

This article highlights and discusses the importance of constraint validation early in the design flow, and analyzes the impact of this validation approach on a real design. The article then looks at the possibility of generating constraints using automated techniques – and once again, presents the results of trying it on a new design.

The Role of Constraints

While the functionality of the design is represented by the RTL code, timing constraints play the role of influencing the performance parameters of the design. These performance parameters include power, area and timing. These parameters tend to be inter-related, but the majority of design constraints tend to be related to timing.

In the context of timing, constraints convey the following important information about the performance of the design:

• The target operating frequency for various clocks
• The time at which various inputs are available
• The time at which various outputs are desired
• The drive capacity of external drivers
• The external load that needs to be driven
• Certain topological paths that need not be timed (false paths)
• Certain topological paths that are allowed more than one clock cycle to complete (multi-cycle paths)

These constraints are then used by:

• Synthesis tools: To direct that it should infer logic and choose gates so as to meet those performance requirements
• Static timing analysis (STA) tools: To direct that it should validate that the realized circuit actually meets the stated performance requirements
• Place and route tools: To complete placement and routing – such that the performance requirements continue to be met

The Need for Constraint Validation Tools

Simulation tools don’t make use of constraints and will not catch constraint-related problems. The earliest that a designer can catch wrong/missing constraints is when he/she runs synthesis. Here also, there are several possibilities – depending on the nature of the constraint [1].

1. Certain constraints have a default value – which is highly optimistic, e.g., set_input_delay. If a user has forgotten to specify set_input_delay, a default value of “0” is assumed, and no issue will be reported. Even a typical STA tool will not be able to catch such an issue. Both synthesis and STA tools will happily assume the “0” value and provide optimistic results. Unfortunately, the silicon might not behave that optimistically, and the device might not meet its performance target. Several other constraints (e.g., set_input_transition) have a highly optimistic default value.

2. The majority of constraints are simply assumed to be a “statement of fact” from the user. Implementation/timing tools simply honor those, without any verification or warning. A particular set of constraints which relax a requirement fall under such category, e.g., “set_false_path”. If a path is declared as “set_false_path” – both synthesis and STA tools will not time the path. Once again, this could cause the silicon to fail.

3. Some constraints, when missing, would be reported by a synthesis tool, e.g., “create_clock” or “create_generated_clock”.

Even if synthesis tools could be relied upon to catch some of the issues with constraints, they still would not catch issues related to mismatches or inconsistencies among the constraints of various blocks. This is because synthesis tools look at each block in isolation – without looking at its surrounding blocks. The earliest that such mismatches would be caught is during STA at the full chip level; though even at this point they are often caught indirectly and manifest as timing problems rather than constraint problems. Unfortunately, by this point the blocks have already been synthesized and we are already too far along in the flow to catch such issues. This will often result in repeated iterations through synthesis onwards.

Figure 1 summarizes the above discussion.


Figure 1: Catching Missing/Erroneous Constraints

There is a real need to verify timing constraints much earlier in the design flow, so that we are not caught by surprise later during implementation/STA. For example -

• During silicon testing: The silicon may not meet timing, because of optimistic “defaults” in various tools
• During STA: Even though the individual blocks were meeting the timing, the full chip does not meet timing because of constraint inconsistencies between different blocks

Complexity of Constraints

Conceptually, constraints are very simple. However, there are a number of ways in which high impact mistakes can be made.

Let’s consider clock constraints in the traditional design flow, and review where mistakes can be made (and when those mistakes can be detected) -

1. A clock is not declared at a signal/port – which is being used as a clock. Will be caught during synthesis and also during STA
2. A clock is declared at a signal/port – which is not being used as a clock. Will not be caught!!!
3. A generated clock is being generated, but, the source specification is wrong. Will not be caught!!!
4. A generated clock is being declared, but, with the wrong value for divide_by. Will not be caught!!!
5. A simple clock divider, implemented using a flop’s output inverted and fed back to its own “data” input. Depending on whether the generated clock is being tapped before or after the inversion – the clock waveform would be different. A generated_clock is declared with a waveform – that is not commensurate with the point of tapping. Will not be caught!!!

It should be noted that issues (c) through (e) will not be caught anywhere and would result in incorrect clock waveform inference, thus rendering STA useless by giving a false sense of security.

There are also complexities associated with:

• set_input_delay (of –add_delay option; many times written in short as: -add)
• set_clock_transition (needs to be replaced with input transition)
• Timing exceptions, etc.

Since constraint development/maintenance is traditionally thought of as a “backend” issue, many RTL designers are not that conversant with these complexities. There is a good chance that they will make some of the mistakes outlined above – which can result in silicon failure, or, in the best case synthesis re-spins.

Early constraint validation allows one to avoid issues such as -

• Missing constraints - where tools may proceed with “optimistic defaults”
• Constraints which are inconsistent among different partitions - which will result in additional synthesis iterations after STA
• Other less commonly used constraint scenarios – it’s likely that these may be overlooked during manual review. Many new designers might not be aware of these fine details. The backend teams (who usually have reasonable knowledge of constraints) may not be familiar enough with the design to catch these issues

Design Example

Texas Instruments used Atrenta’s SpyGlass®-Constraints product on one of its designs.

This design performs an image-processing function within a wireless application, and power is of utmost importance. There are 16 main clocks, but, due to the power sensitive nature of the design there is extensive clock-gating. Including the gated clocks, the design has 95 clocks in total.

SpyGlass-Constraints offers several rules and various parameters – to fine-tune/customize the checks. We used the default “Methodology” rules for this exercise.

SpyGlass-Constraints found following issues with our constraints – in the RTL stage itself:

a) Missing definition at several places for “generated clocks”. For example, a primary clock was passing through a clock divider – which was then followed by a clock-gating cell. This gated clock was driving some sequential elements. Hence, there should have been a create_generated_clock declared on it.

create_generated_clock -name Gclk -edges {1 2 5} -source [get_pin box_div_reg/q] [get_pins box_clk_icg_i/clkout]

Analysis in SpyGlass-Constraints identified this issue.


b) Incorrect divide_by factor for several generated clocks

c) Missing “-add_delay” on some of the set_input_delay/set_output_delay specifications, causing subsequent delay constraints on the same ports to overwrite each other. The same input was being sampled by multiple clocks. Hence, the related set_input_delay constraint needed to be specified with respect to multiple clocks.

set_input_delay –add_delay -max [expr 0.7 * $325MHZPD] -clock [get_clock Clock] [get_ports InputName]

In some cases this “-add_delay” option was missed – thereby overwriting the earlier input delay specification on this input.

d) Our integrated clock gating cells were causing the duty-cycle of the gated clock to be 25%, but the related constraints were specified with a default (50%) duty-cycle.

Example of incorrect division factor:

create_generated_clock -name Gclk -edges {1 3 5} -source [get_pin box_div_reg/q] [get_pins box_clk_icg_i/clkout]

As can be seen, issue (a) would have caused us issues during synthesis. Issue (c) might have also been caught during synthesis or STA.

However, issues (b) and (d) would not have been caught during synthesis or STA.

We used the default SpyGlass reports to identify these issues. These reports indicate the location of the RTL and/or constraints file – besides reporting the actual issue.

Constraint Generation

Since several issues were found in the user-defined constraints, we also investigated automating the process of constraint generation using SpyGlass-Constraints [2].

SpyGlass-Constraints can generate a set of SDC constraints with all the syntactical information, and the user completes the constraint generation process by providing:

• Actual numerical values for clock period, input-delay, etc.
• At some places where the tool is not able to take a “concrete” decision – prune out the candidate decisions offered by the tool, e.g. say, two ports get ANDed and the output of the AND gate drives a flop. Now, a clock has to be declared at either of the two ports – but the tool does not know which one. The tool presents these two ports as the candidate, allowing the designer to retain one, and prune out the other one.

We tried this capability on a block with about 250K gates. We gave the RTL description to SpyGlass, and used its clock-detection capability. SpyGlass identified 6 candidates for primary clock signals. We then pruned these candidates to remove “test” related clocks – as our immediate interest was only in functional mode clocks. This pruned list of clocks was again fed to SpyGlass-Constraints.

SpyGlass-Constraints came back with:

• A set of create_clock commands for these clocks
• A set of create_generated_clock commands for the corresponding generated clocks, which were being derived from these clocks. These commands had the right “source” etc. specified
• The SpyGlass GUI also opened up a spreadsheet, which allowed us to fill in:
• Clock period (for create_clock commands)
• Factors for divide_by/multiply_by (for create_generated_clock commands)

We then validated that all our flops have been constrained with clocks.

Now that we had our clocks constraints in place, we then invoked SpyGlass-Constraints again, to add set_input_delay and set_output_delay constraints in “incremental” mode. This made use of clocks already generated and validated – rather than doing everything afresh.

Once again, the SpyGlass GUI opened up a spreadsheet, which allowed us to:

• Quickly review the association of various input and output delays with the corresponding clocks
• Fill in the corresponding delay values – as per our design specification

Now that we have proven the constraint generation capability with this block, we are now applying this technique for several other RTL blocks, having a gate-count ranging from 200K to 300K.

Overall, we found the tool to be:

• A quick way to generate functional clocks and generated clocks
• A great way for the designer to review and refine the constraints, and to use that as a baseline
• A very simple and fast (<5 minutes) mechanism to complete the remainder of timing constraints

References

[1] Evaluate IP Timing Constraints Before Use in SOC Designs; Michael Robinson; SoCcentral – July 2006

[2] Timing Constraints Generation Technology; Ramesh Dewangan; EETimes – May 2007