Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutRoadmapCareersInternshipsFAQContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • The NanoSoC Tour
  • Reading Path
  • SoC Glossary10
  • SoC Metrics Reference
  • SoC Cheatsheet
  • What SoC Integration Is12
  • Architecture and Budgets21
  • Memory Maps and Address Decode26
  • Interconnect and Bus Fabrics26
  • Clock and Reset Architecture24
  • Power Architecture21
  • Interrupts, DMA and Peripherals15
  • Memories, Boot and Security21
  • IP Integration and Handoff21
  • Top-Level Verification and Bring-up21
  • Package, Pads and I/O18
    • I/O Ring and Pad Types
    • Pad Count and Simultaneous Switching
    • Package and Ballout
    • Power Delivery Through Package and Bumps
    • ESD and Latch-Up at the Top
      • What the Integrator Checks
      • Cross-Domain Discharge Paths
      • Pad-to-Core Interfaces and Latch-Up
    • Test and Debug Pins (extension)
  • Chip Signoff and Tapeout18
  • SoC Interview Prep16
  • Capstone: Integrate NanoSoC14
Loading lesson

←ESD and Latch-Up at the Top
  1. Topics
  2. SoC Design
  3. Package, Pads and I/O
  4. ESD and Latch-Up at the Top
  5. Cross-Domain Discharge Paths
On this page

    Part 11 of 14, lesson 14 of 18Part 11 of 14/Package, Pads and I/O/Lesson 14 of 18All levels

    Cross-Domain Discharge Paths

    Tracing a discharge through the pad, the rails and the grounds in four power states, starting from none.

    Why it matters

    The dominant discharge events, handling and assembly, hit a chip with every supply off. A path that works only when the chip is powered is a path that fails in the state where most discharges actually arrive. NanoSoC has more states than it first appears: the I/O rail and the core rail, and within the core a switchable domain that may be off. This lesson walks the path in each of them.

    The core idea

    A discharge entering a GPIO pad flows first through the pad's diode pair to the I/O rails, then must reach ground through the rail clamps and on to the board ground balls, crossing between the I/O ground and the core ground through the on-die diode pair if that is the shorter way. The review traces this in words before trusting any diagram: pad, pad diode, rail, rail clamp, ground, ground link, ground ball, each step named and each step present. The trace is then walked in four states. UNPOWERED: every rail floats, which is where handling discharges arrive. RUN and IDLE: everything is powered. SLEEP: the always-on domain is powered and PD_SW is off.

    Two rules follow. In UNPOWERED and SLEEP the path must use clamps that need no supply voltage to trigger, the transient-triggered rail clamps of the I/O library, because there is no supply to bias a supply-triggered clamp. And in SLEEP the path must never rely on the switched PD_SW rail: the header switch is open, so that rail is connected only through a high-impedance device, not removed. The always-on rails and their clamps complete the path. This is why the checklist names the clamps per rail and why the always-on supply is never allowed to depend on the sleeping domain.

    Discharge flow on NanoSoC: pad to diode to I/O rail to rail clamp to the joined grounds, entirely on the die.
    Discharge flow on NanoSoC: pad to diode to I/O rail to rail clamp to the joined grounds, entirely on the die.

    State

    I/O rail

    Core rail

    PD_SW

    What the path may use

    UNPOWERED

    floating

    floating

    off

    Diodes and transient-triggered clamps only.

    RUN

    on

    on

    on

    Any clamp.

    IDLE

    on

    on

    on (CPU clock gated)

    Any clamp.

    SLEEP

    on

    on

    off

    Clamps on the I/O and always-on rails; nothing on PD_SW.

    The four-state trace

    The script below holds the path as a list of elements, each with the rail it sits on, whether it needs a supply voltage to trigger, and whether it sits on the switched rail. It checks every element in every state. It then runs the same check on two bad designs: a supply-triggered rail clamp, which fails in UNPOWERED, and a clamp placed on the PD_SW rail, which fails in SLEEP.

    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    STATES = {"UNPOWERED": {"vdd_io": False, "vdd_core": False, "pd_sw": False},
              "RUN": {"vdd_io": True, "vdd_core": True, "pd_sw": True},
              "IDLE": {"vdd_io": True, "vdd_core": True, "pd_sw": True},
              "SLEEP": {"vdd_io": True, "vdd_core": True, "pd_sw": False}}
    # element: (name, rail it sits on, needs a supply to trigger, sits on the switched rail)
    PATH = [("pad_diode_pair", "vdd_io", False, False),
            ("io_rail_clamp", "vdd_io", False, False),
            ("ground_link_diodes", "vdd_io", False, False),
            ("core_rail_clamp", "vdd_core", False, False)]
    
    def check(path):
        for state, live in STATES.items():
            for name, rail, needs_supply, on_sw in path:
                if needs_supply:
                    assert live[rail], (state, name, "needs a supply that is off")
                if on_sw:
                    assert live["pd_sw"], (state, name, "depends on the switched rail")
        return len(STATES) * len(path)
    
    assert check(PATH) == 16
    supply_triggered = [PATH[0], ("io_rail_clamp", "vdd_io", True, False)] + PATH[2:]
    on_switched_rail = PATH[:3] + [("core_rail_clamp", "vdd_core", False, True)]
    for bad in (supply_triggered, on_switched_rail):
        try:
            check(bad)
            raise SystemExit("a path with a dead end was accepted")
        except AssertionError:
            pass
    print("PASS: the discharge path holds in UNPOWERED, RUN, IDLE and SLEEP; a supply-triggered clamp and a PD_SW clamp are rejected")

    What the review looks for

    • The pad-to-ground trace written per state, UNPOWERED first, not assumed from one diagram.

    • Clamps stated to be transient-triggered where no supply is present, and none placed on the switchable rail.

    • No path step that depends on a switch being closed or a rail being up.

    • The clamp location stated: on the die, in the pad cells or ring cells, never on the package.

    Verify and debug

    Rail clamps between the rails sit on the die, either inside the pad cells or as separate clamp cells in the ring or the core, depending on the I/O library; the integrator specifies their presence per rail pair and the review confirms it. A rail added late, such as a new analog supply or a split core rail, needs its clamp row before it needs its decoupling, because the discharge does not wait for the power-integrity sign-off. Walk the trace against the schematic in all four states and keep the four walks with the review minutes; a new power state added later re-opens all of them.

    An ESD walk done only in RUN. The path looks complete on the powered schematic, and a rail clamp that needs its supply to trigger leaves the unpowered chip with no path at all; the first handling discharge goes through the logic. It is caught by walking UNPOWERED and SLEEP as separate states and fixed by transient-triggered clamps on every rail the path uses.

    If asked about ESD across power states, answer with the unpowered case first, then SLEEP: trace the path with the rails off and name the clamps that need no supply. The powered cases are the easy half.

    Check yourself Why must the discharge path avoid the PD_SW rail in SLEEP even though the rail is physically present?

    Because with the header switch open that rail is connected only through a high-impedance device, so it offers no low-impedance route to ground; a surge sent that way finds its own path, through logic. The path must use rails that stay connected to powered clamps.

    Related topics

    • What the Integrator Checks

    • Next: Pad-to-Core Interfaces and Latch-Up

    • Physical Design: ESD and IO Ring Integration

    Previous

    227 / 289

    Next: Pad-to-Core Interfaces and Latch-Up

    Up next

    Up nextPad-to-Core Interfaces and Latch-Up

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error