Hierarchical Design App Note-edit

Best Practices for Design Compiler topographical mode-IC Compiler Usage in a Top

Level Flow

1

Hierarchical Design:

Best Practices for Design Compiler

Topographical and IC Compiler Usage

In a Top-Level Flow

Kevin Knapp IC Compiler Engagement CAE

Version: 1.1

April 21, 2009


Level Flow

2

Contents

1. Introduction

2. What is Hierarchical Design?

3. Key Issues

4. Summary


Level Flow

3

Introduction

The purpose of this document is to capture significant design flow issues for hierarchical

designs that might have been overlooked or remained undetected in earlier discussions of

the subject. It is not intended to be read as a comprehensive treatment of hierarchical

designs.

The content of this document is based on the content and capabilities of the B-2008.09

Galaxy Flow. If you are using a different tool suite, some changes might be necessary.

However, it is anticipated that much of the content will still be applicable.

What is Hierarchical Design?

There are many concepts of what hierarchical design is and there are many flows that

include these concepts.

For the purpose of this document, the hierarchical design flow is confined to the

implementation portion using Design Compiler topographical mode and IC Compiler. In

terms of the physical hierarchy, the top-level of the design contains one or more logic

blocks, a measurable amount of combinational logic and registers, and numerous

memories or other hard macro IP. The logic blocks are implemented through Design

Compiler topographical mode and IC Compiler and are then modeled as interface logic

models (ILMs). ILMs can be generated by either Design Compiler topographical mode or

by IC Compiler. These ILMs are used for top-level synthesis in Design Compiler

topographical mode and physical design in IC Compiler. It is expected that IC Compiler

ILMs will ultimately be used for final top-level implementation in order to achieve the

best predictability and correlation between Design Compiler topographical mode and IC

Compiler, as well as best overall quality of results (QoR).

A floorplan and design constraints exist for the top level and budgeting for the blocks is

accomplished in the flow.

In such a flow there are many considerations and complexities; not the least of which is

the creation of floorplan information for the blocks and the notion of successive

refinement to enable concurrent design in a spiral design flow. There are specific

technologies to address these issues, such as virtual flat floorplanning and others. These

technologies will not be specifically addressed here as they have already been covered in

other documentation. Rather, this document will cover key issues as these different

technologies merge and come together for implementation of the top-level of the design

through Design Compiler topographical mode and IC Compiler.


Level Flow

4

Key Issues

Handling ILM Blocks in the Top-Level Netlist and SDC File

When writing out the top-level netlist or .ddc file from Design Compiler topographical

mode for use in IC Compiler, care must taken when handling the ILM blocks. These

blocks should not reside in the .ddc that will be used by IC Compiler. Rather, according

to the IC Compiler Reference Methodology (RM) flow, IC Compiler should get its

definition for these blocks from their Milkyway ILM view described in the Milkyway

reference library.

If the ILM blocks are retained in the Design Compiler topographical mode .ddc format,

IC Compiler receives two definitions of the block; one is found in the .ddc and the other

is found in the Milkyway reference library. Therefore, there can be ambiguity about the

information and representation that is actually used. Given that the ILM view contained

in the Milkyway reference library is to be used, the block in Design Compiler

topographical mode should be removed prior to writing the .ddc. You can do this by

using the remove_design -hier [get_designs ILM block name

command.

There are side effects that must be recognized and managed when removing the ILM

designs in Design Compiler topographical mode. There might be constraints applicable to

the top level that originates from within the ILM block (timing exceptions, for example,

among others). These constraints are lost when the block is removed. Therefore, the

Synopsys Design Constraints (SDC) file must be written prior to the removal of the

ILMs, so that such constraints are retained. This SDC file should then be used any time

the .ddc is loaded, either in IC Compiler or reloaded in Design Compiler topographical

mode for analysis, for debugging, or for further implementation work.

Note that this requirement to use the SDC file may run counter to the typical usage

established in the IC Compiler Reference Methodology. For example, if the .ddc file is

used as the input format to IC Compiler, the SDC file will not be read by the standard

scripts because the expectation is that all the necessary design constraints will be found in

the .ddc file. However, given the situation described in the preceding paragraphs, this will

not be the case and the SDC file must be read in addition to the .ddc file.

Handling Timing Derating Factors

To achieve optimal results and good correlation between Design Compiler topographical

mode and IC Compiler, it is imperative that both tools use the same timing derating

factors. Per the issues described previously, the expectation is that the communication of

these timing derating factors is done through the SDC file. However, the handling of

timing derating in SDC files is targeted for PrimeTime usage. Therefore, the SDCs

written from within Design Compiler topographical mode might not represent in total, the


Level Flow

5

timing derating that was in place for synthesis, and therefore, the constraints might not

represent the timing derating that is needed for timing-driven physical design in IC

Compiler.

This is remedied by following three-step process, which is applied after the design has

been read in through the .ddc or by other means.

1) Read the SDCs to apply and establish the design constraints in general.

2) Reset the timing derating by using the reset_timing_derate command.

This will effectively “wipe the slate clean” of any timing derating seen by the

tool, establishing the same context in which the timing derating was initially

applied in Design Compiler topographical mode. This is important because some

of the timing derating factors apply in cumulative fashion versus simply replacing

previously established values.

3) Apply the timing derating constraints you desire, the same ones that were applied

in Design Compiler topographical mode. Note that there might be timing derating

settings in the IC Compiler Reference Methodology scripts. Of particular note are

the common_optimization_settings_icc.tcl and

common_post_cts_timing_settings.tcl scripts. Be sure to handle

these as well. It is probably best to simply remove the timing derating from these

scripts and establish the desired design-specific timing derating in a dedicated

script of your own.

Note that this process is necessary whenever you are applying SDCs in Design Compiler

topographical mode or in IC Compiler. It is a good idea to report timing derating

constraints prior to compilation through the report_timing_derate command in

Design Compiler topographical mode and through the place_opt command in IC

Compiler. These reports should then be compared to ensure the same timing derating

factors are used. It is also a good idea to do the same reporting and comparison in any

reload scripts you might have for Design Compiler topographical mode or IC Compiler

before doing additional implementation work, debugging, or analysis.

Recreating Timing Achieved in Batch Mode Compilation

Any debugging or analysis work in Design Compiler topographical mode should begin

with the recreation of the timing that was obtained during compilation. That is, a QoR

report obtained from the interactive session used for debugging should match the report

obtained from the Design Compiler topographical mode session used for compilation.

This will help ensure that you are debugging or continuing implementation in the same

context used for the compilation.

For the reasons described in the previous section “ILM Block Handling in the Top-Level

Netlist and SDC File,” the ILMs were removed from the top-level design prior to writing

the .ddc, so these designs must be linked back in. This is done in different ways

depending on whether a Design Compiler topographical mode or IC Compiler ILM is

being used. In any case, the interface timing between the ILM block and top-level logic,


Level Flow

6

and the associated interconnect parasitic loading, must be reestablished. To do this, you

must run the extract_rc -estimate command in Design Compiler topographical

mode prior to performing timing analysis. You should not expect any timing analysis

performed prior to relinking the ILM designs and running the extract_rc –

estimate command to match the results obtained in the session used for compilation.

Cells Instantiated in Floorplan DEF File

Specific logic cells can be instantiated in the floorplan DEF file, often as fixed-placed

cells. These cells can serve as interface cells between the top level and the blocks. Thus,

you might need to control their location. There might also be cells used for special

functions, such as isolation cells or level shifters, that are required for multivoltage

designs.

In the process of refining the netlist, the reference names for these cells can change as

different drive strengths or minor functional changes are made. Often, these changes

might not be reflected in the floorplan DEF file and in the cells instantiated therein.

Therefore, this might result in a situation where the cell reference in the floorplan DEF is

different from that in the GTECH or structural netlist used as input to Design Compiler

topographical mode. Fuzzy name matching in Design Compiler topographical mode will

typically enable Design Compiler topographical mode to proceed and recognize these

cells, honoring whatever characteristics they have in the DEF file, that is, the fixed

placement.

However, IC Compiler does not use fuzzy name matching, nor does the macro name

translation utility, , identify these cells because of the

difference in the reference name between the floorplan DEF file and the logical netlist or

.ddc used as input to IC Compiler. This results in a fundamental difference in the physical

constraints seen by IC Compiler versus Design Compiler topographical mode. Design

Compiler topographical mode recognizes the cell and its attributes (fixed placement, in

our example). IC Compiler does not.

IC Compiler actually ends up with two instances of the cell: one of them coming from the

netlist as received from Design Compiler topographical mode and another received from

the DEF file created as a “physical only” cell connected to nothing. Because the cell

coming from the netlist does not have the fixed placement attribute on it, IC Compiler is

free to place it anywhere. However, in Design Compiler topographical mode the

placement of the cell was constrained by the fixed placement attribute in the DEF. This

difference can result in significant differences in timing between Design Compiler

topographical mode and IC Compiler. In our example, interface timing between the ILM

block and top-level logic is affected.

The optimal solution is to obtain an updated, corrected floorplan DEF file. However, this

may not be realistic for various reasons, such as magnitude of changes and schedule

impact. A potential workaround is to extract the physical constraints for such cells from


Level Flow

7

the output of the extract_physical_constraints command and then apply

these in IC Compiler. However, this can be cumbersome and error-prone and is therefore

not recommended. If you have only a small number of cells in the DEF that are affected

in this way, you can just create the necessary physical constraints in a TCL file.

However, some designs may have thousands of cells so affected.

Figures 1 and 2 illustrate this point. In Figure 1, Design Compiler topographical mode

recognized and honored the fixed placement attribute in the DEF file, though in this case

it was nonoptimal, resulting in a long transition time and poor overall path timing. Figure

2 shows the IC Compiler placement. IC Compiler, unencumbered by the nonoptimal

fixed placement attribute on the cell, placed the cell more sensibly, resulting in much

improved timing versus Design Compiler topographical mode.

Figure 1. Interface logic cell placement in Design Compiler topographical mode.

630um net length, ~2ns transition time


Level Flow

8

Figure 2. Interface logic cell placement in IC Compiler.

30um net length, ~0.5ns transition time

Using Soft Blockages Within Design Compiler topographical mode and IC Compiler

This item is not unique to hierarchical design and may be pertinent to the general

correlation between Design Compiler topographical mode and IC Compiler. However,

hierarchical design offers greater opportunity for this issue to occur because the physical

hierarchy often results in greater usage of soft blockages.

One of the reasons for soft blockages is to keep registers out of small, hard-to-reach

placement regions, thereby helping to prevent an unreasonable situation for balanced

clock tree synthesis. While it might be desirable to keep registers out of these areas,

buffer and repeater cells as well as combinational logic can be placed in these areas to

achieve connectivity and optimal timing to logic on the other side of the blockage. A

typical example would be narrow channels between ILM blocks or hard macro IP blocks

that are used to bring a signal to or from a pad cell or port. Accordingly, repeater cells

(that is, buffers and inverters) might need to be placed in the narrow channel soft

blockage region.

For these situations it is best if Design Compiler topographical mode and IC Compiler are

able to use the soft blockages in similar ways. The following variables are applicable in

both tools and it is recommend that you set them appropriately according to the intentions

for the soft blockages in your design. If you need to allow repeater cells (buffers and

inverters) to be placed in soft blockages, set

placer_allow_repeaters_over_soft_blockages true. If you want to allow


Level Flow

9

any combinational cells in the soft blockages, set

placer_allow_combinational_cells_over_soft_blockages to true.

Figures 3 and 4 illustrate this point. The soft blockage region is highlighted in each

figure. Figure 3 shows the path flylines when repeaters are not allowed in the soft

blockage. Figure 4 shows the path flylines after

placer_allow_repeaters_over_soft_blockages is set true. Clearly, the

timing will be much better for the path in Figure 4 since it does not have to circumvent

the large hard macro.

Figure 3. IC Compiler flylines for path Figure 4. IC Compiler

flylines for path

avoiding soft blockage utilizing soft blockage

Summary There are many complex issues associated with hierarchical design. This document has

covered some of those issues and their resolutions that were not covered in previous

documentation.

Hierarchical Design App Note-edit

Documents

Transcript of Hierarchical Design App Note-edit