← 02 Timing, Pipelining and Microarchitecture | Index | 04 Low Power, Area and Synthesis →

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

Contents

• 0. Resume probe
  • M3Q1 · "Describe the cross-chip sync path on your chip: every clock…
• Part A — Rapid-fire Q and A (0:05–0:20)
  • M3Q2 · A1. What is metastability physically, and what does the MTBF…
  • M3Q3 · A2. A 2-flop synchronizer: what guarantees does it give and what…
  • M3Q4 · A3. Why can you not synchronize a 4-bit bus with four parallel…
  • M3Q5 · A4. Gray code counters for async FIFO pointers: why do they…
  • M3Q6 · A5. How does an async FIFO compute full and empty safely? Which…
  • M3Q7 · A6. Pulse synchronizer vs. toggle synchronizer: pick one for a…
  • M3Q8 · A7. The four-phase handshake for passing a data word across…
  • M3Q9 · A8. What does a reset synchronizer protect, assertion or…
  • M3Q10 · A9. What is a reset-domain crossing (RDC) and why can a design…
  • M3Q11 · A10. Glitch-free clock mux: why does a simple assign clk = sel…
  • M3Q12 · A11. Integrated clock gating cell (ICG): why is a latch inside,…
  • M3Q13 · A12. "Quasi-static" signals (e.g., config registers): what must…
  • M3Q14 · A13. Reconvergence: two independently synchronized control bits…
  • M3Q15 · A14. A synchronized data valid crosses with its data bus (data…
  • M3Q16 · A15. Your TSF counter runs in an always-on 32 kHz/1 MHz domain…
• Part B — Deep dive: cross-chip TSF synchronization with smooth-drift…
  • M3Q17 · B1. Mechanism
  • M3Q18 · B2. Block diagram on chip B
  • M3Q19 · B3. Smooth correction
  • M3Q20 · B4. Firmware/HW split and failure modes
  • M3Q21 · B5. CDC audit
• Part C — Your questions (0:55–1:00)
  • M3Q22 · Questions for the interviewer
• Additional notes
  • Notes. Material not tied to a question

0. Resume probe

M3Q1 · "Describe the cross-chip sync path on your chip: every clock domain it crosses."

Gemini Answer

• Answer: The cross-chip TimeSync block aligns the 64-bit $1\mu \text{s}$ TSF timer across multiple Wi-Fi MAC dies on the same board for multi-radio / MLO operation.
• Clock domains crossed:
  1. Board / Pad Async Domain: An external GPIO sync pulse arrives from the master chip asynchronously to all local clocks.
  2. Always-On Timer Domain (tsf_clk, e.g., $1\text{ MHz}$ / $20\text{ MHz}$ XO-derived): The incoming pulse passes through a 2-flop (or 3-flop) synchronizer + rising-edge detector in the local timer domain, latching the exact 64-bit hardware tsf_capture timestamp in the same clock domain (zero multi-bit CDC hazard at capture!).
  3. MAC Core / APB Clock Domain (mac_clk, $160\text{–}640\text{ MHz}$): Firmware reads the captured 64-bit timestamp and writes the signed drift offset (corr_offset_us) and slew rate (slew_period) via a req/ack handshake crossing from mac_clk back into tsf_clk, while the live 64-bit TSF value is mirrored to mac_clk via a synchronized tick + shadow counter so high-speed MAC blocks can read TSF in 1 cycle.

GPT Answer

"I took ownership of TSF, beaconing, and cross-chip TimeSync after the RX lead left, added smooth-drift TSF correction, and brought those blocks to module-level verification. For a crossing-by-crossing explanation, I would draw the actual clock/reset domains and capture/transfer protocols; the resume does not specify that implementation."

Claude Answer

Template (fill in the real names and frequencies from your design):

"Four domains. The sync pulse arrives asynchronously from the other chip and is
synchronized straight into the always-on timer domain, where the TSF counter lives, so
the timestamp capture itself has no crossing. The captured timestamp and sequence number
cross into the register/firmware clock as stable data behind a toggle handshake. Firmware's
computed offset comes back the other way with a request/acknowledge handshake into the
timer domain, where the slew engine applies it. Finally the TSF is mirrored into the MAC
core clock as a shadow counter driven by the synchronized tick, with a periodic handshake
snapshot to realign, because TBTT and TWT compares run at core speed. The only
asynchronous reset interaction is that the MAC/register side can reset while the timer
domain keeps counting, so every handshake into the timer domain is level-based and
reset-safe rather than toggle-based."

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

M3Q2 · A1. What is metastability physically, and what does the MTBF formula look like? Which term do you actually control as an RTL designer?

Gemini Answer

• Physically: When a data transition violates a flip-flop's setup/hold aperture, the master latch nodes sit near the metastable balance point $V_m\approx V_{DD}/2$ where regenerative positive feedback gain is initially tiny; thermal noise and small voltage delta grow exponentially with regeneration time constant $\tau$.
• Formula:$$\text{MTBF}=\frac{e^{t_r/\tau }}{T_0\cdot f_{\text{clk}}\cdot f_{\text{data}}}$$
• What RTL controls: The resolution time $t_r$ (by adding synchronizer stages, e.g., 2 vs. 3 flops, and keeping zero combinational logic between sync flops) and the toggle rate $f_{\text{data}}$ (by throttling how often signals cross).

GPT Answer

Metastability is an analog state caused by sampling near a transition. A common model is MTBF ~ exp(Tresolve/tau)/(C*fclk*fevent), with library-dependent constants. RTL controls synchronizer depth and event rate; placement and cell selection determine how much resolution time is really available.

Claude Answer

A flop clocked while D is inside its setup/hold window leaves the regenerative pair
balanced; it resolves exponentially with time constant τ.
MTBF = e^(t_r/τ) / (T₀ · f_clk · f_data). τ and T₀ are library/process. The RTL designer
controls t_r (resolution time: number of synchronizer stages × destination period) and
f_data (how often the crossing toggles).

M3Q3 · A2. A 2-flop synchronizer: what guarantees does it give and what does it not guarantee? When do you need three flops?

Gemini Answer

• Guarantees: Reduces the probability of a metastable voltage reaching downstream logic to an acceptably large MTBF (e.g., $>{10}^6$ years).
• Does NOT guarantee: Deterministic latency (can take 1 or 2 cycles depending on when the edge hits the aperture), multi-bit coherence across parallel bits, or pulse capture if the input pulse is narrower than $1.5\times T_{\text{dest\_clk}}$.
• When 3 flops are needed: High destination clock frequencies (e.g., $\ge 600\text{ MHz}$ where $T_{\text{clk}}$ is small), ultra-low-voltage corners (where $\tau$ increases sharply), or safety-critical automotive specs.

GPT Answer

Two flops reduce failure probability, not to zero. They do not guarantee pulse capture, exact latency, or bus coherence. Add stages when library/PVT, frequency, and the system reliability target require it; keep logic out from between stages.

Claude Answer

Gives: a clean 0/1 after the sync with a bounded MTBF, with the transition seen 1–2
destination cycles after it happened. Does not give: deterministic latency, pulse-width
preservation (a source pulse shorter than ~1.5 destination periods can be missed), ordering
between separately synchronized signals, multi-bit coherence, or glitch filtering (a source
glitch can be captured). Three flops when the MTBF target fails: multi-GHz destination, low
voltage/low τ corner, high toggle rate, or a safety target.

M3Q4 · A3. Why can you not synchronize a 4-bit bus with four parallel 2-flop synchronizers? Give the exact failure scenario.

Gemini Answer

• Failure scenario: Suppose a counter transitions from 4'b0111 (7) to 4'b1000 (8) near the destination clock edge. All 4 bits change simultaneously with slight routing skew and independent metastability resolution. Bit 3 may resolve to the new 1 on cycle $T$ while bits [2:0] resolve to the old 111 on cycle $T$ (and 000 on cycle $T+1$), causing the destination to sample 4'b1111 (15)—an completely invalid phantom value!

GPT Answer

A bus transition 0011 -> 0100 changes several bits; independent synchronizers can deliver a mixed word. Use a bundled-data handshake, FIFO, or a valid Gray sequence with its physical constraints.

Claude Answer

The four bits change at slightly different times (launch skew, routing) and each
synchronizer resolves independently to old or new. 0011 → 0100 changes three bits; the
destination can see 0111, 0000, 0101, 0110 … any mix, for one cycle, and act on it.

M3Q5 · A4. Gray code counters for async FIFO pointers: why do they work, and why does the FIFO depth have to be a power of two?

Gemini Answer

• Why they work: Adjacent Gray code values differ in at most 1 bit (Hamming distance = 1). If the pointer increments while being sampled across clock domains, that single changing bit resolves to either its old value (pointer = $P$) or new value (pointer = $P+1$)—never a bogus intermediate state.
• Why depth must be a power of two: A standard $N$-bit Gray code has $2^N$ states and is only cyclic (1-bit transition from max value back to 0) when wrapping at $2^N-1\to 0$ (or symmetric even subset around the midpoint). Wrapping an arbitrary count like $9\to 0$ flips multiple Gray bits simultaneously.

GPT Answer

Conventional binary-reflected Gray FIFO pointers change one bit per increment, including wrap for a power-of-two ring. Arbitrarily wrapping at a non-power-of-two count breaks that property. Gray crossing also needs skew/max-delay constraints; encoding alone is insufficient.

Claude Answer

Consecutive Gray values differ in exactly one bit, so any sampling instant returns
either the old or the new pointer, both valid. A non-power-of-two depth wraps from a
mid-sequence value to zero, which changes several bits at once and breaks the property.
Use the next power of two and throttle with almost-full if the depth must be odd.

M3Q6 · A5. How does an async FIFO compute full and empty safely? Which one is pessimistic in which direction, and why is that acceptable?

Gemini Answer

• How computed:
  • empty is computed in the read clock domain by comparing local rptr_gray against the synchronized wptr_gray_sync: empty = (rptr_gray == wptr_gray_sync).
  • full is computed in the write clock domain by comparing local wptr_gray against rptr_gray_sync (inverting the top 2 MSBs of the $(N+1)$-bit Gray code): full = (wptr_gray == {~rptr_gray_sync[N:N-1], rptr_gray_sync[N-2:0]}).
• Pessimism: full uses a delayed (2-cycle stale) read pointer, so it may report full=1 for 1–2 cycles after a read has actually freed space (safe pessimism: stalls writes briefly, never overflows). empty uses a delayed write pointer, so it may report empty=1 for 1–2 cycles after a write has occurred (safe pessimism: delays reads briefly, never underflows).

GPT Answer

Empty: local read pointer equals synchronized write pointer. Full: next write pointer equals the synchronized read pointer one capacity ahead; conventional Gray full detection inverts the top two Gray bits. Stale pointers may retain empty/full too long, safely reducing throughput rather than permitting an illegal access.

Claude Answer

Use N+1-bit pointers. Write side: full = (wptr_gray == {~rptr_sync[N:N-1], rptr_sync[N-2:0]})
with a synchronized, therefore stale, read pointer: it may say full while space exists —
pessimistic, never overflows. Read side: empty = (rptr_gray == wptr_sync) with a stale
write pointer: may say empty while data exists — never underflows. Each side only trusts
the pointer it owns for the dangerous direction.

M3Q7 · A6. Pulse synchronizer vs. toggle synchronizer: pick one for a 1-cycle event going from a 160 MHz domain to a 32 kHz domain. What is the maximum event rate it supports?

Gemini Answer

• Pick: Toggle synchronizer with feedback acknowledge (closed-loop pulse synchronizer) (or open-loop toggle sync if events are guaranteed slow). Because $160\text{ MHz}$ is $5000\times$ faster than $32\text{ kHz}$, a 1-cycle pulse ($6.25\text{ ns}$) is invisible to a $32\text{ kHz}$ clock ($T=31.25\mu \text{s}$).
• How it works: The 1-cycle pulse flips src_toggle <= ~src_toggle in the $160\text{ MHz}$ domain; the $32\text{ kHz}$ domain 2-flop synchronizes src_toggle and XORs sync_q ^ sync_qq to recreate a 1-cycle pulse.
• Max event rate: At least 2 destination clock periods ($62.5\mu \text{s}$, i.e., $\le 16\text{ kHz}$) between events so the destination samples both Toggle=1 and Toggle=0.

GPT Answer

Use an acknowledged toggle or handshake for guaranteed delivery. An open-loop toggle is safe only if successive toggles are sufficiently separated for destination observation; there is no unconditional maximum event rate without that timing contract. At 32 kHz, even two destination cycles are 62.5 us; a handshake makes the actual throughput depend on the whole round trip.

Claude Answer

Toggle synchronizer. A 6 ns pulse into a 31 µs clock is invisible to a pulse sync.
Source flips a level; destination 2-flop syncs and XORs for the edge. Max rate: one event
per ~2–3 destination periods, about 10–15 kHz. Faster than that needs an ack back to the
source or an event counter, not a bigger synchronizer.

M3Q8 · A7. The four-phase handshake for passing a data word across domains: how many sync delays per transfer, and when is it preferable to an async FIFO?

Gemini Answer

• Sync delays per transfer: 4 phases (req $\uparrow$ syncs to dest: 2 dest clks; ack $\uparrow$ syncs to src: 2 src clks; req $\downarrow$ syncs to dest: 2 dest clks; ack $\downarrow$ syncs to src: 2 src clks — though a 2-phase toggle req/ack cuts this in half to 1 round-trip = 2 dest + 2 src cycles).
• When preferable to async FIFO: Low-duty-cycle wide buses (e.g., 64-bit TSF snapshot or configuration struct updates) where paying $8\times 64$ flops of FIFO storage + Gray pointers is wasted area.

GPT Answer

Four-phase transfer: req up, ack up, req down, ack down, each crossing synchronized. That is four crossing legs, not merely the assertion round trip. Prefer it for infrequent configuration words; use a FIFO for sustained traffic. Hold payload until completion.

Claude Answer

Four sync delays per word: req → dest (2 dest cycles), ack → src (2 src cycles),
req drop → dest, ack drop → src; two-phase halves it. Prefer it over an async FIFO for rare
transfers (config, commands, snapshots), wide data, or when the source needs confirmation.
It is a dozen flops instead of pointers, Gray logic and a RAM.

M3Q9 · A8. What does a reset synchronizer protect, assertion or deassertion? Why is async assert / sync deassert the standard?

Gemini Answer

• Protects: Deassertion (release of reset).
• Why async assert / sync deassert:
  • Async assert resets flops immediately even if the clock is dead/gated at power-on (protecting I/Os and power switches).
  • Sync deassert aligns the rising edge of rst_n to the clock edge so all flops meet recovery and removal timing ($t_{\text{rec}}$, $t_{\text{rem}}$) and exit reset on the exact same clock cycle instead of some FSM bits waking up 1 cycle before others.

GPT Answer

Synchronize reset release locally to avoid recovery/removal failures and inconsistent release. Async assertion is useful when clocks stop, but must meet reset pulse-width and RDC requirements. It is not automatically safe for every downstream receiver.

Claude Answer

Deassertion only. Assertion is asynchronous and unchecked: every flop goes to its
reset value regardless of the clock, which is safe. Deassertion must meet recovery/removal
against the clock or some flops leave reset one cycle before others and an FSM wakes up in
an illegal state. So: async assert through the bypass, sync deassert through two flops.

M3Q10 · A9. What is a reset-domain crossing (RDC) and why can a design be CDC-clean yet fail RDC?

Gemini Answer

• What it is: A signal path where the launch flop (R1) and capture flop (R2) share the same clock (so CDC passes!) but belong to different asynchronous reset domains.
• Why it fails: When R1 is asynchronously reset while R2 is active and clocked, R1.Q transitions asynchronously to 0 right inside R2's setup/hold window, driving R2 metastable!

GPT Answer

A reset in one region can change its outputs asynchronously to another region, even with the same clock. CDC signoff alone can miss this; use RDC analysis, reset sequencing, isolation, and valid qualification.

Claude Answer

A flop in reset domain R1 drives a flop in R2 (or no reset) on the same clock. When
R1 asserts asynchronously the source output changes at an arbitrary time relative to the
destination clock: metastability with no clock crossing, so CDC tools pass it. Fix by
qualifying the data with a reset-aware enable, sequencing resets (assert R2 first), or
isolating the boundary.

M3Q11 · A10. Glitch-free clock mux: why does a simple assign clk = sel ? a : b glitch, and what does the standard glitch-free mux structure look like?

Gemini Answer

• Why assign clk = sel ? a : b glitches: Switching sel while either a or b is high (or near an edge) truncates the clock pulse, creating a sub-nanosecond runt pulse that violates minimum pulse width and causes half the flops on the tree to double-clock or go metastable.
• Standard structure: Two cross-coupled branches—each branch gates sel (and ~sel) through a 2-flop synchronizer into that branch's own clock domain, with the final enable latched on the negative edge while the other branch's enable is guaranteed 0 (break-before-make), then combined with AND + OR.

GPT Answer

A raw clock mux can truncate or create a pulse. Use a library glitch-free mux with mutually exclusive branch enables changed during safe clock phases. Handle stopped-clock switching with the cell's specified protocol.

Claude Answer

A mux switching while the two clocks sit at different levels emits a runt pulse.
Glitch-free mux: per branch, a negedge-clocked enable flop (after a sync), enable of branch
A = sel & ~en_B, so the active branch turns off before the other turns on and only while
its clock is low; output = (a & en_a) | (b & en_b). Needs both clocks running; adds a few
cycles of each clock to switch.

M3Q12 · A11. Integrated clock gating cell (ICG): why is a latch inside, and what happens if you gate a clock with an AND gate from a flop in the same domain?

Gemini Answer

• Why a latch is inside: An active-low transparent latch captures the EN signal while CLK == 0 and holds it frozen while CLK == 1 (GCLK = CLK & latch_q).
• What happens with a raw AND gate (clk & en_flop): Any combinational glitch on en while CLK == 1, or clock-tree skew where en_flop updates slightly after CLK rises, slices the high phase of CLK into a glitch pulse.

GPT Answer

An ICG latch holds enable stable during the active clock phase. A same-edge flop feeding an AND can change enable after the clock rises and create a runt pulse. Use recognized ICG cells and connect their test enable.

Claude Answer

The negative latch holds the enable through the clock-high phase so an enable change
can't chop the pulse. A plain AND with a flop-driven enable changes clk-to-q after the
rising edge, while the clock is still high, and chops it: a runt clock into every flop
downstream.

M3Q13 · A12. "Quasi-static" signals (e.g., config registers): what must be true for you to waive the crossing, and how do you enforce it rather than assume it?

Gemini Answer

• What must be true: The signal is written by firmware/control logic only while the destination block is disabled, clock-gated, or held in reset, and remains completely static ($stable) while the destination logic reads it.
• How to enforce in hardware (not comments): Gate the destination usage with an enable/busy interlock (if block_active == 1, block APB writes to the config register or mux to a shadow copy) and bind an SVA: assert property (@(posedge dest_clk) dest_active |-> $stable(cfg_bus));.

GPT Answer

Quasi-static means stable throughout the consumer's sensitive operating interval, with safe update/settling. Enforce a disabled/reset configuration window or handshake, reject busy writes, and assert the protocol. A comment is not evidence for a waiver.

Claude Answer

Must be true: the value cannot change while the consumer could observe it (consumer
in reset/disabled), or the consumer is insensitive to one cycle of a mixed value. Enforce:
hardware interlock (writes blocked or dropped with an error bit while enable is set),
a synchronized "update" strobe that copies the register at a safe point, an SVA
$changed(cfg) |-> !consumer_en, and a CDC constraint that names that assertion as the
justification. Not a comment.

M3Q14 · A13. Reconvergence: two independently synchronized control bits recombine in the destination. What goes wrong and how does a CDC tool detect it?

Gemini Answer

• What goes wrong: Two independent 2-flop synchronizers (sync_a, sync_b) have $\pm 1$ cycle of non-deterministic latency skew relative to each other. If downstream logic combines them (y = sync_a & ~sync_b), their relative arrival order can flip in silicon, producing a false 1-cycle glitch or illegal state transition.
• How CDC tools detect it: Structural cone analysis flags any combinational gate or register fan-in where two or more distinct synchronizer outputs reconverge.

GPT Answer

Independent synchronizers can resolve in different cycles and momentarily create an invalid combined state. CDC tools trace common source/reconvergent cones; consolidate encoded controls or transfer them atomically.

Claude Answer

The two bits were launched together but land in different cycles; a decoder of
both spends a cycle in a state the source never had. Tools trace synchronizer outputs
forward and flag any recombination within N cycles unless the signals are Gray, one-hot
with handshake, or the downstream logic is proven insensitive.

M3Q15 · A14. A synchronized data valid crosses with its data bus (data stable while valid is high). What timing constraint do you need on the data bus, and how do you express it in SDC?

Gemini Answer

• Constraint needed: Even though data is held stable at the launch flops until handshake completion, routing delay skew across the 64 wires must not exceed the 1-to-2 destination clock cycles of the valid synchronizer.
• How to express in SDC:
  • set_max_delay <1.0 * T_dest_clk> -datapath_only -from [get_pins src_data_reg*/CK] -to [get_pins dst_data_reg*/D]
  • set_bus_skew <0.8 * T_dest_clk> -from [get_pins src_data_reg*/CK] -to [get_pins dst_data_reg*/D]

GPT Answer

Bundled data must settle before destination capture and remain stable until acknowledgment. Constrain the source holding-register to destination capture-register path with a protocol-derived set_max_delay -datapath_only; check bus skew if relevant. Do not hide it under broad false paths or invent a universal two-cycle budget.

Claude Answer

Data must be settled before the synchronized valid can be sampled and must stay
stable until the handshake completes; across bits the skew must not exceed one destination
period. SDC: set_max_delay -datapath_only <T_dest> -from <src_data_regs> -to <dst_data_regs>
(plus a bus-skew style check where the tool supports it), never a false path, and an SVA
that data is stable while valid is high.

M3Q16 · A15. Your TSF counter runs in an always-on 32 kHz/1 MHz domain and the MAC reads it at 160 MHz. Describe the safe read structure with no handshake latency on the fast side.

Gemini Answer

• Architecture: Maintain the golden 64-bit tsf_cnt in the always-on $1\text{ MHz}$ domain. Synchronize the $1\text{ MHz}$ tsf_tick (via a toggle synchronizer) into the $160\text{ MHz}$ mac_clk domain. Since tsf_cnt is guaranteed stable for $990\text{ ns}$ after tsf_tick toggles and the 2-flop toggle sync takes only $2\times 6.25\text{ ns}=12.5\text{ ns}$ (constrained with set_max_delay 10ns -datapath_only), the synchronized tick edge cleanly samples tsf_cnt into a mac_clk shadow register tsf_mac_q[63:0] that any MAC block can read in 0 cycles.

GPT Answer

For an immediate cached fast-side read, continuously update a coherent shadow through a mailbox/FIFO and specify its staleness. A fresh atomic slow-domain sample needs a transfer protocol and latency. A directly synchronized Gray counter is possible only with a compatible one-step update sequence; smooth double-step corrections violate ordinary Gray adjacency.

Claude Answer

Keep the counter in the slow always-on domain. In the 160 MHz domain, run a shadow
counter: the slow tick comes across a toggle synchronizer and increments the shadow by one
µs; align it once at startup and after wake with a handshake snapshot of the full 64 bits,
and re-snapshot periodically. Reads in the MAC domain are local flops, zero latency. (A
Gray-coded counter sampled directly also works while the counter steps by exactly one, but
my slew engine double-steps and pauses, which breaks the one-bit-change property.)

Part B — Deep dive: cross-chip TSF synchronization with smooth-drift correction (0:20–0:55)

Two Wi-Fi chips (A and B) sit on the same board and must present a single, coherent TSF
(64-bit, 1 µs resolution) so that beacons, TWT schedules and MLO-style coordination line up.
Each chip has its own crystal (±20 ppm). Chip A is the master.

Available between chips:

• one dedicated GPIO wire sync_pulse from A to B (unidirectional, ~2 ns board skew),
• a bidirectional low-speed serial link (SPI-like, ~10 Mbps, driven by firmware on both sides,
  non-deterministic latency of tens of µs).

Requirements:

1. Steady-state offset between TSF_A and TSF_B ≤ 1 µs.
2. TSF_B must never jump backwards and must never jump forward by more than a configurable
   step; corrections must be applied smoothly (the "smooth-drift" requirement).
3. B must detect loss of sync (A reset, cable removed) and flag firmware.
4. The mechanism must work when B's TSF is also being used locally in real time (TBTT, TWT,
   NAV timers are counting against it).

M3Q17 · B1. Mechanism

1. (5 min) Mechanism. Propose the sync protocol: what is on sync_pulse, what goes over
   the serial link, and how B computes its offset. Explain why you need both channels.

Gemini Answer

Task 1: Two-Channel Sync Protocol (sync_pulse + Serial Link)

• Why both channels are required:
  • sync_pulse GPIO wire has sub-10 ns timing precision (~2 ns board trace delay) but carries 1 bit (cannot transmit a 64-bit number without serializing over many $\mu \text{s}$).
  • The 10 Mbps SPI/serial link carries the full 64-bit timestamp + sequence ID ({seq_id[7:0], tsf_master_capture[63:0]}), but has tens of $\mu \text{s}$ of firmware/interrupt jitter.
• Protocol sequence:
  1. Every sync interval (e.g., $100\text{ ms}$), Master Chip A generates a $2\mu \text{s}$ rising edge on sync_pulse, simultaneously latching its own TSF_A_snap and incrementing seq_id.
  2. Slave Chip B's hardware captures its local TSF_B_snap on the synchronized rising edge of sync_pulse and increments its local hardware pulse counter rx_seq_id.
  3. Master A sends {seq_id, TSF_A_snap} over the serial link to B.
  4. B verifies seq_id == rx_seq_id (ensuring no missed/extra glitch pulse) and computes the exact signed error:$${\mathrm{\Delta }}_{\text{us}}=\text{TSF\_A\_snap}-\text{TSF\_B\_snap}$$

GPT Answer

1. Protocol and feasibility

A hardware pulse identifies an exact A-side timestamp. B captures a local timestamp on pulse arrival. The serial link carries {epoch, pulse_sequence, A_timestamp, status, integrity_check}; pair it with B's capture and compensate calibrated capture/board delay. Firmware transport latency then affects correction freshness rather than the original measurement.

A single pulse wire cannot carry a sequence number by itself. Establish numbering with an acknowledged arm/epoch protocol and an identifiable first pulse; reject missing/duplicate/ambiguous associations and re-arm after reset. A free-running pulse counter without resynchronization is insufficient after a lost edge.

Challenge the budget: two +/-20 ppm clocks can separate at 40 us/s. Without frequency compensation, the entire 1 us budget is consumed in 25 ms. Choose a much shorter measurement interval after reserving capture/quantization error, or estimate frequency and bound residual drift. A 32 kHz capture clock cannot meet 1 us precision. Use a fast always-on capture clock and fractional timestamp/interpolation; even a 1 MHz capture leaves little error budget. Confirm whether the limit is measured continuously or only at update instants.

Claude Answer

• sync_pulse: A asserts it at a known TSF_A value, e.g. whenever TSF_A[19:0] == 0
  (~1.05 s), stretched to ≥ 3 timer clocks, with a sequence number incremented per pulse.
• B hardware timestamps the rising edge with TSF_B into a capture register and bumps a
  capture sequence counter.
• Serial link: A's firmware sends {seq, TSF_A_at_pulse}; B's firmware pairs it with the
  capture of the same seq and computes offset = TSF_A_at_pulse − cap_ts − t_known,
  where t_known is the constant synchronizer + board delay (calibrated once).
• Why both: the wire gives a sub-µs instant but carries no value; the serial link carries
  the value but with tens of µs of jitter. Pairing a precise instant with a late-arriving
  label is what makes the serial latency irrelevant. The sequence number guards against
  mispairing when a pulse or packet is lost.

M3Q18 · B2. Block diagram on chip B

2. (10 min) Block diagram on chip B. Clock domains involved (at least: 32 kHz/1 MHz
   always-on timer domain, MAC core clock, the async sync_pulse input). Show every crossing
   and the structure used for each one.

Gemini Answer

                    CHIP B
  pad: sync_pulse (async)
       |
       v  [CDC #1: 2-flop sync + posedge detect in clk_tsf (1 MHz)]
  +-------------------------------------------------------------------+
  | Always-On Timer Domain (clk_tsf = 1 MHz, rst_aon_n)               |
  |                                                                   |
  |  sync_edge ---> [Capture Reg: tsf_b_snap_q[63:0], snap_seq_q[7:0]]|
  |  sync_edge ---> [Watchdog Timer: resets to 0 on edge;             |
  |                  if > MAX_MISS_US -> sync_lost_q = 1]             |
  |                                                                   |
  |  [Smooth-Drift TSF Engine]                                        |
  |    pending_corr_q (signed 16b), slew_timer_q                      |
  |    step ∈ {0 (pause), +1 (normal), +2 (double-step)}              |
  |    tsf_b_q[63:0] <= clear/jump ? load_val : tsf_b_q + step        |
  +-------------------------------------------------------------------+
       |                         ^                       |
  [CDC #2: Toggle+Capture]  [CDC #3: Req/Ack Handshake] [CDC #4: Sync Tick + Shadow]
       v                         |                       v
  +-------------------------------------------------------------------+
  | MAC Core / APB Domain (clk_mac = 160-640 MHz, rst_mac_n)          |
  |  - CSR Read: tsf_b_snap, snap_seq, sync_lost_irq                  |
  |  - CSR Write: corr_offset_signed, slew_period, hard_jump_load     |
  |  - Local Shadow TSF (tsf_mac_q[63:0]) -> TBTT, TWT, NAV timers    |
  +-------------------------------------------------------------------+

GPT Answer

GPIO -> input pad -> fast-AON synchronizer/edge capture -> atomic {sequence, timestamp} mailbox -> MAC/FW.

Serial RX -> checked message -> pairing/offset estimator -> command mailbox -> timer correction engine.

The timer maintains monotonic integer TSF plus fractional phase if needed. Provide a coherent timer-to-MAC snapshot stream with a documented age bound. Keep timestamp generation and event capture in the same domain where possible; otherwise transfer time/phase through a defined atomic protocol, not independent synchronized bits.

Claude Answer

Domains: clk_t (1 MHz always-on timer, TSF lives here; 32 kHz is the sleep backup),
clk_mac (160 MHz), clk_apb (register/firmware), async sync_pulse.

M3Q19 · B3. Smooth correction

3. (10 min) Smooth correction. Design the correction engine: given a measured offset
   (signed, µs) and a maximum slew (e.g., 1 µs per 10 ms), how does the TSF increment logic
   apply it? Handle: negative offsets without going backwards, a new offset measurement
   arriving before the previous one is fully applied, and a huge offset after a cold start
   (when a hard jump is actually desired).

Gemini Answer

• Normal operation: Every $1\mu \text{s}$ tick, tsf_b_q increments by $+1$.
• Bounded Slew Rate: Suppose crystal offset is up to $\pm 40\text{ ppm}$ ($40\mu \text{s/sec}$). We configure slew_interval = 1000 ticks ($1\text{ ms}$, i.e., up to $\pm 1000\text{ ppm}$ correction capability).
  • Every slew_interval ticks:
    • If pending_corr_q > 0 (B is behind A): increment tsf_b_q by +2 on that tick and decrement pending_corr_q <= pending_corr_q - 1.
    • If pending_corr_q < 0 (B is ahead of A): increment tsf_b_q by 0 (hold/pause for $1\mu \text{s}$)—never decrement (-1), so TSF is strictly non-decreasing!—and increment pending_corr_q <= pending_corr_q + 1.
    • If pending_corr_q == 0: increment tsf_b_q by +1.
• New offset arrives before previous finishes: Overwrite (pending_corr_q <= new_delta), do NOT add! Because new_delta = TSF_A_snap - TSF_B_snap was measured against TSF_B_snap, which already incorporates all corrections applied up to the moment of the pulse. (Wait-and-subtract any correction applied strictly between sync_edge and the FW write corr_applied_since_snap_q so pending_corr_q <= new_delta - corr_applied_since_snap_q for zero overshoot!).
• Cold start / large offset: If |new_delta| > HARD_JUMP_THRESH (or cold_start_en == 1), bypass the slew engine, load tsf_b_q <= TSF_B + new_delta directly, and fire a tsf_jumped_pulse to tell TBTT/TWT blocks to re-anchor their next target timestamps.

GPT Answer

At each microsecond tick, normally add 1. At an allowed correction slot, positive residual means add 2 and reduce residual by 1; negative residual means add 0 and increase residual by 1. This preserves monotonic nondecreasing time. With a maximum extra adjustment of 1 us, the largest positive increment is 2 us; clarify whether the configuration limits extra correction or total increment.

One correction every 10 ms gives 100 ppm correction authority, exceeding 40 ppm oscillator mismatch, but large startup offsets may take a long time to settle. Track frequency error and correction debt separately if necessary. A new measurement should replace the estimated residual at the current epoch after accounting for its age and corrections already applied since capture; blindly accumulating or replacing a stale raw offset is wrong.

Permit a hard initial load only in an explicitly authorized initialization mode with local time consumers disabled. If backward loads are forbidden even then, reset/reinitialize the time epoch or wait for monotonic convergence. Report acquiring until the precision bound is met.

Claude Answer

3. Smooth correction engine (in clk_t, one tick per µs)

registers: tsf[63:0], pending (signed), slew_cnt, applied_since_cap (signed)
each tick:
  step = 1
  if (slew_cnt == 0 && pending != 0) begin
    if (pending > 0) begin step = 1 + min(pending, max_step); pending -= step-1; end
    else             begin step = 0;  pending += 1;                               end  // pause, never go back
    slew_cnt = slew_period
  end else if (slew_cnt != 0) slew_cnt -= 1
  tsf += step
  applied_since_cap += step - 1        // net correction since the last capture

• Negative offset = pause for one tick every slew_period; the counter never decrements.
  With 1 µs per 10 ms (100 ppm) the slew outruns the 40 ppm worst-case relative drift, so
  the loop converges.
• New measurement before the previous one is done: don't accumulate. Firmware's offset is
  "as of capture k"; hardware resets applied_since_cap at each capture, so on load
  pending = new_offset − applied_since_cap. Anything already applied since that capture
  is subtracted out instead of being applied twice.
• Cold start / huge offset: if |offset| > jump_thresh and firmware set allow_jump,
  load tsf directly (forward or backward) and raise tsf_jumped. allow_jump is only
  legal before timers are armed; after that the hardware ignores it and slews, and
  firmware sees the request rejected in status.

M3Q20 · B4. Firmware/HW split and failure modes

4. (5 min) Firmware/HW split and failure modes. What is in hardware vs. firmware, what
   registers exist, and how is loss-of-sync detected? What happens to in-flight TBTT compares
   while a correction is being applied?

Gemini Answer

• HW vs. FW:
  • Hardware: sync_pulse timestamp latch, pulse watchdog counter, smooth-drift $+0/+1/+2$ accumulator, corr_applied_since_snap_q tracker, and shadow TSF propagation.
  • Firmware: Reads serial message {seq_id, TSF_A_snap}, matches seq_id, computes ${\mathrm{\Delta }}_{\text{us}}$, filters outliers, and writes new_delta to hardware CSR.
• Loss-of-sync detection: Hardware watchdog counter in clk_tsf increments every $1\mu \text{s}$ and clears on sync_edge. If it reaches 3 * sync_period (e.g., 3 missed pulses), hardware asserts sync_lost_irq, sets pending_corr_q <= 0 (free-runs on local crystal), and notifies FW.
• In-flight TBTT/TWT compares: Because a $+2$ step skips one integer value (e.g., $999\to 1001$), all timer comparators in the MAC must use >= (tsf_q >= target_time) rather than ==, paired with an armed state bit so a paused tick (+0, holding $1000$ for two $\mu \text{s}$) never fires a double pulse.

GPT Answer

Hardware owns capture, coherent mailboxes, correction rate limiting, monotonic increments, pulse/message age watchdogs, and sticky faults. Firmware owns serial association, configuration, calibration, and policy. Registers include epoch/sequence, capture, signed error, slew limit, lock/acquiring state, last valid-message age, and fault clear controls.

TBTT/TWT comparisons use threshold crossing with per-event one-shot state. A double increment must not miss an equality target, and a paused TSF must not repeatedly fire it. Large jumps need an explicit skip/re-arm policy. Sync timeout enters holdover and reports degraded accuracy; avoid a surprise live hard correction.

Claude Answer

• Hardware: pulse sync + timestamp capture + sequence count, slew engine,
  applied_since_cap, pulse watchdog (expected interval ± tolerance; N consecutive misses
  → sync_lost sticky + interrupt), MAC-domain shadow TSF.
• Firmware: serial exchange, pairing by sequence, offset computation with calibrated
  delay, choosing jump vs slew, slew rate, re-arming after a reset, serial-side timeout.
• Registers: CAP_TS_LO/HI, CAP_SEQ, CAP_STATUS{valid, overrun}, CORR_OFFSET,
  CORR_CTRL{load, allow_jump}, JUMP_THRESH, SLEW_PERIOD, MAX_STEP,
  APPLIED_SINCE_CAP, SYNC_STATUS{locked, lost, miss_count, jumped}, PULSE_TIMEOUT.
• In-flight compares: the TSF only pauses or steps by up to 1 + max_step, so every
  TBTT/TWT compare is tsf >= target, never ==, and the spec says an event may fire up
  to max_step µs early. NAV and relative timers count down independently and are not
  affected. A hard jump invalidates absolute targets: tsf_jumped interrupts firmware to
  re-program them.

M3Q21 · B5. CDC audit

5. (5 min) CDC audit. Walk your own diagram and list every crossing, its type (single-bit
   control, multi-bit data, pulse, reset), and the justification. The interviewer will play
   the CDC tool and challenge each one.

Gemini Answer

Task 5: Full CDC & RDC Audit

GPT Answer

Claude Answer

5. CDC audit (what I'd say when the "tool" challenges each line)

1. sync_pulse → clk_t: async single bit, 2-flop; pulse width guaranteed ≥ 3 clk_t
   periods by A, otherwise add an async-set pulse catcher. Constant latency subtracted.
2. cap_toggle → clk_apb: single-bit level, 2-flop; rate once per second.
3. cap_ts/cap_seq → clk_apb: multi-bit, stable-data; stability enforced by the
   1-second capture interval and the before/after cap_seq check; set_max_delay -datapath_only.
4. corr_offset/load → clk_t: multi-bit under a level req/ack handshake, data stable
   until ack; SVA on stability; set_max_delay -datapath_only.
5. slew_period/jump_thresh/max_step: quasi-static, hardware interlock (writes dropped
   with error bit while engine_en), SVA.
6. TSF → clk_mac: multi-bit; shadow counter + handshake snapshot; no direct sampling.
7. sync_lost → clk_apb: sticky level, 2-flop; clear goes back as a handshake.
8. RDC: clk_apb/clk_mac reset while clk_t runs. Handshake inputs into clk_t are
   levels that reset to "idle", the tick synchronizer in clk_mac is reset-safe (shadow
   re-snapshots after reset), and timer-domain state is only reset by the always-on reset.

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

M3Q22 · Questions for the interviewer

Gemini Answer

1. "Do you run both structural CDC and RDC sign-off (e.g., SpyGlass CDC/RDC or Questa CDC) at the block level before SoC integration?"
2. "Are designers required to instantiate hard library synchronizer macros (SYNC2_CELL) with embedded placement/false-path attributes, or behavioral 2-flop templates?"
3. "How are multi-bit MCP crossings verified in gate-level or RTL simulation—do you inject random $\pm 1$ cycle CDC jitter in DV?"

GPT Answer

What is the allowed TSF read staleness? Which capture error terms are calibrated? Who approves CDC/RDC waivers and physical Gray-bus constraints?

Claude Answer

1. What is the CDC waiver policy, who approves, and how do waivers survive reuse?
2. Are synchronizer cells library cells with placement constraints, and does STA check
   them for the metastability window?
3. Is there an RDC flow in addition to CDC, and at what level is it run (IP or SoC)?

Additional notes

Notes. Material not tied to a question

Gemini Answer

No answer in gemini_answer.md.

GPT Answer

Practice answers; proposed circuitry is not a description of undisclosed production RTL.

Reference

Intel: Understanding Metastability in FPGAs. Final MTBF and timing requirements must use the target ASIC library and signoff methodology.

Claude Answer

No answer in claude_answer.md.