bpv impact on zroute qor (1)

Synopsys 2013 1

BPV Impact on Zroute QoR

Router CAE

January, 2013

Synopsys 2013 2

CONFIDENTIAL INFORMATION

The following material is being disclosed to you pursuant to a non-disclosure agreement between you or your employer and Synopsys. Information disclosed in this presentation may be used only as permitted under such an agreement.

LEGAL NOTICE

Information contained in this presentation reflects Synopsys plans as of the date of this presentation. Such plans are subject to completion and are subject to change. Products may be offered and purchased only pursuant to an authorized quote and purchase order.

Synopsys 2013 3

Agenda

BPV Fundamentals

Design rule resource

Case studies:

Open nets

Runtime speedup by multiple isDefaultContact

M1 violations when accessing pins

Fat spacing found over macro

Fat spacing NOT found over macro

NDR spacing

Synopsys 2013 4

BPV Impact on Design Stage

Data

Preparation

(FRAM)

Placement Routing

Synopsys 2013 5

Library Data Preparation

MW Library

CEL FRAM lib_1, lib_2, lib_3

GDSII or LEF

Stream File

Synopsys 2013 6

Library Data Preparation (Milkyway)

Create library with

Library > Create

Import layout cell with

Cell Library > Stream In

Identify P/G ports with

dbSetCellPortTypes

Smash cell with

Cell Library > Smash

Extract blockage, pins & vias with

Cell Library > Blockage, Pin & Via

Set PR boundary with

Cell Library > Set PR Boundary

Define wire tracks with

Wire Tracks >

Define Unit Tile Wire Tracks

Specify Multiple-Height PR Boundary

Cell Library > Multi Height Cell

Import Logic Model DB

update_mw_port_by_db

End cell library data preparation Technology

File

GDSII or LEF

Stream File

Cell Type

Definition

Layer File

(Optional)

DB File

If needed

Note B

Note C

Note D

Note E

Note F

Note A

Synopsys 2013 7

Library Data Preparation (cont.)

Note A Import LEF with Cell Library > LEF-In(read_lef)

Note B This is normally for macros

Note C Extract macro with Cell > Make Macro abstract (geNewMakeMacro)

Note D Set PR boundary for standard cell only

Note E Set Multiple-Height PR boundary for standard cell only

Note F Define wire tracks for standard cell only

Synopsys 2013 8

What is BPV?

BPV Blockage, Pins, and Vias

Reduce Milkyway database to contain only relevant information for place-and-route application tools

FRAM view is extracted from CEL view

CEL view FRAM view Top routing

GDSII or LEF

Stream File

Synopsys 2013 9

Placement

Why is BPV important?

BPV extraction will impact routers behavior

Selecting different options will result in different FRAM views

A proper FRAM view ensures routing to be completed correctly, whereas an improper FRAM view may cause unexpected problems during routing, such as:

False DRC errors near the boundary of standard cells or macros

Long run time due to fixing of excessive DRC violations

Data

Preparation

(FRAM)

Routing

Synopsys 2013 10

Blockage Layers

Route Guides / Zero min-spacing Route Guide

User added in the CEL view or created automatically by BPV in the FRAM view on layer 190.

It can prohibit routing (signal or pre-routes in both) on named layers in a specific area.

Real metal blockage layer

Metal layers in the FRAM view, either extracted for all non-pin geometries on the metal layers defined in the Layer sections

of the technology file, or converted from the system metal

blockages in the CEL view (LEF obstructions, or OBS).

All design rules defined in technology file must be checked by classic router and Zroute.

Synopsys 2013 11

Blockage Layers (cont.)

System metal blockage layer

User added in the CEL view or created automatically by BPV in the FRAM view, on system layer 218, 219, and others.

It can be used in covering up routing area.

Classic router and Zroute always treat system metal blockages as thin wire.

System via blockage layer

User added in the CEL view, on system layer 224, 225, and so forth.

It can be used in covering-up via landing area.

Synopsys 2013 12

Blockage Layers (cont.)

Real metal blockage layer

System metal blockage layer

Synopsys 2013 13

Blockage Extraction Example (CEL)

The pad cell has three metal2 pins - PIN_A, PIN_B, and PIN_C, on the top boundary.

PIN_A and PIN_C are fat pins. PIN_B is thin pin. There are three pieces of metal2 OBS (non-pin polygons) below PIN_B.

Synopsys 2013 14

Blockage Extraction Example (FRAM)

The MakeMacro Command options used in this scenario are:

Preserve All Metal Blockage: 0

Treat All Blockage as Thin Wire: 0

Routing Blockage Output Layer: Metal Blockage

Other options: Treat metal 2 block As Thin, block all

The MakeMacro command creates real metal2 blockage but shrinks it (fat_spacing min_spacing) from boundary because of the Treat metal2 block As Thin option. The MakeMacro command creates system metal2 blockage to block all areas except the pins.

Synopsys 2013 15


The spacing of PIN_B and system metal2 blockage is different from PIN_B and real metal2 blockage because the system metal blockage is

always treated as thin. Therefore, one is thin to thin, the other one is thin

to fat.

Real metal2 blockage:

shrink by (fat_spacing min_spacing) System metal2 blockage: block all

Thin spacing: thin to thin

Fat spacing: thin to fat

Synopsys 2013 16


The MakeMacro Command options used in this scenario are:

Preserve All Metal Blockage: 0

Treat All Blockage as Thin Wire: 1

Routing Blockage Output Layer: Metal Blockage

Other options: block all

Metal2 pins are trimmed around by minSpacing. MakeMacro only created real metal2 blockage to block all the other areas.

No metal2 system metal blockage layer

Real metal2 blockage: block all

Synopsys 2013 17

Blockage merge / block all / block core

A B

A B Merge X Y

Macro/Pad cell

A B Block All

routing blockage

Block Core

with Margin A B

routing blockage

Synopsys 2013 18

Pins (Macro vs Stdcell)

Identify pins by text in GDSII

Extract pins for routing

For Macro / Pad type

Access edge

Access direction

For Standard Cell type

VIA region

Macro / Pad type Standard cell type

Synopsys 2013 19

VIA Region

BPV will look for any possible area (without considering tracks) to generate a region (in

red color) for VIA landing

VIA region has to minimize DRC violations with neighboring geometry

Standard cell type

Synopsys 2013 20

Via Region Global Route

Global routing divides the whole routing area into small global routing cells (GRC).

Real via and virtual wire (G-links) are created at this stage.

Global route also follows NDR

During global route, router will not consider via region at this stage.

Global Route

Track Assign

Detail Route

Synopsys 2013 21

Via Region Global Route (cont.)

Via created by GR G-links

created by

GR

Synopsys 2013 22

Via Region Track Assign

Global route is followed by track assignment, where the location and level of

each routes GRC crossing is assigned.

During track assign, router will select the primary isDefault contact of vias in the

technology file and put it on the track in the

via region area of the pins.

Most overlap removal is also done at this stage

No DRC check is performed here

Global Route

Track Assign

Detail Route

Synopsys 2013 23

Via Region - Track Assign (cont.)

Synopsys 2013 24

Via Region Detail Route

Detail route follows, as the detail router only has to complete the interconnect

details within each GRC to completely

implement the route plan.

Information contained in the via region serves as guidance for detail route.

During detail route, the router will try to replace or rotate the vias, if DRC violations

exist on the pins.

Global Route

Track Assign

Detail Route

Synopsys 2013 25

Via Region Detail Route (cont.)

At track assign stage

At detail route stage

Synopsys 2013 26

Case Study (1)

Synopsys 2013 27

Thousands of Open Nets Issue:

There is no error or warning message during route_global, route_track, and

route_detail and only a few DRC violations are

left after route_detail.

At the beginning of the following route_search_repair, the router reports

thousands of open nets and stops further processing:

WARNING: Net [U_TOP_/U_SUB/n1] is broken into 2 parts, reconnect!

.. WARNING: Net [U_TOP_/U_SUB/U_TNT/n28] is broken into 9 parts, reconnect!

There are 45287 open signal nets!

Re-connect 45287 open nets!

**** ERROR:Too many broken nets. Cannot continue!

route_global

route_track

route_detail

route_search_

repair

Why are these open nets are not properly connected at previous routing stages such as the global route stage?

Synopsys 2013 28

Thousands of Open Nets

Investigation:

Many M1 pins did not have VIA1 to complete the net connection

In the standard cells FRAM view, the M1 pin viaRegion is as follows:

VIA3 used for M1

pin connection?

------- attributes -------

OBJECT TYPE : PIN [ID #x805]

PIN NAME : SI

LAYER : M1 (31)

. VIA-REGIONS OF THE PORT :

via [3]: 1 rects, via [3]rotated: 1 rects,

In the top-level design, [3] is the VIA3 contactCode defined in TF. The router used VIA3 for the M1 pin access because the standard

cell's viaRegion is misleading.

Synopsys 2013 29


Investigation: (Continued)

In the log file there are multiple warning messages about the inconsistency

between the top-level design and the

standard cell libraries: Warning: Reference Library Inconsistent With Main Library

Reference Library: /remote/testcase/lib/mw/std_lib (MWLIBP-300)

Warning: Inconsistent Data for Contact Code 3

Main Library (MW_TOP) | Reference Library (std_lib)

Cut Layer VIA3 (70, 70) | VIA1 (70, 70)

Lower Layer M3 (0, 30) | M1 (0, 30)

Upper Layer M4 (0, 30) | M2 (0, 30) (MWLIBP-324)

Warning: Reference Library Inconsistent With Main Library

Reference Library: /remote/testcase/lib/mw/std_lib (MWLIBP-300)

Warning: Inconsistent Data for Contact Code 11

Main Library (MW_TOP) | Reference Library (std_lib)

Cut Layer VIA1 (70, 70) | VIA8 (300, 300)

Lower Layer M1 (0, 30) | M8 (70, 0)

Upper Layer M2 (0, 30) | M9 (70, 0) (MWLIBP-324)

Usually this is caused by an inconsistent technology file used with the top-level design and the standard cell library.

------- attributes -------


PIN NAME : SI

LAYER : M1 (31)


via [3]: 1 rects, via [3]rotated: 1 rects,

Synopsys 2013 30


Solution:

Make sure the technology file is consistent for both the top-level

design and the standard cell library.

Re-create the FRAM view for all standard cells by using blockage, pin,

via (BPV) extraction and make sure

the new viaRegions have consistent

contactCodes with the top-level design

Technical details are documented in SolvNet article 024604

Inconsistent Contact Codes Between Design and Standard Cell Reference Library

------- attributes -------


PIN NAME : SI

LAYER : M1 (31)


via [xx]: 1 rects, via [xx]rotated: 1 rects,

Synopsys 2013 31

How about Zroute?

Same problem as classic router:

Many M1 pins did not have VIA1 to

complete the net connection

VIA3 used for M1

pin connection?

Different log message: Total number of nets = 1234567

595 open nets, of which 0 are frozen

Total number of excluded ports = .......

12 ports without pins of 0 ports of 0 cover cells connected to Total number of DRCs = Total number of antenna violations = . Total number of voltage-area violations = ...

Synopsys 2013 32

How about Zroute? (Continued)

Log after route_zrt_detail:

Total number of nets = 1234567



.

Log after route_zrt_eco open_net_driven true: Total number of nets = 1234567



.

The open nets NEVER get reconnected by multiple runs of route_zrt_eco

route_zrt_global

route_zrt_track

route_zrt_detail

route_zrt_eco

(open_net_driven)

Solution:

Re-run BPV

Synopsys 2013 33

Case Study (2)

Synopsys 2013 34

Speed Up Routing Time: Pin Access With Multiple

Default Contact Codes

There are 3 on-grid pin-access candidates on this L-shaped M1 pin.

Assumption that only is free from DRC violations if just one default contact code is available in the technology file:

M1

M2

1

2 3

ContactCode "VIA12_HV" {

contactCodeNumber = 2

cutLayer = "VIA1"

isDefaultContact = 1

}

3

Synopsys 2013 35



Additional default contact codes with upper and lower metal enclosures can provide one more pin-access solution at

ContactCode "VIA12_HV" {


cutLayer = "VIA1"


}

1

2

M1

M2

3

1

ContactCode "VIA12_VV" {


cutLayer = "VIA1"


}

Synopsys 2013 36



Steps to achieve this:

1. Create an additional contact code, for example, VIA12_VV in the technology file and add isDefaultContact = 1 in this new ContactCode section.

2. Update the new technology file to the standard cell libraries and top-level design.

3. Re-create the standard cell FRAM views by using BPV:

BPV automatically picks up all VIA1 default contact codes and creates VIA1 viaRegions with multiple default contact codes, for example

4. Route the top-level design.

------- attributes -------


PIN NAME : SI

LAYER : M1 (31)


via [2]: 1 rects, via [2]rotated: 1 rects, via [27]: 1 rects,

Synopsys 2013 37



M1 DRC violations are the most difficult to fix in many designs. Additional solutions on M1 pin reduces signal route runtime.

Design

(#Instances)

Runtime %

Single (hour) Multiple (hour)

Design 1

(4500K)

Classic: 45 Classic: 33 26%

ZRT: 15.25 ZRT: 3.59 74%

Design 2

(3700K)


ZRT: 10.94 ZRT: 3.39 69%

Design 3

(1200K)


ZRT: 7 ZRT: 4 42%

Design 4

(890K)

Classic: 8.5 Classic: 6 29%

ZRT: 2.5 ZRT: 1.5 40%

Synopsys 2013 38

Case Study (3)

Synopsys 2013 39

Difficult M1 minEdgeLength Violations

Issue:

I have multiple isDefault contacts defined in the TF but router still has difficulty fixing DRC violations, especially minEdgeLength ones.

The VIA1 seems to be locked on the wire-track where DRC fixing is limited.

Case 1 Case 2

Synopsys 2013 40

Difficult M1 minEdgeLength Violations

Solutions: Preserve M1 pins

To prevent excessive DRC violations at metal1 pins, you can force the router to place via1 inside m1 pin and preserve M1 pin shape

set_route_zrt_common_options connect_within_pins \ {{m1 via_standard_cell_pins}}

Restrictively use only when the width of ALL M1 pins is greater than VIA1; otherwise, long runtime with DRC divergence occurs

VIA1 placed completely

inside M1 pin

Dont use the options when M1 pins width smaller than VIA1s size

Case 1 Case 2

Synopsys 2013 41

Case Study (4)

Synopsys 2013 42

fat

rectangles

in the

macro

signal

wires in top

cell

Fat diff-net spacing found around macros

Issue:

The top design was signoff proven; why did the Synopsys router still report

many diff-net spacing violations?

Technical background:

The top design was migrated from third-party tool by read_def

The ref libraries are done by read_lef

The fat spacing errors occur where signal wires were routed across macros

In competitors router, it requires minSpacing only

Caused by default BPV after LEF-in the macro

Synopsys 2013 43

Fat diff-net spacing found around macros

Solution:

verify_zrt_route

Re-BPV for macros

(Treat All Blockage as Thin Wire)

fat

rectangles

in the

macro

signal

wires in top

cell

Synopsys 2013 44

Case Study (5)

Synopsys 2013 45

fat

rectangles

in the

macro

signal

wires in top

cell

Fat diff-net spacing NOT found around macros

Issue:

In my design, any fat-spacing violations are found around macros ONLY by

signoff. Why these fat-spacing

violations are not found by router?


The ref libraries are done either by LEF-in or GDS-in flow.

The fat spacing errors occur where signal wires were routed across macros

The fat metal attribute seems to be missing in these macros FRAM

Check if ZRT-023 appears in the log:

Warning: BPV on 17 macros were done with "treat blockage as thin". (ZRT-023)

Synopsys 2013 46

Fat diff-net spacing NOT found around macros

Root cause:

The fat metal attribute is overwritten by BPVs Treat All Blockage as Thin Wire

Router will only check minSpacing on all metals inside the macros FRAM

verify_zrt_route

Re-BPV for macros Do NOT use Treat All Blockage

as Thin Wire

Solution:

fat

rectangles

in the

macro

signal

wires in top

cell

Synopsys 2013 47

Case Study (6)

Synopsys 2013 48

DEF-flow: Many spacing violations near PG nets

NDR spacing violation

2x minSpacing

PG wires

Issue:

Many NDR spacing violations near PG nets are reported after DEF-in of a fully routed design from third party tool.


Third party tools have an option to ignore NDR spacing between NDR

nets and PG.

Power and ground wires are alternative shielding shapes

Solutions:

set_route_zrt_detail_options \

-ignore_var_spacing_to_pg true

minSpacing?

Synopsys 2013 49

Predictable Success

bpv impact on zroute qor (1)

Documents