ICC2：Design Planning（01）initial_DP

blog.csdn.net/m0_61544122/article/details/127564957

1.Create Design Library

The files needed for create_lib include reference library ( .ndm ), Technology File (.tf),
and parasitic parameter extraction rule file (.tluplus). The tech file and tluplus files can be
generated by the library manager tool as tech_lib.ndm.

1.1 Use tech file&& tluplus create_lib

create_lib -tech tech.tf -ref_lib "xx.ndm ... "

read_parasitic_tech -tlup cmax.tluplus -layer map layer.map -name cmax

read_parasitic_tech -tlup cmin.tluplus -layer map layer.map -name cmin

1.2 Use tech lib create_lib

create_lib -use_technology_lib tech.ndm -ref_libs "tech.ndm xx.ndm ..." ; #If you use -
use_technology_lib, tech.ndm needs to be put in the list of ref_libs.

Process reference for generating tech.ndm:    ICC2: tech only library

2.Read Verilog Outlines

1/22
Outline is understood as an outline. When the design is large and only for design
planning, timing analysis or optimization is not performed. Use read_verilog_outline,
and the loaded content is as follows:

read_verilog_outline will subtract the modules, turning some modules into "dense" and
others into "sparse".

dense module: Reserve the module port minus buf and inv, for small modules.

sparse module: Only hard macro is reserved, module port is not reserved, and it is
aimed at large modules.

ICC2 supports partition (default partition) and allocate to set the dense module and
sparse module of the top level.

2.1 Partition Method

read_verilog_outline -top ORCA {ORCA.V ...} -partition -glue_cell_count 10000(default)

-keep_port_depth -1 -target_block_size 1000000(default) ;#-keep_port_depth -1保留所
有module port。

The partition method works as follows:

1.Choose Partition Module

A.Leaf count > 1M -> identify as partition(sparse)

B.Leaf count < 1M, and hierarchical cell count > 1M -> dense+explore child modules

      •  Child leaf count > 1M -> identify as partition (sparse)

2/22
      •  Child leaf count < 1M ->skip

      •  Child hier. count > 1M ->go to (B)

C.Leaf and hierarchical count < 1M ->skip

2.Find Glue Modules (modules not defined as partitions / skipped)

A.Module cell count + total glue count < glue count target (100,000)

      • Mark module dense

      • Add cell count to total glue count

      • Repeat

B.Module cell count + total glue count > glue count target (100,000)

      • Mark module sparse

2.2 Allocation Method

 read_verilog_outline -allocation -top ORCA_IO {ORCA_IO.v BSLICE.v ...}   -

large_threshold (default: 10,000)  -target_cell_count (default: 1,000,000)

The allocation method works as follows:

By default, the TOP std. cells are preserved (dense). This is controlled using -depth
(default: 1).

Other modules are dense as long as:

The std cell count in the module < 10,000 (default large_threshold)

The total number of std cells < 1,000,000 (always excluding buffers/inverters)

3/22
Modules are sparse if:

The std cell count in the module > 10,000, or

The total number of std cells > 1,000,000

If depth=2, the same story occurs one level deeper. The top + first level modules are made
dense, regardless of their size. For all modules beneath, follow the conditions from above.

3.Create Initial Floorplan Shape

3.1 Create the Initial Floorplan

Set the boundary and the core area for std cell placement.

Example 1.

initial_floorplan -side_length {3700 3700} -core_offset {300}; #The default rectangle

only needs to input the length of both sides, core offset specifies the distance between core
boundary and die boundary.

4/22
Example 2.

initial_floorplan -boundary {xx xx ...} -core_offset {40}; #The tool supports custom
borders, and it is necessary to accurately input the coordinates of the outer vertices of the
boundary.

5/22
Example 3.

initial_floorplan -shape U -orientation W -side_ratio {3 1 2 2 1 2} -core_offset {40}; #The

tool template supports L-shaped, T-shaped, and U-shaped floorplans, and the user can
specify the direction, the length ratio of each side, etc.

6/22
4.Place IOS and Flip Chip Bumps

1) I/O cells are added after the initial floorplan.

2) The commands for Flip chip or Wire bound design plus I/O are the same.

7/22
4.1 Create Bump Cells
The bump cell should be added before place I/O. Adding a bump can read def, aif
(advanced input format, read_aif), and can also be created using create_bump_array.

It should be noted that all bump cells need the same lib cell.

create_bump_array

  -lib_cell bump_cell_name 

  -delta {dx dy} 

   [–name array_name]

   [–bbox { {x1 y1} {x2 y2} }]

   [-boundary {{x y} {x y} {x y}... }

   [–pattern inline | staggered_1 | staggered_2] 

   [–repeat {columns rows}]

   [–origin {x y}] 

   [–orientation N|W|S|E|FN|FS|FE|FW]

The -pattern option has three options, namely inline, staggered1 and staggered2.
Generally use inline to create signal bump, use staggered to create PG bump, PG mesh
will not have short. In the figure below, purple and green are used to represent P/G.

Examples are as follows:

8/22
4.2 Create I/O Guides

The place of the I/O cell needs to follow the I/O guide (create_io_guide or
create_io_ring).

Examples are as follows:

Both -line and -side in create_io_guide are required options, which respectively define
the starting point of I/O and the length of clockwise extension.

4.3 Set I/O Placement Constraints

This step is not necessary, the function is to control the position of I/O and adjust the
spacing. Use the command as follows:

set_signal_io_constraints \

-file constraint_file_name

or

set_signal_io_constraints \

-io_guide_object io_guide_name -constraint io_guide_constraints

Here -file and io_guide_object and -constraint are mutually exclusive and cannot be used
at the same time. It is easy to understand that constraint_file is to write io_guide and
corresponding constraints into a file according to a certain format, as shown in the
following figure.

9/22
As for, there are three ways of io place for io_guide and constraint constraints, namely
order-based constraints, location constraints and boundary-spacing control constraints.

1) Among them, order-based constraints have four definition methods, written as follows:

Order-only sequence (let the tool find the right position by itself)

   {{order_only} pad1 pad2 pad3 ...}

Space without any pads 

   {spacing_value}

List of pad names and spacing distances

   {pad1 space1 pad2 pad3 space3 pad4}

Pitch-based array（pitch是cell width加spacing）

   {{pitch} pad1 pad2 ...}

Writing examples are as follows:

-constraint {{80} {{55} d1 d2 d3} {10} {d4 40 d5 60 d6} {d7 d8}}

10/22
 2) location constraints

Using the relative position method, the io position obtained in this way is fixed, and the
writing method is as follows:

-constraint {{absolute} pad offset}

Where offset refers to the distance from the starting point in the io guide.

3) boundary-spacing control constraints

This method is to determine the relative position of the first or last io in the io guide and
the starting point or end point in the io guide, which can be used together with
order_based. The writing method is as follows:

｛no_space｝begin/end/both

Examples are as follows:

-constraint {｛{no_space} begin } {20 pad 45 pad2 pad3}

The first io is 20um away from the starting point of the io guide, the distance between the
first and the second is 45um, and the distance between the second and the third is 0.

There is a point to note here. The default direction of IO in place is R0. The
specific direction to use depends on the situation. You can use the following
commands to adjust the default orientation.

set_attribute [get_lib_cells xx/xx] reference_orientation R90

5.Place I/O Drivers

11/22
The place of I/O relies on the previous io guide and io constraints. When the position of
I/O is fixed, it can be connected to the bump or PG mesh with RTL.

The command used is: place_io

5.1 IO Driver Pad Pin

If you use flip chip encapsulation, you need to connect the IO Pad pin to the bump after
place_io, which requires the IO Pad pin to be defined as "CLASS BUMP" in LEF, and the
IO Pad pin attribute should be "is_pad = true ", but the properties connected to the core
or other IO pads are false.

 An example of an IO pad pin in Lef is as follows:

…

PADIO
  PIN
    DIRECTION
INOUT ;
    USE SIGNAL ;

    PORT

      CLASS
BUMP ;

      LAYER MRDL ;
        RECT 127.9990
4.0030 200.0000 36.0040 ;
    END

    …

5.2 RDL Path line Display

To view the flying lines of IO pad and bump, you can click to open the GUI:

View->RDL Flylines

5.3 Create Match type

If the connection between IO and Bump is not satisfactory, you can use match type to
redefine the connection relationship before place_io . Examples are as follows:

create_matching_type -name test [get_pins {A/pin} ] 

12/22
add_to_matching_type test [get_cells {bump1}]

The match type means that an object can only be connected with other objects of the same
match type. match type can also be used to connect hard macro and bump.

The create_matching_type -uniquify <value> option is required when multiple bumps

need to be connected to a pin, or multiple pins are connected to a bump. If value<0,
multiple bumps correspond to one pin; if value>0, multiple pins correspond to one bump;
if value=0, one bump is assigned to all pins.

Examples are as follows:

The three bumps of A, B and C correspond to the seven IO pad pins of ag, and now they
need to be redistributed. The rules are as follows: A allocates two, B allocates three, and C
allocates two.

13/22
 The command is as follows:

Step 1: Create matching types create_matching_type –name pn1 \ [get_pins {A/PAD

a/PAD b/PAD}] –uniquify 2

create_matching_type –name pn2 \ [get_pins {B/PAD c/PAD d/PAD e/PAD}] \ –

uniquify 3

create_matching_type –name pn3 \ [get_pins {C/PAD f/PAD g/PAD}] –uniquify 2

Step 2: IO placement to perform bump assignment place_io –matching_types {pn1 pn2

pn3}

Step 3: RDL routing route_rdl_flip_chip –layers $LAYER \ –nets VDD11

The corresponding pad pin and bump connections after reallocation are as follows:

To record the connection of match type, you can use the command
write_matching_type -from_existing_assignment -file_name mystery.tcl

14/22
6.Perform Hierarchy Exploration
Hierarchy exploration: Allows the user to determine which modules should be divided
into physical blocks by analyzing the module connection relationship by expanding the
logic hierarchy.

The main process is as follows:

15/22
6.1 Module Boundary Creation
It is recommended to click "initialize" to view the top level module first, then select the
module and click "expand" to expand the analysis. After the module boundary place, you
can also select the module boundary and then "expand". For example, some important
sub-modules need to focus on adjusting the position and size .

16/22
6.2 Module Boundary Placement

After the initial module boundary is created, the "Placement" section functions to see
where they are in the design. The user needs to choose whether to see an irregular straight
shape or a regular rectangle. The shape created for the module boundary is not the final
shape of the commit block, but it can estimate the block's position.

If the provided place scheme shows overlap. Means that logic from overlapping module
boundaries all expects place to be in the same region. This can cause congestion issues
and helps to issue issues ahead of time. An example is shown in the figure below.

Rectangular form:

 Rectilinear form:

17/22
There will be less overlap between the Rectilinear form module boundaries.

6.3 Connectivity Analysis

1）Net Connections

After the place module boundary, it is necessary to analyze the connection relationship
between them. The "Net Connections" tool is used, and the flying wire will display the
degree of correlation.

You can also open it yourself at View->Flylines->Net Connections .

18/22
In this process, if the position of the module boundary can be determined, you can set a
fixed attribute for it.

19/22
Then "Place All" again, the module boundaries of these fixed attributes will not be
passively affected, and the tool will refer to these fixed module boundaries to place again.

2) Data Flow Flylines

Open Data Flow Flylines or View->Flylines->Data Flow Flylines in the Hierarchy

Exploration task .

In addition to Net Connections, the tool also has a tool "Data Flow Flylines" for viewing
connection relationships. You can view the logical relationship outside the buffer. The
"Aggregate" mode is used by default. In this mode, the connections of the pins are
aggregated into flying lines.

DFF can trace registers (preferably level 5), combinatorial logic other than buffer (up to
level 100), and fanout with an upper limit of 256. Users can choose a maximum value for
calculation, and then use a smaller value for later analysis.

20/22
7.Commit the Blocks

7.1 Commit Block

Commit block is an independent step, and commit means converting logic hierarchy into
physical sub-block.

If you use the command, the reference command is as follows:

commit_block "block name"

The block name is used here, but the module is operated, so it is necessary to obtain the
ref name corresponding to the module. The method is as follows:

commit_block [get_attribute [get_cells module_name] ref_name]

Or click "To Blocks" directly in the Hierarchy exploration task.

Examples are as follows:

In the figure below, A, B, C, M, and U all need commit blocks.

21/22
The corresponding command is: commit_block "ABCM U", where M does not need to
commit twice.

7.2 Commit into Separate Libraries

With the help of the above example, save the commit block to the new lib, the reference
command is as follows:

copy_lib -no_designs -to_lib C.lib

copy_lib -no_designs -to_lib M.lib

set_attribute [get_libs "TOP.lib C.lib M.lib"] use_hier_ref_libs true

set_ref_libs TOP.lib -add ./C.lib 

set_ref_libs C.lib -add ./M.lib

commit_block -library M.lib "M"

save_block -hierarchical -label initial_design

22/22