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
  • Chip Signoff and Tapeout18
  • SoC Interview Prep16
    • The Whiteboard Framework
    • Design a SoC on a Whiteboard
      • Requirements to a Timed Plan
      • NanoSoC as the Model Answer
      • Variations: Bandwidth, a Second DMA, a Secure Partition
    • Integration Storm and Budget War Scenarios
    • Rapid-Fire Questions by Section
    • Numeric Drills
  • Capstone: Integrate NanoSoC14
Loading lesson

←Design a SoC on a Whiteboard
  1. Topics
  2. SoC Design
  3. SoC Interview Prep
  4. Design a SoC on a Whiteboard
  5. Requirements to a Timed Plan
On this page

    Part 13 of 14, lesson 4 of 16Part 13 of 14/Interview Prep/Lesson 4 of 16All levels

    Requirements to a Timed Plan

    One line of requirements becomes seven drawing steps with a minute budget each.

    Why it matters

    The failure mode of the design question is not ignorance but sequence: candidates draw the CPU first, the fabric second, and realise at minute twenty that the secure region has no filter and the slow peripherals have no bridge. A fixed plan prevents that by forcing the decisions in dependency order. This lesson is that plan, with what each box must contain before the marker moves on.

    The core idea

    Spend the first two minutes restating the requirements as budgets: how many masters, how many slaves, peak bytes per second per master, latency deadlines, power states, secure versus non-secure regions. Everything downstream divides one of those numbers. Then draw in dependency order. Block diagram: masters left, fabric middle, slaves right, with each crossing labelled by mechanism. Address map: regions sized to powers of two, bases aligned to size, holes named with their error response, decode bits written beside each window. Interconnect: topology, arbitration, outstanding limits, and the 4 KB rule stated as a splitter, not a hope. Clocks and resets: sources, dividers, domain table with frequencies, release order with slaves before masters. Power: domains, isolation boundaries, the wake sequence with its dominant term. Interrupts and boot: wiring table with priorities, then the boot ledger with its dominant step named.

    The whiteboard order: each box consumes the budgets of the previous one.
    The whiteboard order: each box consumes the budgets of the previous one.

    The minute budget for thirty minutes: 2 for requirements as budgets, 5 for the block diagram, 5 for the map, 5 for the fabric, 5 for clocks and resets, 4 for power, 4 for interrupts and boot. The last box is smallest because it reuses numbers from all the others: interrupt latency divides the periods, boot time divides the loader bandwidth. If any box overruns, steal from the next box's detail, never from its existence: a thin power box with the wake total beats a missing one.

    Diagram
    # not-run: the thirty-minute budget, NanoSoC teaching values for pacing
    Requirements as budgets: 2 min (masters, slaves, MB/s, deadlines, states, security).
    Block diagram with crossings: 5 min. Address map with decode bits: 5 min.
    Fabric with arbitration and 4 KB: 5 min. Clocks and resets: 5 min.
    Power with wake total: 4 min. Interrupts and boot ledger: 4 min.
    Reserve: the last 2 minutes for the trade-off you deferred and the check you promised.

    What the review looks for

    • Requirements are rewritten as numbers before any box is drawn: master count, slave count, bandwidth per master, deadlines, states.

    • Every crossing on the diagram names its mechanism; every hole on the map names its error response.

    • Each box closes with one total: sustained link rate, wake time, boot time, worst-case interrupt latency.

    Verify and debug

    Rehearse with a timer and a blank page: at minute seven the map must exist with decode bits, at minute seventeen the clocks must have frequencies and a release order, at minute thirty the boot total must be written. The usual failure is a beautiful block diagram at minute twenty with no map: enforce the budget by moving on mid-sentence if needed. Review the recording for numbers per minute; fewer than one number per two minutes means the answer is drifting generic.

    Address decode overlap or hole: windows not rounded to a power of two overlap or gap, and the symptom is another block's data or a hang. Drawing the map second, with sizes and alignment checked as you go, is the whiteboard version of the single-source-map rule.

    If the interviewer adds a requirement mid-answer, for example a secure region, do not redraw: add it as a variation box in the margin with its filter and its cost. The variations lesson trains exactly this move.

    Check yourself The interviewer cuts you to fifteen minutes. Which boxes survive?

    Requirements as budgets, the block diagram with crossings, the map with decode bits, and one total per remaining box compressed into the diagram margin: sustained rate, wake time, boot time. Detail is sacrificed; no box is deleted.

    Related topics

    • Next: NanoSoC as the Model Answer

    • System Design Questions

    • SoC: Sizes, Alignment and Power-of-Two Windows

    Previous

    253 / 289

    Next: NanoSoC as the Model Answer

    Up next

    Up nextNanoSoC as the Model Answer

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Variations: Bandwidth, a Second DMA, a Secure Partition