From RTL to Reality – Issue #6

Title: The Life of a Net – From RTL to Routed Reality

From RTL to Reality – Issue #6 Title: The Life of a Net – From RTL to Routed Reality

“Every signal starts as code… but what it becomes defines the silicon.”

🚀 From a Line of Code to a Wire on Silicon

We often write RTL like this:

assign y = a & b;        

But did you ever wonder what this signal y actually becomes on the chip? What paths it takes? What delays it picks up? How many buffers carry it across metal layers?

This issue is all about walking with the net — from HDL to metal.


🔬 The Lifecycle of a Signal

1️⃣ RTL Definition:

  • Defined in HDL as a logical function
  • No timing, no size, just pure logic

2️⃣ Synthesis:

  • Mapped to standard cells
  • Registers, combinational gates
  • Delay starts becoming real

3️⃣ Floorplanning & Placement:

  • Net endpoints (source/sink flops) are placed
  • Congestion, spacing, and hierarchy affect routing

4️⃣ Clock Tree Synthesis:

  • Skew is inserted intentionally or reduced
  • Now net y may be impacted by clock arrival times

5️⃣ Routing:

  • Net is physically drawn using metal tracks
  • Buffers inserted to drive long nets
  • Crosstalk, coupling, IR drop begin to play

6️⃣ Post-Route Timing Analysis:

  • Delay is now not just logic, but RC delay + extraction
  • STA tools see the actual behavior

7️⃣ Signoff:

  • Final checks on timing, noise, DRC, antenna
  • If y passes all — it becomes real on silicon


💡 Why This Matters

  • You wrote 1 line of RTL. The tools made 400μm of copper out of it.
  • Every signal is a delay path, a noise victim, and a function carrier
  • Understanding this flow means:


🧠 Real-World Lesson:

Let’s zoom into a classic mistake that even experienced engineers overlook: assuming a small control signal won’t impact timing.

In one of our old project, we had a low-fanout net — just a simple control signal generated by a flip-flop. On RTL, it looked harmless.

But here’s what happened post-layout:

The issue was that a control signal (say, enable_ctrl) was generated far away from where it was consumed — likely in a different module or hierarchy level.

// In control_logic.v
always @(posedge clk) begin
  enable_ctrl <= condition;
end        
// In datapath.v (far away physically)
assign mux_out = enable_ctrl ? data_a : data_b;
        

  • The control flop was placed 1200μm away from the 2:1 mux it was supposed to drive.
  • This long net ran across a congested part of the chip, spanning multiple voltage domains and metal layers.
  • 5 buffers were automatically inserted just to meet transition and drive strength requirements.
  • The net picked up significant parasitic resistance and capacitance.
  • Result? Its delay shot up, and despite being a control signal, it became part of the timing critical path.
  • Even worse, the long metal trace ran parallel to an aggressive data path, causing crosstalk coupling that degraded the slack further — into negative territory.

Fix? We took a smarter look at the RTL.

Instead of generating enable_ctrl in a distant module, we moved the generation of the control signal closer to where it’s used, like this:

// In datapath.v or nearby control block
wire local_enable_ctrl;
assign local_enable_ctrl = condition; // moved logic closer
assign mux_out = local_enable_ctrl ? data_a : data_b;        


The control logic didn’t need to live so far apart. A minor tweak to move that control logic hierarchy closer to the mux logic brought huge benefits:

  • Reduced wirelength by over 60%
  • Eliminated 4 of the 5 inserted buffers
  • Recovered 0.17ns of slack, turning a violator into a safe path

This case reinforced a golden rule: what looks simple in code can become complex in silicon.

Always trace the physical impact of control logic — especially low-fanout nets!

Code matters. Floorplan matters. Everything is connected.


📚 For GATE Learners:

Even though routing isn’t in the GATE syllabus — Understanding how nets get delayed helps you appreciate:

  • Elmore delay model
  • RC path loading
  • Logic + wire + clock = true path delay


🎯 Challenge for This Week:

  • Pick any RTL module you’ve written
  • Use synthesis → see gate-level netlist
  • Check which signals become long nets
  • Try moving logic closer in hierarchy

🔁 Post before/after logic delay improvement if any!


🗓️ Coming Next:

“The Myth of Zero Slack – Why Meeting Timing Isn’t Enough” We’ll explore how zero slack might still mean failure — and how margins can be your best friend.


📩 Enjoyed this deep trace of a signal? Share it. Comment. Subscribe. Let’s trace more — From RTL to Reality.

#RTLtoReality #PhysicalDesign #VLSI #SignalIntegrity #NetDelay #Routing #TimingClosure #EDAtools #FromRTLtoReality #ChipDesign #GDS #Netlist #BackendDesign #STA

Thiago Maia

Digital IC Designer

1mo

Congratulations Ashok Tirumalasetty your posts are always so insightful. About the Real World Lesson, I have a doubt. At first glance, not knowing the constraints you faced, we could simply change the placement script to put the two modules closer to each other, avoiding the long detour, right?

To view or add a comment, sign in

Others also viewed

Explore topics