← 07 ECO, LEC and Post-Freeze Flows | Index | 09 FPGA Emulation, Tooling and Methodology →

Round 08 — Combined answers (Gemini · GPT · Claude)

Contents

• 0. Resume probe
  • M8Q1 · "What changed in the MAC between Wi-Fi 7 and Wi-Fi 8 that…
• Part A — Rapid-fire Q and A (0:05–0:20)
  • M8Q2 · A1. Where is the MAC/PHY boundary in 802.11? What is in TXVECTOR…
  • M8Q3 · A2. SIFS is 16 µs in 5/6 GHz. Break that budget down: what must…
  • M8Q4 · A3. Slot time, DIFS, AIFSAC, CWmin/max — which of these does…
  • M8Q5 · A4. TSF: what is it, who is the timing master in a BSS, and how…
  • M8Q6 · A5. TBTT definition from the standard; what does a STA do if it…
  • M8Q7 · A6. A-MPDU: what does the MAC hardware need to do on Tx and Rx…
  • M8Q8 · A7. Block Ack: what state does the hardware keep per TID, and…
  • M8Q9 · A8. MU-MIMO vs. MU-OFDMA: from the Tx MAC's perspective, what is…
  • M8Q10 · A9. Trigger frames and TB PPDUs: what deadline does a STA have…
  • M8Q11 · A10. Multi-link operation (Wi-Fi 7): what does MLO change in…
  • M8Q12 · A11. Wi-Fi 8 / UHR headline goals (reliability, latency,…
  • M8Q13 · A12. Register interface for firmware: name five design rules…
  • M8Q14 · A13. Interrupt vs. polling vs. descriptor-ring completion for…
  • M8Q15 · A14. DMA descriptor rings: what makes a descriptor format…
  • M8Q16 · A15. Give one example each of a MAC decision that must be…
• Part B — Deep dive: beaconing subsystem for a multi-link AP (0:20–0:55)
  • M8Q17 · B1. Clarify and partition.
  • M8Q18 · B2. Block diagram.
  • M8Q19 · B3. Timestamp insertion.
  • M8Q20 · B4. Corner cases.
  • M8Q21 · B5. Verification hooks and SW interface.
• Part C — Your questions (0:55–1:00)
  • M8Q22 · Questions for the interviewer
• Additional notes
  • Notes. Material not tied to a question

0. Resume probe

M8Q1 · "What changed in the MAC between Wi-Fi 7 and Wi-Fi 8 that actually affected your subsystems? Not the marketing version."

Gemini Answer

• Answer: While Wi-Fi 7 (802.11be) was about peak throughput (320 MHz, 4096-QAM, initial MLO), Wi-Fi 8 (802.11bn / Ultra High Reliability) focuses on deterministic tail latency, multi-AP coordination, and sub-dB link margin reliability. In the hardware MAC blocks I own, three concrete changes hit RTL:
  1. Tx Length-Parameter & Rate Tables: New unequal modulation / intermediate MCS and DRU (Distributed Resource Unit) tone-plan encodings and LDPC coding-rate granularity added new lookup dimensions and padding rules to the N_DBPS/N_SYM/pre-FEC padding pipeline.
  2. TSF / Cross-Chip TimeSync & Beaconing: Multi-AP Coordinated Beamforming / Coordinated TDMA (Co-TDMA / Co-SR) tightened inter-radio / cross-chip synchronization tolerances and required low-jitter TWT/restricted-TWT schedule alignment across links.
  3. Preemption / Low-Latency TXOP Handling: Tighter control over A-MPDU truncation and TXVECTOR handshaking with the baseband so high-priority low-latency traffic can preempt long aggregates cleanly.

GPT Answer

"I own Tx length parameters, TSF, cross-chip synchronization, beaconing, FPGA emulation, and the baseband interface, across Wi-Fi 6E through Wi-Fi 8 IP deliveries. My documented changes include Wi-Fi 7 MU datapath re-architecture, removal of a multicycle path, smooth-drift TSF correction, and Wi-Fi 8 block-DV extensions. I would discuss an actual supported 802.11bn mode and its interface/verification impact rather than inventing an implementation detail from the resume."

Claude Answer

Template (keep only what you can say without NDA trouble):

"Three things. First, multi-AP coordination: coordinated spatial reuse / TDMA / beamforming
all assume APs agree on time to well under a µs, so the cross-chip sync and TSF path went
from 'nice to have' to a requirement with a tolerance and a loss-of-sync contract. Second,
the new PPDU format and unequal modulation per stream: N_DBPS becomes a per-stream sum, so
the length-parameter datapath and the factored lookup had to change shape, not just add
rows. Third, latency features (TXOP sharing/preemption) changed what the scheduler can do
mid-TXOP, which changed the baseband interface handshakes. Beaconing itself barely moved;
what moved was everything that feeds it."

Part A — Rapid-fire Q and A (0:05–0:20)

M8Q2 · A1. Where is the MAC/PHY boundary in 802.11? What is in TXVECTOR vs. RXVECTOR, and which TXVECTOR fields does your length-parameter block produce?

Gemini Answer

• MAC/PHY boundary: The PHY-SAP (often implemented over a streaming MAC-PHY interface like MPDU/PSDU byte stream + control sideband).
• TXVECTOR (MAC → PHY): PPDU format (L-SIG/HT/VHT/HE/EHT/UHR), CBW, MCS, NSS, GI/LTF size, FEC_CODING (BCC/LDPC), STBC, DCM, BSS_COLOR, TXOP_DURATION, TXPWR_LEVEL, and per-user RU allocation.
• What my Tx length-parameter block computes for TXVECTOR: L_LENGTH (for L-SIG), PSDU_LENGTH / APEP_LENGTH, N_SYM, PE_DISAMBIGUITY / PACKET_EXTENSION ($0,8,16,20\mu \text{s}$), PRE_FEC_PADDING_FACTOR ($a\in \{1..4\}$), LDPC_EXTRA_SYMBOL, and exact TXTIME.
• RXVECTOR (PHY → MAC): Decoded preamble parameters (FORMAT, MCS, NSS, LENGTH, BSS_COLOR, TXOP_DURATION) plus RSSI/RCPI, SNR, and Rx start/end timing markers.

GPT Answer

MAC handles framing, aggregation, access/retry/security policy and exchange control; PHY handles coding/modulation and the radio waveform. TXVECTOR describes requested transmit format/rate/bandwidth/users/length/coding; RXVECTOR reports detected receive parameters/status. The length block supplies or contributes symbol counts, length/padding/duration and format-specific preamble fields; exact bus ownership is implementation-specific.

Claude Answer

The PHY SAP: PHY-TXSTART.request(TXVECTOR) then PHY-DATA.request per octet,
and PHY-RXSTART.indication(RXVECTOR) the other way. TXVECTOR: format, BW, GI/LTF, per-user
MCS/NSS/FEC/STBC/DCM, RU allocation, L_LENGTH, APEP/PSDU length per user, TXOP duration,
BSS colour, spatial reuse, pre-FEC padding factor, LDPC extra symbol, PE disambiguity,
packet extension. RXVECTOR: same plus RSSI/RCPI and RX timing. My block produces L_LENGTH,
N_SYM/TXTIME, per-user PSDU/APEP length, pre-FEC padding factor, LDPC extra symbol and the
packet-extension fields.

M8Q3 · A2. SIFS is 16 µs in 5/6 GHz. Break that budget down: what must happen in the MAC between RX end and TX start of an ACK/BA, and what does that imply for pipeline latency?

Gemini Answer

• Budget breakdown ($16.0\mu \text{s}$ total from last symbol on air to first preamble bit on air):
  1. PHY Rx tail delay (OFDM FFT + demap + LDPC iterative decode + descramble of final symbol): $\sim 6\text{–}9\mu \text{s}$.
  2. MAC Rx processing (delimiter parse, final MPDU FCS check, address/RA match, BA scoreboard bitmap latch): $\sim 1.0\text{–}2.0\mu \text{s}$.
  3. MAC Tx response preparation (select ACK/BA/TB-PPDU response rate, run Tx length-parameter pipeline to build TXVECTOR, assemble BA frame + FCS): $\sim 1.5\text{–}2.5\mu \text{s}$.
  4. PHY Tx turn-on & DAC/RF ramp-up (aRxTxTurnaroundTime): $\sim 2.0\text{–}3.0\mu \text{s}$.
• Implication for RTL: Total MAC Rx-to-Tx turnaround is only $\sim 2\text{–}4\mu \text{s}$. Firmware cannot be in the loop; FCS checking, BA bitmap lookup, response frame generation, and Tx length calculation must all be deterministic hardware pipelines.

GPT Answer

The 16 us OFDM response budget includes PHY RX indication latency, header/FCS/address classification, BA/ACK decision and content, Tx scheduling/vector preparation, and PHY Tx turnaround. Some work must start before end-of-frame. Sum worst-case pipeline, arbitration, CDC, and PHY delays; firmware cannot be in the critical response loop.

Claude Answer

RX end → PHY RX delay (last codeword decode, a few µs) → RF turnaround → MAC: FCS of
the last MPDU, BA scoreboard update, address/response decision, build BA, TXVECTOR for the
response (length params again) → PHY TX delay → preamble must begin at exactly RX end +
16 µs. The MAC owns maybe 3–5 µs of that: hundreds of cycles at 160 MHz, so a pipelined
hardware response path with precomputed parameters; a firmware round-trip is impossible.

M8Q4 · A3. Slot time, DIFS, AIFS[AC], CW[min/max] — which of these does hardware need to count, and at what resolution?

Gemini Answer

• Hardware counts ALL of them inside the EDCA / DCF channel-access engine:
  • Slot time: $9\mu \text{s}$ (5/6 GHz) or $9/20\mu \text{s}$ (2.4 GHz), counted at $1\mu \text{s}$ (or sub-$\mu \text{s}$ clock-tick) resolution synchronized to CCA transitions.
  • SIFS ($16\mu \text{s}$), PIFS ($\text{SIFS}+1\text{ slot}=25\mu \text{s}$), DIFS ($\text{SIFS}+2\text{ slots}=34\mu \text{s}$), and $\text{AIFS}[AC]=\text{SIFS}+\text{AIFSN}[AC]\times \text{SlotTime}$ for all 4 Access Categories (AC_BK, AC_BE, AC_VI, AC_VO).
  • Backoff counters: 4 independent hardware pseudo-random backoff counters drawing from $[0,\text{CW}[AC]]$ and decrementing once per idle slot after AIFS[AC].

GPT Answer

Hardware counts idle slot boundaries, AIFS/DIFS, backoff and TXOP duration, freezing/resuming backoff correctly on busy medium. AIFS=SIFS+AIFSN*slot; CW controls the random counter range. Use PHY-specific timing units and a clock/tick resolution that meets the timing tolerance.

Claude Answer

Hardware counts all of them: slot (9 µs), SIFS, PIFS = SIFS + slot, DIFS = SIFS +
2·slot, AIFS[AC] = SIFS + AIFSN·slot, CW backoff per AC in slots, NAV in µs. Resolution: at
least 1 µs for NAV/TSF, sub-µs (clock-cycle) for slot-boundary and CCA alignment.

M8Q5 · A4. TSF: what is it, who is the timing master in a BSS, and how does a STA adjust its TSF from a received beacon? Why must the hardware timestamp the beacon at a specific byte?

Gemini Answer

• What it is: A 64-bit unsigned counter incrementing at $1\text{ MHz}$ ($1\mu \text{s}$ per LSB) used to synchronize all stations in a Basic Service Set (BSS).
• Master & STA update rule: In an infrastructure BSS, the AP is the timing master. Upon receiving a valid Beacon or Probe Response from its BSSID, a STA overwrites its local TSF with the received 64-bit Timestamp field plus the local PHY+MAC Rx path delay from the moment the first bit of the timestamp field hit the antenna.
• Why HW must timestamp at a specific byte: Because EDCA medium contention and PHY preamble duration vary per frame, firmware cannot know when the frame actually hits the air. IEEE 802.11 requires the transmitted timestamp to equal the AP's TSF at the exact microsecond the first bit of the Timestamp field is transmitted at the antenna connector.

GPT Answer

TSF is a 64-bit microsecond timing reference; the AP supplies the infrastructure BSS reference. A STA uses a correctly received beacon timestamp and receive-delay correction according to the applicable mode's synchronization rules, conventionally advancing to a later reference rather than blindly loading every timestamp. Capture the defined timestamp-field reference point so preamble, buffering, and receive latency do not bias synchronization.

Claude Answer

64-bit µs timer; the AP is the timing master in an infrastructure BSS. On a beacon
the STA sets TSF = timestamp_field + local_rx_delay, in either direction (IBSS: forward
only). Hardware must insert the timestamp at the instant the symbol carrying the first bit
of the field is handed to the PHY plus the PHY delay, because only hardware knows that
instant to µs precision.

M8Q6 · A5. TBTT definition from the standard; what does a STA do if it wakes for a beacon that is late? What does an AP do if it misses a TBTT because the medium is busy?

Gemini Answer

• TBTT definition: Target Beacon Transmission Time occurs whenever $\text{TSF}mod(\text{BeaconInterval\_TU}\times 1024\mu \text{s})==0$.
• STA waking for a late beacon: Keeps Rx awake until either the beacon arrives (updating its TSF without shifting future TBTT cadence) or a configurable beacon_timeout expires, after which it returns to doze and increments its missed-beacon counter.
• AP when medium is busy at TBTT: Holds the pending beacon at the head of the highest-priority beacon queue, waits for CCA/NAV idle + backoff/PIFS, transmits the beacon late with the actual live TSF at the moment of delayed transmission, and does NOT shift the next TBTT (which still occurs at the next exact integer multiple of BI).

GPT Answer

TBTT is a scheduled beacon target on the beacon-interval grid, not a guarantee of immediate air transmission. A waking STA waits according to its receive/power policy; a busy AP defers access under the applicable beacon medium-access rules. A late beacon carries an updated actual-transmission timestamp; the next scheduled target stays aligned.

Claude Answer

TBTT = TSF mod BI == 0. A STA that wakes and sees no beacon stays awake for a
configured window, counts a missed beacon, and sleeps; it never moves its TBTT. An AP that
misses a TBTT sends the beacon as soon as the medium allows, with the actual TSF in it, and
keeps subsequent TBTTs on the original schedule.

M8Q7 · A6. A-MPDU: what does the MAC hardware need to do on Tx and Rx (delimiters, CRC, BA bitmap)? How does the length-parameter block interact with A-MPDU padding?

Gemini Answer

• Tx HW: Prepends a 4-byte MPDU Delimiter (EOF bit, 14-bit MPDU length, 8-bit CRC-8, 0x4E signature) to each MPDU, appends 32-bit FCS per MPDU, pads each subframe to a 4-byte boundary (0..3 pad bytes), and appends EOF padding delimiters/octets at the end of the aggregate to fill PSDU_LENGTH / per-user MU duration.
• Rx HW: Scans for delimiter signature 0x4E + valid CRC-8 (re-synchronizing byte-by-byte if a delimiter is corrupted!), extracts each MPDU, verifies per-MPDU FCS, and updates the BA bitmap bit corresponding to that MPDU's Sequence Number (SN).
• Length-parameter interaction: In SU, the sum of MPDU subframes determines APEP_LENGTH $\to$ N_SYM; in MU-OFDMA/MIMO, the longest user's N_SYM dictates the shared PPDU N_SYM, and the length-parameter block returns each shorter user's exact pre-FEC EOF padding byte count to the A-MPDU aggregator!

GPT Answer

Tx builds MPDUs/delimiters, lengths, delimiter CRC and alignment/padding; Rx validates/delineates MPDUs, FCS, sequence/reorder and BA state. MAC aggregate bytes and PHY/FEC padding have distinct meanings. The length model must use the exact bytes sent to PHY, including relevant delimiters and aggregate padding.

Claude Answer

Tx: MPDU delimiters (EOF, 14-bit length, CRC-8, signature), 4-byte subframe padding,
EOF padding delimiters to fill the PPDU, max A-MPDU length and minimum MPDU start spacing
per receiver, one RA/TID. Rx: delimiter hunting on CRC + signature, per-MPDU FCS, BA window
and bitmap update. The length block sees the final aggregate length after padding, and in
the TB-PPDU direction runs the inverse: given the PPDU length, how many bytes fit and how
much EOF padding to add.

M8Q8 · A7. Block Ack: what state does the hardware keep per TID, and why is the scoreboard (BA bitmap) hardware rather than firmware?

Gemini Answer

• Per-TID state: (WinStart_SN[11:0], WinSize, Bitmap[255:0] or [1023:0]) indexed by (Peer_STA_ID, TID).
• Why in hardware: An Compressed BlockAck frame must begin transmitting on the air exactly SIFS ($16\mu \text{s}$) after the end of the received A-MPDU, leaving only $\sim 2\mu \text{s}$ after the last MPDU's FCS check to serialize the 64-bit / 256-bit / 1024-bit BA bitmap into a response frame.

GPT Answer

Track agreement/window/starting sequence, received or outstanding MPDU bitmap, retries and reorder state per peer/TID as applicable. Hardware supports line-rate updates and SIFS response; firmware manages policy and setup.

Claude Answer

Per TID per peer: window start SN, bitmap (64/256, up to 1024 in Wi-Fi 7), buffer
size, last SN, policy, plus the originator-side retry bitmap. Hardware because the BA goes
out SIFS after the A-MPDU and the bitmap must be updated from per-MPDU FCS results in real
time; firmware latency is 10–100× too slow.

M8Q9 · A8. MU-MIMO vs. MU-OFDMA: from the Tx MAC's perspective, what is the same and what is different (per-user parameters, padding, alignment of user PSDUs)?

Gemini Answer

• Same: Both multiplex multiple users (1..N_users) into a single PPDU duration (max_N_SYM), requiring per-user A-MPDU generation, per-user MCS/FEC parameters, and per-user pre-FEC EOF padding so all user streams terminate on the exact same OFDM symbol.
• Different:
  • MU-OFDMA: Partitions the channel in frequency—each user has a distinct RU size (N_SD) and distinct NSS/MCS.
  • DL MU-MIMO: Users share the same RU (N_SD) in frequency and are separated spatially (NSS_u per user, subject to $\sum {\text{NSS}}_u\le 8$).

GPT Answer

Both need per-user coding/rate/length information and a common PPDU duration. MU-MIMO separates spatial users, OFDMA separates resource units, and formats can combine them. RU mapping, stream allocation and legal modes differ; derive padding from the final common duration and each user's coding capacity.

Claude Answer

Same: per-user MCS/NSS/PSDU/BA, one N_SYM for the PPDU computed as the max over
users with per-user pre-FEC padding so all users end on the same symbol. Different:
MU-OFDMA has per-user RU sizes (so per-user N_SD/N_DBPS) and pairs with trigger-based UL;
MU-MIMO users share the RU and differ in spatial streams, and need sounding/steering on the
PHY side.

M8Q10 · A9. Trigger frames and TB PPDUs: what deadline does a STA have between trigger reception and TB PPDU transmission, and what hardware does that force?

Gemini Answer

• Deadline: The STA must begin transmitting its HE/EHT/UHR Trigger-Based (TB) PPDU on the air exactly SIFS ($16\mu \text{s}$) after the end of the received Trigger frame (with $\pm 0.4\mu \text{s}$ timing and carrier-frequency pre-correction!).
• What hardware this forces:
  1. Hardware Trigger Frame parser that extracts the STA's User Info field (matching AID12) on the fly as bytes stream from the PHY.
  2. Hardware TB length / PSDU sizing engine that takes the AP-allocated UL_LENGTH, RU_ALLOCATION, and UL_MCS from the Trigger frame, computes how many bytes the STA can pack into that exact symbol duration, and pulls MPDUs/QoS-Nulls from the Tx queues within $<3\mu \text{s}$.

GPT Answer

Trigger-based uplink normally follows the specified SIFS response timing. Hardware must parse allocations, validate eligibility, select prepared payload, compute TB parameters/padding, and coordinate PHY start without firmware scheduling latency.

Claude Answer

SIFS after the trigger ends. Forces hardware trigger parsing (common info + the
STA's user info: RU, MCS, UL length, power), hardware derivation of TB-PPDU parameters,
the inverse length computation (bytes that fit + EOF padding), pre-queued MPDUs, and
power pre-correction values ready; no firmware in the loop.

M8Q11 · A10. Multi-link operation (Wi-Fi 7): what does MLO change in the MAC — sequence numbers, BA, power save, TSF per link? Where did you see this in your subsystems?

Gemini Answer

• Upper MAC (MLD level — shared across links): Unified Sequence Number (SN) assignment per (Peer_MLD, TID), unified BlockAck scoreboard window across links (an MPDU sent on Link 0 can be acknowledged or retransmitted on Link 1!), unified GCMP-256 packet number (PN) pool.
• Lower MAC (Link level — independent per link): Independent per-link TSF timer, per-link TBTT/beaconing, per-link EDCA backoff/CCA/NAV state, and per-link MAC addresses (Link_Addr).

GPT Answer

MLO adds affiliated-link state, shared upper-MAC ordering/reorder/BA concerns, TID-to-link mapping, link power state and radio concurrency constraints. Do not assume fully independent sequence spaces/BA per link. Timekeeping needs defined per-link references/offsets. My resume supports TSF/TimeSync/baseband ownership, not a particular MLO sequence-number architecture.

Claude Answer

One MLD with several links: sequence numbers and PNs shared per TID across links,
BA agreements spanning links (reordering across links), per-link TSF/beacon/BSS, per-link
power save, EMLSR/EMLMR link switching with padding, TID-to-link mapping. In my subsystems:
per-link TSF derived from a shared master timer with per-link offsets, per-link beaconing,
and exposing link TSF offsets for the multi-link element.

M8Q12 · A11. Wi-Fi 8 / UHR headline goals (reliability, latency, roaming): name two concrete MAC hardware features that follow from them.

Gemini Answer

1. Multi-AP Coordination (Co-BF / Co-SR / Co-TDMA) hardware triggers & tight TSF sync: Hardware parsing of inter-AP coordination frames and sub-microsecond TXOP boundary enforcement.
2. Preemptable TXOP / Low-Latency Priority Injection: Hardware ability to pause or truncate an ongoing long best-effort A-MPDU at the next MPDU boundary to inject a high-priority ultra-low-latency frame without waiting for a new contention window.

GPT Answer

Two plausible UHR hardware implications are time-bounded multi-AP coordination controls and faster/robuster link/resource scheduling with deadline/retry state. Describe them as draft/version-specific capabilities, not universal finalized requirements. Pin any detailed claim to the supported TGbn draft; public TGbn material establishes the UHR scope, not my chip's feature list.

Claude Answer

Reliability → multi-AP coordination → sub-µs cross-AP time sync and hardware-
scheduled coordinated TXOP starts. Latency → TXOP sharing/preemption → scheduler that can
abort/insert mid-TXOP and keep the response path intact. Roaming → seamless transition →
BA/SN/key context that can be switched between APs in hardware.

M8Q13 · A12. Register interface for firmware: name five design rules for a register block that SW will thank you for (think atomicity, read-clear, shadowing, interrupts).

Gemini Answer

1. Write-1-to-Clear (W1C) (or separate SET and CLR addresses) for all interrupt and sticky status bits—never Read-to-Clear (which breaks debuggers and racing ISR threads) or Read-Modify-Write (RMW).
2. Atomic 64-bit counter reads via read-latch shadowing: Reading TSF_LOW (0x00) automatically latches TSF_HIGH into a shadow holding register (0x04) in the same clock cycle so FW never reads a torn 64-bit value across a 32'hFFFF_FFFF -> 32'h0000_0000 rollover.
3. Shadowed multi-register configuration with an explicit COMMIT strobe: FW writes 5 multi-field registers at leisure, then writes cfg_commit = 1 so hardware switches all 5 fields atomically on one clock edge.
4. Standard 3-register interrupt structure per source: INT_RAW_STATUS (W1C), INT_MASK (RW), and INT_MASKED_STATUS (RO = RAW & MASK).
5. Hardware BUSY bit + write-protection lock: Prevent FW from modifying active DMA base addresses while the engine is running.

GPT Answer

Defined reset/access semantics; atomic wide reads and shadowed multi-register updates; set-dominant sticky status/W1C instead of ambiguous read-clear; masked/coalesced interrupts; reserved fields/version discovery. Also document ordering, endianness and busy/rejected writes.

Claude Answer

Write-1-to-clear status; separate set/clear registers for control bits; shadow
registers with a commit bit for multi-field atomic updates; latch-on-low-read for 64-bit
counters; raw/mask/status interrupt triplet; no side effects on reads of debug-visible
registers; ID/version register; reserved bits read 0, writes ignored; a busy/ready bit for
anything that triggers hardware action.

M8Q14 · A13. Interrupt vs. polling vs. descriptor-ring completion for MAC events: which for TBTT, which for Tx completion, which for Rx frames? Why?

Gemini Answer

• TBTT / Pre-TBTT: Direct Hardware Interrupt (low frequency—once every $100\text{ ms}$, strict real-time latency requirement).
• Tx Frame Completion: Descriptor-Ring Status Write-back + Coalesced Interrupt (high rate—thousands of MPDUs/sec; interrupting per packet would saturate the CPU, so HW writes completion status into DRAM/SRAM ring and fires an interrupt after $N$ completions or $T\mu \text{s}$ timeout).
• Rx Frames: Descriptor-Ring DMA + NAPI-style Interrupt/Polling (interrupt wakes driver on first packet; driver masks interrupt and polls the ring until empty under high load).

GPT Answer

Pre-TBTT/TBTT use low-rate timed events/interrupts while hardware owns the deadline. Tx/Rx use descriptor-ring completions with batching/coalescing and polling at high load; interrupt for wakeup/errors. Avoid one interrupt per received frame at peak traffic.

Claude Answer

TBTT: interrupt (rare, latency-sensitive, firmware must prepare). Tx completion:
descriptor ring with completion write-back and coalesced interrupts (high rate). Rx frames:
descriptor ring with threshold/timeout interrupt (bursty, needs buffering). Polling only
for debug or when firmware is already in the loop.

M8Q15 · A14. DMA descriptor rings: what makes a descriptor format future-proof across three generations of a MAC?

Gemini Answer

• Include a 4-bit DESC_VERSION + DESC_LEN_DWORDS header in DW0.
• Keep core pointers/lengths in fixed offsets (DW0–DW3) and append generation-specific extensions (e.g., Wi-Fi 7 MLO link mask, Wi-Fi 8 UHR fields) in tagged TLV or reserved tail DWords initialized to 0 by legacy software.

GPT Answer

Include version/length/type, capability negotiation, aligned addresses with sufficient width, reserved extension space, explicit ownership and completion status, and stable endianness. Publish producer/consumer ordering, cache-coherence, and reset-epoch rules.

Claude Answer

Versioned header with explicit length; reserved fields that must be zero; a
length-prefixed variable/TLV section; flags never re-purposed; offsets not absolute
addresses; an ownership bit and generation tag for ordering; no generation-specific
constants (MCS indices) without a version field.

M8Q16 · A15. Give one example each of a MAC decision that must be hardware, one that must be firmware, and one that could be either and how you would decide.

Gemini Answer

• Must be Hardware: SIFS response generation (ACK/BA/CTS, TB-PPDU trigger response) and inline beacon timestamp + FCS insertion ($<2\mu \text{s}$ real-time deadlines).
• Must be Firmware: Association/authentication state machines, channel switch policy, MLO link-steering heuristics, and complex rate-adaptation algorithms (milliseconds timescale, high algorithmic complexity).
• Could be either (Hybrid): Beacon frame assembly. Best split: Firmware writes a static Beacon Template in SRAM and updates only dynamic IEs (CSA, TIM bitmap) on pre_tbtt_irq, while Hardware autonomously fetches the template at TBTT, stamps the 64-bit TSF, updates the Sequence Number, computes the FCS, and transmits it—giving deterministic zero-CPU-jitter beaconing when the TIM doesn't change!

GPT Answer

Hardware: SIFS ACK/BA timing. Firmware: policy/configuration such as administrative channel choice. Either: rate adaptation or longer-timescale scheduling, depending on latency, computation, update frequency and interoperability needs. No fundamental law requires every policy calculation to be firmware; that is an engineering partition.

Claude Answer

Must be hardware: ACK/BA response within SIFS, backoff/CCA/NAV, timestamping,
per-MPDU FCS/crypto. Must be firmware: rate adaptation policy, association/authentication,
channel-switch decisions. Either: beacon content updates (hardware template with firmware
fields vs firmware rebuild per beacon), aggregation decisions. Decide by decision rate,
latency bound (< tens of µs → hardware), certification volatility (likely to change → FW),
and silicon cost.

Part B — Deep dive: beaconing subsystem for a multi-link AP (0:20–0:55)

Design the beaconing subsystem of an AP MAC that supports up to 4 links (MLO), each
with its own BSS, beacon interval, and TSF offset relative to a shared master timer.

Must:

1. Generate TBTT per link, with firmware-configurable pre-TBTT lead time for beacon
   preparation.
2. Transmit the beacon at TBTT with highest priority, subject to the medium being idle
   (EDCA/CCA), and insert the 64-bit TSF timestamp into the beacon body at the exact
   moment the frame goes to the PHY (the timestamp field is at a fixed offset in the frame
   body and must reflect the time the first bit of the timestamp hits the air, adjusted for
   PHY delay).
3. Tolerate a beacon that is delayed by a busy medium: transmit it as soon as possible,
   with a correct timestamp, and ensure the next TBTT is still on schedule.
4. Tolerate a TSF slew correction (from cross-chip sync) occurring while a beacon is being
   prepared or transmitted.
5. Support "beacon skip" by firmware (e.g., during channel switch) without losing TBTT
   cadence.
6. Provide firmware with TBTT and beacon-sent events plus a per-link beacon_missed count.

M8Q17 · B1. Clarify and partition.

1. (5 min) Clarify and partition. What does hardware do, what does firmware do? What
   is pre-computed vs. computed at transmit time?

Gemini Answer

• Hardware owns:
  1. Shared 64-bit Master Timer (1 MHz) + per-link 64-bit signed offset adder (tsf_link[i] = tsf_master + offset_link[i]).
  2. Per-link TBTT & Pre-TBTT generator with divider-less jump catch-up.
  3. Per-link ping-pong Beacon Template buffer pointers, hardware Sequence Number increments, and beacon_skip_req[i] gating.
  4. High-priority Beacon Queue arbitration (PIFS / zero-backoff EDCA priority above AC_VO).
  5. On-the-fly streaming 64-bit Timestamp insertion (compensated for PHY preamble + Tx chain delay) and inline CRC-32 FCS generation downstream of the timestamp mux.
• Firmware owns:
  1. Populating the Beacon Template (MAC header, fixed fields, IEs) in template RAM and flipping the ping-pong buffer index on pre_tbtt_irq[i] when TIM/CSA changes.
  2. Programming beacon_interval_tu[i], pre_tbtt_us[i], tsf_offset[i], and phy_tx_delay_comp_ns[i].

GPT Answer

Clarify supported PHY formats, timestamp reference/precision, allowed lateness/skip policy, radio-sharing constraints, template lifetime, and whether link offsets may change live. Firmware prepares beacon contents/TIM/channel-switch policy and commits an immutable template version before a deadline. Hardware owns target generation, access requests, timestamp/FCS patching, and completion/missed accounting.

Claude Answer

• Hardware: master timer, per-link TSF = master + offset_link, four TBTT generators with
  pre-TBTT, beacon fetch from template memory, scheduler priority, timestamp insertion,
  FCS, skip handling, events and counters.
• Firmware: template content (TIM, CSA, multi-link element), offsets, lead time, skip bits,
  missed-beacon policy.
• Pre-computed when firmware updates a template: the beacon's TXVECTOR and preamble
  duration (from the length block). Computed at transmit time: timestamp and FCS only.

M8Q18 · B2. Block diagram.

2. (15 min) Block diagram. Draw: shared master timer, per-link TSF offset/derived TSF,
   per-link TBTT generator, beacon queue / template memory, the Tx scheduler interface
   (how the beacon pre-empts EDCA queues), the timestamp-insertion point in the Tx datapath,
   and the PHY interface. Name every clock domain.

Gemini Answer

  [Always-On Timer Domain: clk_tsf = 1 MHz]
     +------------------------------------------+
     | Master 64-bit TSF Counter (with Slew)    |
     +------------------------------------------+
                          | (Sync Tick + Shadow Copy)
  ========================|=====================================================
  [MAC Core Domain: clk_mac = 640 MHz]
                          v
     +------------------------------------------+
     | Master Shadow TSF (tsf_master_q[63:0])   |
     +------------------------------------------+
         |            |            |            |
         v (+off0)    v (+off1)    v (+off2)    v (+off3)
     +--------+   +--------+   +--------+   +--------+
     |Link 0  |   |Link 1  |   |Link 2  |   |Link 3  |
     |TSF &   |   |TSF &   |   |TSF &   |   |TSF &   | ---> pre_tbtt_irq[3:0]
     |TBTT Gen|   |TBTT Gen|   |TBTT Gen|   |TBTT Gen| ---> tbtt_irq[3:0]
     +--------+   +--------+   +--------+   +--------+
         | bcn_req0   | bcn_req1   | bcn_req2   | bcn_req3
         v            v            v            v
     +---------------------------------------------------+
     | Per-Link EDCA / Beacon Tx Scheduler               |
     | (Beacon Queue preempts AC_VO..AC_BK at TBTT;      |
     |  waits for CCA/NAV idle + PIFS; fetches Template) |
     +---------------------------------------------------+
                          | (Streaming MPDU Bytes + Byte Offset Counter)
                          v
     +---------------------------------------------------+
     | On-the-Fly Timestamp Inserter (Bytes 24..31)      |
     |   latched_tsf = tsf_link[i] + T_preamble + T_phy  |
     |   muxes latched_tsf[63:0] at byte_idx == 24..31   |
     +---------------------------------------------------+
                          |
                          v
     +---------------------------------------------------+
     | Inline IEEE 802.11 CRC-32 (FCS) Appender          |
     +---------------------------------------------------+
                          |
                          v
                 [MAC-to-PHY TX FIFO]

GPT Answer

Always-on master timer -> coherent snapshot -> MAC time service
                                      -> per-link offset/config epoch [0..3]
                                      -> aligned TBTT/pre-TBTT engines
FW/APB -> shadow config + template RAM -> beacon pending queues
TBTT engines -> radio-aware Tx scheduler -> template/data fetch
             -> timestamp insertion -> FCS -> MAC/PHY elastic boundary -> PHY
                                  completion/status -> FW event ring/interrupt

Domains: always-on timer, MAC core, APB if separate, template-memory clock if separate, and PHY/link clocks. Use atomic mailboxes for configuration/time, FIFOs for streams/events, and local reset-release protocols. Beacon priority applies at a legal scheduling opportunity; it cannot interrupt an already transmitted frame or bypass mandatory medium-access rules. Radio sharing arbitrates among links and records deferral without shifting their target grids.

Claude Answer

• Always-on timer domain (1 MHz, 32 kHz in sleep): master TSF with slew engine.
• MAC core clock (160 MHz): synced tick → shadow master TSF; four adders with
  quasi-static offset_link → tsf_link[3:0]; four TBTT generators (round-05 design with
  catch-up FSM, >= compares); per-link beacon controller (IDLE → PREP at pre-TBTT →
  QUEUED at TBTT → SENDING → SENT); Tx scheduler with a beacon queue above AC_VO that wins
  arbitration at TBTT but never interrupts a PPDU in flight and still obeys CCA/NAV;
  MPDU assembly → timestamp-insertion mux → CRC-32 → PHY Tx FIFO.
• Register/firmware clock (APB): template memory writes (double-buffered per link so
  firmware updates while hardware sends), config, counters, interrupts.
• PHY interface clock (may equal MAC clock or cross via an async FIFO): TXVECTOR +
  byte stream with valid/ready, PHY_TXSTART, PHY_TXEND; one per radio.

M8Q19 · B3. Timestamp insertion.

3. (10 min) Timestamp insertion. Precisely: when is the timestamp latched, how is PHY
   delay compensated (preamble duration depends on PPDU format — who computes it?), how does
   the datapath overwrite 8 bytes in a frame that is already streaming, and how do you
   handle the FCS?

Gemini Answer

Task 3: Exact On-the-Fly Timestamp Insertion & FCS Mechanics

• Where the Timestamp sits in an 802.11 Beacon: Immediately after the 24-byte MAC Header (at byte offsets 24..31, little-endian 64-bit microseconds).
• When to latch the timestamp: At the exact clock cycle tx_phy_start when the MAC begins releasing the beacon PPDU to the PHY (or when byte 0 enters the constant-latency PHY FIFO).
• Exact Compensation Formula:$$\text{TS\_field}[63:0]=\text{TSF\_link}[i]+T_{\text{preamble}}(\text{format},\text{bw})+T_{\text{sym}}\times \lfloor \frac{24\times 8}{N_{\text{DBPS}}}\rfloor +T_{\text{phy\_dac\_rf\_delay}}$$where $T_{\text{preamble}}$ (e.g., $20\mu \text{s}$ for Legacy 20 MHz Non-HT beacon) is provided directly by the Tx length-parameter block and $T_{\text{phy\_dac\_rf\_delay}}$ is a calibrated per-band CSR constant.
• Streaming Overwrite & FCS:
  • A byte counter byte_idx tracks the streaming frame bytes. For byte_idx in [24..31], a 2:1 byte mux replaces the template's dummy 0x00 bytes with latched_ts_q[(byte_idx-24)*8 +: 8].
  • Crucial rule: The CRC-32 FCS generator MUST sit downstream of the timestamp insertion mux so the 4-byte FCS appended at the end of the frame is computed over the newly inserted live timestamp bytes!

GPT Answer

Latch a coherent per-link TSF at a defined irrevocable transmit reference point. Compute the TSF for the symbol containing the first timestamp bit, including PHY pipeline and format-dependent serialization/preamble delay. If the interface can still stall unpredictably, a timestamp predicted at tx_start is insufficient: either guarantee launch-to-air latency after commit, patch at the final controlled boundary, or obtain a PHY timing handshake/reference.

Use a byte-offset counter and lane mask to overwrite all eight timestamp bytes, handling bus-word straddling and little-endian serialization. Hold patched bytes stable under valid/ready stalls. Run FCS generation over the final patched MPDU; do not reuse an FCS computed over the template's stale timestamp. The PHY/length logic supplies format-dependent timing, with calibrated fixed delay in the agreed reference convention.

If TSF may slew before the reference instant, extrapolate using the same correction/phase model or capture later; simply adding elapsed wall time can be off by a correction tick. Template preparation must not latch the final timestamp.

Claude Answer

• The spec value is the TSF when the data symbol containing the first bit of the Timestamp
  field is handed to the PHY, plus the PHY delay. Latch the shadow TSF at PHY_TXSTART
  once per beacon, then add: preamble duration (from the length block's TXTIME machinery
  for the beacon's TXVECTOR) + floor((16 + 8·24) / N_DBPS) · T_SYM for the symbol
  holding body offset 0 + aTxPHYDelay. All constants come from the template's precomputed
  parameters, so the sum is ready before byte 24 streams.
• Overwrite: the assembly stage keeps a byte counter; a comparator on offsets 24–31 muxes
  the latched 8 bytes (little-endian) into the stream. One latch per beacon, never
  re-latched.
• FCS: the CRC-32 engine sits after the mux, so the template never carries a precomputed
  FCS. With beacon protection the MIC is computed with the Timestamp field masked (check the
  exact masking rule), which is what allows firmware to precompute the MIC and hardware to
  insert the timestamp late.

M8Q20 · B4. Corner cases.

4. (5 min) Corner cases. Walk through: (a) medium busy for 2 ms at TBTT; (b) TSF pause
   (slew) exactly during timestamp latch; (c) firmware skips the beacon on link 2 only; (d)
   two links' TBTTs coincide and the AP has a single radio per link pair.

Gemini Answer

1. (a) Medium busy for $2\text{ ms}$ at TBTT:
   • At TBTT ($t=100.000\text{ ms}$), tbtt_pulse[i] fires and queues bcn_pending[i] = 1, while next_tbtt_us[i] immediately advances to $200.000\text{ ms}$ (preserving strict cadence!).
   • The beacon waits in the Beacon Queue while CCA/NAV is busy. At $t=102.000\text{ ms}$, the medium goes idle; the timestamp is latched at $t=102.000\text{ ms}$ (when tx_phy_start actually fires, NOT when TBTT fired!), so receiving STAs get the true air time $102.000\text{ ms}+{\mathrm{\Delta }}_{\text{preamble}}$.
   • If the medium stays busy for an entire beacon interval ($>100\text{ ms}$) until the next TBTT arrives while bcn_pending[i] is still 1, the stale pending beacon is cancelled, beacon_missed_cnt[i] increments by 1, and the new beacon replaces it.
2. (b) TSF slew pause (+0) occurs during timestamp latch:
   • Because the timestamp is latched atomically in a single 64-bit register latched_ts_q on the single cycle tx_phy_start, all 8 bytes (24..31) read from latched_ts_q—never from the live changing tsf_link[i] across 8 different cycles! A $+0$ pause simply means tsf_link[i] was adjusted by $1\mu \text{s}$ as intended by the smooth-drift engine.
3. (c) Firmware skips beacon on Link 2 only (e.g., Quiet / CSA test):
   • Firmware sets cfg_bcn_skip_oneshot[2] = 1 (or bcn_tx_en[2] = 0). At Link 2's TBTT, the TBTT generator still advances next_tbtt_us[2] <= next_tbtt_us[2] + bi_us[2] and fires tbtt_irq[2], but suppresses queuing the frame to the Tx scheduler, increments beacon_skipped_cnt[2], and auto-clears the one-shot skip bit. Links 0, 1, and 3 are completely unaffected.
4. (d) Two links' TBTTs coincide on a shared single-radio / EMLSR hardware path:
   • First, recommend firmware stagger tsf_offset[i] across links (e.g., by $25\text{ TU}$) per 802.11be MLO best practice.
   • Second, if configured identically, the hardware round-robin link arbiter grants Link $A$ first and keeps Link $B$'s bcn_pending[B] = 1; as soon as Link $A$'s beacon finishes, Link $B$'s beacon transmits with a freshly latched timestamp at Link $B$'s actual tx_phy_start.

GPT Answer

• Busy for 2 ms: retain one valid pending beacon, transmit at the next permitted access with fresh timestamp, and leave next TBTT on the interval grid. Define stale-template expiry and skipped-target accounting.
• Pause at capture: use one atomic time-service sample and documented old/new-edge convention, including phase. No independent sampling of timer bits and slew state.
• Skip link 2: consume that target's skip policy, advance its grid, record the intentional skip separately from a fault, and leave other links running.
• Coincident targets/shared radio: serialize with a documented priority/fairness rule, update timestamp at actual launch, and record lateness. Simultaneous on-air beacons are impossible on one shared radio; the requirements must allow deferral.

Claude Answer

• (a) Medium busy 2 ms at TBTT: beacon waits in the queue, goes out at TBTT + 2 ms with
  the real timestamp; next TBTT unchanged; beacon_late and max-latency stats update. If
  the next TBTT arrives first, drop the stale beacon, count beacon_missed, send the fresh
  one.
• (b) TSF pause exactly at latch: the latched value may be 1 µs stale; within tolerance
  for a 1 µs slew step. The rule is latch once; a later slew step must not re-latch or
  modify bytes already streamed.
• (c) Skip on link 2: TBTT still pulses and interrupts (cadence kept), Tx is suppressed,
  beacon_skipped increments, no beacon_missed. Skip bit sampled at TBTT, auto-clear or
  sticky per firmware choice.
• (d) Coincident TBTTs on a shared radio: scheduler picks by configurable link priority
  or round-robin; the loser sends immediately after and is marked late. The integration guide
  recommends firmware stagger offset_link so this is rare.

M8Q21 · B5. Verification hooks and SW interface.

5. (5 min) Verification hooks and SW interface. What registers, counters, and debug
   signals do you expose, and which three SVAs would you bind at the subsystem level?

Gemini Answer

Task 5: Verification Hooks, Registers & Three Subsystem SVAs

• Registers & Counters per Link: CFG_BI_TU, CFG_PRE_TBTT_US, CFG_TSF_OFFSET_LO/HI, CFG_TEMPLATE_BASE_ADDR (ping/pong), CNT_BCN_TX_OK, CNT_BCN_LATE, CNT_BCN_MISSED, CNT_BCN_SKIPPED, DBG_LAST_TX_TIMESTAMP_LO/HI.
• Three Subsystem-Level SVAs:

  // 1. No early beacon: a beacon Tx start on link i can never occur before its armed TBTT
  ap_no_early_bcn: assert property (@(posedge clk_mac) disable iff (!rst_n)
    bcn_tx_start[i] |-> (tsf_link_q[i] >= armed_tbtt_snapshot_q[i]));
  
  // 2. Atomic timestamp integrity: the 8 bytes [24..31] emitted on the PHY stream must
  //    equal the single 64-bit value latched at bcn_tx_start (no mid-stream tearing).
  ap_ts_no_tear: assert property (@(posedge clk_mac) disable iff (!rst_n)
    (bcn_stream_valid && byte_idx == 31) |-> (streamed_ts_64 == latched_ts_at_tx_start_q));
  
  // 3. Valid FCS on every transmitted beacon (checked against independent reference CRC-32)
  ap_bcn_fcs_valid: assert property (@(posedge clk_mac) disable iff (!rst_n)
    (bcn_tx_end && !bcn_tx_abort) |-> (crc32_residue == 32'hC704DD7B));
  

GPT Answer

Expose per-link BI/offset/lead, atomic commit/version, template pointer/length, skip, pending/busy, scheduled target, actual Tx timestamp, lateness/missed counts, sticky errors, and interrupt mask/status. Debug tags should connect target, template version and PHY commit.

Three subsystem assertion intents: (1) each eligible target creates at most one pending/sent identity and a bounded outcome under medium/radio-progress assumptions; (2) committed timestamp bytes equal the time-service value at the defined PHY reference plus compensation, and FCS covers those bytes; (3) targets stay aligned and unrelated links retain configuration/state across another link's update. Avoid unconditional bounded-transmit assertions when CCA can remain busy forever.

Claude Answer

• Per link registers: BI, TSF_OFFSET, PRE_TBTT, CTRL{en, skip, prio},
  STATUS{tbtt, sent, late, missed}, counters tbtt_cnt, sent_cnt, late_cnt,
  missed_cnt, skipped_cnt, max_latency, last_timestamp[63:0] for debug; raw/mask/
  status interrupts for TBTT and beacon-sent.
• Debug signals: tbtt_pulse[3:0], beacon_req/grant[3:0], ts_latch, phy_txstart.
• SVAs: (1) beacon PHY_TXSTART never before its link's TBTT, and never while another
  PPDU is in flight on that radio; (2) monitor-level: the 8 bytes at body offset 0 equal the
  latched TSF plus the computed delay; (3) after a late beacon, the next TBTT equals the
  previous TBTT + BI exactly; plus one ts_latch per beacon.

Part C — Your questions (0:55–1:00)

M8Q22 · Questions for the interviewer

Gemini Answer

1. "As you look toward Wi-Fi 8 (802.11bn) and multi-AP coordination, which features are you pushing into hardware vs. keeping in firmware?"
2. "How is the upper-MAC / lower-MAC hardware split architected here for Multi-Link Operation (MLO)—do links share a unified packet buffer or separate per-link MAC slices?"
3. "What was the trickiest Wi-Fi Alliance certification test issue on your last tapeout?"

GPT Answer

Which draft/version defines current features? How are PHY timestamp-delay changes communicated? Who resolves radio-sharing and beacon-deadline conflicts?

Claude Answer

1. How far ahead of the standard does the architecture work, and when does a feature get
   hardware vs. firmware?
2. What drove the HW/FW split for MLO beaconing and TSF here?
3. What does the certification feedback loop look like from the architecture seat?

Additional notes

Notes. Material not tied to a question

Gemini Answer

No answer in gemini_answer.md.

GPT Answer

References

IEEE TGbn status and scope; IEEE contribution quoting the beacon timestamp reference. Confirm detailed behavior against the project's applicable standard/draft, rather than treating this older contribution as the complete current specification.

Claude Answer

No answer in claude_answer.md.