2-mmmc analysis using talus flow manager

MM/MC analysis using Talus FlowMM/MC analysis using Talus Flow Manager

Aravind ChandramohanWipro Limited

Surendra MistryyTexas Instruments

Hari PendurtyInsert Company

Logo Here

Hari PendurtyTexas Instruments

S San Jose, CA | March 10, 2010Copyright 2010 Magma Design Automation, Inc.

Introduction

Timing closure within P&R domain has historically been done with merged mode constraints and MIN/MAX corners.

• Timing signoff done through multi mode multi corner analysis. • Long iterative loops between third party extraction and signoff tools

with respect to timing at all process corners and modes.with respect to timing at all process corners and modes.

Talus 1.X offers multimode multicorner optimization. This evaluation is focused on

• MMMC capability of Talus.• Reasonable runtimes using MMMC.

Magma’s reference flow : Talus Flow Manager (TFM) is used for MMMC optimizations.

2Copyright 2010 Magma Design Automation, Inc.

Talus Flow Manager

Magma’s reference flow from RTL to GDSii.

• Best practices and recommendations from Magma• Best practices and recommendations from Magma.• On the fly updates of latest code releases.• Removes depreciated/not-recommended commands/options

• Modular directory structure with respective ownership User owns only specific directoriesP ll lParallel runs

• Graphical representation of reports through ‘Visual Volcano’Analyze and review reports through tables, graphs and charts

effortlessly across runs and designs.


TFM Setup

TFM supports the following styles:

Flow style :Flow style : Single modeMMMC

D iDomains :Single domainMulti domainUPFUPF

Design Start point :VolcanoNetlistRTL


Floorplan/Domain Setup

• 65nm• 4 power domains• MMMC• I t i N tli t• Input is Netlist

• IO, macro placement and power routing done through custom tools build over Talus• Domain/Floorplan settings are done in variables.tcl• Domains applied through native Talus commands through domainOverride file

set floorPlans { { floorplan1 domain1 {optional list of hierarchical cells} }

{ floorplan2 domain2 {optional list of hierarchical cells} }}}


Design Run

TFM flow was taken through from netlist to routing with focus on

RuntimeQORs:

• Speedp• CTS : Insertion Delay, Skew, Clock power• Quality of Hold Fixing (WNS, number of hold buffers)• Routing closure• Routing closure

Drc closureRedundant Via Insertion

• Leakage recovery• Timing correlation with signoff extraction tool


Run Time reduction

Main contributors for runtime• Too many scenarios to handle• Wire load model used• Secondary cost function recovery effort• Native Talus commands

RebufferingSizing with high effort for second cost function recovery.

Steps taken to reduce runtime:Elmore model was used for fixcell instead of AWE (default).


Run Time reduction contd..

Rebuffering during fix-cell, fix-cell-opt, fix-clock, fix-clock-opt took ~60 – 70% of runtime.

B l t i ti t th d f lt TFM fl f b ff i dBelow customization to the default TFM flow for rebuffering were done:Limited for fixing limit violationsLeakage optimization disabledCloning disabled

Sizing during fixcell was contributing to ~10% of runtime.Sizing during fixcell was contributing to 10% of runtime.Low secondary effort was used during sizing.


Speed

• Netlist which was used for tapeout design at 95Mhz was used• The frequency of 120Mhz was targeted to stress the tool to the

imaximum • Achieved 110MHhz with reasonable runtimes


CTS

• Design had multiple clock sources with different clock origin points • Successive clock generation logic in the same path and many intra

clock domains


CTS Methodology

The clocking scheme prompted a different CTS methodology to be used :

• Existing buffers and back-to-back inverters in the clock network were removed

• All the flop clock pins and latch enable pins were made skew dontcare. This made the tool not balance the clock gates with the clock gate register clock pins.

‘force plan clock $m –pin clk_reg1/clk –skew_dont_care’

• The default clock gating skew groups were dumped out using:g g g p p g‘config_clock_auto_clockgate_balance on’‘report plan clock $m –auto_clockgate_balance’


CTS Methodology contd..

Talus will automatically create CTS constraints to try to balance skew between the ena_reg clock pin and the clock gater clock pin

• The skew don’t care on the clock gate register clock pins were cleared by ‘clear plan clock $m –pin clk_reg1/clk –skew_dont_care’

• The automatic clock gate were re-applied.‘config clock auto clockgate balance off’config_clock_auto_clockgate_balance off‘force plan clock $m –pin clk_reg1/clk -skew_group1‘force plan clock $m –pin clk_gater1/clk_in -skew_group1‘force plan clock $m –pin clk_gater1/clk_in -skew_anchor


CTS MetricsMMMC M d M dMMMC Merged Mode

Metrics Skew Latency

Clock Target:300ps

Target :5200ps300ps 5200ps

PLL 427 5472

TCK 241 4758

LPO80K 45 1377

LPO10M 59 3101

OSCIN 292 3518

ZPLL 417 1805


Hold Fixing

• Seven scenarios were used for hold fixing through ‘fix-clock-opt’4 for setup and 3 for hold

• Quality of hold fixing was compared against the hold fixing done through a internal tool

Hold violations below -292ps was not getting fixed through fix-clock-optopt These were fixed manually through data path buffers CR has been raised for resolving this


Routing

Global and track routing were noise driven optimization was done for crosstalk delay

Major Drcs after fixwire:• >8M viso violations

Via overhangs were matching with the via rule definitions Violations were falsely reported check needs to be turned off for gs60 designs – ‘rule library physical -min_width_overhang off /gs60’


Routing contd.

~3K inter_layer spacing violations

• The inter_layer spacing violations were because of stub routing done. It is recommended to switch off stub routing for gs60 designs.

config snap replace [config snap level] fix-wire-stub {}


Redundant Via Insertion

An attempt was made to increase the redundant via percentage after fixwire through

‘ t ti i i d d t’‘run route optimize via_redundant’ Percentage achieved was low compared to the target

T h b i t i d t i RVITwo approaches are being tried to improve RVI


Redundant Via Insertion contd..

• A fat wire was formed when double via was inserted• This via overhang caused spacing rule violation.

• Two runs were tried after relaxing the spacing rule:"rule layer spacing MET2 0.13u /gs60 -width 0.185u "



After rule relaxing with double via insertion

Native redundant via flow with rule relaxing and with double via insertion

However, these rules were compatible to our signoff drc rule deck and hence they were violating for the signoff runs.



H-via custom via RVI insertion is considered nowThis approach does not require rule relaxation

• H-shaped double via insertion is not the default one supported by Talus/Magma• But, it is expected to give the same higher RVI numbers compared to relaxing the rule


Leakage Recovery

• Leakage optimization was turned on throughout the flow ‘config optimize leakage on’ ‘config optimize secondary cost ${::m} -yield 0 -leakage 0.5 -

area 0.5’ • After routing, ‘run optimize detail –optimize leakage’ was attempted

for leakage recovery Final leakage numbers were below the expected values.


Timing Correlation

• Miscorrelation between Talus and the other timing signoff tools • Result in more stringent deration settings, and iterations back and forth between Talus

optimization and signoff timing numbers Talus has the feature to import the sdf from pt report the annotated delays andTalus has the feature to import the sdf from pt, report the annotated delays and optimize the difference extraction was done using signoff tool and the sdf was imported into TalusOn timer update, it was found that Talus was optimistic on setup by 230ps and hold by 75ps.p

• Timing optimizations were tried on the annotated delays ‘run optimize detail $m $l -optimize {setup hold} -useful_skew -effort high’

• Able to recover the difference


Spef Correlation

• Spef comparison tool was used to compare the parasitics of nets in the spef extracted from Talus and signoff tool

Spef compare before RC deration Spef compare after RC deration


Early CTS

TFM has the feature of doing early CTS along with placement

• Network latencies visible during fixcell • Although the clocks are still in ideal mode, the clock gate enable

paths can be optimized during fixcell stage itself

Early CTS also gives a better insight into any area congestion in the layout because of clock tree buffer addition y

• Early CTS is currently being tried


Visual Volcano

The html reports page dumped through TFM flow can be a good study for comparison against target values and across designs as well


Visual Volcano contd..


Visual Volcano (chart representation)


Expectations from TFM

Single reference library volcano Multiple reference library volcanos makes lib update complicated:• All the reference library volcanos need to be updated. Or,• Correct library volcano needs to be identified and updated.

Decap insertion around clock tree cells for better EMI

Better correlation with industry signoff toolsBetter correlation with industry signoff tools

Complete Hold Fixing


Conclusion

MMMC optimizations using Talus gives accurate and less iterative timing closure of a design provided the most optimal set of scenarios are used at various stages.

On hold fixing alone, 3-4 legacy hold fixing iterations can be eliminated thus saving 4-5 days of run. Talus Flow Manager provides the user with on the fly option of

using Magma’s recommendations and updates without disturbing theusing Magma s recommendations and updates without disturbing the existing setup All commands in TFM have two level of enwraps , Talus enwraps

and TFM enwraps. This gives us more options for controlled flow changes using snapschanges using snaps Specific ownership of the directory structure and the graphical

representations of the reports allow the user to have minimal effort in flow settings and debugs With Enhancements identified in this evaluation pertaining to run

time improvements, better redundant via coverage and more aggressive leakage optimization it is concluded that TFM will provide a good and fast solution for design closure.


g g

ThankYou


2-mmmc analysis using talus flow manager

Documents