2-MMMC Analysis Using Talus Flow Manager

MM/MC analysis using Talus Flow Manager
Aravind Chandramohan Wipro Limited Surendra Mistry y Texas Instruments Hari Pendurty Texas Instruments
Insert Company Logo Here
San Jose, CA | March 10, 2010

Copyright 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.
Talus 1.X offers multimode multicorner optimization. This evaluation is focused on MMMC capability of Talus. Reasonable runtimes using MMMC. Magmas reference flow : Talus Flow Manager (TFM) is used for MMMC optimizations.
2
Talus Flow Manager

Magmas reference flow from RTL to GDSii.
Best practices and recommendations from Magma 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 directories Parallel P ll l runs Graphical representation of reports through Visual Volcano Analyze and review reports through tables, graphs and charts effortlessly across runs and designs.
3
TFM Setup
TFM supports the following styles: Flow style : Single mode MMMC Domains : D i Single domain Multi domain UPF Design Start point : Volcano Netlist RTL
4
Floorplan/Domain Setup

65nm 4 power domains MMMC Input is Netlist I t i N tli t
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} } }
5
Design Run
TFM flow was taken through from netlist to routing with focus on Runtime QORs: Speed p CTS : Insertion Delay, Skew, Clock power Quality of Hold Fixing (WNS, number of hold buffers) Routing closure Drc closure Redundant Via Insertion Leakage recovery Timing correlation with signoff extraction tool
6
Run Time reduction

Main contributors for runtime Too many scenarios to handle Wire load model used Secondary cost function recovery effort Native Talus commands Rebuffering Sizing with high effort for second cost function recovery. Steps taken to reduce runtime: Elmore model was used for fixcell instead of AWE (default).
7
Run Time reduction
contd..
Rebuffering during fix-cell, fix-cell-opt, fix-clock, fix-clock-opt took ~60 70% of runtime. Below customization t th d f lt TFM flow for rebuffering were done: B l t i ti to the default fl f b ff i d Limited for fixing limit violations Leakage optimization disabled Cloning disabled Sizing during fixcell was contributing to ~10% of runtime. 10% Low secondary effort was used during sizing.
8
Speed

Netlist which was used for tapeout design at 95Mhz was used The frequency of 120Mhz was targeted to stress the tool to the maximum i Achieved 110MHhz with reasonable runtimes
9
CTS

Design had multiple clock sources with different clock origin points Successive clock generation logic in the same path and many intra clock domains
10
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 g p were dumped out using: g g groups p g config_clock_auto_clockgate_balance on report plan clock $m auto_clockgate_balance
11
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 dont 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
12
CTS Metrics
MMMC Merged Mode M dM d
Metrics
Clock PLL TCK LPO80K LPO10M OSCIN ZPLL
Skew Target: 300ps 427 241 45 59 292 417
Latency
Target : 5200ps 5472 4758 1377 3101 3518 1805
13
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-clockopt These were fixed manually through data path buffers CR has been raised for resolving this
14
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
15
Routing
~3K inter_layer spacing violations
contd.
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 { }
16
Redundant Via Insertion

An attempt was made to increase the redundant via percentage after fixwire through run route optimize via_redundant t ti i i d d t Percentage achieved was low compared to the target
Two approaches are being t i d t i T h b i tried to improve RVI
17

A fat wire was formed when double via was inserted This via overhang caused spacing rule violation.
contd..
Two runs were tried after relaxing the spacing rule:

"rule layer spacing MET2 0.13u /gs60 -width 0.185u "
18

After rule relaxing with double via insertion
contd..
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.
19

H-via custom via RVI insertion is considered now This approach does not require rule relaxation
contd..
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
20
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.
21
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 and pt, optimize the difference extraction was done using signoff tool and the sdf was imported into Talus On 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
22
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
23
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
24
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
25
Visual Volcano
contd..
26
Visual Volcano (chart representation)
27
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 tools Complete Hold Fixing
28
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 Magmas recommendations and updates without disturbing the Magma s 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 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 g g a good and fast solution for design closure.
29
ThankYou
30

2-MMMC Analysis Using Talus Flow Manager

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

2-MMMC Analysis Using Talus Flow Manager

Hochgeladen von

Copyright:

Verfügbare Formate

MM/MC analysis using Talus Flow Manager

Insert Company Logo Here

San Jose, CA | March 10, 2010

Talus Flow Manager

Run Time reduction

Run Time reduction

Skew Target: 300ps 427 241 45 59 292 417

Redundant Via Insertion

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

Redundant Via Insertion

Two runs were tried after relaxing the spacing rule:

Redundant Via Insertion

Redundant Via Insertion

Timing optimizations were tried on the annotated delays

Spef compare before RC deration

Spef compare after RC deration

Early CTS is currently being tried

Visual Volcano (chart representation)

Expectations from TFM

Das könnte Ihnen auch gefallen