Color Slides SOCE 3 3

December 22, 2017 | Author: Mohammed El-Adawy | Category: System On A Chip, Logic Synthesis, Electronic Design Automation, Digital Electronics, Design
Share Embed Donate


Short Description

simple slides for soc-encounter...

Description

®

SoC Encounter™: Continuous Convergence (Flat and Hierarchical)

Version 3.3

March 3, 2004

SoC Encounter Course ‹ This course is flow-based. It draws heavily on Tcl commands to

implement the design. ‹ In this course, it is assumed that you know how to use the Encounter

engine and have some basic knowledge of the features of the Encounter platform. ‹ In this course, you will execute all the major steps required to

complete the design flow from gate level through place and route. ‹ You will fix signal integrity and timing problems using parasitic data

extracted with the Fire & Ice® extractor. ‹ You will run power analysis and view the IR drop in your design.

3/3/04

SoC Encounter

2

Course Objectives In this course, you will ‹ Explore high-level and hierarchical design planning and virtual

prototyping. ‹ Run Amoeba and block placement. ‹ Route the design with Trial Route. ‹ Estimate parasitics and run delay calculation. ‹ Create clock trees. ‹ Run delay calculation. ‹ Optimize timing. ‹ Run final route. ‹ Extract parasitics. ‹ Run crosstalk analysis. ‹ Run power analysis. 3/3/04

SoC Encounter

3

Course Agenda Day 1

Day 2

‰ Introduction to the SoC

‰ Top-Level Implementation

Encounter Environment

‰ Chip Assembly and Sign-Off

‰ Logical Synthesis and Scan

‰ Chip Finishing

Insertion

‰ Timing and Signal Integrity

‰ Silicon Virtual Prototyping

Closure

‰ Hierarchical Floorplan

‰ IPO and Physical Optimization

Generation ‰ Detailed Block Implementation

3/3/04

‰ Postmask ECO Flow

SoC Encounter

4

Customer Support and Documentation SourceLink® Online Customer Support

Customer Support

http://sourcelink.cadence.com ‰ Search the solution database and the entire site. ‰ Access all documentation. ‰ Find answers 24x7. ‰ Submit a service request online. ‰ Track a service request (SR).

If you don’t find a solution on the SourceLink site, you can send email or call customer support.

Service Request

E-mail E-mail

If your problem requires more than customer support, then a product change request (PCR) is initiated.

PCR

[email protected] [email protected]

R&D

You You can can send send aa service service request request by by e-mail. Include details and e-mail. Include details and data data or or pointers pointers to to the the data data to to illustrate illustrate the the problem. problem. If your request does not require that you send data for someone to analyze, then call the hotline.

1- 877- CDS 4911 (1- 877- 237- 4911) Quick access to support for questions, advice, or status checks. Support is available from 7:00 a.m. to 7:00 p.m., CST.

3/3/04

SoC Encounter

5

3/3/04

SoC Encounter

6

®

Introduction to SoC Encounter

Module 1

March 3, 2004

Cadence Products at a Glance Encounter

Ensemble (+ standalone synthesis)

RTL/Datapath/ Low Power Synthesis

SE-PKS

PKS

BGX

Hierarchical partitioning

Virtual prototyping / Placement (Block/Cell)

First Encounter Ultra

SoC

Physical Optimization

PKS

Encounter

Nano Encounter

WRoute

SE-PKS SE-Ultra

Route Accelerator

SE-DSM

NanoRoute Ultra

NanoRoute

3/3/04

Signal Integrity Sign-off Analysis

Celtic Analyzer

Sign-off Extraction and Power Analysis

Fire & Ice QXC, VoltageStorm

SoC Encounter

8

The SoC Encounter Window Pull-Down Menus Toolbar Icons

Floorplanning Icons

Design Display Area Design Views Display colors

Satellite Window

Auto Query of Objects 3/3/04

SoC Encounter

9

SoC Encounter Design Flow

Design Entry

Optimized Netlist Mapped Constraints

Logic Synthesis and Scan Insertion (BuildGates)

RTL Design Data Initial Constraints

Hierarchical Virtual Prototyping and Physical Implementation Environment (SoC Encounter)

Final Netlist Routed Database

Chip Finishing (VCE)

3/3/04

SoC Encounter

10

SoC Encounter Design Flow

Design Entry Logic Synthesis/Scan Insertion Silicon Virtual Prototyping Hierarchical Floorplan Generation Detailed Block Implementation Top-Level Implementation BuildGates

3/3/04

Chip Assembly and Sign-Off

SoC Encounter

Chip Finishing

Virtuoso/VCE

SoC Encounter

11

3/3/04

SoC Encounter

12

®

Logic Synthesis and Scan Insertion

Module 2

March 3, 2004

Logic Synthesis and Scan Insertion RTL

Technology Libraries

RTL Design Entry and Constraint Definition

Constraints If you use PKS for preplacement optimization, then provide the floorplan.

Optimize/Map Netlist Design-For-Test Configuration Scan Insertion Custom WLM

Preplacement Optimization

Floorplan

Scan DEF Generation JTAG/BIST Generation Custom WLMs can be generated by the Encounter engine.

Netlist Generation Constraint Generation

Silicon Virtual Prototyping Netlist

Mapped Constraints

Scan DEF RC BG/PKS Third Party

3/3/04

SoC Encounter

14

Logic Synthesis and Scan Insertion Steps Input Files ‹ RTL design data ‹ Timing constraints

Steps ‹ Optimize and Map the Design

An RTL description of a design can contain a mixture of high-level statements, gate-level netlists, and custom blocks. Use RTL Compiler (RC) tool to optimize and map the RTL. RTL Compiler is the next generation synthesis tool for multimillion-gate designs. ‹ DFT Configuration

Test synthesis is performed prior to and during optimization. ‹ Scan Insertion

The tool which inserts the scan components into the design will also output a scan order file. This file contains the order in which scan components need to be connected. 3/3/04

SoC Encounter

15

Logic Synthesis and Scan Insertion Steps (continued) ‹ Preplacement Optimization Preplacement optimization is run before place-and-route to produce a more optimized netlist which is more likely to meet timing after place-and-route. You can use custom wire load models in subsequent runs of optimizations to use more realistic models than the generic wire load models which are typically used in the initial stages of synthesis.

‹ Scan DEF Generation The Scan DEF file (scanDEF) is a subsection of the DEF file format. It is used to describe the scan chain configuration and the set of reorderable scan chains present in the netlist.

‹ JTAG/BIST Generation JTAG (boundary scan) and BIST (built-in-self-test) components are used to isolate manufacturing defects in chips. JTAG/BIST generation is performed with third party tools.

3/3/04

SoC Encounter

16

Logic Synthesis and Scan Insertion (continued) Output Files ‹ Optimized gate-level netlist ‹ Mapped constraints ‹ Scan order DEF file

3/3/04

SoC Encounter

17

3/3/04

SoC Encounter

18

®

Silicon Virtual Prototyping

Module 3

March 3, 2004

Silicon Virtual Prototyping Netlist Timing and Clock Constraints

CTE TA (no net loading)* I/O, P/G Placement, or Flip Chip JTAG Placement Block Placement** Specify/Refine Floorplan

IO Placement

Silicon Virtual Prototyping Hierarchical Floorplan Generation

Vendor Floorplan

Detailed Block Implementation

Add/Delete/Modify

    

Top-Level Implementation

Module guides Fences (shaping/sizing)

Chip Assembly and Sign-off

Blockages (place/routing) Assign block locations Power plan

* Check constraints.

Amoeba Placement***

** Place top-level modules and blackboxes. (Used in an all-block design)

hardmacros and cells

Scan Chain Reordering Power Planning (rings/stripes)

Timing/Routing Issues

Trial Routing/Extraction/CTE Clock Issues

No

Clock Tree Synthesis

Timing Issues

Trial Routing/Extraction/CTE IPO Trial Routing/Extraction/CTE Power Analysis

Timing Issues Power Issues

***Depending on design size, you can use floorplanning mode or ClusteringPlace for increased capacity.

To Hierarchical Floorplan Implementation Floorplan / Fences

Timing/CTS Constraints SoC Encounter Optional

3/3/04

SoC Encounter

20

Virtual Prototyping Steps To create a virtual prototype, complete the following procedure: ‹ Run timing analysis. Analyze timing with the Common Timing Engine (CTE) using zero net loading to determine whether the initial design meets timing requirements.

‹ Place I/O, power, and ground pads. During this step, you have the option of reading a file that contains coordinates for pad placement or pad ordering information. You must include power and ground pads in the I/O file.

‹ Place JTAG cells. Specify and place JTAG cells near the I/O cells. Once placed, they will not be moved in subsequent placement runs.

‹ Place the blocks in the design if you have an all-block or channelless

design methodology. You can use the Encounter block placer or manually place blocks.

3/3/04

SoC Encounter

21

Virtual Prototyping Steps

(continued)

Specify and Refine the Floorplan ‹ Defining Module guides and fences Define the initial placement guides for key modules. Guides tell the placer to place a specific module’s cells near the guide location. Alternatively, fences can be used. After a fence is created, components that belong to the fence will not be allowed to go outside the fence boundary.

‹ Shaping and Sizing Fences Refine the shape and size of fences to align the fences manually, using relative placement to preserve relationships between fences and to keep fenced areas in specific locations. Correct the aspect ratio and size of the fenced areas. As an alternative, you can run the automatic block placer. The goal of this step is to make sure that when blocks are committed later in the process, you can successfully implement the blocks individually, and the design as a whole.

‹ Adding Placement and Routing Blockages Add placement or routing blockages to clear routing channels in congested areas. For example, if there is heavy congestion around the corner of a block, add a placement blockage to relieve the congestion in that area. 3/3/04

SoC Encounter

22

Virtual Prototyping Steps (continued) Refining the Floorplan ‹ Adjust block placement locations. Adjust block placement manually, if necessary.

‹ Power plan. Optionally, define Multiple Supply Voltages (MSV), and define the power rings and power stripes. You can save the power plan to a file after achieving a satisfactory initial structure. Typically, you do this step only if you use a predefined power structure in the design.

3/3/04

SoC Encounter

23

Virtual Prototyping Steps (continued) ‹ Run Amoeba placement. Use the Amoeba placer to place cells in the design. The placer places cells according to module guide and fence constraints. Running placement and analyzing the congestion lets you quickly gauge the feasibility of the design in meeting timing and placement density goals.

‹ Reorder scan chains. Refine the initial scan-chain order based on Amoeba placement results. Although changes made at this step are not used after the initial floorplanning, this step is still recommended for reducing wire length for a more accurate analysis of congestion. Refine the initial scan-chain order based on the most recent Amoeba placement results.

‹ Run power planning. Define the power rings and power stripes.

3/3/04

SoC Encounter

24

Virtual Prototyping Steps (continued) ‹ Run trial routing. Use the trial router to route the design. Examine the congestion map and the report to identify congested areas. Use the prototyping option of Trial Route to gauge the routability of the design.

‹ Extract RCs. Extract parasitic resistance and capacitance (RC) values to calculate delays based on the wire lengths determined by trial routing.

‹ Analyze timing to find timing violations. Although timing at this stage is likely to have many violations, you can still discover useful information. Analyze the timing to determine how to alter the floorplan.

3/3/04

SoC Encounter

25

Virtual Prototyping Steps (continued) ‹ Define clock tree constraints, such as insertion delay and skew limits. Synthesize the clock tree. Analyze the clock tree reports to determine if timing constraints have been met. At this stage, netlist changes are not passed forward. A clock tree is generated to determine clock and timing issues with the current floorplan.

‹ Run trial routing, extract parasitics, and analyze timing. Run trial routing. Perform parasitic extraction to determine net RCs. Analyze the timing to determine whether the initial design meets timing requirements. If it does not, then rearrange the module guides. If timing issues remain after several floorplan iterations, you might need to change the RTL.

‹ Run in-place optimization (IPO). Run in-place optimization, which adds buffer cells, resizes gates, and fixes design rule violations. Although netlist changes made at this stage are not kept, in-place optimization is necessary for assessing potential timing issues with the current floorplan.

3/3/04

SoC Encounter

26

Virtual Prototyping Steps (continued) ‹ Run trial routing, extract parasitics, and analyze timing. If timing issues remain after several floorplan iterations, you might need to change the logical netlist. If no satisfactory floorplans are found, you might have to alter the RTL of the design.

‹ Analyze power. Perform power analysis. Note that the power plan will be refined in the next procedure.

‹ Save the floorplan. Save the floorplan file to pass to Floorplan Refinement.

3/3/04

SoC Encounter

27

Virtual Prototyping Commands ‹ Use the loadConfig command to load the configuration file into the

SoC Encounter environment. ‹ The setCteReport command sets the report format to the Common

Timing Engine (CTE). ‹ When you run the buildTimingGraph command with the

-ignoreNetLoad option, you ignore the loading due to nets. ‹ The reportTA command generates a timing analysis report. ‹ Use the specifyJtag and placeJtag commands to specify and place the

Jtags in the design.

3/3/04

SoC Encounter

28

Virtual Prototyping Commands (continued) ‹ Place the critical blocks in the design using the placeInstance

command. Instead of the placeInstance command, use the Move icon to move blocks and instances to the core area. ‹ Use the addRing and addStripe commands to create the power rings

and stripes around the core area and power rings around the blocks. ‹ Use the amoebaPlace command to place the cells and the blocks

which have not been preplaced. The -timingdriven option places the cells in timing-driven mode and requires a constraints file. Otherwise, the cells will be placed in congestion mode. ‹ Next, you create floorplan guides, which you might later convert to

fences. The command to create guides is createGuide. ‹ After placement, you can run trial route and extraction using the

trialRoute and extractRC commands. View the congestion map to determine if there are any hot spots in your design that might lead to routing problems downstream. 3/3/04

SoC Encounter

29

Virtual Prototyping Commands (continued) ‹ If there are timing violations, you can run In-Place Optimization using

setIPOMode and fix the violations using fixSetupViolation. ‹ After fixing setup violations, run clocktree synthesis. First specify the

clock tree synthesis file, and run clock tree synthesis using the ckSynthesis command. ‹ After checking setup and hold time with the actual clock (instead of the

ideal clock) you can run power analysis to analyze the power consumption and IR drops in the design, using the updatePower and displayRailAnalysisResults commands. ‹ Finish the virtual prototyping stage by saving the design and the

floorplan with the saveFPlan and saveDesign commands.

3/3/04

SoC Encounter

30

Lab Exercises Lab 1-1 Virtual Prototyping

3/3/04

SoC Encounter

31

3/3/04

SoC Encounter

32

®

Hierarchical Floorplan Generation

Module 4

March 3, 2004

Hierarchical Floorplan Generation Flow Partition Clock and Timing Constraints

Initial Netlist

SVP

Physical Partition Definition

Silicon Virtual Prototyping

Amoeba Placement Fenced Floorplan

Trial Routing Parasitic Extraction/CTE TA

Timing or Congestion Problem

Hierarchical Floorplan Generation Detailed Block Implementation

IPO with -honorPartition

Top-Level Implementation

Trial Route (use -honorPartition)

Pin Optimization Time Budget

Parasitic Extraction/TA

Push Down Power

Power Routing

Chip Assembly and Sign-off

Timing Problems

LEF Generation

Power Problems

TLF/STAMP Generation

Power Analysis

Top-Level Implementation Top-Level Netlist Block LEF(s)

3/3/04

Floorplan Placement

Commit Partitions Save Partitions

Detailed Block Implementation Block Netlist

Block TLF(s)

Budgeted Constraints

SoC Encounter

Floorplan/ Placement Boundary Voltages

SoC Encounter

34

Inputs to Hierarchical Floorplan Generation The following information is needed for this stage: ‹ Initial netlist ‹ Timing and block constraints ‹ Fenced floorplan

3/3/04

SoC Encounter

35

Hierarchical Floorplan Generation Steps ‹ Define the physical partitions. ‰ Change fences to partitions.

‹ Run Amoeba placement. ‰ Run timing-driven placement based on the partitions you defined. This will

place the remaining cells at the top level of the design. ‹ Run trial routing, extract parasitics, analyze timing. ‰ Route signals based on partitions, and examine the congestion map. If

congestion is acceptable, proceed to extract parasitics. If congestion is unacceptable, refine the floorplan by beginning with detailed block placement. ‰ Extract parasitic RC values to calculate delays based on the wire lengths

determined by trial routing. ‰ Analyze timing using CTE to determine whether the floorplan, based on

the partitions you chose, meets timing constraints. If timing constraints are met and congestion is acceptable, commit the partitions. If they are not met, go back and refine the floorplan. 3/3/04

SoC Encounter

36

Hierarchical Floorplan Generation Steps (continued) ‹ In-Place Optimization (IPO) ‰ To create the best budgets for the blocks, the design is run through IPO to

optimize the timing. The IPO option -neverAddPort will run IPO without creating any additional module ports. Use this option to avoid changes to the block port lists at this stage. ‹ Run trial routing, extract parasiitics, analyze timing. ‰ The design is routed, extracted and timed again.

‹ Route power. ‰ Power is routed to the blocks and the components.

‹ Analyze power. ‰ Power analysis must be done prior to partitioning so that power budgets

can be created for the partitions.

3/3/04

SoC Encounter

37

Hierarchical Floorplan Generation Steps (continued) ‹ Commit Partitions ‰ Make a final decision on the partitions to implement as separate blocks.

Committing partitions creates fences, which constrain the module to a specific location without making a final commitment to the location. ‹ Committing partitions automatically does the following: ‰ Optimizes pins.

 For each block, the pin optimization places pins along the edges of the block. The pin optimizer uses trial routing to determine the optimal pin placements.

‰ Creates the timing budget.

 Distributes timing delays: latch-to-pin within modules and pin-to-pin between modules.

‰ Pushes power into blocks.

 Pushes stripes and rings down into the blocks. The blocks inherit the power structure from the top-level floorplan.

3/3/04

SoC Encounter

38

Hierarchical Floorplan Generation Steps (continued) ‹ Save Partitions ‰ When the partitions are saved, a directory for each block is created. Its

netlist, floorplan, and budgeted constraints are saved in the directory. The cell placements within the partitions can optionally be saved as well. ‰ A directory is also created for the partitioned top level. The top-level

netlist, floorplan, and updated constraints are saved into it. In addition, a simple timing model (STAMP) and LEF model is generated to represent each block that is instantiated in the netlist.

3/3/04

SoC Encounter

39

Hierarchical Floorplan Generation Commands In addition to the commands in the Silicon Virtual Prototyping stage the following commands are used in Hierarchical Floorplan Generation: ‹ The createPartition command changes the guides to fences for the

specified module of a hierarchical design. ‹ The createPtnCut creates partiton cuts so that core rows are cut out

from the partition area at the top level. ‹ The partitionPlace command runs a two-phase placement to better

handle the partition flow to assign pins more accurately and reduce the routing congestion. ‹ After committing the partitions, save the partitions using the

savePartition command. Saving the partitions saves the timing and LEF models in the partition directory.

3/3/04

SoC Encounter

40

Results of Hierarchical Floorplanning The following data is generated for top-level floorplan implementation: ‹ Block LEFs ‹ Block timing models ‹ Top-level netlist ‹ Top-level block placement ‹ Top level timing constraints

The following data is generated for detailed block implementation: ‹ Block netlist ‹ Floorplan and placement information ‹ Budgeted timing constraints ‹ Boundary Voltages 3/3/04

SoC Encounter

41

Lab Exercises Lab 2-1 Implementing the Hierarchical Floorplan

3/3/04

SoC Encounter

42

®

Detailed Block Implementation

Module 5

March 3, 2004

Detailed Block Implementation Flow From Hierarchical Floorplan Generation Block Netlist

Budgeted Constraints

Floorplan/ Placement

Timing-Driven Placement Scan Chain Reordering Trial Route/ Parasitic Extract/CTE

High Effort IPO Congestion Optimization

Difficult Timing

Slew Balancing IPO Clock Tree Synthesis Trial Route/Parasitic Extract/CTE

High Effort IPO Skew Clock Post CTS

Celtic Encounter

Physical Optimization Flow

NanoRoute Sign-off extractor

Trial Route/Parasitic Extract/CTE

TD Route with SI awareness Extraction* Timing/SI Closure Flow Power Grid Analysis

SI Closure

Noise Model Generation Output DEF, GDS or OA, Netlist and Spef Timing Model Creation Equiv. Check

Sign-off Power Grid Analysis Equivalence Checker Optional Step

* SoCE Detailed extraction with -assumeMetalFill.

To Top-Level Implementation Timing Model Noise Model

3/3/04

SoC Encounter

Power Model

To Chip Assembly and Signoff DEF

Netlist

SPEF

GDSII

LEF OA

44

Inputs to Block Implementation ‹ Block netlist ‹ Timing and clock constraints for the block ‹ Floorplan and placement information ‹ Boundary voltage for VoltageStorm® power analysis

3/3/04

SoC Encounter

45

Block Implementation Steps ‹ Run Amoeba placement. After starting a new session in the block directory, read in the block netlist and floorplan. Use the constraints from Hierarchical Floorplan Generation and place the block in timing-driven mode.

‹ Reorder scan chains. Reorder scan chains to relieve routing congestion.

‹ Run trial routing, extract parasitics, and run timing analysis. The block is routed and extracted. Then, the timing of the block is analyzed. For blocks with very difficult timing, you might have to run PKS (physical synthesis) to optimize and restructure the netlist.

3/3/04

SoC Encounter

46

Block Implementation Steps (continued) ‹ Run high-effort in-place optimization (IPO). ‹ Run congestion optimization. Running the congOpt command affects placement and has the benefit of preventing downstream signal integrity (SI) issues.

‹ Balance slews. Balancing slews is a part of the flow that prevents SI problems by upsizing or downsizing components that are close to each other. This process minimizes the effect of aggressor on the victim due to differences in their slew rates.

‹ Run high effort IPO again. ‹ Synthesize the clock trees in the block. Select the option to generate a Macro model for the block when synthesizing the clock tree. The information in the Macro model file contains the insertion delay for the block that will be used later when implementing the top level.

‹ Run trial routing, extract parasitics, and run timing analysis. The block is trial routed, extracted, and the timing is again analyzed, this time with propagated clocks.

3/3/04

SoC Encounter

47

Block Implementation Steps (continued) ‹ Run high-effort in-place optimization (IPO). When you run IPO with the -highEffort option, physical synthesis optimization commands run on paths with timing closure challenges.

‹ Do a useful skew analysis and implementation for paths whose timing

is hard to close with IPO. Post-CTS useful skew performs time-borrowing by inserting buffers/inverter pairs or resizing cells on clock nets.

‹ Run trial routing, extract parasitics, and run timing analysis. ‹ Run routing with signal integrity options. The NanoRoute tool will use soft spacing as a method to prevent long wire from running next to each other, thus reducing the possibility of crosstalk effects.

‹ Run extraction. ‹ Go to the timing/signal integrity closure subflow.

3/3/04

SoC Encounter

48

Block Implementation Steps (continued) ‹ Run power analysis. Assuming that the netlist is clean, use the Encounter engine to run a power analysis, and then use the VoltageStorm power analyzer to run an IR drop analysis. At this point, the block is essentially complete and the rest of the steps involve creating various representations of the block to use during top-level implementation and chip assembly.

‹ Create an Echo model. To create an Echo noise model for the block, run the CeltIC tool in the Encounter engine or in standalone mode.

3/3/04

SoC Encounter

49

Block Implementation Steps (continued) ‹ Generate LEF, DEF, GDS/OA, netlist, and SPEF. The Encounter tool can directly generate a GDSII representation of the block. In addition, it can also create an OpenAccess (OA) database for the block. The database can be read by the Virtuoso Chip Editor (VCE) during chip assembly in place of the GDSII. A block power model, consisting of a power grid model and a power consumption value, can be created to represent the block during top-level power analysis.

‹ Create a timing model. Create a detailed and characterized TLF or .lib blackbox timing model of the block. The STAMP model that was created during partitioning in the hierarchical floorplan generation was only a simple one-dimensional representation of the block and contained no load- or slew-dependent timing information.

‹ Run an equivalence check. Because the netlist has been modified, run a formal verification tool to ensure that the changes that were made did not change the logic or the functionality of the netlist.

3/3/04

SoC Encounter

50

Block Implementation Commands ‹ To fix setup violations, use the IPO command fixSetupViolation. ‹ If there are hold violations, fix them by running fixHoldViolation. ‹ If timing does not converge using the IPO commands in –highEffort

mode, run the runPhySyn command on the design. ‹ Report and optimize leakage power by running reportLeakagePower

and optLeakagePower. ‹ Optimize the clock tree for the block and save the clock tree macro

model using the ckSynthesis command and the -macromodel option. The saved macro model will be used later in top-level clock tree synthesis. ‹ Add filler cells using the addFiller command. ‹ Use NanoRoute to route the critical nets first, and then route the

remaining nets. The globalDetailRoute command runs NanoRoute.

3/3/04

SoC Encounter

51

Block Implementation Commands (continued) ‹ Add metal fill using the addMetalFill command. Verify the geometry,

connectivity and antenna to make sure that the addition of filler cells and metal fill did not violate any design rules. The verification commands are verifyConnectivity, verifyGeometry and verifyProcessAntenna. ‹ Fix block-level crosstalk violations using fixCrosstalk. ‹ Extract the block by using the Fire & Ice® runQX command. ‹ Generate the .lib or TLF timing model and the OpenAccess database

for the block using the genTlfModel and oaOut commands.

3/3/04

SoC Encounter

52

Output of Block Implementation The result is a placed and routed block. The output files are: ‹ DEF file ‹ Verilog® netlist ‹ LEF file ‹ SPEF file ‹ OpenAccess database ‹ Timing Model ‹ Power Model ‹ Noise Model ‹ GDSII file 3/3/04

SoC Encounter

53

Lab Exercises Lab 3-1 Detailed Block Implementation

3/3/04

SoC Encounter

54

®

Top-Level Implementation

Module 6

March 3, 2004

Inputs to Top-Level Implementation ‹ Top-level netlist ‹ Floorplan and hard block placements ‹ Top-level constraints

3/3/04

SoC Encounter

56

Top-Level Implementation Import Block Model Data

From Hierarchical Floorplan Generation Top Level Netlist

Floorplan

Constraints

Timing-Driven Placement Scan Chain Reordering Trial Route/Parasitic Extract/CTE High effort IPO

From Block Implementation Antenna Models

Timing Models

Power Models

Noise Models

Repeater Insertion Congestion Optimization Slew Balancing IPO Useful Skew pre-CTS CTS Trial Route/Parasitic Extract/TA High effort IPO Skew clock post-CTS Trial Route/Parasitic Extract/TA TD Route with SI awareness Extraction* Hier Timing/SI Closure Flow Hier Power Grid Analysis

SI Closure SI Analysis and Repair

Output top-level DEF, GDS or OpenAccess, Netlist and Spef Equivalence Check

Celtic Encounter

Difficult Timing

NanoRoute Sign-off extractor Sign-off Power Grid Analysis

Physical Synthesis

Equivalence Checker Optional Step

* SoCE Detailed Extraction with –assumeMetFill

To Chip Assembly and Sign-Off DEF

Netlist

SPEF

GDSII

OA

3/3/04

SoC Encounter

57

Top-Level Implementation Steps ‹ Import the Block LEF files. Update the configuration file to import the block LEFs. ‹ Run Amoeba placement. Run placement on the top level, leaving block placement fixed. ‹ Re-order the scan chains. The placed scan chains at the top level are re-ordered to relieve routing congestion. ‹ Run trial routing, extraction, and CTE timing analysis. The top level is routed and extracted. The timing is analyzed. Use a sign-off extractor to extract top-level parasitics. Signal integrity and timing optimization are done simultaneously by the Encounter engine. Leakage power is also optimized by resizing gates in this step. ‹ Run high effort IPO. ‹ Insert repeaters. Repeaters are inserted after crosstalk prevention has been implemented. ‹ Run congestion optimization. ‹ Balance slews. 3/3/04

SoC Encounter

58

Top-Level Implementation Steps ‹ Run high-effort in-place optimization (IPO). Run high-effort IPO with restructuring to fix setup and hold violations.

‹ Run Useful Skew Pre-CTS. ‹ Run clock tree synthesis. ‹ Do trial routing, extract parasitics, and analyze timing. The design is trial routed, extracted, and timing is again analyzed – this time with propagated clocks.

‹ Run high-effort IPO. ‹ Do clock skew. Do a useful clock skew post CTS.

‹ Run trial routing, extraction and timing analysis ‹ Run routing with signal integrity. The NanoRoute tool runs signal integrity and timing-aware detailed routing. This tool is integrated natively into the Encounter executable and runs from the same in-memory data structures. 3/3/04

SoC Encounter

59

Top-Level Implementation Steps (continued) ‹ Extract the design. Extract the design using either the Encounter detailed extraction or the Cadence® Fire & Ice® QX extractor. Both are available in the Encounter cockpit.

‹ Run the timing optimization and signal integrity subflow. ‹ Run a hierarchical power grid analysis. Run power and an IR drop analysis using the Encounter or VoltageStorm® tools. The VoltageStorm tool requires an additional license.

‹ Generate top-level GDSII/OpenAccess, DEF, Verilog® netlist, and

SPEF. At this point, the top level is essentially complete. An OpenAccess (OA) database and GDSII file can be created for the top level. The database can be read by DFII during chip assembly instead of the GDSII.

‹ Run an equivalence check.

3/3/04

SoC Encounter

60

Example of Repeater Rule file Command insertRepeater {-rule ruleFile | -template} [-selNet selNetFile] [-excNet excNetFile] Example Rule File # Buffer Drive Strength Cell Max Wirelength Total Cap # Name Microns pF SetBufferDrivingStrength BUFX16 1200 2.5 SetBufferDrivingStrength BUFX20 1500 3.0 SetInvertorDrivingStrength INVX20 1500 3.0 # Block Output Drive Strength (Optional to customize) SetCellDrivingStrength alu 50 0.5 SetCellDrivingStrength rpt_blk 2500 5.0 # Block Input Load (Optional to overwrite timing library values) SetCellReceiverLoad alu 50 0.05 SetCellReceiverLoad rpt_blk 50 0.05 # Default Block Drive Strength SetDefaultDrivingStrength 2000 4.0 3/3/04

SoC Encounter

61

Output of Top-Level Implementation The result is the placed and routed design and these outputs: ‹ Top-level GDSII ‹ Top-level netlist ‹ Top-level SPEF ‹ Top-level DEF ‹ Top-level OpenAccess database

3/3/04

SoC Encounter

62

Lab Exercises Lab 4-1 Top-Level Implementation

3/3/04

SoC Encounter

63

3/3/04

SoC Encounter

64

®

Chip Assembly and Sign-Off

Module 7

March 3, 2004

Chip Assembly and Sign-Off From Block Implementation

From Top-Level Implementation Top-Level DEF Top-Level Netlist

Flatten (unpartition) Full-Chip Power Grid Analysis

Block DEFs

Silicon Virtual Prototyping Hierarchical Floorplan Generation

Block Netlists

Detailed Block Implementation

Full-Chip Parasitic Extraction

Top-Level Implementation

Full-Chip SPEF Top-Level SPEF

Stitch

Chip Assembly and Sign-off

Stitching SPEF or Flat SPEF

Block SPEFs

Full-Chip Timing Analysis Celtic Encounter Sign-off extractor Sign-off Power Grid Analysis

Full-Chip SI Analysis

Timing Constraints

Full-Chip SDF

Full-Chip Timing Simulation

To Chip Finishing Use SignalStorm for delay calculation.

Top-Level OA

Top-Level GDSII

Block OA’s

Block GDSII

NC Verilog Optional Step

3/3/04

SoC Encounter

66

Inputs to Chip Assembly and Sign-off At this stage, you bring together the top-level and block-level design information to flatten the design and to run a final analysis. Inputs ‹ Top-level DEF ‹ Block-level DEF ‹ Top-level netlist ‹ Timing constraints ‹ Block netlist ‹ Full-chip DEF

3/3/04

SoC Encounter

67

Chip Assembly and Sign-Off Steps ‹ (Optional) Flatten the design. Flatten the design by merging the top-level and block-level DEF files.

‹ Run a full-chip power analysis. Use the VoltageStorm® tool to perform a power analysis.

‹ Extract full-chip parasitics (optional). Use the Fire & Ice® QX extractor to run a flat extraction to derive all parasitics, including potentially undetected coupling between routing at the top-level and in the blocks. Either a 64-bit full-chip parasitic extraction can be performed on the flattened design, or the SPEFs from the top level and the blocks can be stitched together for 64-bit timing and SI analysis.

3/3/04

SoC Encounter

68

Chip Assembly and Sign-off Steps (continued) ‹ Run a full-chip timing analysis. Use the Encounter engine in CTE mode to analyze the timing. You can run either a fullchip extraction on the flattened design, or stitch the SPEFs from the top level and the blocks together for timing and signal integrity analysis.

‹ Run a full-chip crosstalk analysis. In the Encounter engine, read the SPEF file generated by the extractor, the top-level netlist, the timing constraints file, and the netlists for all the blocks. Use the CeltIC tool to run a full-chip crosstalk analysis.

‹ Generate a full-chip OpenAccess database. Generate the OpenAccess database files using the oaOut command.

‹ Generate a full-chip SDF file (optional). If the methodology calls for dynamic simulation in the sign-off process, an SDF file can be produced to feed the NC-Verilog® simulator.

‹ Run a full-chip timing simulation (optional). Run a full-chip timing simulation if possible. 3/3/04

SoC Encounter

69

Chip Assembly and Sign-Off Commands ‹ If the design is hierarchical, one of the main steps at this stage is to

flatten the database. To flatten the database, you need to unpartition the design using the flattenPartition command. ‹ You can then run extraction, delay calculation, SI analysis, and power

analysis on the flat design.

3/3/04

SoC Encounter

70

Outputs of Chip Assembly and Sign-off The outputs of chip assembly and sign-off include: ‹ Full-chip Verilog netlist ‹ Top-level GDSII ‹ Block-level GDSII ‹ Full-chip OpenAccess database

3/3/04

SoC Encounter

71

3/3/04

SoC Encounter

72

®

Chip Finishing

Module 8

March 3, 2004

Chip Finishing From Chip Assembly and Sign-Off

Block OA’s

Top-Level OA

Import Top and Block OA DBs

* Modified OA DB

*Non Connectivity Modifying edits

Top-Level GDSII

Block GDSII

Import Top and Block GDSII

Need to import either OA DBs or GDSII

Import Std Cell GDSII/OA Layout Finishing/Editing Physical Verification

Restore OpenAccess Design

Errors?

Yes

Verify/Extract/TA Encounter

* Modified OpenAccess database can be read back into SoC Encounter.

3/3/04

RTM GDS

VCE Assura

Optional Step

SoC Encounter

74

Inputs to Chip Finishing Import one of the following formats into Virtuoso® Chip Editor (VCE) or a layout editing tool to complete the flow: ‹ Top-Level GDSII and Block-Level GDSII ‹ Top-Level OpenAccess database and Block-Level OpenAccess

database ‹ Full-Chip OpenAccess database

3/3/04

SoC Encounter

75

Chip Finishing Steps ‹ Import the GDSII layouts for the standard cells into a DFII database. ‹ Import the OpenAccess databases or GDSII files for the top level and

for the blocks, or import the full-chip OpenAccess database. ‹ Run layout finishing. Layout finishing steps include adding scribe lines, adding fiducials, adding alignment marks, and adding test fixtures.

‹ Run physical verification. After the layout finishing steps are complete, run a sign-off-level physical verification with Assura to look for any design rule violations. If any are found, they can be corrected in Virtuoso® and the layout finishing steps might need to be redone. When the design passes error free, then masks can be generated and the chip fabricated.

3/3/04

SoC Encounter

76

SoC Encounter

VCE Flow Steps

‹ Library Creation for VCE ‰ Use the lefin program (the DFII version of lef2oa) needs to create correct

techfile information and abstract cellviews for VCE. ‹ Complete your design in SoC Encounter. ‹ Save the floorplan file. ‰ Needed when restoring design in SoC Encounter.

‹ Output an OpenAccess database from the Encounter environment. ‹ Open the OpenAccess database in VCE. ‹ Edit the database in VCE.

3/3/04

SoC Encounter

77

SoC Encounter

VCE Flow Steps (continued)

‹ Save the OpenAccess database in VCE. ‹ Import a design in SoC Encounter. ‹ Restore floorplan from the previous Encounter session. ‹ Clear floorplan to remove any special routing (power, ground, signal). ‹ Load the OpenAccess database from VCE into SoC Encounter to

update wiring and placement. ‹ Use the Encounter commands for verification, timing analysis, and

other tasks. ‹ Repeat loop as required. ‹ You can produce a GDSII stream from either VCE or SoC Encounter. ‰ Usually VCE is used, because the GDSII stream file needs to include

scribe info and other data that typically does not exist in the Encounter database. 3/3/04

SoC Encounter

78

Lab Exercises Lab 5-1 Chip Assembly and Sign-Off

3/3/04

SoC Encounter

79

3/3/04

SoC Encounter

80

®

Timing and Signal Integrity Closure

Module 9

March 3, 2004

Timing and Signal Integrity (SI) Closure Flow Extracted Design w/Metal Fill Assumed in Extraction

Timing Analysis Setup/Hold IPO fixSetupViolations IPO fixHoldViolations SI-Aware ECO Route SI Analysis Fix Crosstalk Add Filler Cells (postroute) Wire Editing Add Metal Fill Fill Notch Verify Metal Density Verify Geom./Conn./Ant. Detailed Extraction SI Analysis Timing Analysis Setup/Hold

3/3/04

SoC Encounter

Celtic Encounter NanoRoute Sign-off extractor

82

Timing and Signal Integrity Closure Steps ‹ Run timing analysis to determine if there are violations in your design. ‹ Run in-place optimization and fix setup and hold violations. Set the IPO mode using the setIPOMode command. You can set the mode to -highEffort, which will automatically call synthesis optimization transforms to meet timing. Use fixSetupViolation and fixHoldViolation to fix timing violations in your design. Syntax initECO ipo.txt fixSetupViolation endECO Bracketing the IPO commands with the initECO and endECO commands will log the changed components in the ipo.txt file. ‹ Run a signal integrity-aware ECO route using NanoRoute. ‹ Run a signal integrity (SI) analysis. ‹ Fix crosstalk. Use the fixCrosstalk command in signoff mode to run the CeltIC™ and NanoRoute™ tools to iteratively analyze and fix the signal integrity violations in the design. Fixing crosstalk involves fixing glitches and also the delay due to noise. 3/3/04

SoC Encounter

83

Timing and Signal Integrity Closure Steps (continued) ‹ Add filler cells.

‰ ‰

Adding filler cells after routing will not cause DRC violations in the design because the tool will analyze potential violations before selecting the appropriate filler cells from the physical library. Use the addfiller command to add filler cells to your design.

‹ Add metal fill.

‰

Use the addMetalFill command with the -layer option.

‹ Fill notches.

‰

Filling notches at this stage is necessary to prevent errors downstream in tools which check masks for notches and gaps.

‹ Verify metal density. ‹ Verify geometry, connectivity, and antenna.

‰

3/3/04

The verifyConnectivity, verifyGeometry and verifyProcessAntenna commands generate markers and error logs of the DRCs in the design.

SoC Encounter

84

Timing and Signal Integrity Closure Steps (continued) ‹ Extract the design using the Fire & Ice® QXC tool. Assume metal fill for

the extraction. ‹ Run a signal integrity-aware ECO route using the NanoRoute tool. ‹ Run a timing analysis and fix setup/hold times.

Command Syntax for IPO and Timing Closure setIPOMode –high fixSetupViolation fixDRCViolation fixHoldViolation

3/3/04

SoC Encounter

85

Timing and Signal Integrity Closure Steps (continued) Signal Integrity Closure Commands ‹ The fixCrosstalk command performs an incremental or signoff SI

analysis, repair, and RC extraction based on the options that you specify. ‹ The fixGlitchViolation command creates a violation file for SoC

Encounter to fix. ‹ The fixNoiseDelay command fixes the delta delay caused by noise.

This command takes timing into consideration.

3/3/04

SoC Encounter

86

®

IPO and Physical Optimization

Module 10

March 3, 2004

Physical Optimization Flow From Block or TopLevel Implementation Placement

Netlist

Constraints

Run through SoCE/PKS Interface

Full PKS Optimization Capabilities

Create Path Groups Pre-Clock Optimization Clock Tree Synthesis Useful Skew Optimization

Standalone PKS

TD Global Route IPO TD Global Route IPO Setup/Hold Fixing

PKS Encounter

To Block or Top-Level Implementation Routed DEF

Optimized Netlist

NanoRoute Sign-off extractor

SPEF

Equivalence Checker Optional Step

3/3/04

SoC Encounter

88

Physical Optimization Flow (continued) From Block or TopLevel Implementation Placement

Netlist

Constraints

Run through SoCE/PKS Interface

Full PKS Optimization Capabilities

Create Path Groups Pre-Clock Optimization Clock Tree Synthesis Useful Skew Optimization

Standalone PKS

TD Global Route IPO TD Global Route IPO Setup/Hold Fixing

PKS Encounter

To Block or Top-Level Implementation Routed DEF

Optimized Netlist

NanoRoute Sign-off extractor

SPEF

Equivalence Checker Optional Step

3/3/04

SoC Encounter

89

Optimization Transforms Full set of logical synthesis transforms are available in conventional synthesis, including:

LEF,.lib, .alf, .tlf

RTL/ Gate-Level Netlist

Timing Constraints

DEF/ PDEF

‰ Restructuring ‰ Cloning ‰ Buffering

Parsing, Structuring, Mapping

‰ Resizing

Initial Placement

Each optimization is incrementally placed, routed, and timed.

PKS

Optimization Transforms restructure, clone, resize, buffer, etc.

‰ Allows millions of logical and

physical tradeoffs against highly accurate timing.

Incremental Placement Time using Steiner Route

106

accept/reject

‰ If placement is not possible,

Placement Legalization

logic change is rejected.

3/3/04

SoC Encounter

90

Group Paths ‹ By default, PKS optimization works on one path at a time. The path

worked on is the one with worst slack. Hence if a path is over constrained, the remaining paths are not optimized. ‹ Group path command distributes paths into different groups, and the

path with the worst slack in each group is now optimized. ‹ All paths originally start in the default group (default). ‹ Translator will now automatically translate Synopsys group_paths

command to the BuildGates equivalent Tcl command. Example set_path_group –name IO –from [find –input]

3/3/04

SoC Encounter

91

Physical Optimization Steps ‹ Create the path groups. ‰ Path groups are recommended to isolate specific areas of the design. This

helps to assist in uncovering areas that are prone to closure issues and allows the optimizer to close timing on the rest of the design. ‹ Run preclock optimization. ‹ Run pre-CTS useful skew. ‹ Run clock tree synthesis. ‰ Synthesize the clock tree. Analyze the clock tree reports to determine if

constraints have been met. ‹ Run a useful skew optimization.

3/3/04

SoC Encounter

92

Physical Optimization Steps (continued) ‹ Run timing-driven global routing. ‰ Global routing creates the route plan for the detail router. The extraction

and timing analysis at this stage will provide you with an accurate picture of what to expect after detail routing. ‹ Do in-place optimization (IPO) if there are timing errors. ‰ Run the design through IPO to optimize the timing.

‹ Rerun global routing. ‰ Because the netlist has been modified, the route plan has to be re-

created. ‹ Rerun in-place optimization, if there are violations.

3/3/04

SoC Encounter

93

IPO Strategies IPO has two major phases: ‹ Global optimization phase (also known as weed-whacking) ‰ Transforms are applied to all violating nets/instances in a global pass.

‹ Critical path fine tuning phase (high effort only) ‰ Transforms are applied to a small critical range of the violating

nets/instances

IPO refines placement, runs trial route, runs extraction, and updates timing at the end of each major step. ‹ Uses incremental trial route for better run times. ‰ Only nets touched by IPO are rerouted.

3/3/04

SoC Encounter

94

Optimizing Setup Timing In SoC Encounter, IPO has three effort levels: ‹ Low effort This level performs changes, such as buffering long nets or resizing cells. This step is extremely fast and needs to be used at the prototyping stage.

‹ Medium effort This level triggers more optimization process than -lowEffort does, and further optimizes the most critical paths. Its target is to get an accurate estimation of the design performance or to close timing on less challenging designs.

‹ High effort You need to use this level to reach timing closure for challenging designs. It turns on all the physical synthesis optimization transforms.

Syntax setIPOMode -highEffort

3/3/04

SoC Encounter

95

Optimizing Setup Timing (continued) There are two separate commands for Setup optimization. ‹ Setup timing optimization after placement ‰ setIPOMode -highEffort ‰ fixSetupViolation

‹ Setup timing re-optimization ‰ setIPOMode -highEffort ‰ optCritPath

After each individual optimization step, fixSetupViolation performs placement legalization, routing, extraction, and timing updates.

3/3/04

SoC Encounter

96

Fixing Setup Using IPO setIPOMode –low/-medium fixSetupViolation

Downsize

Resize

After each optimization step, placement legalization, routing, extraction, and timing update are performed.

Buffer insertion

Resize setIPOMode -high fixSetupViolation

optCritPath

Critical Paths Optimization using Physical Synthesis transforms

Use Model Use fixSetupViolation after placement. Use optCritPath for re-optimization.

3/3/04

setIPOMode -usefulSkew Useful Skew

*

setIPOMode -reclaimArea

reclaimArea

Reclaim Area SoC Encounter

* = Not by default 97

Downsizing/Resizing ‹ Initial global pass downsizes gates without worsening violations. ‹ For medium and high effort, initial resizing does the following: ‰ What-if analysis for all candidates to be resized without committing the

resizes ‰ Order resize moves in decreasing order of gain ‰ Commit resize moves in above order, invalidating neighboring moves for

each committed move ‰ Iterate until number of moves found or slack improvement is negligible or

maximum # of pass (10) is reached ‹ Combinational and sequential resizing are done separately. ‹ A global sizing pass is run to improve DRVs. ‹ In high effort, second global sizing does a greedy input-to-output pass

with more accurate delay updating to guarantee no slack worsening.

3/3/04

SoC Encounter

98

Buffering For each violating net, from input to output, ‹ The tool chooses a wire topology ‰ TrialRoute topology ‰ Topology based on physical clustering (similar to CTS)

‹ Quick buffering is done for each topology assuming certain capacitive

load per buffer. ‹ The topology with the fewer number of levels of buffers is chosen. ‹ Buffering prefers trialRoute topology in case of tied results. ‹ Buffering determines which segment is not bufferable due to no-new-

port, and dont-touch constraints.

3/3/04

SoC Encounter

99

The optCritPath Command Boolean restruct

pinswap deleteBuffer resize addBuffer resize

setIPOMode -highEffort

‹ Each step operates on a 5%

critical range of the violations.

topoMap

‹ The optCritpath command

optimizes the critical paths and stops when target slack is met or when timing cannot be optimized further. ‹ It tries to improve the worst

remapCone

mergeInverter

negative slack and you must use it each time you want to reoptimize a netlist. 3/3/04

remapGate

SoC Encounter

moveInstances

100

Design Rules Violation Fixing ‹ DRV fixing is done during fixSetupViolation, and the remaining DRVs

can be cleaned using the fixDRCViolation command. ‹ The fixDRCViolation command will loop up to three times to fix the

DRV. Use -maxIter to specify the number of loops allowed. ‹ To check if DRVs are cleaned, use the isDRVClean command. Reports 0 or 1.

‹ An extra pass of DRV fixing is run in global optimization phase (weed-

whacking). To report the DRV, use: reportTranViolation/reportCapViolation/reportFanoutViolation

Use bufferMultiDriverNet to fix all DRV on multidriver nets.

3/3/04

SoC Encounter

101

Optimization Guidelines ‹ Creating a clean footprint file is important. ‹ No or bad footprint definitions leads to less than optimal IPO results. ‹ Use the checkFootPrint command after making a footprint file. ‹ Steps to making a footprint file: ‰ Generate a footprint file. ‰ Modify this file to specify the buffer, inverter, and delay cell footprints to

separate the cells that you don’t want to use. ‰ Load the footprint file.

‹ The IPO process will also respect the set_dont_use attribute.

3/3/04

SoC Encounter

102

Optimization Guidelines (continued) After running IPO, you must examine the remaining violating paths or DRV for the following possibilities: ‹ Be sure that the Worst path can meet your target slack. ‹ Use Path Group to further optimize the design. ‹ If there are remaining DRVs, then call fixDRCViolation. ‹ Check routability numbers from TrialRoute. ‹ Check the congestion map to see if worst paths are going through

local congestion hot spots. ‹ If there are congestion issues, then run placement in congestion-

driven mode followed by IPO. ‹ If there are timing issues, try IPO on a design that has been placed

using the -timingdriven option.

3/3/04

SoC Encounter

103

3/3/04

SoC Encounter

104

®

Postmask ECO Flow

Module 11

March 3, 2004

Making Postmask Changes to the Design Reasons for Making Changes ‹ Base layers of the design have been taped out and you have found

logic errors. At the same time, you need to preserve the poly and diffusion layers that are already taped out. To fix the errors, you need to ‹ Route to pre-existing spare-cells. ‹ Change only metal and via layer masks by rerouting to spare cells.

You can create ‹ A new netlist with minor logical changes based on the old netlist

or ‹ A new ECO file

3/3/04

SoC Encounter

106

Procedure: Postmask ECO with a New Verilog File To prepare for postmask changes spare cells could have been added to the netlist prior to generating a mask. There are two ways in which spare cells are added to the design: ‹ Spare cells are added to the original Verilog netlist. ‰ Spare cells are identified with this command:

specifySpareGate –inst mySpareInst ‹ Spare cells are added using a previous spare.eco file: ‰ ADDHIERINST mySpareInst mySpareCellName ‰ ADDINST mySpareInst/mySpareAnd_1 AND2 ‰ ATTACHTERM mySpareInst/mySpareAnd_1 IN1 VSS ‰ ATTACHTERM mySpareInst/mySpareAnd_1 IN2 VSS ‰ followed by loadECO spare.eco

3/3/04

SoC Encounter

107

Postmask ECO with a New Verilog File Read old Verilog® floorplan, placement, routes files into the Encounter engine. Compare current netlist to new Verilog netlist to create an ECO file. ecoCompareNetlist -verilog new.v -outFile oldchip.eco ‹ The ECO file has all changes required to make the current netlist match the

new netlist.

‹ Physical-only cells like filler cells are ignored.

Load the ECO file to update the current netlist to match the new netlist. loadECO -useSpareCells -suffix _SPARE oldchip.eco ‹ Instances that only appear in the old Verilog netlist are implicitly deleted by

leaving them in place and changing the name (i1/i2/i3 to i1/i2/i3_SPARE). The dangling inputs are attached to GND.

‹ New instances are placed by using the nearest matching sparecell with the

same cell.

‹ New ports are created on Verilog modules as needed. ‹ Routing on deleted nets is removed. ‹ Error messages are output for any unplaced cells. 3/3/04

SoC Encounter

108

Postmask ECO with a New Verilog File (continued) ‹ Incremental route with NanoRoute/WRoute ‰ Antenna diodes are disabled because poly/diffusion cannot be modified. ‰ Routers automatically detect opens and shorts, and incrementally route

any nets that are incomplete or have violations. ‹ The old Verilog netlist after ECO might be slightly different from the

new Verilog netlist. ‰ The auto-generated ports and nets probably have different names.

3/3/04

SoC Encounter

109

Postmask ECO with a New Verilog File Example Tcl Script # Read old Verilog netlist into Encounter

loadConfig oldchip.conf # Read old floorplan, special routes, placements and routing

defIn oldchip.def # Compare the current old netlist to the new Verilog netlist

ecoCompareNetlist -verilog new.v -outFile oldchip.eco # Load the ECO file to incrementally update the current netlist to match the new netlist

loadECO -useSpareCells -suffix _SPARE oldchip.eco # Write out changed Verilog netlist if desired

saveNetlist oldchip_after_eco.v # Incremental route

setNanoRouteMode routeInsertAntennaDiode false globalDetailRoute

3/3/04

SoC Encounter

110

Comparing Netlists ‹ The following command compares the currently loaded netlist with a

different netlist file: ecoCompareNetlist {-verilog | -def } -outFile ‰ The ecoCompareNetlist command uses instance names and net names

for matching. ‹ An ECO file (file.eco), or change list, is generated. ‰ The file has all the changes needed to differentiate the current netlist from

the external netlist. ‰ The file.eco contains the loadECO syntax.

‹ The Verilog file must already be uniquified.

3/3/04

SoC Encounter

111

The loadECO Command and Spare Cell Support You can use the following command to support spare cells in the design: loadECO[-useSpareCells | -useGACells ] [-suffix ]

-useSpareCells

‹ For a newly added instance, spare cells are chosen by looking for a spare cell that matches the new cell type and is closest to the pins connected to the new instance. ‹ When an instance is deleted, it is really renamed as a spare cell ‰ i1/i2/i3 becomes i1/i2/i3_SPARE ‹ If a net is deleted, any routing attached is deleted ‹ If a net is modified, any routing attached is not affected

-suffix

‹ Suffix to append to new spare cells, default “_SPARE”

-useGACells

‹ Same as –useSpareCells except for GACoreSite type cells. ‹ New GACoreSite type cells are left unplaced. ‹ Deleted GACoreSite cells are really deleted.

3/3/04

SoC Encounter

112

®

Blackbox What-If Timing Analysis

Appendix A

March 3, 2004

What-If Timing Analysis What-If Timing Analysis: The capability allowing on-the-fly modifications of blackbox timing arcs along with subsequent STA.

The design cycle can start: ‹ Without blackbox timing models ‹ With preliminary blackbox timing models (soft IPs)

You can use What-If commands for a powerful and interactive budgeting at the top level of the design.

3/3/04

SoC Encounter

114

Timing Model Normalized 5

4

6

5

4

6

1

2 7

#

3

Data Type

Command

1

Combinational delay from an input port to an output port, setBlackBoxCombDelay including the driver delay

2

Timing check, delay from the clock input port to the data input setBlackBoxTimingCheck port

3

Sequential delay from the clock input port to the data output port, including driver delay

setBlackBoxSeqDelay

4

Driver type Driver input slew Total driver output net capacitance (optional)

setBlackBoxDriveType

Clock insertion delay to internal registers

setBlackBoxClockLatency

5 6 7

3/3/04

SoC Encounter

115

What-If Graphical User Interface

3/3/04

SoC Encounter

116

Application Examples Top-Down Flow ‹ You can define a preliminary timing model and the constraints of a

blackbox in its environment at the top level. ‹ You can refine timing models and constraints of soft IPs, taking into

account a new top-level design environment. Starting Block Implementation Before Top STA ‹ After importing the netlist of a blackbox, you can refine its timing

budget. ‹ Run a top-level STA using a timing model from block synthesis. Then,

check the model and generate a new set of SDC constraints if needed.

3/3/04

SoC Encounter

117

3/3/04

SoC Encounter

118

®

SoC Encounter Support for TSMC Reference Flow

Appendix B

March 3, 2004

Crosstalk Prevention Using Encounter ‹ Placement and optimization stage ‰ Set max transition to prevent weak victims. ‰ Avoid the strong aggressors created by sharp transition.

‹ Postplacement stage ‰ First Encounter: slew balance and congestion removal

‹ Routing stage ‰ NanoRoute: global routing, track assignment, and detail routing with

crosstalk prevention ‹ Prevention effects ‰ Routing is more effective than placement in crosstalk prevention. ‰ Target for reducing crosstalk violations is 50% or more per iteration.

3/3/04

SoC Encounter

120

Crosstalk Repair Using Encounter CeltIC — First Encounter — NanoRoute — CeltIC loops ‹ NanoRoute fixes glitch violations. ‹ First Encounter fixes timing violation.

Most crosstalk glitches and timing violations are fixed in 3 iterations. Manual script is used to fix remaining violations. ‹ High-strength victim nets ‰ Wire spacing ‰ Buffer insertion

‹ Low-strength victim nets ‰ Cells are sized up.

3/3/04

SoC Encounter

121

Encounter Supports Design for Manufacturability in Reference Flow Design for manufacturability (DFM) provides increased visibility into the manufacturing process. DFM addresses nanometer challenges, including: ‹ Uniform density and thickness ‹ Via placement ‹ Signal electromigration ‹ Dynamic IR drop ‹ LEF spacing and blockage modeling enhancements ‹ Routing rule support in NanoRoute tool ‹ Reliability enhancements (such as double cut vias)

DFM is incorporated through design rules, tech files, and scripts.

3/3/04

SoC Encounter

122

Redundant Via Insertion Methodology For Yield Improvement, NanoRoute supports redundant via insertion for TSMC 130 nm and 90 nm technologies.

0.08 µ 0.05 µ

(f)

(d)

(a)

(b)

0.05 µ 0.05 µ

0.08 µ

0.005 µ

0.005 µ 0.05 µ

0.005 µ

0.005 µ

(a)

(c)

(b)

(c) 0.08 µ

0.05 µ

0.05 µ 0.08 µ

0.005 µ 0.005 µ

0.005 µ

(d)

3/3/04

(e)

(f)

SoC Encounter

123

3/3/04

SoC Encounter

124

®

Partitioning

Appendix C

March 3, 2004

Partition Menu Design

Partition

FloorPlan

Place

Specify Partition... Specify Black Box Create Feedthroughs… Assign Black Box Pins Show Wire Crossing Estimate Routing Channel… Partition… Unpartition… Check Pin Assignment Change Partition View

3/3/04

SoC Encounter

Clock

Route …

Creates the partitions. Displays Trial Route feedthrough wires that are crossing over a selected partition. Flattens the partition. Changes design view between chip level and partitions.

126

Blackbox Options A blackbox is a special application of the partition. ‹ Create a LEF file for the hierarchical instance (module, submodule, or block)

and enter the file name in the Design Import form. ‹ After importing the design, dark blue colored blackbox guides appear with the

blocks. ‹ Complete floorplanning with the blackbox. ‹ Use the command, specifyBlackBox . ‹ Use the Specify Partition form for blackboxes as well as for partitions. ‹ You can resize the blackbox. Apply the resizeBlackBox command. ‹ Run placement and Trial Route. ‹ Generate blackbox pins by applying the blackBoxPinAssign command. ‹ The Save Partition form will also create a blackbox subdirectory.

3/3/04

SoC Encounter

127

Blackbox Pin Assignment Before Black Box Pin Assign

You need to update the Blackbox abstract file with the pin placements.

After Black Box Pin Assign

3/3/04

SoC Encounter

128

Specifying a Blackbox Partition – Specify Black Box

The following text commands provide equivalent or additional functionality: ‰ resizeBlackBox ‰ specifyBlackBox ‰ unspecifyBlackBox 3/3/04

SoC Encounter

129

Partitioning a Design ‹ Divides the design task into manageable partitions so that work can

continue on several blocks in parallel. ‹ Partitioning uses the full-chip environment and performs analysis to ‰ Analyze top-level route congesting from early top-level floorplanning

information. ‰ Optimize pin assignment based on full-chip placed and routed (in-context)

results. ‰ Push down the top-level floorplan objects (power plan, blockages) into

each partition if they overlap the partition. ‰ Generate timing budgets based on full-chip timing analysis.

Timing constraints, clock exceptions, and path exceptions are pushed down to all partitions. Stamp models are generated for the partitions.

3/3/04

SoC Encounter

130

Results of Partitioning Results of partitioning are two levels of partition hierarchy — the top-level infrastructure and the partition level. ‹ Partitioning generates top-level partitions and pushes down floorplan

objects to the floorplan file. ‹ Partitioning generates all the necessary files for the First Encounter

engine and other backend tools. You create partitions that exist: ‹ Logically

A partition is one of the modules or submodules in the design. ‹ Physically

A partition must be completely intact and constrained by a fence.

3/3/04

SoC Encounter

131

Steps in Partitioning a Design Specifying the Partitions The name of the module that you want partitioned.

Partition – Specify Partition Directory where the files that belong to the partition will be saved.

Layer names are determined from the technology file. The LEF file for the partition will contain obstructions for the unselected layers.

3/3/04

SoC Encounter

132

Steps in Partitioning a Design (continued) Specifying Partition Pins Partition Pins

Core of Partition

Std Cell Row

3/3/04

Min Pin spacing on all sides

SoC Encounter

133

Steps in Partitioning a Design (continued) Partitioning the Partitions Partition – Partition

3/3/04

SoC Encounter

134

Steps in Partitioning a Design (continued) Saving the Partition – Creates the infrastructure for the hierarchy. Design – Save Partition

3/3/04

SoC Encounter

135

Specifying a Module to Be a Partition Specifying the Partitions ‹ Each specified module must first be floorplanned. ‹ For multiple instantiated modules to be partitioned you need to

uniquify the netlist in the synthesis step of the design process. ‹ You can change the standard cell row height and place the partition’s

pin away from standard cell power rails.

3/3/04

SoC Encounter

136

Multiply Instantiated Partitions Handling Repeated Partitions ‹ These are multiple instantiated hierarchical instance of same cell type. ‹ You can choose all or none of them are to be partitions. ‹ You can choose to modify the netlist, so hierarchical instance names

are unique. ‹ The hierarchical instance entered in the Specify Partition form is the

master partition and other partitions are clones of it. ‹ Clones can have orientation changed using their Attribute form during

floorplanning.

3/3/04

SoC Encounter

137

Running the Unpartition Program Use the Unpartition program to remove selected partitions from a design. If changes are necessary for any of the partitions, you can change the partition status from a block to a fence. Choose Partition – Unpartition.

3/3/04

SoC Encounter

138

Deriving Timing Budget Files for Partitions Partition – Partition

The Trial IPO Estimates option produces proper timing constraints between partitions.

To resolve multiple timing constraints for I/O partitioning

Proportional will create proportional timing constraints between partitions.

3/3/04

SoC Encounter

139

Timing Budgeting Each block requires: Block 1

Clock definition set_input_delay

L

Block 2

set_output_delay

L

set_drive set_load

L

Path exceptions (False, multicycle paths)

Block 3

Accurate timing budgets result in predictable timing convergence. 3/3/04

SoC Encounter

140

Deriving Timing Budget Files for Partitions (continued) ‹ Produces proper timing constraints between partitions. ‹ Resolves conflict for multiple timing constraints for partition I/Os. ‹ Makes the timing constraints proportional between top and partitions or can fix

the top first.

After Saving Partition Top Level Files top.v top.conf top.fp top.fp.spr top.lef top.constr top.dat top.def top.lib top.tlf top.pwr.cmd

3/3/04



Partition Files

Files for FEU



par_1.v par_1.conf par_1.fp par_1.fp.spr par_1.constr par_1.constr.pks par_1.constr.pt

Files for FEU and third party tools

SoC Encounter

par_1.trk.tcl par_1.def par_1.pdef par_1.fp.cmd par_1.pwr.cmd par_1.pin.tdf 141

Timing Budget – Interface Logic Models ‹ Interface logic models (ILMs) provide an accurate, yet simplified timing models

for hierarchical design. ‹ The original gate-level netlist of a block is modeled by another gate-level netlist

that contains the interface logic of the block. ‹ The logic other than the interface logic is stripped out, thus simplifying the

number of computations and shortening the time taken to perform timing analysis.

A

B

3/3/04

X

A

X

B

Y

Y

SoC Encounter

142

Partitioning ILMs Bottom-Up Flow Use the interface logic model (ILM) flow to produce accurate timing analysis for a completed partition design. To prepare for an ILM flow: 1. Make sure the work directories are created by a partition flow (saving partition). 2. When the design work is complete for all partitions, use the two commands to derive and save the ILM netlist and SPEF files for each partition. deriveInterfaceLogic saveInterfaceLogic -spef 3. To do timing analysis for the entire chip, cd to the top-level directory where the work is complete.

3/3/04

SoC Encounter

143

Partitioning ILMs Bottom-Up Flow Top Level Note When restoring the design, you need to stitch the SPEF file for each partition by using the spefIn command.



(continued)

Completed chip netlist

Design Import with partition ILM files Load top -level floorplan Load partition SPEF files by:

spefIn -ilm

With ILM files from Step 2, the First Encounter tool is now in an ILM mode.

for all partitions

Run Placement and Trial Route Flatten ILMs When the timing graph is built, the SPEF data for the partitions are stitched and the SPEF for the top level are automatically extracted and stitched.

3/3/04

Extract RC Timing Analysis and Optimization

Trial Route knows to route to the partition pin locations.

Un-Flatten ILMs Top-Level CTS and Detail Route Save Design SoC Encounter

144

Partition Floorplan Objects Partition Pin Blockage — to block area from creating pins on specific metal layers. Select the metal layers to be blocked. Partition Feedthrough — to assign routing feed through area on a specific metal layers. Feedthrough object must cut through both sides of the partition. Add Partition Pin Guide — to assign guides where you want to place certain pins on the partition.

3/3/04

SoC Encounter

145

Partition Floorplan Object — Partition Feedthrough You can use Partition Feedthrough to reserve space in a partition for toplevel routing and buffer insertion. This flow is to: ‹ Create partitions. ‹ Create partition feedthroughs. ‹ Commit partitions.

Partition feedthrough affects only the physical aspect of the partition not the logical aspect. The two types of partition feedthrough are: ‹ Channel — For top-level routing ‹ Placement island — For top-level buffer insertion

3/3/04

SoC Encounter

146

Partition Floorplan Object – Partition Feedthrough (continued) ‹ Method 1: Use the Add Partition

Feedthrough icon to create the feedthrough buffer on the partition. Double-click the buffer to open the Object Attribute form, specify the metal layer, and click OK.

Partition Feedthrough Floorplan icon

Use Partition – Create Feedthrough

This creates the channel for the routing on the specified layers at the top level and pushes down appropriate routing blockages at the block level. ‹ Method 2: To specify narrow

feedthroughs or several of them on a given partition, choose Partition – Create Feedthrough to open the Create Feedthrough form.

3/3/04

SoC Encounter

147

Partition Feedthrough – Placement Island At partition level, commit partition automatically creates the following: ‹ Routing blockage(s) for channel feedthrough ‹ Placement blockage for placement island feedthrough

Channel Feedthrough (layer = M6)

Routing Obstruction (M6)

Channel Feedthrough (layer = M5)

Placement Obstruction

Placement Island Feedthrough

Partition with Partition Feedthroughs

3/3/04

Routing Obstruction (M5)

Committed Partition

SoC Encounter

148

Finding Feedthrough Nets Use the showPtnWireX command to find nets that cross partitions. showPtnWireX [ptnName] [–outfile ] [-exclude Net ]

‹ Use ptnName to generate a file that lists the nets that cross a

specific partition. Use the output file as a starting point to generate a list of nets for feedthrough insertion. ‹ Not all nets in the generated partition-crossing net file will become

feedthrough nets automatically. ‹ You need to decide which nets to use for inserting feedthrough buffer

cells and add them to the excluded nets file.

3/3/04

SoC Encounter

149

Partition Feedthrough Buffer Insertion Use insertPtnFeedthrough for inserting partition feedthrough buffer cells insertPtnFeedthrough –bufCell -selectNet | { -chanLess [-excludeNet ] } {-doubleBuffer | -nobuffer} [-netMapping]

The -chanLess option specifies that the design is pure channelless, having no channel available for routing, and therefore all nets must be selected for feedthrough insertion.

3/3/04

SoC Encounter

150

Partition Feedthrough Buffer Cell (Continued) Use netMapping to generate a mapping file for the original and new created net names. Use doubleBuffer to insert 2 buffers for feedthrough nets. ‹ Insert one buffer close to incoming pin and another one close to an

outgoing pin. ‹ Without this option, the buffer is inserted near the incoming pin.

Technique ‹ Create new feedthrough pins. ‹ Insert buffers and modify netlist. ‹ Run ecoPlace to place inserted buffers.

3/3/04

SoC Encounter

151

Partition Feedthrough Without Buffer Insertion Allow creating logical partition feedthrough without inserting any buffer ‹ Use the insertPtnfeedthrough –noBuffer option. ‹ Adds a Verilog assign statement in the netlist of the partition block.

FE_FEEDX_new_in_port

FE_FEEDX_new_out_port

assign FE_FEEDX_new_in_port

=

FE_FEEDX_new_out_port

;

Note: A dummy buffer with FE_DUMMYCELL cell type is inserted inside the data base to represent an assign statement. 3/3/04

SoC Encounter

152

Partition Floorplan Objects: Partition Pin Guide Partition Pin Guide — to create partition port for a net or a bus name. Must overlap partition fence. 1

2 3

Partition1

Partition2

1. You can create ports at the top side, starting left to right. 2. You can create ports at the top and bottom sides of Partition1 (one set of pins will be actually feed-through pins), and create ports at the top side of Partition2, starting left-toright. 3. You can create ports at the right side, starting bottom-to-top, of Partition1.

3/3/04

SoC Encounter

153

Partition Floorplan Objects: Partition Pin Guide (continued) ‹ Assign net names by changing the

partition pin guide’s Name to a net name, bus name (bus_name[#,#]), or net group name. ‹ For a net group, use these

commands: createNetGroup and addNetToNetGroup. Assign port names by changing the partition pin guide’s name to a port name or pin group name. ‹ For a pin group, use these

commands: createCellPinGroup and addPinToCellPinGroup. ‹ Then, enter cell type name in the

PinGroup Cell field. 3/3/04

SoC Encounter

154

Partition Pin Editor Use the interactive pin editor to edit pin properties: Location Metal layer Pin depth and width Equal spacing Snapping to metal tracks or Microns. Fixing

Choose Tools – Pin Editor.

Can list pins as: All Side Unassigned Other (group)

‰ ‰ ‰ ‰

Group pins as a bus.

3/3/04

SoC Encounter

155

Channel Width Estimation ‹ After specifying the partition, you

can estimate the required spacing between partitions, blackboxes, and hard macros, and update the floorplan based on the required spacing information.

To estimate the routing channel, choose Partition – Estimate Routing Channel.

To estimate the routing channel, use this form: ‹ This will output an estimate of the

required spacing surrounding each partition based on its pins, the relative distance between partition blocks required for toplevel routing. This output also includes the estimated distance between blocks and core boundaries (top, bottom, left, right). 3/3/04

SoC Encounter

156

Example Report of Channel Width Estimation Instance name Block1

HB1

BB1

bot-boundary bot-boundary bot-boundary lft-boundary lft-boundary lft-boundary INST1 INST1 HB1 HB1 INST4 INST4 … …

INST4

INST3 INST2 INST1

Partition

3/3/04

HB2

Hard macro

Blackbox

SoC Encounter

Block2

Spacing in micron Current

INST1 24.6 INST2 54.3 HB2 25.0 INST1 38.2 INST3 43.2 HB1 46.8 INST3 64.8 INST2 72.1 top-boundary 57.2 BB1 44.5 top-boundary 59.5 rht-boundary 53.0 … … … …

Required 28.8 46.9 31.2 45.5 37.8 33.5 39.4 55.7 10.9 69.1 51.7 50.5 … …

Core boundary edge

157

Channel Width Estimation Constraints Set the following block placer constraints when adjusting channel widths ‹ Block halo ‹ Block-to-block distance (setBlockDistance) ‹ Block-to-boundary distance (setBlockToBoundary) ‹ Block order and alignment (setBlockOrderAlignment) ‹ Net weight (specifyNetWeight)

Reshape blackboxes and partitions to improve congestion ‹ The Channel Width Estimator honors user-specified block aspect ratio

constraint (setBlockAspectRatio).

3/3/04

SoC Encounter

158

Global Partition Pin Size ‹ You can define the global pin size constraint for a specific partition. ‹ Set the global pin width, the pin depth, or both.

Applies to all pins of a partition that do not have their own pin widths/depths. Use the setPtnPinWidth and setPtnPinDepth Tcl commands to set global pin width and depth, respectively. setPtnPinWidth setPtnPinDepth Width (in micron) Depth Width Depth 3/3/04

SoC Encounter

159

Channelless Partitions Different types of hierarchical design methodology: ‹ Channel-based (All top-level routing use channels.) ‹ Channelless (All top-level routing use feedthroughs.) ‹ Mixed (Some top-level routing use channels; some use feedthroughs.)

Channel-based methodology

3/3/04

Channelless methodology

SoC Encounter

Mixed methodology

160

Channelless Partitions (continued) Techniques and approaches to insert feedthroughs ‹ Use insertPtnFeedthrough command. ‰ Changes the top-level and partition-level netlists.

‹ Use Partition – Create Feedthrough to create feedthroughs ‰ No netlist change

insertPtnFeedthrough is recommended for pure channelless or mixed methodology.

3/3/04

SoC Encounter

161

Channelless Partitions Simple Methodology Flow ‹ Design import ‹ Floorplan a design ‹ Specify partitions ‹ Place (with Amoeba) ‹ trialRoute ‹ showPtnWireX ‹ insertPtnFeedthrough ‹ trialRoute ‹ extractRc ‹ buildTimingGraph ‹ Commit partition ‹ Save partition 3/3/04

SoC Encounter

162

Channelless Partitions Simple Methodology Flow

(continued)

showPtnWireX generates an output file that lists all nets routed over partitions. You have a choice of inserting feedthroughs for all nets or only for selected nets. insertPtnFeedthrough can read a file that lists all the top-level nets for feedthrough insertion. This command does the following: ‹ Inserts buffer or buffers for the feedthrough nets. ‹ Modifies the netlist. ‹ Places buffers in the appropriate locations. ‹ Generates a partition boundary. ‹ Creates a timing budget with feedthroughs.

3/3/04

SoC Encounter

163

Channelless Partitions Example of Channelless Methodology Design After Committing Partitions

3/3/04

SoC Encounter

164

®

Flip-Chip

Appendix D

March 3, 2004

Flip-Chip Functions ‹ Supports full flip-chip flow. ‹ Creates bump MATRIX. ‹ Creates rows for I/O placement. ‹ Runs automatic I/O placement. ‹ Runs signal routing from bumps to I/O. ‹ Runs power routing from bumps to stripes. ‹ Supports flat and hierarchical flows. Chip bumps Contact pads

3/3/04

SoC Encounter

166

Area I/O Features ‹ Bump and tile flows ‰ Tile selection ‰ Bump array and matrix generation ‰ Bump assignment (signal and power/ground) ‰ I/O row generation ‰ Interface to CIOP (route feasibility)

‹ AIO placement ‹ Routing ‰ SRoute power and signal bumps ‰ Differential routing

‹ Hierarchical flow – partition ‹ LEF syntax

3/3/04

SoC Encounter

167

Area I/O Flows Verilog

I/O file (Bump/Rows)

LEF

Floorplan

Bump Flow

Edit Bumps Route Feasibility Interface Add Stripes

CIOP Route Feasibility

Place AIO Assign Bumps Route Bumps

3/3/04

Partition

PlaceCells

Block Design

RouteDesign

SoC Encounter

SOCE CIOP

168

Flip Chip: Add Tile Icon Placing Tiles ‹ Tiles are a group of bumps. ‹ Tiles can contain macros

and routing.

Add Tile Icon

3/3/04

SoC Encounter

169

Flip-Chip and Chip I/O Setup Create bump array (4x4) to match package balls.

3/3/04

SoC Encounter

170

Flip-Chip: Signal Assignment

Select an I/O signal.

3/3/04

SoC Encounter

171

Flip-Chip: Signal Assignment (continued)

Signal Bumps Blue = signal assigned

CLK

DI[0]

3/3/04

SoC Encounter

172

Flip-Chip: Power/Ground Assignment Select Bumps and assign power ‹ Red = power

Select Bumps and assign ground ‹ Yellow = ground

Signal Bumps ‹ Blue = signal

Signal

3/3/04

SoC Encounter

Power

Ground

Signal

173

Flip-Chip: I/O Driver Row Place rows for I/O driver cells. These areas are used by placeAIO.

I/O Row

3/3/04

SoC Encounter

174

Flip-Chip: Route Feasibility Inputs ‹ Aio_bga.cio # package binary ‹ Default.ldf

# Lef/cml pointer

Outputs ‹ route_feasibility.cio

# binary

‹ route_feasibility.rpt

# report

‹ Highlight un-routable Bumps

CIOP package routing

3/3/04

SoC Encounter

175

Place: PlaceAIO placeAIO places I/O driver in rows. LEF OBS LAYER OVERLAP ‹ Restricts standard cell

placement. Overlap

IO Driver

Bump

3/3/04

SoC Encounter

176

Partition – Internal Pin for Better Routing Bump is pushed into Blk2 Blk1

Blk2

Routing without internal pin

3/3/04

Routing with internal pin

SoC Encounter

177

Partition Commands ‹ Move module inside floorplan view ‹ Double click on partition (attribute editor) – change size ‹ placeAIO and trialRoute ‹ Specify partition ‹ handlePtnAreaIo

# New TCL command

‹ commitPartition ‹ checkPinAssignment ‹ Change partition view

3/3/04

SoC Encounter

178

Partition – FeedThru Buffer Partition

IO Cell

Bump input IO output (internal pin) Inserted buffer Boundary Pin Partition Standard cell

3/3/04

IO Driver output Buffer

SoC Encounter

179

Partition – Commit

Partition

3/3/04

Placement Island

SoC Encounter

180

Partition – Block: Push Down Blockages

Cell already in module

Bump Routing Blockage

P&R Blockages

3/3/04

SoC Encounter

181

LEF 5.5 Syntax BUMP MACRO bumpcell CLASS COVER BUMP ; Pin PAD ;

# no SITE required. Only one pin is allowed

Driver Cell MACRO drivercell CLASS PAD AREAIO ; SITE IO ; PIN IN ; LEF Tile Macro

# multiple pins – must be flattened

MACRO Tile1 CLASS COVER BUMP ; * “BUMP” is a reserved word in LEF5.5 3/3/04

SoC Encounter

182

Flip-Chip Routing Support ‹ Supports both signal and power bump

routing. ‰ fcroute is the new command that supports

this feature. ‹ Routes signal bump cells to the I/O cell. ‹ Routes power bump cells to the nearby

stripes. ‹ Routes bump pins in the cover macro to the

I/O drivers for the signals. ‹ Routes power bumps in the cover macro to

the stripe rails.

3/3/04

SoC Encounter

183

Flip-Chip Routing Support (continued) Signal Routing ‹ Primary and secondary layer change

control. ‹ An option to use the user-defined

width to do the bump to IO driver connection. ‹ Supports Redistribution Layer (RDL)

Routing. An RDL is a routing layer of conductive metal within an IC that connects the diepad or solder bump to a connection point on an I/O driver. The Encounter router supports routing to this special layer.

3/3/04

SoC Encounter

184

View more...

Comments

Copyright ©2017 KUPDF Inc.
SUPPORT KUPDF