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
    • Memory Subsystem Integration
    • ECC and Error Handling
    • External Memory Controller Integration
      • What the Integrator Wires
      • Bandwidth and Ordering Budgets
      • Initialisation and Training Ownership
    • Boot ROM and Boot Modes
    • eFuse and OTP
    • Secure Boot and Root of Trust
    • Security Architecture
  • 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

←External Memory Controller Integration
  1. Topics
  2. SoC Design
  3. Memories, Boot and Security
  4. External Memory Controller Integration
  5. Initialisation and Training Ownership
On this page

    Part 8 of 14, lesson 9 of 21Part 8 of 14/Memories, Boot and Security/Lesson 9 of 21All levels

    Initialisation and Training Ownership

    From power-up to first legal access: who calibrates the PHY, who programs the controller, and what software may assume.

    Why it matters

    This lesson has one job: assign every step between power-up and the first memory access to exactly one owner. A controller that answers before its PHY is calibrated returns garbage with a valid handshake; firmware that programs timing registers while traffic flows corrupts the calibration it stands on. The sequence crosses hardware, firmware and the power controller, which is why unowned gaps appear and why the first-access hang is the classic symptom.

    The core idea

    The order is fixed: power rails ramp, the PHY reference clock stabilises, hardware or firmware runs training that centres each data eye and stores the delays, firmware programs the controller timing registers from the memory datasheet values and the saved training results, and only then does the fabric gate open for traffic. Training results must survive sleep, so they are saved to always-on registers or re-run at wake (fuses cannot hold them: fuse data is written once at the factory, while training results move with voltage and temperature; the reset-cause register tells the ROM whether to train or restore); the retention lesson's save-and-restore discipline applies bit for bit. Ownership splits three ways: the power controller owns rails and clocks, firmware owns the training firmware and register programming, and the controller hardware owns the gate that blocks traffic until training completes. For the firmware view see Firmware Initialization and DRAM Training Flow; for the controller theory see Row Buffers and Controller Scheduling.

    Diagram
    # not-run: illustrative training budget, illustrative teaching values
    Training sweep: 64 delay steps x 32 lines x 10 reads per step = 20,480 reads.
    At 100 ns per read: about 2.05 ms, paid once per boot and once per wake.
    First-access rule: no fabric transaction until the trained flag reads back set;
      a single polling loop on that flag replaces every guess about timing.

    What the review looks for

    • The sequence diagram names the owner of each step and the flag that proves the step finished.

    • Training results have a named home across sleep: retained registers or a documented re-train at wake.

    • No software path issues a memory access before the trained flag reads back set.

    Verify and debug

    Simulate the sequence with the training engine modelled as a timed stub and confirm the traffic gate stays shut until the trained flag sets; then force the flag path low and confirm every early access errors instead of hanging. If the first access hangs rather than erroring, the gate is missing and the default-slave discipline of the decode section was not extended to the controller window.

    Trim and fuse data loaded late: analog trim not applied before it is needed, so the first accesses run on safe-default or wrong timing. Symptom: wrong frequency or corrupt early traffic, caught by a boot-sequence simulation that includes the fuse read. Fix: sequence loading before release with safe defaults until then.

    If asked who brings up external memory, walk the five steps and name the owner of each. The trap answer is firmware does everything; the hardware gate and the power controller each own steps firmware cannot.

    Check yourself Firmware skips re-training at wake to save 2 ms and restores the old delays. When is that legitimate?

    Only when the delays are retained in always-on storage across sleep and the operating point is unchanged. If voltage or frequency changed, or the values were not retained, the shortcut corrupts traffic and the 2 ms must be paid.

    Related topics

    • Bandwidth and Ordering Budgets

    • eFuse and OTP

    • DRAM: Firmware Initialization and Training Flow

    Previous

    159 / 289

    Next: Boot ROM and Boot Modes

    Up next

    Up nextBoot ROM and Boot Modes

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • What the Integrator Wires