Between every pad driver and the core logic sits a boundary where high currents, noisy supplies and different spacings meet small transistors. Misbehave there and a parasitic path can turn on that stays on: the chip draws excess current until power is removed. That is latch-up at the concept level, and while its prevention is physical, the integrator asks the questions that confirm it was done. This lesson states those questions for NanoSoC.
Latch-up, conceptually, is a parasitic current path near the pad-to-core boundary that, once triggered by a voltage spike or a mis-sequenced supply, sustains itself. As a general guideline it is kept away with spacing rules, guard structures that collect stray current, clean supply ties at the boundary, and a correct power-up order, which is the sequencing lesson of this section pulling double duty. The integrator's questions at review are short: are the boundary spacings signed off against the design rules, do guard structures ring the high-current drivers, are the boundary supply ties connected to the right rails, and does the supply specification's order get followed so that no rail is powered while another floats in a forbidden combination.
On NanoSoC the boundaries that earn extra attention are the 16 GPIO driver rows, which face the board's unknown loads, the crystal pads beside them, and the pad-cell supply interface where the I/O rail meets the core rail. A second boundary deserves a look: the interface between the switchable and the always-on core domains, where well ties and guard spacing must match the power-intent file. That is a physical question; the isolation cells of the power architecture cover the logic side only.
Review question | Evidence | NanoSoC focus |
|---|---|---|
Boundary spacings signed off? | Design-rule sign-off for the ring | The GPIO driver rows and the crystal pads. |
Guard structures around drivers? | Layout confirmation per driver group | The 16 GPIO drivers first. |
Boundary ties on the right rails? | Schematic ties list | I/O rail to core rail interface, and the switchable-to-always-on boundary. |
Sequence matches the supply specification? | Sequence review minutes | I/O rail and core rail order as the I/O library requires; power-on control keeps drivers off until the core is valid. |
The four questions answered with attached evidence, not verbal assurance.
High-drive boundaries and the domain boundary listed by name with their guards.
The rail order cross-referenced as latch-up evidence, linking both topics.
Verification here is review of implementation sign-off owned elsewhere: the integrator confirms the sign-off exists and covers the named boundaries, and refuses to duplicate the physical checks. On the bench, the symptom that points here is excess supply current that persists until power is cycled, distinct from functional overcurrent that tracks activity, and the response is a failure-analysis loop with the implementation team, not a firmware workaround.
Because they are two different boundaries with different physics. The driver rows are where high pad currents meet small transistors and need spacing and guards. The domain boundary is where two core supplies meet and needs matching well ties. The isolation cells do not cover either, since they handle logic levels only.