DDR Controller / PHY Split: Inputs & Outputs

Inputs and outputs contract

Inputs & Outputs for DDR Controller / PHY Split focuses on command efficiency, PHY training pass rate, read/write turnaround loss. The goal is to connect the observable symptom to protocol mechanism, ownership, and regression risk.

Treat these as a signed interface contract. Ambiguity here is the single biggest source of wasted integration weeks, because two teams debug against different assumptions.

INPUTS
  - protocol spec revision and feature subset
  - clock/reset assumptions
  - address map, ID/tag width, ordering attributes
  - traffic class, QoS, firmware register settings

OUTPUTS
  - legal transaction trace
  - integration waiver list
  - VIP/compliance report
  - owner-signed debug or signoff note

Transaction sequence

SEQUENCE — DDR Controller / PHY Split

  initiator            interconnect/PHY            target
      |  request (id) ------->  |                     |
      |                         |  forward ----------> |
      |                         |                     | work
      |                         |  <---- response ---- |
      |  <----- complete ------ |                     |
      |
   metric captured here: command efficiency, PHY training pass rate, read/write turnaround loss

Ownership map

OWNERSHIP MAP — DDR Controller / PHY Split

evidence type        owner who reads it
-----------------    ---------------------------
waveform/RTL        memory controller owner
spec/VIP            PHY owner
firmware/system     SoC integration owner

Rule: every metric must have a named owner before a review starts.

Protocol deep dive

DDR bandwidth is scheduler + PHY: rows, banks, refresh, and turnarounds eat headline data rate.

Concept diagram

MEMORY PATH

masters -> controller scheduler -> PHY -> DRAM banks
              |                      |
         refresh/QoS            training/margin

Scheduler sees transactions; PHY sees picoseconds.

Metric graph

BANDWIDTH LOSS WATERFALL

peak              ████████████████████████
refresh           █████████████████████
turnaround        ██████████████████
row miss          ██████████████
effective         ██████████████

Quote the bottom bar in reviews.

Metrics and artifacts to collect

• effective BW

• row hit rate

• refresh stall %

• training margin

• ECC error log

Mini case study

Video workload lost half effective bandwidth after firmware enabled aggressive low-power refresh. Scheduler and firmware QoS had to be co-designed.

Debug branches

• If ECC errors, check training margin and address interleave first.

• If BW low with high row hit, suspect port arbitration not DRAM.

• If boot fail, stop at training step in transcript.

Senior review question

Ask: what is the first transaction that deviates, and which spec rule does it test?

Key takeaways

• Connect every protocol claim to a transaction identity and measurable metric.

• Store the artifact (waveform, log, counter) next to every signoff decision.

Common pitfalls

• Debugging timeouts without finding the first bad transaction.

• Quoting peak bus width without payload efficiency and retry overhead.

• Treating VIP compliance as a substitute for system integration replay.

Principal review addendum

Re-read DDR Controller / PHY Split against one concrete product workload, not a synthetic directed test.

the controller schedules memory commands while the PHY handles electrical timing, calibration, and lane alignment.