JEDEC Command Sequencing: Inputs and Outputs

Inputs and outputs contract

Inputs and Outputs for JEDEC Command Sequencing focuses on Issue legal ACT/PRE/READ/WRITE command streams while respecting bank-group cadence (tRRD, tFAW, tCCD) and per-bank state transitions.. The purpose is to turn memory observations into mechanism-backed actions with explicit owners and release-safe validation.

Use this contract for architecture, controller firmware, PHY, and validation handoffs. Missing inputs create expensive late-stage rework and inconclusive debug loops.

INPUTS
  - workload distribution and QoS target
  - firmware revision, controller policy profile, timing registers
  - data-rate / voltage / temperature operating state
  - training snapshot and reliability policy status

OUTPUTS
  - bottleneck classification with command-level evidence
  - owner-signed mitigation proposal
  - before/after trend for latency, bandwidth, and reliability
  - regression matrix with rollback triggers

Ownership split

MEMORY OWNERSHIP LAYERS - JEDEC Command Sequencing

artifact area     owner
----------------  ----------------------------
architecture    Memory controller microarchitecture
controller FW   Command scheduler design
verification    DRAM subsystem verification
silicon bringup TBD

Rule: every signoff metric has a named accountable owner.

DRAM deep dive

Timing closure requires command scheduling that respects tRCD/tRP/tRAS/tFAW windows under bursty traffic.

Concept diagram

COMMAND TIMING SEQUENCE

ACT -> tRCD -> READ/WRITE -> tRAS(min) -> PRE -> tRP -> next ACT

Metric graph

TIMING LOSS DRIVERS

read/write turnarounds  ██████
tFAW throttling         ████
guardband padding       ███

Reports and artifacts

• timing-parameter budget table

• command-bus utilization timeline

• tFAW window violation log

• read/write turnaround penalty report

Mini case study

A firmware timing preset favored stability but overpadded turnaround timing, reducing sustained throughput during mixed traffic.

Debug branches

• Audit command spacing against JEDEC minimums and guards

• Track bus-direction switches and hidden dead cycles

• Validate timing updates on both average and p99 latency

Senior review question

Ask: which latency, bandwidth, and reliability evidence proves this DRAM topic is closed under real traffic?

Key takeaways

• Always tie controller and PHY counter shifts to application latency and throughput outcomes.

• Lock firmware timing profile, thermal condition, and DIMM state before comparing DRAM captures.

Common pitfalls

• Chasing peak bandwidth while ignoring p99 latency and fairness tails.

• Changing timing guardbands without separating SI noise from scheduling issues.

• Declaring closure without reliability gates, fault injection, and regression replay.

Handoff explanation

Inputs extend beyond timing registers. DRAM analysis inputs include traffic distribution, address map, queue policy, training state, SI/PI condition, thermal state, and firmware version.

Outputs must be action-ready: Issue legal ACT/PRE/READ/WRITE command streams while respecting bank-group cadence (tRRD, tFAW, tCCD) and per-bank state transitions., artifact packet (Per-cycle command legality matrix and bank-state timeline showing ACT -> READ/WRITE -> PRE transitions under JEDEC timing windows.), bottleneck class, owner, expected gain, and rollback scope. "Bandwidth improved" without this packet is not signoff-ready.

The safest handoff is a before/after evidence set: environment tags, traces, hypothesis, chosen fix, rejected alternatives, and regression criteria.