IntermediateQuestion 156 of 162Source: Synopsys ICC2 Implementation User Guide: Routing

Why do hard macro pins fail access at smaller nodes, and how do pin access guides help?

From PDVerse PnR Interview Handbook · pdVerse Mentor Guide

Short Answer

Hard macros and IP are often reused from older designs, and at smaller nodes their pins can sit too close to the macro edge, to each other or to blockages for the router to reach cleanly. derive_pin_access_routing_guides fixes this by creating routing guides, metal blockages around the macro with cutouts at each pin, and via blockages on the adjacent via layers. The cutouts give every pin a clear, rule-legal path in.

Technical Reference DiagramWhy do hard macro pins fail access at smaller nodes, and how do pin access guides help?
A macro edge with pins, a metal blockage around the macro on the chosen layers, and cutouts in the preferred direction that give each pin a clear access channel.

Technical Explanation

  • A pin is only useful if a wire can reach it legally. At smaller nodes, end-of-line and spacing rules around pins get stricter, and pins that were fine on an older process become hard to reach.
  • derive_pin_access_routing_guides needs the macro cells, the layers and the widths: -cells, -layers, and -x_width and -y_width.
  • It creates metal blockages around the macro on those layers, with cutouts where the pins are, plus via blockages on adjacent via layers. Vertical guides and blockages use the x-width and horizontal ones use the y-width.
  • Cutouts are made in the preferred direction only by default. -nonpreferred_direction adds non-preferred cutouts, and -pin_extension extends them beyond the blockages.
  • The command also sets is_rectangle_only_rule_waived on the macro pins.
  • If the macro already has pin access guides and blockages, they are replaced. If the macro moves, they must be regenerated, because they cannot be edited by hand.
  • Check access before and after with check_routability, which reports blocked macro ports using the longer macro access range.

What To Check

  • Blocked macro ports from check_routability, before and after.
  • Detail routing DRCs along the macro edge.
  • That guides were regenerated after any macro move.
  • Congestion just outside the macro, since the blockage ring takes some tracks.

Command Checks & Actions

ICC2check_routability

Reports blocked macro ports before and after adding the guides.

ICC2derive_pin_access_routing_guides -cells [get_cells u_sram0] -layers {M2 M3} -x_width 0.6 -y_width 0.7

Creates pin access guides, a blockage ring with pin cutouts, and via blockages around the macro.

ICC2get_routing_guides *

Lists routing guides, including the ones derived around the macro.

ICC2check_routes

Checks DRCs along the macro edge after routing.

Healthy, Suspicious & Hard-stop Results

  • Healthy (illustrative): Zero blocked macro ports and no DRC cluster at the macro edge after routing.
  • Suspicious (illustrative): A few DRCs at pins where cutouts are tight, often fixed with -pin_extension or non-preferred cutouts.
  • Hard stop: Guides left from an old macro position, blocking the new pin locations.

Common Mistake

The Trap: Moving a macro by a few microns late in the floorplan and not regenerating its pin access guides. The old cutouts no longer line up with the pins, the blockage ring now covers them, and the macro shows blocked ports and dozens of DRCs at its edge.

What The Interviewer Is Testing

  • Whether you understand why reused IP fails pin access at new nodes.
  • Do you know what the command creates?
  • A strong answer shows you remember guides must be rebuilt after a macro moves.

Follow-up Question & Model Response

"Why add a blockage ring at all, instead of just guides at the pins?"

Candidate Model Response: The ring stops random signal wires from running along the macro edge right next to the pins. Those passing wires are what make pins hard to reach: they take the tracks a pin connection needs, or create end-of-line conflicts. The cutouts then give each pin a reserved lane. Guides alone would steer routing but still leave the edge open to through traffic.

Practical Example

Tapeout Scenario: An SRAM reused from an older node has 128 pins on M2 and M3 along one edge (illustrative). check_routability reports 19 blocked macro ports, and a trial route leaves 95 DRCs along that edge. The engineer runs derive_pin_access_routing_guides -cells [get_cells u_sram0] -layers {M2 M3} -x_width 0.6 -y_width 0.7. check_routability then shows 0 blocked ports, and routing ends with 3 DRCs at the edge, cleared by adding -pin_extension 0.2 and rerunning.

PnR Flow Mentor Guide

Read the complete 8-chapter PnR Flow Mentor Guide free on the web — library setup through placement, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO, all the way to stream-out.

PnR Flow Physical Design Mentor Guide — eight chaptersPnR Flow Mentor GuideEight chapters, library setup through to stream-out. →