VLSI - PD

Isolation, Level Shifters, Power Domains… and finally Clock Skew — all in one debug chain.
Today’s debugging reinforced a few non-obvious truths.

🔹 1️⃣ Isolation vs Level Shifter is not about cell type — it’s about intent
• Isolation is required when a source domain can turn OFF
• Level shifter is required when there is a voltage mismatch
If both conditions exist → the tool may insert ISO + LS (or a combo cell).
👉 Seeing level shifters in report_isolation is not necessarily wrong.
Often it simply means the cell is functionally acting as isolation.

🔹 2️⃣ “Where cells are placed” ≠ “what they do”
• Isolation is usually placed in the receiving (safe) domain
• Level shifters may be placed in:
• Source domain
• Destination domain
• Or wherever timing / placement allows
👉 This is why you might see:
• Isolation cells in a default domain
• Level shifters inside a core domain
• Sometimes ISO and LS sitting side-by-side

🔹 3️⃣ Don’t think “around memory” — think “domain crossings”
These cells are not placed randomly near blocks.
They appear at power domain boundaries.
So the real questions should always be:
• What is the source domain?
• What is the destination domain?
• Is there a voltage difference?
• Can the source shut down?

🔹 4️⃣ Library definition matters more than cell names
Not seeing certain keywords in the cell name doesn’t mean
No level shifters exist.
👉 The .lib definition decides whether a cell is:
• Isolation
• Level shifter
• Or a combo ISO-LS cell

🔹 5️⃣ Clock debugging: Latency vs Skew
• Latency → clock arrival time at a flop
• Skew → difference between earliest and latest arrival
👉 If skew becomes comparable to the clock period,
it usually indicates a clock balance problem rather than just latency.

🔹 6️⃣ Skew is rarely fixed directly
In the debug process we observed:
• Significant clock detours
• Highly unbalanced clock paths
👉 Skew is usually a symptom
👉 Routing detours or floorplan imbalance are often the root causes

🔹 Final takeaway
Low-power intent and clock quality are not independent problems.
• Weak domain understanding → incorrect cell insertion
• Poor floorplan → clock detours
• Clock detours → skew explosion

Everything is connected.
A practical debug flow often becomes:
Intent → Mapping → Placement → Timing

Curious to hear how others approach similar debug chains.
And if something here is inaccurate, happy to be corrected — always learning.

The Truth About “Corners” in STA

Almost everyone entering timing analysis gets this wrong:

“More corners = more accuracy”

Wrong.

More corners = more runtime, more noise, and more confusion — if you don’t understand what they represent.

Stage 1: The Myth (What Most People Think)

“Corners are just different PVT combinations”

Half-knowledge.

People assume:
Add maximum corners
Run STA
Signoff is safe

This mindset is why timing closure drags forever.

Because you’re measuring everything… but understanding nothing.

Stage 2: The Foundation (What a Corner Actually Is)

A corner = Process + Voltage + Temperature (PVT)

Each one directly changes delay:

Process
Fast silicon → lower delay
Slow silicon → higher delay

Voltage
Higher V → faster switching
Lower V → slower switching

Temperature
Higher T → higher delay (mostly)
Lower T → lower delay

Stage 3: The Critical Mapping (What Impacts Setup vs Hold)

This is where most beginners fail.

Setup worst case → Slow process + Low voltage + High temperature

Hold worst case → Fast process + High voltage + Low temperature

If you don’t know this mapping, you’re debugging blindly.

Stage 4: The First Mistake Engineers Make

They treat all corners equally.

Reality:
Not all corners matter equally
Not all paths fail in all corners

Some corners dominate:
Setup-dominant corner
Hold-dominant corner

If you don’t identify them early:

You waste effort fixing non-critical scenarios
You increase iteration cycles