Christopher Krueger ST Micro

Christopher Krueger christopher.krueger@st.com ST Micro
ICC Tips and Tricks Christopher Krueger ST Micro

TIPS Agenda Inverted Global Route Congestion Maps ECO Patch Flow
ICC the GDS Plotter Polygon Processing Inside ICC with Calibre Make a Synopsys Tool Hot-Source a Script Minimum metal ECO routing (MMER)

TIP: Inverted Global Route Congestion Maps
Zroute congestion maps show you the horizontal and vertical overflow sums Overflow doesn’t always mean the design won’t route The detail router has tricks of its own to make routing converge Congestion reduction during global routing conceals congested areas by smoothing the overflow Ideally a congestion map would be binary: 1=will not route, 0=will route

Inverted groute maps use reversed overflow ranges ex. from -30 to 0 Any gcell that has zero or more overflow is colored hot Heat  Routing density  Routing DRC An analogy is seeing the whole iceberg, not just the part above the surface

Case 1: Normal Groute map (routes clean)

Case 1: Inverted Groute map (routes clean)

Case 2: Normal Groute map (less channel placement blockage – doesn’t route clean)

Case 2: Inverted Groute map (less channel placement blockage – doesn’t route clean)

Full design Investigate!

Benefits of Inverted map Quickly find where the routing sensitive areas in the design are Evaluate floorplan improvements made to improve routability Use to size channels (hot=>make channel bigger, cold=>make channel smaller) Determine the max stacking of memories

TIP: ECO Patch Flow Usually frontend has to do a functional ECO after physical design has reached “ECO mode” The main things happening in the backend at this point are Upsizes Buffering Route DRC fixing Backend releases the netlist to frontend Backend work stops while front end “owns” the netlist

TIP: ECO Patch Flow Typical ECO flow Wait for eco.v…
icc_shell> open_mw_cel ref icc_shell> write_verilog ref.v Wait for eco.v… icc_shell> eco_netlist –by_verilog eco.v

TIP: ECO Patch Flow Better ECO flow – convert ECO to a “patch”
icc_shell> open_mw_cel ref icc_shell> write_verilog ref.v Continue P&R until eco.v is ready icc_shell> eco_netlist –by_verilog eco.v –write_changes eco.tcl icc_shell> close_mw_cel Apply “patch” to latest cel icc_shell> open_mw_cel latest icc_shell> source eco.tcl

TIP: ECO Patch Flow In practice there is low likelihood that the backend/frontend changes will conflict Equivalence checking is a must! Benefits of ECO patch method Increased backend productivity – no need for frontend to own netlist Pressure is taken off front end to produce the netlist quickly

TIP: ICC the GDS Plotter
GDS plotters produce large scale printouts of chips for display purposes GDS plotters often draw black spots in layout areas with a lot of routing detail GDS plotters are expensive and hard to use This tip shows how ICC can be used to replace a GDS plotter, and even produce better quality plots

Step 1: Use Milkyway to stream in a gds using tech file and layer map Disable Fast Mode if gds is large otherwise memory usage can be huge Step 2: Configure the view settings Increase view depth to a large number Enable TrueVue if available ( only) Change all objects to hidden except routes and vias Save settings to a file for later Step 3: Create virtual frame buffer Xvfb :10 -screen x15000x24 setenv DISPLAY :10

Step 4: Hack ~/.config/Synopsys/icc_shell.conf ... [EkMainWindow_LayoutWindow] 30) ) [EkMainWindow_MainWindow] Step 4: Use ICC to render gds linux> icc_shell -gui icc_shell> open_mw_cel –lib lib_name cel_name icc_shell> source ./layout_settings.tcl icc_shell> gui_zoom -fit -window Layout.1

Step 5: Capture high resolution image linux> xwd –out chip.xwd –display :10 –root linux> display –display :1 chip.xwd linux> convert -quality 100 chip.xwd chip.png Step 6: Take chip.png (~400MB) to commercial printer

TIP: Polygon Processing Inside ICC with Calibre
Layer processing commands are an essential capability Commands have been added to ICC in and more improvements are coming (ask your local AC) compute_polygons # Creates polygons (AND, OR, NOT, etc.) convert_from_polygon # Converts polygons to boxes convert_to_polygon # Converts objects to polygons Disadvantage is that they are “low level” => list based, as following example shows

set hard_blkgs [get_placement_blockages -type hard] set hard_polys {} foreach_in_collection blkg $hard_blkgs { set poly [convert_to_polygon $blkg] if {[llength $hard_polys] > 0} { set hard_polys [compute_polygons -boolean or $hard_polys $poly] } else { lappend hard_polys $poly } remove_placement_blockage $hard_blkgs set boundary [get_attribute [current_mw_cel] boundary] set hard_polys [compute_polygons $hard_polys $boundary -boolean and] foreach poly $hard_polys { foreach box [convert_from_polygon $poly] { create_placement_blockage -type hard -bbox [list \ [lindex [lindex $box 0] 0] [lindex [lindex $box 0] 1] \ [lindex [lindex $box 1] 0] [lindex [lindex $box 1] 1]]

Here are high level commands for doing the same in Calibre NEW_HARD = HARD AND BOUNDARY Calibre is fast, can read ASCII, has a powerful language I created an ICC API for running Calibre code on ICC object shapes Data exchange is in ASCII – no streamout required

icc_shell> snug10::run_calibre_code \ -code { NEW_HARD = HARD AND BOUNDARY } -input [list HARD [get_placement_blockages -type hard] \ BOUNDARY [get_die_area]] \ -output [list NEW_HARD hard] icc_shell> remove_placement_blockage -all icc_shell> foreach box $hard {create_placement_blockage -type hard \ -bbox $box}

Before After Merged Truncated

This code blocks channels between macros icc_shell> snug10::run_calibre_code -code { X = NOT (SIZE MACROS BY 15 OVERUNDER) MACROS } -input [list MACROS [all_macro_cells]] -output [list X boxes] icc_shell> foreach box $boxes \ {create_placement_blockage -type hard -bbox $box}

Before After

TIP: Make a Synopsys Tool Hot-Source a Script
Wouldn’t it be great if you could edit scripts dynamically? Problem is that TCL interpreters slurp up the entire script file the moment you source it Note that you can append commands to the file being sourced and they will be executed

This implies a script file can be made dynamically editable if its contents are “throttled” to the TCL interpreter Syntactically complete “chunks” of code are passed to the interpreter one at a time Each code chunk is followed by a command to append the next chunk, etc.

Here’s an example usage icc_shell> source_hot input.tcl input.tcl is now dynamically editable! input.tcl.fifo is the throttled “fifo” file actually being processed by the TCL interpreter input.tcl.cmd is a cmd log of what has already been executed

Example input.tcl source constraints.tcl place_opt report_timing This is what gets written to input.tcl.fifo source_hot input.tcl 23 input.tcl.fifo input.tcl.cmd source_hot input.tcl 33 input.tcl.fifo input.tcl.cmd source_hot input.tcl 47 input.tcl.fifo input.tcl.cmd

proc source_hot {src {cur_pos 0} {fifo ""} {cmdlog ""}} { set src_fh [open $src r] seek $src_fh $cur_pos set write_mode a if {$cur_pos == 0} {set write_mode w} if {$fifo == ""} {set fifo $src.fifo} if {$cmdlog == ""} {set cmdlog $src.cmd} set fifo_fh [open $fifo $write_mode] set cmdlog_fh [open $cmdlog $write_mode] set code_chunk "" while {[gets $src_fh line] != -1} { append code_chunk "$line\n" if {[regexp {\\$} $line]} { # Keep appending to chunk if line continuation char # The following will return 0 if the TCL code in $code_chunk is complete } elseif {![catch {info complete $code_chunk}]} { break }

if {[catch {info complete $code_chunk}]} { error "Syntax error in TCL code: $code_chunk" } else { puts -nonewline $fifo_fh $code_chunk if {![eof $src_fh]} { # Get next chunk unless at eof puts $fifo_fh "source_hot $src [tell $src_fh] $fifo $cmdlog" } puts -nonewline $cmdlog_fh $code_chunk close $fifo_fh close $cmdlog_fh close $src_fh # This starts the iteration if {$cur_pos == 0} { uplevel 1 source $fifo

TIP: Minimum metal ECO routing (MMER)
MMER is the process of minimizing the number of metal layers changed during a metal ECO Every mask layer saved saves the company thousands of dollars. Saving half the metal layers on a few chips a year could pay for your salary The Astro/ICC classic router only had “token” support for MMER

The classic ECO router could only repair broken nets using the detail router, and the net material for each net could not be broken by more than ~20 gcells Otherwise route_eco would abort and leave opens Since 99% of ECOs involve rewiring with scope more than 20 gcells => MMER not really supported I found a way to hack the classic ECO router so that MMER works (see paper)

The good news is that MMER works out of the box with Zroute and it’s simple to use: icc_shell> set_route_zrt_common_options -freeze_layer \ {{m5 true} {m6 true} {m7 true}} -freeze_via_to_frozen_layer true icc_shell> route_zrt_eco If you’ve tried MMER in the past and had no success, now’s the time to revisit it

Food for Thought I suggest to Synopsys to expand Solvnet to allow users to contribute Users could create articles Users could pose/answer questions in a forum Users could collaborate on code projects, like an ICC reference methodology Inject Solvnet with a dose of “Open Source” Give thanks to Synopsys for giving us a high quality, documented, TCL API Code discussed today available here

THE END

BONUS SLIDES TIME PERMITTING

TIP: New Command get_pin_shapes
In the past getting the polygon shape of a pin was a cumbersome process The only way was to open the associated FRAM view and get the polygon shape of the appropriate terminal and transform it back to parent context Opening FRAM views is slow, so an efficient script would have to batch the queries or cache the results The resulting scripts are complicated and not very pretty

Thankfully, there is a new command get_pin_shapes which returns a collection of “shape” objects for the pin arguments icc_shell> set shapes [get_pin_shapes –of $pin] Notable attributes are: points, layer, access_direction It’s now much easier to write scripts that need pin shape information The following is an example of a script that creates terminals for design ports based on the pin shapes of a macro in the design

proc ::snug10::create_terminals_from_pins {ports} { foreach_in_collection port $ports { set port_name [get_object_name $port] set net [get_nets –all -of $port] set pins [get_pins –all -leaf -of $net] if {[sizeof_collection $pins] == 1} { remove_terminal [get_terminals -of $port] foreach_in_collection shape [get_pin_shapes -of $pins] { set layer [get_attribute $shape layer] set points [get_attribute $shape points] foreach bbox [convert_from_polygon $points] { create_terminal -bbox $bbox -layer $layer -port $port }

TIP: Analyzing Trends in ICC/DCT Log Files
Plot QOR profile from ICC log files Simple, visual way of comparing runs Generally, if an improvement is made to the input netlist or optimization settings, the QOR improvement will manifest and be maintained from the outset of optimization Therefore the plots give you a way to predict if a run has improved convergence. You don’t need to wait until the end of the run to know this An “improvement” is likely not a good one if the QOR doesn’t close as quickly as before A friend of mine used to joke that he’d often sit there watching the log file

linux> log_qor_plot.pl med_effort/logs/place_opt.log –title ‘med effort’ high_effort/logs/place_opt.log –title ‘high effort’ OPTIMIZATION TNS MED EFFFORT HIGH EFFORT TNS TIME

OPTIMIZATION AREA MED EFFFORT HIGH EFFORT AREA TIME

Christopher Krueger ST Micro

Similar presentations

Presentation on theme: "Christopher Krueger ST Micro"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Christopher Krueger ST Micro

Similar presentations

Presentation on theme: "Christopher Krueger ST Micro"— Presentation transcript:

Similar presentations

About project

Feedback