Synopsys Insight Newsletter 

Insight Home   |  Previous Article   |   Next Article

Issue 1, 2012

Technology Update
Constraint Analysis Makes For More Predictable Tapeout

How can design managers save weeks of engineering time without disrupting their design flows? Bernadette Mortell, director of marketing for PrimeTime Suite, Synopsys, explains how a growing number of design teams are using look-ahead timing constraint analysis to reduce the risk of unexpected delays.

The relentless increase in System-on-Chip (SoC) design complexity is forcing many design managers to look for new ways to make the tapeout process more predictable. One way to do this is to ensure that all of the timing constraints inputs are as “clean” as possible as early as possible in the life of the project. This approach makes it less likely that unexpected timing violations will delay the tapeout. Inconsistent, incomplete or conflicting timing constraints can create problems for downstream tools, which can cause them to run inefficiently or never converge. Modifying one constraint to fix a problem on a particular timing path can affect many other timing paths, which means that identifying the root cause of a constraint problem is critical. Manually identifying constraint issues from timing reports is error prone and can take hours, or even days, with potentially catastrophic consequences for the design tapeout schedule.

To be more effective, design teams have to ensure that once the input timing constraints are clean, they don’t subsequently introduce new errors as the design progresses.

By cleaning up constraints early, design teams can focus on getting the best possible performance from the design, rather than wasting engineering time having to find and resolve unexpected timing violations.

The Constraint Complexity Problem
Implementation and signoff tools rely on design timing constraints at almost every step of the design process. Unfortunately, the complexity of constraints has grown as process geometries have shrunk, and the number of constraints that design teams have to manage has exploded inline with chip complexity. Timing constraints files can contain hundreds of thousands of lines of code.

Figure 1
Figure 1: Faster signoff with better constraints.
Galaxy Constraint Analyzer makes minimal changes to the existing flow, and uses existing scripts (SDC or Tcl) from Design
 Compiler, IC Compiler and PrimeTime. It can be used for block level design and chip level design through all phases of the
process, including design planning and budgeting, chip integration, place and route, and final signoff.

During the course of a project, design teams may face situations where timing constraints are:
  • Missing
  • Incorrect
  • Conflicting
  • Over-constraining
  • Redundant
  • Inefficiently written (creating long runtimes in the implementation and signoff tools)

Some design managers depend on the skills of their designers to avoid these problems. Overseeing constraint generation and problem diagnosis is the responsibility of the most experienced designers on the team and they have to be constantly involved in the constraint refinement process, which reduces the time they have to work on other critical tasks, e.g. improving overall chip performance.

The experience of the designer impacts the quality of the design constraints, but sometimes, the source of the design constraints file is outside the design manager’s control. For example, this might happen when the project uses third-party intellectual property (IP) or requires collaboration with an external design team.

Some design managers choose to delay the process of cleaning up constraints until the point where the design has been mostly completed and bad constraints are beginning to impact the timing results. They try to find and fix constraint issues on a case-by-case basis, but this is a high-risk strategy because it puts more time pressure on the back-end of the design schedule closer to tapeout, when constraint issues can take an indeterminate amount of time to fix. By this time, it is possible that the design team has already performed optimizations using bad constraints, which may take a lot more time to correct.

What is Constraint Analysis?
While Static Timing Analysis (STA) tools, like Synopsys PrimeTime, will tell the design team that a design has failing paths, tracing that information back to a problem with a timing constraint requires manual intervention. The design team must decide from the STA report whether a failing path is due to a bad netlist implementation or a problem with a timing constraint.

Constraint analysis tools help designers to find and fix the root causes of timing constraint problems at the start of the project and whenever changes to the constraints are made. Synopsys’ Galaxy Constraint Analyzer boosts designer productivity by using look-ahead constraint analysis technology. This technology, which is based on the PrimeTime “golden” timing engine, propagates timing constraint information through the gate-level netlist and checks for structural compliance of the timing constraints with downstream tools like IC Compiler and PrimeTime itself. This approach gives designers a signoff-correlated view of the timing constraints early in the design process, reducing design iterations due to bad constraints.

Galaxy Constraint Analyzer: Fast Timing Constraint Analysis
The ability to use existing PrimeTime STA timing constraint scripts allows design teams to be up and running almost immediately with Synopsys’ Galaxy Constraint Analyzer. Its setup is compliant with other Synopsys implementation tools, and it uses the same interpretation of timing constraints as the Synopsys PrimeTime timing engine to check that constraints are structurally compliant with the downstream tools that will use them. Less experienced designers benefit from the direct and actionable feedback that the tool provides, enabling them to easily find and fix problem constraints and freeing up the more experienced designers to work on other tasks.

Galaxy Constraint Analyzer is fast and can analyze multi-million instance designs in minutes and tens of millions of instances in a few hours. Customers have reported the ability to run constraint analysis 3-4 times in the time it takes to run a single STA analysis, in part because constraint analysis does not have to perform delay calculations in order to analyze the design. It also manages memory efficiently, which enables the tool to handle complete designs. This is important because many constraint issues occur when the design team integrates the lower-level blocks into the top-level. For example, if a designer has incorrectly named a clock, the block-level clock constraint does not correspond to the top-level reference clock, so parts of the design will become untimed. Galaxy Constraint Analyzer helps design teams maintain block-to-top constraint consistency throughout a project, and also helps to ensure that the behavior of two sets of constraints remain equivalent when they are edited, modified, combined or simplified.

Table 1
Table 1: Runtime and memory use for a range of designs

Once the Galaxy Constraint Analyzer constraint analysis run has completed, designers can view any violations reported in the violation browser. This provides helpful debug information with likely reasons for the reported problem. Clicking on the “execute and show” link in the report will show a context-specific schematic that includes the cells in the violating portion of the design netlist with annotations showing where the violation has been detected and the probable source of the violation. This is a very simple and intuitive way to review violations when compared to the alternative approach of using STA where the only information available to the user is the output timing reports and STA log files. Galaxy Constraint Analyzer avoids duplicating reports of violations.

Galaxy Constraint Analyzer checks constraints against over 100 built-in rules. Significant effort has been made to ensure that each rule identifies real constraint issues and that duplicate reports of violations are not generated as a result of multiple rules flagging a violation from several different perspectives. This was a common problem with the first generation of commercial constraint analysis tools. It was one of the reasons that many experienced designers chose not to use first-generation technology. They had to spend a great deal of time sifting through the thousands of duplicate violations generated without any assistance from the tool to find the root cause of the violations reported. Another omission of the first generation of constraint analyzers was the ability to allow designers to easily define their own custom rules. With this capability available in Galaxy Constraint Analyzer, design teams can create rules that reflect best practice for their particular design application, which may not be a common practice among all applications. These custom rules can be added or deleted at will and eliminate the delay of waiting for the next official release of the software from the tool provider.

Table 2
Table 2: Some of the built-in rules checked by Galaxy Constraint Analyzer

Beyond Single Design Analysis
Block-to-top analysis allows design teams to verify that block-level constraints are correct in the context of the chip – identifying issues such as conflicts with chip-level constraints that would not be visible during block-level analysis.

SDC-to-SDC constraint checking allows design teams to ensure that constraints remain equivalent as they undergo change (original Tcl constraints vs. tool-generated SDC for the same design, for example).

Table 3
Table 3: Rules table for block-to-top checks

Constraint Examples
The following constraint examples help to illustrate the way Galaxy Constraint Analyzer handles real designs.

Case Study 1
In this case study, a generated clock has been defined incorrectly. Galaxy Constraint Analyzer reports that the defined characteristics of the generated clock do not reflect its actual behavior in the circuit. Figure 2 describes the logic related to the generated clock.

Figure 2
Figure 2: Logic for case study 1

The source and generated clocks are defined as follows:

        create_clock –name clk1 –period 2 [get_ports CLK1] \
–waveform {0.5 1.25}
create_clock –name clk2 –period 10 [get_ports CLK2]
create_generated_clock –name gclk1 b2/mux/Z \
–source [get_ports CLK1] \
-combinational –master_clock clk1 –add

Galaxy Constraint Analyzer reports the following error:

        Generated clock ‘GCLK1’ has edge relationships with its master
clock ‘CLK1’ that cannot be satisfied. Only paths with a negative
sense exist from the master clock to source pin ‘b2/mux/Z’. A
‘positive’ sense is expected.

When such an issue is encountered, there is a risk that the generated clock waveform will be incorrect, the necessary source latency paths might be disabled, and the propagated latency may not be able to be computed. These problems can lead to incorrect and/or unexpected timing results.

Case Study 2
In this second example, Galaxy Constraint Analyzer is being used to ensure that the timing constraints defined for block-level implementation and analysis are consistent with those defined for the top level of the design. The key parts of the circuit related to the constraints being compared are captured in Figure 3.

Figure 3
Figure 3: Logic for case study 2

In this case, the set_case_analysis constraint has been used at both the block and top-level on the port ‘MODEB’ as follows –

Block-level constraint file:

          set_case_analysis 1 [get_ports MODEB]

Top-level constraint file:

          set_case_analysis 1 [get_ports MODEB]

When these two sets of constraints are analyzed, Galaxy Constraint Analyzer reports that there is a mismatch between the value set on the b1/MODEB port and the value that actually propagates to it from the top level. As can be seen from the schematic above, the value of ‘1’ set on the top level MODEB port is propagated to the MODEB port on the b1 instance as a ‘0’. This is in conflict with the block-level constraint that forces this port to ‘1’.

The risk of this conflict is that the block level will not be analyzed under the same conditions as it was created. This might result in inaccurate analysis coverage or even incorrect behavior for the block or the full chip. This is a great example of how Galaxy Constraint Analyzer quickly identifies an issue that may otherwise be very difficult to diagnose.

Project Highlights
Many design teams are benefiting from using Galaxy Constraint Analyzer on their SoC designs. The following project highlights quantify some of the key benefits for three customer projects.

Profile: Digital technology development group
  • Reduced constraint clean-up time by 50%
  • 6x faster, using 3.8x less memory than alternative solution
  • Best correlation with signoff tools
  • Efficient debugging: ability to analyze clock networks, data paths, unclocked pins, and report details of constant propagation
Profile: Home entertainment electronics
  • Iteration time between front- and back-end design teams reduced from days to less than 30 minutes
  • Detected problems that were previously only found at signoff
Profile: Graphic Processing Unit (GPU) design group
  • Completed analysis of an 80 million instance design in 3 hours using 70GB of memory
  • Constraint “scrubbing” turnaround time reduced from days to hours
  • Ran Galaxy Constraint Analyzer every time an engineer modified the constraints
  • Deployed across other groups

Galaxy Constraint Analyzer helps design teams clean up their timing constraints at the start of the design and keep them clean throughout the duration of the project. This approach reduces the risk of project delays as a result of surprises at the implementation and signoff phases. Galaxy Constraint Analyzer is easy to deploy within Synopsys flows and fast to run with efficient use of memory. It reduces design risk by making design schedules more predictable, and lets designers spend more time on optimizing and differentiating their designs and spend less time on chasing and fixing timing constraint issues.

More Information:

About the Author
Bernadette Mortell
Bernadette (Bernie) Mortell is the marketing director for the PrimeTime Suite at Synopsys and drives the development and deployment of Timing and Constraint Analysis products. Prior to Synopsys, she was in the applications and marketing team at Compass Design Automation working on Place and Route and Floorplanning tools, and worked for 10 years as a Physical Design Manager on Data Converter, Amplifier and Linear products and DSP Processors at Analog Devices in Ireland.

Having read this article, will you take a moment to let us know how informative the article was to you.
Exceptionally informative (I emailed the article to a friend)
Very informative
Somewhat informative
Not at all informative