Constraints and hierarchical designs

To understand how constraints interact with other factors in a hierarchical design methodology, consider how such a methodology works. The basic premise is simple. By dividing a design into multiple blocks, each hierarchical block can be worked on individually and in parallel, from RTL through physical implementation. Working with smaller blocks keeps tool runtimes short. In addition, block-level timing closure and test insertion should be relatively easy to achieve compared to the timing closure and test insertion for the entire chip in a flat optimization approach.

Once timing closure has been achieved on all the hierarchical blocks, these blocks are integrated to create the final chip implementation. To speed up the process on larger designs, you can model the blocks as black boxes. (These black-box models may be Interface Logic Models or Extracted Timing Models, which can include timing, physical, test, interface and I/O information.) Final timing closure is more assured on the first iteration because block-level timing has already been met; only the inter-block connections may need to be analyzed and optimized.

Figure 1, below, shows a simplified physical design flow for hierarchical design. Note that the hierarchy referred to in "hierarchical design" is physical hierarchy, which differs from logical hierarchy. The latter is based on the function of the design modules/blocks, which is usually determined by the designers and their HDL coding methods.

Physical hierarchy is based on back-end considerations such as cell placement, I/O placement, macro placement, interconnect routing and associated timing issues. The two hierarchies therefore may not have much in common. Whatever the correlation, it is necessary to evaluate placement/timing issues as part of design planning to determine how to group cells in the logical hierarchy into physical hierarchical blocks to reduce the time needed to achieve timing closure. This process of design planning or floorplanning gets more critical in very deep submicron (VDSM) designs.

The key part of design planning for efficient hierarchical design is to set block-level physical and timing constraints that allow parallel implementation of each block. The better the constraints, the easier it is to integrate the blocks (sometimes referred to as sub-chips, sub-blocks, lower-level blocks, modules or hierarchical blocks) and achieve overall timing closure. Good constraints thus enable a hierarchical flow that reduces design turnaround times and permits predictable schedules for timing closure.

The traditional flat submicron flow avoids the effort to set up hierarchy, but carries a higher risk of having to iterate all the way back to the architecture of the design to correct timing problems that appear after routing. The flat submicron flow is also subject to memory limitations and long run times in multi-million-gate designs. Establishing a hierarchical flow enables you to achieve timing closure of multi-million-gate designs efficiently and make incremental functional and timing fixes of individual blocks after timing closure.

Although the general idea of this design approach is fairly simple, the details are often challenging. Setting appropriate constraints is among the most challenging tasks.

Setting physical constraints

Physical constraints define the size, shape, utilization, and pin/pad placement. of a design. You can specify these constraints based on utilization, aspect ratio and dimensions of the die, and shape of the design. The pin/pad placement depends on the physical external environment of the design.

For hierarchical designs, you apply the physical constraints to the chip and then develop the shape/size of the hierarchical blocks (propagated down). In a bottom-up hierarchical approach, you apply the physical constraints to the hierarchical blocks, then develop the top/chip-level physical constraints (propagated up).

After grouping cells into hierarchical blocks, you derive each block's physical constraints from top-level floorplanning. Figures 2, 3 and 4 show the progression in floorplanning from the initial logical hierarchy to the physical hierarchy and associated physical constraints. These constraints include size, shape and pin placement. The blocks' internal physical constraints, such as memory placement, blockages and regions, can be defined locally in the same way as in a flat design.

The top-level physical constraints include block placements and inter-block repeater distributions. It usually takes a few iterations in floorplanning to derive high-quality physical constraints for the blocks and top level. These iterations typically include both top-down and bottom-up approaches.

In the top-down approach, top-level design specifications such as die size, shape and pin positions drive block partitioning, size, shape and placement. In the bottom-up approach, the size, shape and pin positions of off-the-shelf hard IP macros usually drive the top-level floorplanning.

Somewhere between the extremes of the ideal top-down and bottom-up approaches lie the various real-world methodologies that work for different designs. For example, you can obtain initial gate count estimates for top-level chip size estimation by executing a quick synthesis of the soft macros in a design, even though these macros might not have been finalized in RTL.

For incomplete or missing blocks, you have to rely on judgment and experience to estimate sizes based on design characteristics and inter-block connections. Conservative design practice experience has shown that time can be saved if you add margins to the initial estimated chip and block sizes.

Setting timing constraints

Typically for hierarchical designs, you apply timing constraints to the chip level and develop hierarchical-block timing constraints in a top-down and bottom-up iteration process. The process of budgeting (developing hierarchical-block timing constraints) is an invaluable step in a hierarchical design methodology, and budget accuracy is critical.

Design experience has shown that the necessary accuracy is best achieved after floorplanning, because then you get a good estimate of the hierarchical blocks' physical pin locations and thus an accurate picture of the top-level block interconnectivity. Additionally, if the design can be routed (global or detail), you can get even more accurate budgeting results.

The value of the budgeting process in hierarchical designs lies in the timing constraints developed for the hierarchical block I/Os. In a hierarchical block, the clock frequency constrains register-to-register timing. However, you constrain the I/O paths according to the budgets calculated by determining the path delay through the hierarchical I/O pins and the logic at the design's top level.

Figure 5 illustrates a potential timing path in a hierarchical design. Each hierarchical block's budgets take into account the delay through the logic clouds not in that hierarchical block, to set a valid input/output timing constraint.

Conservative design practice experience has shown that it is a good idea to add enough timing margins to the derived block budgets to cover inaccuracies in early stage design and inter-block interconnect timing estimations.

For a mostly top-down flow, you can use static timing analysis or synthesis tools to help generate block-level constraints from a set of chip-level constraints. For a simplified example of this process, consider two lower-level blocks and one timing-critical signal that passes through both of them.

Say that the tool shows a 5-ns path delay through block A (from input register to output register) and the same path delay through block B, with 1 ns of interconnect delay between the blocks. If these blocks use a clock that has a 10-ns period, the 11-ns total for the path will violate timing. Based on this information, you can over-constrain the timing-critical path in synthesis (by 10 to 20 percent) to help achieve timing closure.

Best practices in developing timing constraints

Take care to avoid placing unreasonable timing constraints on the design. Such constraints cause the synthesis tool to waste time applying a number of strategies iteratively before it gives up.

As a general rule, keep timing constraints as simple as possible. The more constraints that are applied to the design, the more time the tool takes for optimization and analysis. Often an RTL designer passes constraints to someone who actually runs the synthesis tool. When the RTL designer changes part of the design and forgets to remove an associated constraint, unused and unapplicable constraints can accumulate.

At a bare minimum, a design will have clock constraints, and input and output delay constraints. As a design gets more complicated, you may tend to add exception constraints. However, the fewer the exceptions the better in terms of tool run time.

To reduce the number of exception constraints, experience shows that it is good design practice to consider the necessary constraints earlier in the design cycle, while you are writing the RTL. For example, if a design has multiple clocks, it is generally advisable to partition the design into its respective clock domains. Logic in two or more domains may work together to accomplish a single task, but it is a good idea if possible to write all the RTL for a particular clock domain in one block.

This practice enables clearly defined interface logic between the clock domains, and you can more easily set constraints on the blocks. Today's tools can handle multiple clock optimizations and analysis, but the general rule of keeping constraints simple holds true to reduce tool run time.

Here are some general rules to keep constraints simple:

• Whenever possible, avoid setting exceptions (multi-cycle or false paths). You can avoid exceptions through good partitioning and planning of the design.
• Use case analysis to set the design into different modes of operation for easier timing analysis. For example, run an analysis in scan mode.
• Keep optimization and sign-off timing constraints separate. Optimization constraints tend to be pessimistic for added margin. Sign-off static timing analysis constraints need to be more accurate to realize the margins.

To achieve timing closure, it is essential to have good correlation between the placement optimization timing and post-layout timing. A good practice is to conduct a placement vs. post-layout wire RC and timing correlation study. Such a study is based on the results of a "pipe-cleaning" timing closure commonly performed in the early stage of a design to test the flow, library, and environment. You can use the correlation study results for purposes such as tuning the wire-routing models used in placement optimization.

Design experience shows that long wires often cause poor placement and post-layout timing correlation, especially when weak cells drive these wires. Such wires are often present when placement includes library cells that are modeled with large maximum capacitance. You can resolve this issue by ranking the library cells according to their impact on post-layout timing and then scaling down the maximum-capacitance values the cells can drive. Experience with the library helps in determining how much to reduce the maximum-capacitance values.

Another option is to set slightly pessimistic maximum transition time and maximum fanout constraints on the design in the placement optimization. These conservative design rule constraints prevent long nets in the layout and thus minimize crosstalk problems.

Designs that have multiple operating modes, or a special test mode, present special challenges to design optimization because placement optimization tools do not optimize the design simultaneously in multiple modes. The constraints used in optimizing the design in one mode may mask the timing constraints in paths that are not part of that mode.

You can resolve this issue by removing the constraints that mask timing paths in other modes to let the tool optimize as many paths as possible. When two modes share a path that runs at different clock speeds, let the tool optimize the path with the worst-case constraints. In some cases, these worst-case constraints may over-constrain the paths, causing reports of false timing violations that cannot be fixed in the optimization. To handle these cases, you can define local constraints to isolate the problematic paths from the mode in which the design is optimized.

Vijay Gullapalli is currently a Senior Design Consultant with Synopsys Professional Services. He has over 8 years collective experience in the ASIC industry, and over 5 years in design consulting. He can be reached at gvijay@synopsys.com.