BeginnerQuestion 120 of 127Source: Synopsys ICC2 Implementation User Guide: Routing

Why are clock nets routed before signal nets?

From PDVerse PnR Interview Handbook · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

Clocks are routed first so they get clean routing resources, their NDRs and any shielding, before thousands of signal nets fill the tracks. CTS balanced the tree assuming certain wire lengths and layers; routing the clocks first keeps that intact. If signal nets went first, clocks would be forced into detours that change skew and latency.

Technical Reference DiagramWhy are clock nets routed before signal nets?
Flow: route clock nets with their NDRs, verify skew and latency, then route signal nets around the finished clock wires.

Technical Explanation

  • In the basic Zroute flow, clock nets are routed right after the routing options are set, before any signal nets.
  • CTS has already placed clock buffers and built global routes for the clock. route_group -all_clock_nets -reuse_existing_global_route true routes the clocks and reuses those routes, so the physical path matches what CTS planned.
  • Clock nets usually carry NDRs, wider wires and extra spacing, and sometimes shielding. Those need space that is only easy to find in a mostly empty block.
  • A detoured clock net changes latency to its sinks. Two sinks that were balanced can end up with different wire lengths, and skew grows without any change to the tree itself.
  • Once clocks are routed, signal routing works around them. The clock wires are already there, so signal nets simply see them as obstacles.
  • After clock routing, check clock quality again with the actual routes. report_clock_qor shows skew and latency so you can confirm routing did not undo CTS.
  • Redundant vias on clock nets can be specified in the clock NDR, so Zroute reserves space during global routing and inserts them during detail routing.

What To Check

  • Skew and latency from report_clock_qor after clock routing, compared with the CTS result.
  • DRCs and opens on clock nets from check_routes, filtered to the clock net names.
  • That the clock NDR is applied to the routed wires.
  • Open clock nets, which must be zero before signal routing starts.

Command Checks & Actions

ICC2route_group -all_clock_nets -reuse_existing_global_route true

Routes all clock nets first, reusing the global routes from CTS.

ICC2report_clock_qor

Reports skew and latency on the routed clock tree to confirm CTS results held.

ICC2check_routes

Confirms no DRCs or opens on the clock nets before signal routing.

ICC2route_auto

Routes signal nets around the finished clock wires.

Healthy, Suspicious & Hard-stop Results

  • Healthy (illustrative): Skew and latency after clock routing within a few picoseconds of the CTS result, with no DRCs or opens on clock nets.
  • Suspicious (illustrative): Skew grows noticeably after clock routing, usually a sign of detours around blockages or congestion.
  • Hard stop: Clock nets left unrouted or with DRCs when signal routing starts.

Common Mistake

The Trap: Running route_auto straight after CTS without routing clocks first. Clock nets get routed at the same priority as data nets, some take long detours through congested channels, and skew grows by tens of picoseconds. The block needs a clock reroute and a new round of hold fixing.

What The Interviewer Is Testing

  • Whether you connect routing order to protecting CTS results.
  • Do you know how clocks reuse the CTS global routes?
  • A strong answer shows you re-check clock quality after clock routing.

Follow-up Question & Model Response

"What does -reuse_existing_global_route true actually change?"

Candidate Model Response: By default the global router ignores existing global routes and starts over. With this option it starts from the global routes already in the block, the ones CTS built for the clock. So the clock follows the paths CTS used when it calculated delays, rather than new paths the router might choose. The option only affects the global routing step, not net delay calculation.

Practical Example

Tapeout Scenario: After CTS a block reports 38 ps global skew (illustrative). The engineer runs route_group -all_clock_nets -reuse_existing_global_route true, then report_clock_qor: skew is now 41 ps, within the expected range, and check_routes shows no DRCs on clock nets. Signal routing then runs with route_auto. On an earlier trial where clocks were not routed first, skew after full routing was 67 ps, because two clock branches detoured around a congested bus channel.

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.

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

Continue practising

Related PnR (Place & Route) questions

BeginnerWhat is a non-default routing rule (NDR)?IntermediateWhy and how do you route a subset of nets first?BeginnerWhat does report_clock_qor actually show you, and what do its -type variants each report?IntermediateHow do you constrain which metal layers a clock tree is allowed to route on, and can you be more specific than "the whole tree"?