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
    • Partitioning and Hierarchy
      • Flat Versus Hierarchical
      • Boundary Choices and Feedthroughs
      • NanoSoC Partition Rationale
    • Area Budgets
    • Timing Budgets Across Hierarchy
    • Power Budgets
    • Bandwidth Budgets
    • Budget Governance
    • Multi-Die and Chiplet View
  • 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
  • Chip Signoff and Tapeout18
  • SoC Interview Prep16
  • Capstone: Integrate NanoSoC14
Loading lesson

←Partitioning and Hierarchy
  1. Topics
  2. SoC Design
  3. Architecture and Budgets
  4. Partitioning and Hierarchy
  5. NanoSoC Partition Rationale
On this page

    Part 2 of 14, lesson 3 of 21Part 2 of 14/Architecture and Budgets/Lesson 3 of 21All levels

    NanoSoC Partition Rationale

    Why NanoSoC is split into its partitions: the clock, power and protocol reasons behind each boundary.

    Why it matters

    Every NanoSoC boundary exists for at least one of three reasons — a clock change, a power change or a protocol change — and the table below says which, on a real, small chip. When the next project proposes a new partition, this is the shape of the defence it must produce: one row per boundary, one reason per row, and no row that says convenience.

    The core idea

    Read the NanoSoC block diagram as three cuts. The clock cut separates the 192 MHz CPU side, the 96 MHz system side and the 24 MHz peripheral side; the two bridges that cross it, the asynchronous AXI bridge and the APB request-acknowledge bridge, are owned artifacts with their own verification. The power cut separates the switchable domain from the always-on domain; isolation cells clamp all 114 signals crossing from switchable to always-on, and the SRAM0 wrapper straddles the cut with its arrays on the always-on side. The protocol cut separates AXI from APB and memory-mapped from streaming: the AXI-to-APB bridge sits where AXI becomes APB, the slot decoder fans that one peripheral space into per-slot selects, and the stream bridge sits where memory-mapped AXI becomes AXI-Stream.

    Boundary

    Reason

    Crossing mechanism

    Owner

    CPU side to system side

    Clock: 192 MHz to 96 MHz

    Async AXI bridge, dual-clock FIFOs

    CPU owner (CPU side) with the integrator

    System side to peripheral side

    Clock 96 to 24 MHz plus protocol pace

    APB request-acknowledge bridge

    Integrator

    AXI fabric to APB

    Protocol: AXI to APB

    AXI-to-APB bridge plus slot decoder

    Integrator

    Memory-mapped to streaming

    Protocol: AXI to AXI-Stream

    Stream bridge read and write engines

    SBR owner

    Switchable to always-on

    Power: PD_SW to PD_AON

    114 isolation clamps, asserted before reset

    Integrator (reset and power controller)

    Secure to non-secure

    Security attribute, not a partition

    Secure filters at fabric and slot decoder

    Integrator

    Diagram
    # not-run: NanoSoC partition seam count, NanoSoC teaching values
    Partitions: CPU side, system side, peripheral side, plus power cut PD_SW/PD_AON.
    Crossing groups: 10 (specification clock section). Isolation cells: 114.
    Rule of thumb: one named bridge per clock or protocol seam, one clamp per
    power-seam signal. NanoSoC has exactly that: no seam without a mechanism.

    What the review looks for

    • Every boundary row names its reason, its mechanism and its owner; unowned crossings are rejected.

    • The isolation count (114) reconciles with the port lists: 47 plus 52 plus 13 plus 2.

    • Security is enforced by filters, not by partitions: no boundary relies on physical separation for access control.

    Verify and debug

    Walk each boundary with its checker: clock crossings against the synchroniser inventory, power crossings against the isolation list, protocol crossings with bundle-completeness tests. The classic failure here is the missing isolation on the two interrupt lines — 112 clamps present instead of 114 — which power-aware simulation catches as X on INTC RAW while PD_SW is off, and which shows in silicon as a spurious wake loop on entering SLEEP. Count the clamps; the number must be exactly 114.

    Missing isolation on a power boundary. The switched domain floats, the always-on side sees unknowns or spurious wake events, and the symptom looks like a reset bug. Check every cross-domain signal against the power-intent list; waive nothing on this boundary.

    If asked to defend a partition, give the three-reason test: clock, power, protocol. A boundary with none of the three is org-chart hierarchy, and saying so calmly is the senior answer.

    Notice what is missing from the cut list: area and timing alone rarely justify a partition at NanoSoC's size (0.585 mm2 of blocks). A large uniform block stays whole even when it dominates the die, because slicing it creates a timing budget across the cut that did not exist before. Capacity and runtime justify a partition only when the design outgrows what one tool run can hold. Even then, cut along a clock, power or protocol seam so that the cut adds the fewest new timing budgets. Area and timing divide budgets within a partition; the seams draw the lines between them.

    Check yourself Why is the secure to non-secure line not a partition in the table?

    Because separation is enforced by filters at the fabric and the slot decoder on every access, not by placing logic in different partitions. Partitions organise work; filters enforce policy.

    Related topics

    • Boundary Choices and Feedthroughs

    • PD: Top-Down Pushdown vs Bottom-Up

    • RTL: Three Architectures, One Decision

    • CDC & RDC: Reset Sequencing

    • CDC & RDC: Interface Checklists

    Previous

    20 / 289

    Next: Area Budgets

    Up next

    Up nextArea Budgets

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Flat Versus Hierarchical