Mode 3 (CPOL=1, CPHA=1)

Three modes down. Chapter 3.4 built the CPHA = 0 first-bit launch, Chapter 3.5 showed CPHA = 1 removing it, and Chapter 3.6 demonstrated that flipping polarity changes every physical direction and no logical behaviour.

Mode 3 completes the set, and it carries the module's most commercially significant question.

Why do so many devices list "Mode 0 or Mode 3", and what does that actually guarantee?

Serial flash, in particular, almost invariably specifies both. Chapter 3.3 §4 showed why they are so alike — they agree on both physical directions. This chapter works out what follows from that, and where the equivalence stops.

1. Mode 3, Derived

The three steps, for the last time.

Step 1 — where does the clock rest? CPOL = 1, so SCLK idles high. Same as Mode 2.

Step 2 — which direction is the leading edge? Away from rest: leading is falling, trailing is rising. Same as Mode 2.

Step 3 — which logical edge samples? CPHA = 1, so the trailing edge samples and the leading edge launches. Same as Mode 1.

Composing: Mode 3 launches on falling edges and samples on rising edges, with the clock idling high.

Now the observation that makes this chapter necessary. Mode 0, derived in Chapter 3.4, launches on falling edges and samples on rising edges — with the clock idling low.

The physical directions are identical. Only the idle level differs.

2. The Transfer

Two comparisons are worth making.

Against Chapter 3.5's Mode 1 figure: the mosi and cs_n rows are identical, and only sclk is inverted. That is Chapter 3.6's independence result again, applied to the other phase — changing polarity alone reverses directions and leaves the data timing alone.

Against Chapter 3.4's Mode 0 figure: the data is displaced by half a bit time, and nothing is launched at CS. The two modes agree on physical directions but differ in when within the bit time the data changes. That distinction is the whole of §4.

3. Why Modes 0 and 3 Travel Together

Set the two side by side.

The two middle rows are the reason they are listed together. Both launch on falling and sample on rising, arrived at by opposite routes: Mode 0 because its trailing edge is falling, Mode 3 because its leading edge is falling.

For a receiver, that similarity is powerful. If a device's capture logic is built around "sample whatever is on the line at each rising edge," it behaves identically in Mode 0 and Mode 3 — the rising edges arrive at the same points in the transfer and carry the same bits. The device does not need to know which mode it is in.

This is why a datasheet can honestly say "Mode 0 and Mode 3 supported" without implementing two behaviours. Frequently it implements one behaviour that happens to be correct under both.

4. Where the Equivalence Stops

Three places, in increasing order of how likely you are to meet them.

The first bit. This is the real one. Mode 0 is CPHA = 0 and requires the first bit to be launched by CS assertion (Chapter 3.4); Mode 3 is CPHA = 1 and launches it on the first clock edge (Chapter 3.5). A device that genuinely supports both must implement the CS launch for the Mode 0 case — and a master driving such a device must do the same for its own transmit path.

So "0 or 3" is symmetric for the sampling side and asymmetric for the transmitting side. A device whose MISO output is only ever read after the first byte, or whose first returned byte is documented as don't-care, can be indifferent in practice while a device that returns meaningful data in bit one cannot.

The idle level itself. If the board relies on a pull resistor while the master's output is high-impedance — during FPGA configuration, during reset, on a hot-swappable module — the pull's direction must match the mode in use (Chapter 3.6 §7). A device indifferent to idle level does not make the board indifferent.

The transition between them. Switching a controller from Mode 0 to Mode 3 changes cpol, which moves the shared clock line — an edge every device on the net observes (Chapter 3.1 §3). The modes may be interchangeable in steady state while the change is not free, which matters on a bus carrying a second device that is mid-transaction or sensitive to spurious edges.

5. Reading "Supports 0 and 3" Correctly

A practical procedure, because this claim appears constantly and is easy to over-trust.

Check whether the first returned bit is meaningful. If the device's read transactions begin with an opcode phase during which MISO is undefined — as most serial flash does (Chapter 1.4 §3) — then its first MISO bit never carries data and the CPHA asymmetry of §4 cannot hurt you. If the device returns meaningful data from bit one, check the datasheet's first-bit behaviour explicitly.

Check the transmit side separately. Your master must still launch its own first MOSI bit correctly for whichever mode you configure. The device's indifference says nothing about your controller's obligation, and Chapter 3.5 §11's review scenario is exactly the failure that results from conflating the two.

Check what the board does when nobody drives the clock. A pull resistor, a shared bus with a differently-configured device, or a power-sequencing window can all impose an idle level the mode must agree with.

Prefer the timing diagram to the mode number. Chapter 3.3 §8 made this point generally and it applies with force here: a datasheet claiming both modes will usually show one timing diagram, and that diagram tells you which behaviour is actually implemented.

6. Why This Chapter Has No New RTL

The pattern from Chapter 3.5 and Chapter 3.6 holds, and by now the reason should feel structural rather than convenient.

Mode 3 is CPOL = 1, CPHA = 1. Polarity is absorbed by the divider (Chapter 3.1) and the decoder (Chapter 3.3); phase is handled by the cpha input to Chapter 3.4's transmit path, whose cpha = 1 behaviour is already built and already verified by its testbench. The mode decoder's testbench verifies Mode 3's role mapping explicitly — the check(2'd3, …) cases confirm that falling launches and rising samples — and it additionally checks the §3 relationship directly, asserting that modes 0 and 3 both launch on a falling edge. That check exists precisely because this chapter's central claim deserves to be executable rather than asserted in prose.

There is no Mode 3 module to write. Every line of hardware it needs exists and has been simulated.

What this chapter contributes instead is the comparison table of §3 and the interoperability analysis of §4 and §5, which are judgement rather than logic — and which are, in practice, what an engineer integrating a flash device actually needs.

7. Why a Verification Engineer Cares

The 0/3 pairing is a coverage trap. A test suite that exercises Mode 0 and Mode 3 can feel thorough — two modes, both common — while covering only one physical configuration, since both launch on falling and sample on rising. The untested physical arrangement is modes 1 and 2. A coverage model binning by mode number reports 50%; a model that understood the pairing would report that one of two physical behaviours has never been exercised.

The first-bit path is the asymmetry to target. Mode 0 and Mode 3 differ in exactly one implementation respect, so a directed test that runs the same transfer in both and compares is a precise probe for the CS launch path — the control-case argument Chapter 3.5 §8 made, with a pair of modes a device is likely to support simultaneously.

Model the device's indifference explicitly. If a slave BFM is written to sample on rising edges regardless of mode — mirroring a real device that does the same — then it will pass in Modes 0 and 3 and fail in 1 and 2, which is correct behaviour and should be asserted rather than discovered. A BFM that silently adapts to any mode is modelling a device that does not exist, and it will hide a master's mode-configuration bug.

8. Failure Signature — Flash Works in Mode 0, Fails in Mode 3

Symptom. A serial flash device documented as supporting both modes works when the controller is configured for Mode 0 and fails in Mode 3, or vice versa. Reproducible in both cases, at every clock rate.

Plausible mechanisms. Given §3, the two modes present the same edge directions to the device, so a difference in outcome is unlikely to be the device's sampling. Two candidates remain. The controller's first-bit handling differs between the configurations — it implements one phase correctly and not the other, the review failure of Chapter 3.5 §11. Or the idle level is the problem rather than the transfer: something on the board — a pull resistor, another device, the power-up state — conflicts with one of the two polarities.

The discriminating observations. First, which direction fails? If the flash misinterprets commands, the controller's transmit path is implicated; if command handling is fine and returned data is wrong, look at capture. That halves the space immediately.

Second, does the failure involve the first bit specifically, or the whole word? A first-bit-only corruption in the CPHA = 0 configuration is the missing CS launch. A whole-word displacement points at something else entirely.

Third, scope the idle level in the failing configuration and confirm the master is actually driving it. A controller configured for Mode 3 whose output is being held low by a pull-down between transfers is presenting a Mode 0 idle level while claiming Mode 3 — the inconsistency Chapter 3.6 §10 walked through.

The trap. Because the device supports both, the tempting response is to configure whichever mode works and move on. That is a defensible decision only if you know which mechanism you are avoiding; otherwise you have an unfixed controller defect that will surface on the next device, which may not offer a working alternative.

9. Common Misconceptions

10. Reason It Through

Work this before reading the answers.

A design boots from a serial flash whose datasheet states "SPI Mode 0 and Mode 3 supported." The bootloader configures Mode 0 and works. The main application later reconfigures the same controller to Mode 3 — to share the bus with a second peripheral that requires an idle-high clock — and from then on flash reads return corrupt data, while the second peripheral works correctly.

What does the flash's dual-mode claim actually promise here? That its sampling is indifferent to the idle level, because Modes 0 and 3 present the same edge directions. It does not promise that the flash is indifferent to the first-bit convention, and it says nothing at all about the controller.

So why would switching to Mode 3 break flash reads? Two candidates, and the first is the likely one. If the flash returns meaningful data in the first bit of a read, then Mode 0 and Mode 3 differ for it: under Mode 0 it must launch that bit on CS assertion, under Mode 3 on the first clock edge. A device that implements only the Mode 0 convention — which is entirely consistent with a datasheet claiming both, if the claim is really about idle-level indifference — will present its first bit at the wrong moment in Mode 3.

The second candidate is the controller: its Mode 3 capture may be fine while its Mode 0 capture was what the flash was actually relying on, or its mode change may not have taken effect cleanly.

How would you tell them apart? Look at whether the corruption is confined to the first bit of each read or affects the whole word. First-bit-only points at the first-bit convention and locates the fault at whichever end launches that bit. Whole-word displacement points at a mode configuration that did not take effect, or at a mismatch between what the controller is doing and what the driver believes — resolvable by reading the mode register and scoping the idle level.

What is the architectural problem underneath? Two devices on one bus requiring different idle levels, which Chapter 3.1 §3 identified as a genuine constraint. The application solved it by picking the second peripheral's polarity and assuming the flash's dual-mode claim absorbed the difference. That assumption was doing more work than the claim supports.

What are the options? Reconfigure polarity per transaction, which must happen with no CS asserted and costs inter-transaction latency. Verify whether the flash's first returned bit is actually meaningful — if its reads begin with an opcode phase during which MISO is don't-care, the asymmetry may be harmless and the fault lies elsewhere. Or separate the devices onto different buses. What is not viable is relying on "supports both" to mean more than it does, which is the specific error this chapter exists to prevent.

11. Understanding Check

12. Summary

Mode 3 is CPOL = 1, CPHA = 1: the clock idles high, the leading edge is falling, and the leading edge launches. So it launches on falling and samples on rising — the same physical directions as Mode 0, reached by the opposite route.

That coincidence is why the two appear together in so many datasheets, serial flash especially. A device whose capture logic is built around rising edges behaves identically in both, so "supports Mode 0 and Mode 3" is usually a claim about indifference to the idle level rather than about implementing two behaviours.

The equivalence is real but bounded. It breaks at the first bit, where Mode 0 requires a CS launch and Mode 3 does not — so the pairing is symmetric for the receiving side and asymmetric for the transmitting side. It does not extend to the board, where a pull resistor or a power-up pin state can impose an idle level of its own. And the transition between the two is not free, because changing polarity moves a clock line every device on the bus observes.

For verification, the pairing is a trap: exercising Modes 0 and 3 covers one physical configuration twice and leaves launch-on-rising untested, which a mode-number coverage model will not reveal.

No RTL was required, because polarity is absorbed by the divider and the decoder and phase by the transmit path's cpha input — and the mode decoder's testbench already asserts this chapter's central claim, that Modes 0 and 3 both launch on falling.

13. What Comes Next

All four modes are derived, built and compared. Chapter 3.8 — Mode Mismatch and Its Failure Signature closes the module by asking what happens when the two ends disagree: the distinct signature each kind of mismatch produces, how to tell a polarity disagreement from a phase disagreement from the data alone, and the monitor and coverage work that catches it before hardware does.

Browse the path on the SPI curriculum index, or revisit Mode 0 for the mode this one pairs with, or Deriving Mode Behaviour for the method behind all four.