RAS# — Row Address Strobe

This chapter and the two after it cover RAS#, CAS# and WE# — three signals that together encoded the command in every DRAM generation from the asynchronous era through DDR3.

They are the most misunderstood signals in the interface, for a specific reason: they are taught as though they are how DDR commands work, and in current generations they are not. The registry entry for this chapter says "legacy-style", and that qualifier is load-bearing.

This chapter's question is narrower and more interesting than "what does RAS# do":

Why is a command bit named after a strobe?

The answer is that it was a strobe — not metaphorically, but literally an edge that latched a value — and what happened to it is one of the cleanest examples in digital design of a name outliving its mechanism. Understanding the transition teaches a distinction that transfers well beyond DRAM.

1. What a Strobe Actually Was

To see what changed, you have to see what RAS# originally was — and the answer is more literal than most descriptions suggest.

In asynchronous DRAM, RAS# was a clock. Not "like a clock", not "a timing signal" — the falling edge of RAS# was the event that captured the row address into the device's row latch. Chapter 4.1 §1 described the asynchronous era as a world with no shared clock, in which the controller drove control signals and satisfied specified minimum intervals using its own delay elements. RAS# was one of those control signals, and its edge was the timing reference for the row address.

Why "strobe"? Because that is what the word means in this context: a signal whose transition causes a capture. The row address lines were driven, then RAS# fell, and the falling edge strobed the address into the device.

And it did more than latch. Asserting RAS# also began the row access itself — the wordline activation and sensing that Module 3 describes. So a single signal carried both the timing event and the operation request, which is exactly the conflation that a clocked interface later separated.

2. The Change, Stated in RTL Terms

The transition from asynchronous to synchronous DRAM changed RAS# from a clock into a data input, and that sentence is precise enough to write down:

   ASYNCHRONOUS:   always_ff @(negedge ras_n)  row_latch <= addr;
                   RAS# is the CLOCK of the capture register.

   SYNCHRONOUS:    always_ff @(posedge ck)
                     if (!ras_n && !cs_n) row_latch <= addr;
                   RAS# is DATA into a register clocked by CK.

That is the whole architectural change, in four lines. A signal moved from the clock port of a flip-flop to its data port.

3. Why the Name Survived

If RAS# stopped being a strobe, why is it still called one?

Because interfaces inherit vocabulary faster than they inherit mechanisms. SDR SDRAM was designed to be adoptable by systems and engineers already working with asynchronous DRAM, and keeping the control signals' names and broad roles made the transition legible. The signal that used to start a row access still started a row access; that it now did so as a sampled level rather than as an edge was an implementation change beneath a familiar interface.

The cost is a generation of confused engineers, and the confusion is specific: the name suggests a timing role the signal has not had since the asynchronous era, and it invites the expectation that RAS# somehow times the row address. It does not. CK does.

This pattern is worth recognising because it recurs. Chapter 6.10 covers DQS, which is genuinely a strobe — and one of the most common errors in the field is to reason about DQS by analogy with RAS#, or the reverse. One of them is a real strobe and one of them is a command bit with a strobe's name, and telling them apart is not optional.

4. RTL — Two Capture Disciplines

Engineering problem

Show, in runnable form, the difference between a signal that is the capture event and a signal that is captured. The two disciplines produce different results from the same stimulus, and seeing where they diverge is what makes the distinction concrete.

Classification

SYNTHESIZABLE RTL — and deliberately, because both disciplines genuinely synthesise. The asynchronous half infers a register clocked by ras_n; the synchronous half infers a register clocked by ck with ras_n as an enable term. Both are real hardware, which is the point: this is not a metaphor, it is two ways of building the same function.

What it represents: the historical capture discipline and the modern one, side by side, on shared stimulus.

What it does not represent: any real DRAM device. No array, no sensing, no row activation, no timing intervals of any kind. The asynchronous half is a model of a historical interface discipline, not a model of any asynchronous DRAM part, and it is not offered as something to build.

And a caution about the asynchronous half specifically: creating a register clocked by a data-like signal is generally poor practice in modern design — it creates a clock domain, it makes the signal's edge quality safety-critical, and the crossing back into the main domain needs synchronisation. It is shown here because it is what the interface historically did, and understanding why it was abandoned is more useful than pretending it never happened.

Interface contract

addr_in carries the row address. ras_n is the control signal. sample_evt marks the synchronous sampling event. The two halves report independently through async_* and sync_*.

State

One capture register per discipline, plus an edge-detect flag in the asynchronous half.

Combinational behaviour

The synchronous half's qualification term.

Sequential behaviour

Two registers in two different clock domains — which is itself the lesson.

How to simulate

vlog strobe_vs_level_capture.sv tb_strobe_vs_level_capture.sv then vsim -c tb_strobe_vs_level_capture -do "run -all".

Expected result: the two halves capture at different moments from identical stimulus, and there are events where one captures and the other does not.

// ─────────────────────────────────────────────────────────────────────────
// STROBE VS LEVEL CAPTURE.  Classification: SYNTHESIZABLE RTL.
//
// The asynchronous-to-synchronous transition changed RAS# from a CLOCK
// into a DATA INPUT. Both disciplines genuinely synthesise, which is why
// this is worth building rather than describing:
//
//   ASYNCHRONOUS:  ras_n is the CLOCK of the capture register.
//   SYNCHRONOUS:   ras_n is DATA into a register clocked by CK.
//
// A signal on a clock port and the same signal on a data port impose
// COMPLETELY DIFFERENT OBLIGATIONS -- edge quality and skew versus level
// stability at a known instant -- and that is the transferable lesson.
//
// WHAT THIS DOES NOT REPRESENT: any real DRAM device. No array, no
// sensing, no row activation, no timing intervals. The asynchronous half
// models a HISTORICAL INTERFACE DISCIPLINE, not any asynchronous DRAM part.
//
// AND IT IS NOT A RECOMMENDATION. Clocking a register from a data-like
// signal creates a clock domain, makes that signal's edge quality
// safety-critical, and requires synchronisation on the way back. It is
// shown because it is what the interface historically did, and because
// knowing WHY it was abandoned is more useful than not knowing it existed.
// ─────────────────────────────────────────────────────────────────────────
module strobe_vs_level_capture #(
  parameter int ADDR_W = 16
) (
  input  logic              ck,
  input  logic              rst_n,

  input  logic [ADDR_W-1:0] addr_in,
  // Active low. In the asynchronous half this is a CLOCK; in the
  // synchronous half it is DATA. Same wire, two roles.
  input  logic              ras_n,
  input  logic              cs_n,
  input  logic              sample_evt,

  // ── Asynchronous-era discipline.
  output logic [ADDR_W-1:0] async_latched,
  output logic              async_capture,

  // ── Synchronous-era discipline.
  output logic [ADDR_W-1:0] sync_captured,
  output logic              sync_capture
);

  if (ADDR_W < 1) begin : g_aw
    initial $fatal(1, "strobe_vs_level_capture: ADDR_W must be >= 1");
  end

  // ─────────────────────────────────────────────────────────────────────
  // ASYNCHRONOUS DISCIPLINE: the strobe IS the clock.
  //
  // The falling edge of ras_n captures the address. Nothing else is
  // involved -- no ck, no sample_evt, no qualification. The address must
  // already be stable when the edge arrives, and ensuring that was the
  // CONTROLLER'S analog problem, discharged with delay elements.
  //
  // This register lives in the ras_n clock domain. async_latched crossing
  // into the ck domain below is a REAL domain crossing, and in anything
  // other than a teaching model it would need synchronisation. That
  // hazard is not incidental -- it is a large part of why the industry
  // moved away from this discipline.
  // ─────────────────────────────────────────────────────────────────────
  always_ff @(negedge ras_n or negedge rst_n) begin
    if (!rst_n) async_latched <= '0;
    else        async_latched <= addr_in;
  end

  // Edge detection in the ck domain, purely so the capture is observable
  // in the same trace as the synchronous half. This is OBSERVABILITY
  // SCAFFOLDING, not part of either discipline.
  logic ras_n_d;
  always_ff @(posedge ck or negedge rst_n) begin
    if (!rst_n) begin
      ras_n_d       <= 1'b1;
      async_capture <= 1'b0;
    end else begin
      ras_n_d       <= ras_n;
      async_capture <= ras_n_d && !ras_n;   // falling edge seen
    end
  end

  // ─────────────────────────────────────────────────────────────────────
  // SYNCHRONOUS DISCIPLINE: the strobe is DATA.
  //
  // ck is the clock. ras_n is one term of the enable, alongside chip
  // select (Chapter 6.3) -- it contributes to deciding WHAT this command
  // is, and contributes nothing to WHEN it is captured.
  //
  // Its obligation is the stability contract of Chapter 6.1: be settled
  // and unchanging around the sampling event. Glitches between events are
  // harmless, which is exactly what is NOT true of the half above.
  // ─────────────────────────────────────────────────────────────────────
  logic row_cmd;
  assign row_cmd = sample_evt && !cs_n && !ras_n;

  always_ff @(posedge ck or negedge rst_n) begin
    if (!rst_n) begin
      sync_captured <= '0;
      sync_capture  <= 1'b0;
    end else begin
      sync_capture <= 1'b0;
      if (row_cmd) begin
        sync_captured <= addr_in;
        sync_capture  <= 1'b1;
      end
    end
  end

endmodule

Cycle-by-cycle example

Cycles 2 and 8 are the divergence. The asynchronous discipline captures because an edge occurred; the synchronous one does not, because no sampling event coincided. Same wire, same stimulus, different results — and that is the difference between being the event and being sampled at one.

Cycle 7 is the mirror image. A sampling event occurs and RAS# is high, so the synchronous half correctly sees "not a row command" while the asynchronous half is simply not involved.

Waveform expectation

§5. Watch async_capture and sync_capture fire at different cycles from one stimulus stream.

Synthesis implication

The asynchronous half infers a register clocked by ras_n, which most synthesis flows will accept and most design rules will flag — correctly. The synchronous half infers an ordinary enabled register in the ck domain. The crossing between them is a genuine clock-domain crossing and the model deliberately leaves it unsynchronised so that the hazard is visible rather than papered over.

Corner cases

Reset is asynchronous in both halves, which is necessary in the strobe-clocked one: a register clocked by a signal that may not be toggling cannot be reset synchronously. ras_n glitching produces spurious captures in the asynchronous half and nothing at all in the synchronous one — run that stimulus deliberately, because it is the clearest demonstration of what the transition bought. A sampling event with cs_n high produces no synchronous capture regardless of RAS#, which is Chapter 6.3's qualification.

Debugging clues

If the asynchronous half captures at unexpected moments, look for glitches on ras_n — on a clock port there is no such thing as a harmless glitch. If the synchronous half never captures, check the three-term enable: sampling event, chip select, and RAS# level all participate, and omitting chip select makes every event with RAS# low a row command regardless of which rank was addressed. If async_latched reads inconsistently when observed from the ck domain, that is the unsynchronised crossing behaving exactly as expected.

Limitations

No DRAM. No row activation, no sensing, no restoration, no timing intervals. No modelling of the analog obligations either discipline imposes. The edge-detect logic is observability scaffolding and is part of neither discipline. And the asynchronous half is a historical model, not a design pattern — the header says so at length because the code is perfectly synthesizable and could be mistaken for a recommendation.

5. The Two Disciplines, in Cycles

Cycle 2 is the asynchronous discipline working exactly as designed. RAS# falls, the address is latched, and no clock was involved. The controller had to guarantee the address was stable before that edge using its own delay generation — which Chapter 4.1 §1 identified as the burden the synchronous transition removed.

Cycle 5 is the only coincidence, and it is a coincidence: the sampling event happens to fall where RAS# is low and chip select is asserted. In a real synchronous interface this is not luck — the controller drives RAS# low precisely so that the next sampling event reads a row command.

Cycle 7 shows the synchronous discipline's normal negative case. A sampling event occurs, RAS# is high, and the answer is "this is not a row command". That is a decision, not an absence — the level was read and meant something.

And cycle 8 is the asynchronous half capturing with no sampling event at all, which in a synchronous system would be meaningless. Three asynchronous captures, one synchronous capture, identical stimulus.

Representative educational cycles. The relationship between RAS# transitions and sampling events here is chosen to expose the divergence, not to model any real command sequence.

6. Two Assertions Worth Writing

// VERIFICATION-ONLY, inside strobe_vs_level_capture.

// P1 -- the synchronous capture requires ALL THREE terms. Dropping chip
// select would make every event with RAS# low a row command regardless of
// which rank was addressed -- a fault that only appears in multi-rank
// systems and therefore survives single-rank testing.
property p_sync_needs_all_terms;
  @(posedge ck) disable iff (!rst_n)
    sync_capture |-> ($past(sample_evt) && !$past(cs_n) && !$past(ras_n));
endproperty
assert property (p_sync_needs_all_terms);

// P2 -- and the converse, so the property set is not satisfiable by a
// design that never captures.
property p_sync_captures_when_qualified;
  @(posedge ck) disable iff (!rst_n)
    (sample_evt && !cs_n && !ras_n) |=> (sync_capture
                                         && (sync_captured == $past(addr_in)));
endproperty
assert property (p_sync_captures_when_qualified);

// P3 -- THE DISCIPLINE PROPERTY. The synchronous half must NOT capture on
// a RAS# edge that has no sampling event. This is the whole architectural
// claim of the chapter: in a synchronous interface the strobe does not
// cause captures, the clock does.
property p_sync_ignores_bare_edges;
  @(posedge ck) disable iff (!rst_n)
    ($past(ras_n) && !ras_n && !sample_evt) |=> !sync_capture;
endproperty
assert property (p_sync_ignores_bare_edges);

P3 is the one worth writing, because it asserts a negative that defines the architecture: the synchronous path is indifferent to RAS#'s edges. A design that accidentally became edge-sensitive — through a poorly written enable, or an inferred latch — would satisfy P1 and P2 and fail only P3.

And note what cannot be asserted here at all. The asynchronous half has no clock to sample assertions against, so ordinary concurrent SVA cannot meaningfully check it. Properties sampled on ck observe the ras_n-domain register through an unsynchronised crossing, which means they may sample a value in transition. That is not a limitation of this model — it is the actual reason asynchronous interfaces are hard to verify, and it is worth meeting here rather than as a surprise.

What none of them prove. Nothing about edge quality on ras_n, which is the asynchronous discipline's entire safety argument and is analog. Nothing about setup or hold in either half. And nothing about any DRAM behaviour, since there is no DRAM here.

7. Where RAS# Went

The trio's story ends in Chapter 6.6, but RAS#'s own ending is worth stating now because it is the most commonly misreported fact in DDR.

In DDR4, the pin is RAS_n/A16. It is a multi-function pin, and which function applies is decided by ACT_n:

   ACT_n LOW   ->  the pin carries row-address bit A16
   ACT_n HIGH  ->  the pin carries RAS_n

Read that carefully, because the consequence is counter-intuitive. A DDR4 row activate is signalled by ACT_n low — and at that moment the pin named RAS_n is carrying an address bit, not a command bit. The signal historically named "row address strobe" is, during a row activate, being used as part of the row address.

That is not irony; it is the encoding argument arriving. Chapter 6.6 develops it fully: three command signals give eight encodings, larger arrays need more row-address bits, pins are expensive, and the resolution was to reuse the command pins for address during the one command that needs the most address.

And in DDR5 the arrangement changed again, with a differently encoded command/address interface in which RAS# does not appear. Module 25 owns DDR5's command architecture.

8. Common Misconceptions

"RAS# is how DDR activates a row." Wrong model: asserting RAS# is what opens a row, in all DDR generations. Why it is tempting: it is literally the signal's name, it was true for SDR through DDR3, and most introductory material stops there. Consequence: a completely wrong reading of any DDR4 command table, and — concretely — an engineer looking for a RAS# pin on a DDR4 device and finding RAS_n/A16, then assuming the slash means "either name". During a DDR4 activate, that pin is carrying A16. Reasoning about DDR4 or DDR5 command behaviour in RAS#/CAS#/WE# terms produces conclusions that do not correspond to the hardware. Correct model: RAS# is a dedicated command input in SDR through DDR3. In DDR4 the row activate is signalled by ACT_n, and the RAS_n/A16 pin carries an address bit while that happens. In DDR5 the encoding is different again. Prevention: check the generation before reasoning about command signalling, and read multi-function pin names as modes, not as aliases.

"RAS# times the row address." Wrong model: the strobe provides the timing reference for the address lines. Why it is tempting: the name says strobe, and in asynchronous DRAM it was exactly true. Consequence: looking for a skew relationship between RAS# and the address lines in a synchronous interface, where the relationship that matters is between CK and all of the command signals together — including RAS# itself. The engineer analyses the wrong pair and finds nothing. Correct model: in synchronous DRAM, CK times everything on the command path, and RAS# is one of the sampled signals, subject to the same stability obligation as the address lines beside it. It moved from the clock port of a register to the data port. Prevention: ask which signal is on the clock port. In a synchronous interface it is CK, always.

"RAS# and DQS are both strobes, so they work similarly." Wrong model: the word "strobe" implies a shared mechanism. Why it is tempting: both names contain it, and both are associated with capture. Consequence: expecting DQS to be a command-path level sampled by CK — which loses everything that makes it source-synchronous — or expecting RAS# to accompany data. The two are in different timing domains with different directions and different disciplines, and reasoning about one by analogy with the other produces errors in both. Correct model: DQS is genuinely a strobe — Chapter 6.10 — driven by whichever side drives the data, travelling with it, providing its timing. RAS# is a command bit with a strobe's inherited name, sampled by CK on the command path. One is the real mechanism; the other is a historical label. Prevention: ask what times the signal. DQS times something; RAS# is timed by something.

"Multi-function pins mean the signal can be either thing at any time." Wrong model: RAS_n/A16 is a pin that might carry either, ambiguously. Why it is tempting: the notation looks like an alias, and nothing in the name says what selects between them. Consequence: an inability to read a DDR4 command table, and a controller or monitor that does not know which interpretation applies at a given event — so it decodes some commands as addresses and some addresses as commands. Correct model: the selection is explicit and deterministic: ACT_n decides. Low means the pins carry A16, A15 and A14; high means they carry RAS_n, CAS_n and WE_n. Every event has exactly one interpretation, determined by a signal present at that same event. Prevention: for any multi-function pin, find the signal that selects the mode. If you cannot name it, you cannot decode the interface.

9. Debugging — A Monitor Decodes Commands That Were Never Issued

Symptom. A verification or debug monitor attached to a DDR4 interface reports commands the controller never issued — often a plausible-looking mixture of real ones. Traffic is otherwise functionally correct.

A monitor reporting phantom commands on a functionally working interface is almost always a decode problem rather than a signalling problem, and the shape of the phantom commands says which.

Mechanism 1 — the monitor decodes RAS#/CAS#/WE# without checking ACT_n. Inspect: whether the decode consults ACT_n before interpreting those three pins. Expected evidence: phantom commands appearing exactly when row activates occur, because that is when the pins carry A16/A15/A14 and the monitor is reading address bits as a command encoding. Discriminator: do the phantoms correlate with activates? This is the most likely cause on DDR4 and the correlation is immediate and decisive.

Mechanism 2 — the monitor ignores chip select. Inspect: whether decode is qualified by CS#. Expected evidence: every command reported multiple times, once per rank, or commands attributed to the wrong rank. Discriminator: is the phantom count proportional to rank count? Chapter 6.3 §1 established the CA bus is a broadcast — a monitor that decodes it without CS# has no way to know which device acted, and will report every command as though every rank executed it.

Mechanism 3 — the monitor samples on the wrong event. Inspect: what the monitor uses as its sampling reference. Expected evidence: decoded values that are plausible but shifted in time, or occasional garbage from sampling during transitions. Discriminator: are the phantoms garbage or plausible? Garbage suggests sampling mid-transition; plausible-but-wrong suggests a decode fault, which points back at mechanisms 1 and 2.

Mechanism 4 — the monitor was written for a different generation. Inspect: which generation's command semantics the monitor implements against which device is present. Expected evidence: a monitor with a RAS#/CAS#/WE# decode attached to DDR5, or a DDR4 decode attached to DDR3. Discriminator: compare the monitor's assumed signal set against the device's actual signal list. This is worth checking early because it is free and because a monitor ported across generations without review is common.

Mechanism 5 — not the monitor: CKE. Inspect: whether the reported commands occurred while the device was not sampling. Expected evidence: phantom commands during idle periods. Discriminator: check CKE at the phantom events. Chapter 6.2 §4 established that a device not sampling does not see commands at all — so a monitor watching the wires will faithfully report commands that no device executed. The monitor is right about the wires and wrong about the effect.

Discrimination, cheapest first. Correlate the phantoms against activates — one comparison, and it resolves mechanism 1, which is the most likely. Then check whether the phantom count scales with rank count. Then check CKE at the phantom events. Then compare the monitor's generation assumptions against the device.

The reasoning lesson. A bus monitor reports what is on the wires; a command monitor must report what the devices did, and those differ in three separate ways — multi-function pins mean the wires' meaning depends on another signal, chip select means only one device acted, and CKE means possibly none did. A monitor that decodes signal values without decoding signal context is not a command monitor, and it will be confidently wrong in ways that look like design bugs. This is why Chapter 6.3 §4 insisted that a trace capturing CA without CS# has captured nothing useful.

10. Interview Reasoning

"Why is RAS# called a strobe if it is a command bit?" Because it used to be one, literally. In asynchronous DRAM there was no clock, and the falling edge of RAS# was the event that latched the row address into the device — the signal was the clock of that capture register. The synchronous transition moved it from the clock port of a flip-flop to the data port: it became a level sampled at a CK event, one term in the command encoding alongside CAS# and WE#. The name survived because SDR SDRAM was designed to be legible to engineers already working with asynchronous parts, and keeping the control signals' names made the transition easier to adopt. The cost is that the name now suggests a timing role the signal has not had for decades.

"What changes when a signal moves from a clock port to a data port?" Essentially every obligation attached to it. As a clock, its edge quality is safety-critical — a glitch becomes a capture — its skew relative to what it captures is the whole timing budget, it creates a clock domain, and anything crossing out of that domain needs synchronisation; the controller has to generate a correctly shaped edge at a correctly chosen moment, which is an analog problem. As data, only its level at a known instant matters, glitches between sampling events are harmless, it lives in the same domain as every other command signal, and its obligation is stability around the sampling event. That is a useful question to ask about any unfamiliar interface signal, because the answer tells you immediately which failure modes exist and whether a domain crossing is hiding there.

"Does DDR4 have a RAS# pin?" Not a dedicated one. The ball is RAS_n/A16, a multi-function pin, and ACT_n selects the interpretation: when ACT_n is low the pin carries row-address bit A16, and when ACT_n is high it carries RAS_n. The counter-intuitive consequence is that during a DDR4 row activate — which is signalled by ACT_n low — the pin named RAS_n is carrying an address bit, not a command bit. So "RAS# activates a row" is wrong for DDR4 in a fairly complete way, and reasoning about DDR4 command behaviour in RAS#/CAS#/WE# terms does not correspond to the hardware. DDR5 encodes commands differently again and does not have these signals at all.

"Are RAS# and DQS both strobes?" Only one of them is. DQS is genuinely a strobe — it is driven by whichever side is driving the data, it travels with that data, and it provides the timing reference the receiver uses to capture it. RAS# is a command bit that inherited a strobe's name from the asynchronous era; in a synchronous interface it is timed by CK rather than timing anything. The practical importance is that they sit in different timing domains with different directions and different disciplines, so reasoning about one by analogy with the other produces errors in both directions — expecting DQS to be sampled by CK loses everything that makes it source-synchronous.

"A DDR4 monitor reports commands that were never issued. What is your first hypothesis?" That it is decoding RAS#/CAS#/WE# without checking ACT_n. Those pins are multi-function, so during a row activate they carry A16, A15 and A14 — and a monitor reading them as a command encoding at that moment will decode row-address bits as a command. The confirming evidence is immediate: the phantom commands correlate exactly with real activates. After that I would check whether the monitor qualifies its decode with chip select, because the command bus is a broadcast and a monitor without CS# will report every command as though every rank executed it. And I would check CKE at the phantom events, because a device that is not sampling does not see commands at all — so the monitor can be entirely correct about the wires and still be reporting things no device did.

11. Engineering Exercise

Educational; no timing values implied.

1. In §4's model, ras_n glitches low briefly between sampling events. What does each discipline do? The asynchronous half captures — a glitch on a clock port is a clock edge, and there is no such thing as a harmless one. The synchronous half does nothing at all, because no sampling event occurred and the level is only read at those events. This single stimulus is the clearest demonstration of what the synchronous transition bought.

2. Remove cs_n from the synchronous enable. What breaks, and when would you notice? Every event with RAS# low becomes a row command regardless of which rank was addressed. On a single-rank system nothing changes, so the bug survives all single-rank testing. It appears only when a second rank is populated, as commands intended for one rank being executed by both — which is Chapter 6.3 §9's highest-blast-radius fault class.

3. A DDR4 device is executing an activate. What is the RAS_n/A16 pin carrying? A16 — a row-address bit. ACT_n is low during an activate, which selects the address interpretation. The signal named "row address strobe" is carrying part of the row address and is not acting as a command bit at all.

4. Why can ordinary concurrent SVA not meaningfully verify §4's asynchronous half? Because concurrent assertions are sampled against a clock, and that half has no clock available to the verification environment — it is clocked by ras_n itself. Sampling it from the ck domain observes the register through an unsynchronised crossing, which may catch it in transition. That is not a modelling weakness; it is the actual reason asynchronous interfaces were hard to verify, and it is a concrete benefit of the synchronous transition that is rarely stated.

5. Both disciplines in §4 synthesise. Why is only one of them acceptable practice today? Because clocking a register from a data-like signal creates a clock domain whose quality is determined by a signal nobody designed as a clock, makes every glitch a functional hazard, requires synchronisation on every path leaving it, and multiplies the number of timing-analysis domains. The synchronous discipline concentrates all of that into one well-characterised clock. Chapter 4.1 §1's framing applies exactly: it converted an analog timing problem into a digital sequencing one.

6. A colleague says "DDR4 dropped RAS#". Correct them precisely. DDR4 dropped the dedicated RAS# pin, not the signal function. The ball exists as RAS_n/A16 and still carries RAS_n when ACT_n is high. What DDR4 removed was RAS#'s role in signalling the activate — that moved to ACT_n — and it reused the freed capacity for address bits. "Dropped" and "multiplexed" are different claims, and the second is what happened.

12. Summary

RAS# is a command bit named after a mechanism it stopped using decades ago.

In asynchronous DRAM it was literally a clock: the falling edge of RAS# latched the row address into the device, and the controller was responsible for guaranteeing the address was stable before that edge using its own delay generation.

The synchronous transition moved it from the clock port of a register to the data port. It became a level sampled at a CK event, one term in a command encoding alongside CAS# and WE# and chip select. That single change carries every difference that matters: edge quality stopped being safety-critical, glitches between events became harmless, the clock domain it created disappeared, and its obligation became the stability contract Chapter 6.1 describes.

Asking whether a signal is on a clock port or a data port is a question worth carrying to any unfamiliar interface — it tells you immediately which obligations apply, which failures are possible, and whether a domain crossing is hiding.

The name survived because interfaces inherit vocabulary faster than mechanisms, and the cost is a persistent confusion with DQS, which is a genuine strobe. One of them times something; the other is timed by something.

And in DDR4 the dedicated pin is gone. The ball is RAS_n/A16, with ACT_n selecting: low means the pin carries row-address bit A16, high means it carries RAS_n. So during a DDR4 row activate, the pin named "row address strobe" is carrying an address bit — because the activate itself is signalled by ACT_n. In DDR5 the command/address encoding changed again and RAS# does not appear.

"DDR4 dropped RAS#" is imprecise. DDR4 multiplexed it, and Chapter 6.6 explains why that was the available move.

13. What Comes Next

Chapter 6.5 takes the trio's second member, and it has the larger legacy.

CAS# marks the column half of the access — and because a column command is where the data pipeline actually begins, the interval from that command to data arriving became the number quoted for memory latency. CAS latency is named after this signal, and it is probably the most-used term in the whole field.

6.5 is about why that interval exists, why it attached to this signal rather than to RAS#, and what the row-versus-column asymmetry means for a controller — without consuming the read-operation and timing modules that own the mechanism and the values.

Return to CK / CK# for the sampling contract RAS# is subject to, CS# for the qualification term §4's enable needs, or SDR SDRAM for the asynchronous-to-synchronous transition this chapter watches happen to one wire. The full path is on the DDR tutorials index.