RTL Review

← 09 FPGA Emulation, Tooling and Methodology | Index | 11 AMBA AXI and On-Chip Interconnect →

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

0. Resume probe

M10Q1 · "Of your six subsystems, which one would you hand off first and why?"

Gemini Answer

Answer: I would hand off the Tx length-parameter datapath (specifically the factored NDBPS lookup + single-user / MU pipeline) first.
Why:
1. Self-contained, pure specification contract: Its inputs (TXVECTOR rate/length parameters) and outputs (N_SYM, TXTIME, L_LENGTH, pre-FEC padding) are 100% defined by IEEE 802.11 equations with no asynchronous clock-domain crossings or tricky firmware race conditions.
2. Bulletproof safety net: Because I already re-pipelined it to remove the legacy multicycle path and built an exhaustive module-level testbench + 300+ Wi-Fi 8 rate tests against a golden predictor, a newer engineer can add a new Wi-Fi 8 MCS/RU mode and know within 3 minutes whether they broke anything.
- By contrast, I would hold onto Cross-Chip TimeSync / Beaconing and Baseband Interface longest because mistakes there span multiple clock domains, board-level GPIO timing, and firmware interaction that simulation doesn't easily catch.

GPT Answer

"I would start with the MAC-to-MAC emulation bridge if its interfaces, regression tests, and bring-up documentation are stable. It has a clear consumer and documented sustained use. I would retain time-sensitive architectural risks until the receiving owner could independently debug and release the block." This is a proposed handoff choice, not a past decision.

Claude Answer

"The MAC-to-MAC FPGA bridge. It is the most self-contained, it has the clearest contract
(it mimics the PHY interface and nothing else), it's been stable through every validation
run since bring-up, and its README already explains what it does and doesn't model. Handing
it off frees me for the things with the most Wi-Fi 8 churn — the Tx length path and TSF —
where my context is hardest to transfer."

Part A — Behavioural / judgement Q and A (0:05–0:20, ~75 s each)

Answer each with one specific story: situation, the decision you made, the result, and
what you would change. The interviewer will interrupt if you drift into generalities.

M10Q2 · 1. You own six subsystems. Describe the moment you realised you could not give all six the same attention. What did you de-prioritise, how did you communicate it, and what broke (if anything)?

Gemini Answer

Situation: Leading into the Wi-Fi 8 RTL freeze while also supporting Wi-Fi 7 post-freeze ECO triage and FPGA bring-up, all six subsystems had incoming requests simultaneously.
Decision: I ranked work by critical-path downstream blocking impact: (1) Post-freeze gate-level ECOs holding tapeout/certification, (2) Baseband interface & Tx length-parameter RTL needed to unblock DV and PD trial synthesis, and (3) deferring non-critical FPGA bridge diagnostic enhancements by two weeks. I sent a written priority table to my manager, the DV lead, and the FPGA lead on Monday morning so no one was surprised.
Result: Zero tapeout slip on the ECOs and on-time RTL delivery for synthesis; FPGA team used existing ILA triggers for two weeks until I delivered the bridge update.
What I'd change: Document the FPGA bridge internal registers earlier so an FPGA engineer could add minor counters self-service.

GPT Answer

Six subsystems: "I prioritize by tapeout/certification criticality, active changes, and verification gaps, then make the deprioritized work and owner visible. My resume shows six-subsystem ownership and certification-focused ECO triage; it does not identify a specific overcommitment incident. For that story I need the actual work I deferred, whom I informed, and the outcome. I would not imply nothing broke without checking."

Claude Answer

Six subsystems, not six attentions. Situation: [Wi-Fi 8 feature push + DV gap]. I
ranked by tapeout exposure: length-param and baseband interface first (every PPDU),
beaconing/TSF second (certification), bridge and FPGA last (stable). I told my manager
and the FPGA lead in writing which items would only get bug-fix attention. What broke:
[e.g., an FPGA request waited three weeks]. Change: I'd have named a backup owner for the
de-prioritised blocks up front instead of being the bottleneck.

M10Q3 · 2. You "took on DV when the team ran short." Who asked, what did you push back on, and how did you avoid verifying your own design with your own assumptions?

Gemini Answer

Situation: When the DV team ran short during the Wi-Fi 8 ramp, my manager asked if I could extend the block verification environment and cover the new 802.11bn single-user modes.
Decision & Pushback: I agreed to build the sequences, coverage model, and 300+ tests, on one condition: I refused to reuse my own RTL implementation equations inside the scoreboard predictor. Instead, I coded the reference predictor directly from the IEEE 802.11bn specification tables and cross-checked its output vectors against the systems/PHY team's independent C reference script, then had a senior DV engineer review my testplan and coverage exclusions.
Result: Caught 2 subtle boundary rounding discrepancies between the draft spec and RTL before subsystem integration.

GPT Answer

Taking on DV: "When the team was short, I extended the block environment to Wi-Fi 8 and authored 300+ single-user tests. The risk is reproducing my RTL assumptions in the checker, so I would emphasize specification-derived expected results, DV review, boundary tests and failure sensitivity. The resume does not say who asked, what I pushed back on, or which independence checks were actually used; those need a real example."

Claude Answer

Taking on DV. [Who asked: DV lead/manager.] I pushed back on verifying my own blocks
without a second reviewer: I wrote the test plan, got an independent DV engineer to
review it against the spec, wrote the reference model from the spec tables not the RTL,
and refused to sign off the LDPC/MU boundaries without directed cases. Result: 300+
generated tests, [N] bugs found, [one] of them mine. Change: start the plan review
earlier.

M10Q4 · 3. Tell me about an ECO triage where you argued against fixing a bug in hardware. What was the SW/PM reaction, and were you right?

Gemini Answer

Situation: During post-freeze ECO triage with SW, PM, and skip-level leadership, a rare corner case surfaced where a specific non-standard management frame configuration could misreport a secondary status counter if firmware didn't clear it during link re-init.
Decision: I quantified the hardware ECO risk (touching a multi-clock control block in metal/gates 10 days before tapeout would require 6 spare cells + re-timing sign-off) vs. the firmware workaround (1 line of CSR clear in the already-executed driver init routine, zero throughput or Wi-Fi Alliance certification impact) and recommended SW workaround for this tapeout + RTL fix in the next derivative.
Result: Leadership and PM agreed once they saw it was not a WFA certification blocker; saved 3 days of PD churn and shipped cleanly.

GPT Answer

Against a hardware ECO: "I represented MAC in triage with SW, PM and leadership, prioritizing certification blockers. I would oppose a hardware patch when a demonstrably reliable, deployable software solution meets the requirement and the ECO risk is greater. My resume does not establish a specific disagreement or its reaction/outcome; I need an actual triage case before presenting this as a past decision."

Claude Answer

Arguing against a hardware fix. [Issue]. Criteria I used: occurrence rate,
customer visibility, certification exposure, silicon risk of the fix, and SW cost per
generation. I argued for a documented SW workaround plus a next-generation fix. SW/PM
reaction: [pushback]; outcome: [it held / it didn't]. Was I right: [honest answer].

M10Q5 · 4. Describe a disagreement with the backend team. How was it resolved, and what did you change in how you hand off RTL afterwards?

Gemini Answer

Situation: On the legacy Wi-Fi 6E/7 Tx length-parameter block, PD wanted to keep patching the 3-cycle multicycle path (set_multicycle_path 3) with complex -through pin exceptions, while I saw how fragile those pin names were across synthesis runs.
Decision: Rather than fighting over SDC regexes, I profiled the arithmetic cone, proved that factoring the lookup + pipelining the reciprocal multiply fit in single-cycle 640 MHz stages with negligible flop area overhead, and removed the multicycle path entirely.
What I changed in hand-offs: Every RTL hand-off I own now includes a zero-MCP goal (or explicit enable-gated MCP wrapper with accompanying SVA proving the enable cadence).

GPT Answer

Backend disagreement: "I own releases and backend coordination; removing the legacy multicycle path is a relevant technical example. I would resolve a disagreement with common timing reports, exact exceptions and an agreed endpoint contract, then improve handoff checks. I cannot claim a particular conflict or resolution from the resume alone."

Claude Answer

Backend disagreement. [E.g., a multicycle path they wanted to keep vs my
re-pipelining; or an ECO they wanted in metal that I wanted in RTL.] Resolved by putting
numbers on the table: latency cost vs. constraint risk. Change: I now deliver an SDC
exceptions table with a justification per line, and a timing-budget page in the
release notes.

M10Q6 · 5. A time you were wrong about a technical call that others had to clean up. What was it, how did you find out, and what did you do in the next 48 hours?

Gemini Answer

Situation: When first designing the MAC-to-MAC FPGA bridge, I initially assumed a simplified fixed turnaround delay on cca_busy would be good enough for functional frame exchange.
How I found out: During EDCA contention testing with two active MACs on the FPGA, back-to-back TXOP truncation behaved differently from simulation because cca_busy deasserted 2 $μ s$ too early relative to the PHY rx-end tail.
Next 48 hours: I immediately alerted the FPGA/FW validation team so they wouldn't chase phantom driver bugs, traced the exact TXVECTOR duration to cca_busy deassertion waveform against the PHY spec, patched the bridge's elastic delay counter within 24 hours, and added an automated SIFS/CCA timing assertion to the bridge testbench.

GPT Answer

Being wrong: "I would describe my decision, the evidence that disproved it, the impact on others, and what I did within 48 hours: communicate, contain, correct, and add prevention. The resume contains no such incident, so an honest specific example must come from memory. Avoid turning this into a story about someone else's error."

Claude Answer

Being wrong. [Pick a real one, e.g., a width or a compare assumption, or an
estimate.] How I found out: [DV/FPGA/backend]. First 48 hours: reproduce, own it in the
channel, fix with a second reviewer, add the check that would have caught it (lint rule
or assertion), and tell the people who cleaned up what changed.

M10Q7 · 6. You absorbed the TSF/beacon/TimeSync blocks when the RX lead left. What did you find in that code that you would not have written, and what did you leave as-is on purpose?

Gemini Answer

Situation: Inherited three timing-critical blocks mid-project with sparse documentation.
What I found & fixed: Found brittle exact-equality (==) timestamp comparisons and abrupt TSF step-jumps that risked missing TBTT events during cross-chip sync; I re-architected the smooth-drift (+0/+1/+2) correction and range comparators and brought all three blocks to module-level UVM verification.
What I purposefully left as-is: Kept the legacy CSR register map offsets and bit-field layouts 100% untouched even where the naming was awkward, because changing register offsets mid-project would have broken existing firmware HAL code across three software branches.

GPT Answer

Inherited blocks: "After the RX lead left, I absorbed TSF, beacon and TimeSync, added smooth-drift correction, and brought them to module-level verification. My principle is to preserve proven behavior unless there is a correctness, timing or maintainability reason to change it; fix risky interfaces and add tests before cosmetic rewrites. The exact inherited pattern I kept or changed is not recorded in the resume."

Claude Answer

Absorbing TSF/beacon/TimeSync. What I wouldn't have written: [equality compares on
timers, hand-rolled edge detection on the tick, scattered resets]. What I left alone on
purpose: anything already proven on silicon with no spec change, because touching it
costs verification I didn't have; I documented the debt instead.

M10Q8 · 7. How do you estimate RTL effort for a new feature? Give the last estimate you made, what it actually took, and why they differed.

Gemini Answer

How I estimate: Break every feature into 4 buckets: (1) Spec & corner-case alignment (20%), (2) RTL coding + lint/CDC clean (30%), (3) Self-checking unit test / SVA + synthesis trial (30%), and (4) Integration/documentation buffer (20%).
Last estimate vs. actual: Estimated 2.0 weeks for the Wi-Fi 8 Tx length-parameter + DV extension; actual took 2.5 weeks (+2.5 days) because an ambiguity in the draft 802.11bn LDPC tone-plan spec required cross-checking with the PHY standards representative before locking the table. Lesson learned: add explicit schedule buffer whenever implementing pre-ratified IEEE draft specs.

GPT Answer

Effort estimate: "I split a feature into specification, interfaces/architecture, RTL, verification, integration and signoff, with explicit assumptions and a range. I update after the riskiest prototype. I need a real estimated-versus-actual example and its cause; the resume has no schedule numbers to quote."

Claude Answer

Estimation. Method: break into interfaces, state machines, arithmetic, and the
verification multiplier (usually 1.5–2× the RTL). Last estimate: [X weeks] for
[feature]; actual [Y]; difference came from [spec churn / an interface I didn't own].
Change: I now carry an explicit line for "dependencies on other owners."

M10Q9 · 8. The VP feature summary: what did you include that engineering wanted and leadership did not care about, and vice versa? How did you decide?

Gemini Answer

What engineering cared about vs. what the VP cared about: Engineers wanted to show internal pipeline diagrams, LUT factorization math, and UVM test counts. The VP cared about customer-visible differentiation, die area / power delta vs. Wi-Fi 7, schedule risk to tapeout, and Wi-Fi Alliance certification readiness.
How I structured it: Put a 1-page executive table up front (Feature | Customer Benefit | Area/Power Cost | Schedule/Cert Status: Green/Yellow/Red) and moved microarchitectural block diagrams to backup slides.

GPT Answer

VP summary: "I prepared the Wi-Fi 8 feature summary presented to the VP. For that audience I would lead with supported capability, delivery readiness, certification/schedule impact and decisions needed; retain technical detail as backup. I should verify who presented it and which content changed before claiming a particular leadership reaction."

Claude Answer

VP summary. Engineering wanted the microarchitecture and the rate-matrix coverage
table; leadership wanted certification exposure, schedule risk, and what competitors
can't do. I led with three risks and three decisions needed, put the engineering depth
in an appendix, and cut everything that didn't change a decision.

M10Q10 · 9. Give an example of mentoring a junior engineer through a bug they could not find. What did you not tell them?

Gemini Answer

Situation: A junior engineer was stuck for a day on a simulation hang where a valid/ready downstream block stalled forever after the first backpressure event.
What I did & what I did NOT tell them: Instead of pointing at the line where out_valid combinationally depended on out_ready, I asked them to write down the 3 AXI valid/ready handshake rules on a notepad and trace in_valid, in_ready, out_valid, and out_ready at the exact clock edge where out_ready dropped from 1 to 0. Within 5 minutes they spotted the combinational loop themselves—and never made that mistake again.

GPT Answer

Mentoring: "I would ask the engineer to state expected behavior, identify the first divergent transaction, and build a falsifiable hypothesis. I would withhold the final answer long enough for them to own the reasoning, while intervening if the schedule or risk required it. The resume does not document a mentoring incident; do not present this hypothetical as one."

Claude Answer

Mentoring. [A junior stuck on a bug.] I didn't tell them the answer. I asked what
the symptom ruled out, had them write the three hypotheses down, and showed them how to
bisect by commit and by signal. They found it in [time]. What I withheld: my guess,
because the method is the thing they keep.

M10Q11 · 10. When is a software workaround the right permanent answer for a hardware bug? Give a case where you chose it, and one where you refused.

Gemini Answer

Right permanent answer: Control-plane / configuration sequences executed once per association or channel switch (e.g., writing two registers in a specific order or clearing a false status flag after PLL relock) where hardware complexity adds gates/risk for zero runtime benefit.
When I refuse: Any per-packet / SIFS-critical datapath operation (e.g., asking FW to intervene per MPDU or per TBTT within microsecond deadlines) or anything that violates IEEE 802.11 over-the-air protocol compliance and fails WFA certification.

GPT Answer

Permanent SW workaround: "Accept it when all affected software paths can enforce it, it meets performance/power/certification needs, deployment is controlled, and a test proves it. Refuse it for hard timing, silent corruption, uncontrolled clients, or an unprovable recovery race. My resume supports triage participation, not a specific accepted/refused pair; choose real cases to complete the historical answer."

Claude Answer

SW workaround as the permanent answer. Yes when: rare, invisible to customers, no
certification exposure, cheap per generation, and the hardware fix touches shared or
risky logic. [Case where I chose it.] No when the workaround is on a per-frame or
SIFS-bound path, or every generation re-pays it. [Case where I refused.]

M10Q12 · 11. You built a parser, linter and language server in your own time. What problem at work did it solve, how did you get the team to adopt a tool one person maintains, and what is your plan if you leave?

Gemini Answer

Problem solved at work: Commercial linters and synthesis compilers took minutes to run in batch mode, giving zero instant feedback in VS Code / Neovim while writing RTL, and inconsistent formatting cluttered git diff code reviews.
Adoption & Bus-Factor Plan: I made lucisv zero-config (cargo install / single binary), ran it across our 820-file corpus to hit 99.3% parse success, added token-preservation safety checks so it never corrupts code, and open-sourced it under the MIT license with comprehensive architecture docs and modular Rust crates (lexer, parser, ast, linter, lsp, mcp) so any engineer can maintain or extend a lint rule in ~50 lines of Rust—and because it emits standard SV, the team has zero lock-in if they ever stop using it.

GPT Answer

lucisv adoption/support: "I built an MIT-licensed formatter, 60+ rule linter, language server and MCP server sharing analysis engines. It is in daily production-RTL use. Token-preservation/idempotence checks guard formatting. For maintainability I would document builds/tests, pin versions and support a handoff; I would not claim team-wide adoption or a completed succession plan because the resume does not establish them."

Claude Answer

lucisv adoption. Problem it solved: [slow lint turnaround / no cross-file
navigation / inconsistent formatting]. Adoption: CI integration first (formatter check
and a few blocking rules), docs, and zero-config defaults. Bus factor: MIT-licensed and
public, a second maintainer in the team, tests on an 820-file corpus so the next person
can change it safely, and a documented exit to a commercial tool if it stalls.

M10Q13 · 12. What is the one process change you would make in your current team if you had the authority, and why haven't you been able to make it?

Gemini Answer

Change: Move automated Lint + structural CDC + 10-minute smoke regression + trial synthesis check into a mandatory pre-merge CI gate on every pull request, rather than running lint/CDC in weekly batch sweeps before milestones.
Why it hasn't happened fully yet: Legacy EDA license pool contention and monolithic testbench compile times; I've been addressing the first half with fast zero-license open-source AST linting (lucisv) and incremental block-level smoke targets.

GPT Answer

Process change: "I would propose a traceable release gate linking RTL, ECO netlist, constraints and verification evidence, with risk-based independent checker review. It connects directly to my release/ECO/DV responsibilities. I would first understand existing practices and ownership; I cannot truthfully say why my current team has not implemented it without more context."

Claude Answer

One process change. [E.g., LEC of RTL against the taped-out netlist as a CI gate, or
designer-owned SVAs required at MR.] Why not yet: it crosses the RTL/PD/DV ownership
lines, so it needs a manager-level sponsor and compute budget I don't control.

Part B — Design review simulation (0:20–0:40)

Setup. Pick one subsystem you own (recommended: the Tx length-parameter datapath or the
cross-chip TimeSync). You have 12 minutes to present it to a review board as if it were
the design review before RTL freeze. Whiteboard only, no slides. Cover: purpose, interfaces,
microarchitecture, key tradeoffs, verification status, known risks.

M10Q14 · B-overview. 12-minute presentation

Gemini Answer

Purpose & System Context (2 min): Takes per-PPDU rate/length vector (MCS, NSS, BW/RU, LDPC, STBC, DCM, per-user PSDU_LEN for up to 8–16 MU users) and computes exact N_SYM, TXTIME, L_LENGTH, Packet Extension, and per-user pre-FEC padding within <25 ns so PHY preamble and A-MPDU delimiters can start within SIFS.
Microarchitecture & Key Tradeoffs (4 min):
- Replaced 9,000-gate 1500-entry flat case table with factored N_SD × N_BPSCS × N_SS × R arithmetic (80% area reduction, 90% power reduction with operand isolation).
- Replaced 3-cycle combinational multicycle divider with a 6-stage 640 MHz single-cycle pipeline using exact $K = 36$ reciprocal multiplication (floor(((A-1)*R) >> 36) + 1) and serialized MU user loop (1 user/cycle + running max).
Verification & PPA Sign-off Status (3 min): 100% functional rate-matrix coverage (Wi-Fi 6E/7/8), 300+ 802.11bn tests, formal equivalence on factored LUT, 0 MCP/false-path exceptions in SDC, closes 640 MHz with >15% slack.
Proactively Volunteered Risks & Mitigations (3 min):
- Risk 1: Late IEEE 802.11bn draft changes to new RU/MCS rate tables $\to$ isolated all table constants into a single 80-line LUT package (wifi8_rate_pkg.sv) with spare cells placed nearby.
- Risk 2: High bit-width ( $26 \times 36$ ) reciprocal multiplier power/timing $\to$ input-gated when idle and split across 2 pipeline stages.

GPT Answer

Time	What I would present
0-2 min	Purpose: generate correct PHY length/padding/duration across supported SU/MU modes; timing and correctness are release requirements.
2-4 min	Inputs/outputs, PPDU/user identities, legal modes, initiation interval, latency, reset/flush and PHY deadline contract.
4-7 min	Decode/factored lookup -> exact ceil arithmetic -> STBC/LDPC -> per-user maximum -> common duration and padding. Draw valid/metadata alongside data.
7-9 min	Pipeline versus area/latency, shared arithmetic versus initiation interval, avoiding fragile multicycle constraints. Use actual PPA/timing reports, not invented margins.
9-11 min	Verification matrix, boundary checks, independent oracle, legacy regressions, reset/MU overlap, and outstanding holes. Resume evidence: all-rate Wi-Fi 6E testbench and Wi-Fi 8 extensions; actual current closure must be checked.
11-12 min	Top risks, owners, mitigations, and explicit freeze acceptance criteria.

Claude Answer

Outline for the whiteboard:

Purpose (1 min): per-PPDU, computes N_SYM, TXTIME, L-SIG length, per-user pre-FEC
padding, LDPC extra symbol — the TXVECTOR fields the PHY needs before the preamble.
Interfaces (2 min): tx_start + PPDU params, serial per-user stream (≤ 8), valid
pipeline out to the baseband interface; one new PPDU per SIFS at most; busy and an
assertion for back-to-back starts.
Microarchitecture (4 min): factored N_DBPS lookup (what replaced the 1500-entry
case), ceil-divide by reciprocal multiply with one correction, LDPC pass, TXTIME and
L-SIG in constant-multiply stages, running MAX for MU, second pass for padding. About
11 stages SU, ~25 cycles MU at 640 MHz.
Tradeoffs (2 min): pipelined instead of the legacy 3-cycle multicycle path (two
timing escapes); reciprocal ROM vs sequential divider (chose ROM since the distinct
N_DBPS set is small; the divider is plan B); exact ×12 scaling for fractional N_DBPS.
Verification (2 min): legacy combinational block as golden model, full rate matrix ×
boundary lengths, formal on the divide stage, 300+ generated tests.
Risks, volunteered (1 min): the 22×19 correction multiply is the first stage I expect
to fail post-route (plan B is a hand split); fractional N_DBPS convention must match the
table; I wrote both RTL and tests, so the plan was reviewed independently.

M10Q15 · B1. Architect: "Why is this in hardware at all? Firmware has 2 ms before the beacon."

Gemini Answer

Architect: "Why is this in hardware at all? Firmware has 2 ms before the beacon."
- "For beacons, firmware has time—but this exact engine is shared by hardware SIFS response frames (BlockAck, ACK, CTS) and Trigger-Based (TB) UL PPDUs, where the MAC receives a Trigger frame or A-MPDU at $t = 0$ and must hand a valid TXVECTOR to the PHY within $< 2.5 μ s$ of the $16 μ s$ SIFS window. Firmware interrupt latency alone exceeds that budget. And at ~1,500 gates, the hardware cost is tiny."

GPT Answer

Why hardware with 2 ms available? The relevant budget is worst-case descriptor/config arrival to PHY consumption, including immediate responses, not nominal preparation time. Firmware can precompute stable policy, but timing-critical per-PPDU arithmetic needs deterministic completion. If a use case truly permits firmware, compare that option.

Claude Answer

Why hardware? Firmware has 2 ms for a beacon but not for a BA, a TB PPDU or any
SIFS-bound response, and MU parameters are per-PPDU. One hardware path serves all; a
firmware path for some PPDUs means two implementations to certify.

M10Q16 · B2. Backend: "You have a 64-bit comparator on a 640 MHz path. Show me the timing margin."

Gemini Answer

Backend: "You have a 64-bit comparator / wide multiplier on a 640 MHz path. Show me the timing margin."
- "The 64-bit comparator is in the TSF/TBTT block (which runs on the 160 MHz MAC clock or compares against a registered shadow copy with 14 logic levels = 480 ps out of 1562 ps). In the 640 MHz length-parameter block, the widest operation is the $26 \times 36$ reciprocal multiply, which is explicitly pipelined across 2 register stages (S1 and S2) and synthesizes in 5 nm at 1.18 ns (+380 ps positive slack at SS corner) using only SVT/HVT cells."

GPT Answer

64-bit comparator at 640 MHz? Show mapped/post-place slack and load at relevant corners. If insufficient, split high/low comparison with aligned operands, pipeline it where latency permits, or reduce the compare domain using a proven invariant. No fabricated timing margin.

Claude Answer

64-bit comparator at 640 MHz? It's not in this block; where I have one (TBTT), it's
a registered >= on a 1 µs-granular value, so it's multicycle by design with a stability
assertion, or split into a 32-bit high compare registered and a low compare. Numbers:
a 64-bit compare is ~9 levels, fits with margin at 1.56 ns.

M10Q17 · B3. DV lead: "Your coverage says 100%. Which bug would it not catch?"

Gemini Answer

DV Lead: "Your coverage says 100%. Which bug would it not catch?"
- "100% block coverage proves our RTL matches our block specification and reference model—it would not catch a system-level protocol mismatch where upstream A-MPDU aggregation passes psdu_len_bytes excluding EOF delimiter overhead while the PHY expects it included, or a shared misreading of a draft 802.11bn equation. That is why we cross-validate vectors against the PHY team's C model and run MAC+PHY co-sim."

GPT Answer

100% coverage misses what? Incorrect oracle/rounding, omitted legal mode, reset/CDC hazards, or correlation between RTL and tests. Show mutation/boundary evidence and coverage limitations.

Claude Answer

Which bug would 100% coverage miss? A rounding convention error in the fractional
N_DBPS entries if the generated table and the spec disagree — coverage says I hit the
cell, not that the expected value is right. That's why the model is spec-derived and
audited by a Python script against the spec.

M10Q18 · B4. Architect: "Wi-Fi 8 adds a mode that changes this table. How many lines change, and who else has to change code?"

Gemini Answer

Architect: "Wi-Fi 8 adds a mode that changes this table. How many lines change, and who else has to change code?"
- "Because the lookup is factored into N_SD(ru), N_BPSCS(mcs), R(mcs), and recip_lut, adding a new RU tone size or MCS only touches wifi8_rate_pkg.sv (~15 lines) plus the legality mask (~3 lines). Downstream stages (S1..S5) are parameterized on N_DBPS and R_NDBPS and require zero RTL changes."

GPT Answer

New mode changes table? Keep legality and rate data in reviewed generated tables with independent golden checks. Changes affect model, coverage, firmware/vector capability definitions and tests, not just RTL. Count actual touched artifacts before promising line count.

Claude Answer

Wi-Fi 8 mode changes the table. Unequal modulation per stream changes N_DBPS from a
product to a per-stream sum: the factored lookup grows one adder tree and one ROM
column; the ceil-divide and downstream stages don't change. Lines: ~[80]. Who else: the
baseband interface (new TXVECTOR fields) and firmware register definitions.

M10Q19 · B5. Backend: "If I have to do an ECO on this block in metal, where are your spare cells and which flops would I need?"

Gemini Answer

Backend: "If I have to do an ECO on this block in metal, where are your spare cells and which flops would I need?"
- "The only post-freeze changes that ever hit this block are legality rules or an LDPC threshold tweak in S0 or S3. Both modules have set_ungroup false preserved so their port nets exist intact in the netlist, and standard combinational spare cells (NAND2/AOI21/INV) within $25 μ m$ of u_tx_len_s0 and u_tx_len_s3 are sufficient—no spare flops needed unless pipeline latency changes."

GPT Answer

Metal ECO? Review available placed spares, pin access, cone locality and scan-compatible spare state with PD. RTL cannot promise physical resources that were never reserved.

Claude Answer

Metal ECO on this block. Spare cells are placed per the block's spare plan [1–3%];
the flops I'd expect to touch are the correction stage and the LDPC thresholds — I keep
those constants in registers, not folded into logic, for exactly this reason.

M10Q20 · B6. Skip-level: "What is the one thing in this block you are least confident in, and why hasn't it been fixed?"

Gemini Answer

Skip-Level: "What is the one thing in this block you are least confident in, and why hasn't it been fixed?"
- "The draft IEEE 802.11bn unequal-modulation / DRU legality exclusions, because the IEEE task group is still balloting comment resolutions. To protect the tapeout without guessing, I added a 32-bit CSR-programmable legality override mask (cfg_mcs_ru_allow_mask) so firmware can enable or block borderline draft combinations post-silicon."

GPT Answer

Least confident part? State the actual unresolved item and evidence needed. For this proposal, exact LDPC/common-duration corner handling is a review focus, not a claimed known bug in my delivered design.

Claude Answer

Least confident? The fractional N_DBPS convention. It's not fixed yet because the
table generator is owned by [team] and the spec text is ambiguous; I've flagged it with a
test that fails if the convention changes.

M10Q21 · B7. DV lead: "You wrote both the RTL and the tests. Convince me that is not a problem."

Gemini Answer

DV Lead: "You wrote both the RTL and the tests. Convince me that is not a problem."
- "Two safeguards: first, the scoreboard golden predictor uses floating-point/64-bit direct spec division ($ceil) independent of the RTL's reciprocal-multiply hardware algorithm, and was validated against 10,000 test vectors generated by the PHY team's MATLAB/C model. Second, the testplan and coverage exclusions were peer-reviewed by the DV lead."

GPT Answer

Same RTL/test author? Independent specification/model review, directed boundary vectors, assertions/formal and deliberately injected checker failures reduce correlated-error risk. State which were actually done versus proposed.

Claude Answer

You wrote RTL and tests. The plan was reviewed by DV, the model is spec-derived, the
rate matrix is generated, not hand-picked, and the divide stage is formally proven. The
residual risk is a shared spec misreading, so the legacy block (written by someone else)
is the golden reference.

M10Q22 · B8. Architect: "What would you cut from this design if I gave you half the area budget?"

Gemini Answer

Architect: "What would you cut from this design if I gave you half the area budget?"
- "Instead of a separate $16 \times 12$ multiplier in S3 for N_avbits = N_DBPS * N_SYM and a $26 \times 36$ multiplier in S1/S2, I would time-multiplex (fold) the single multiplier across both stages (adding 2 cycles of latency per user = +16 cycles for 8 users $\approx + 25 ns$ , still well inside SIFS) to cut multiplier area by ~40%."

GPT Answer

Half the area? Share expensive arithmetic or serialize users if the deadline allows; specialize supported configurations and remove duplicate decode. Preserve required correctness and verification; quantify throughput/latency cost before committing.

Claude Answer

Half the area? Drop the pipelined divider for the sequential radix-4 one and the
second multiply for a wider reciprocal; keep the factored lookup. Latency triples, still
three orders of magnitude inside SIFS.

Part C — Tapeout judgement case (0:40–0:55)

Setup. RTL freeze is in 14 days. Tapeout is 10 weeks after freeze. Three issues landed
this week:

# Issue Source Notes

1 TSF cross-chip sync drifts beyond 1 µs under a specific PLL-relock sequence seen once in 400 FPGA hours FPGA team Root cause not confirmed; suspected in the slew engine; 2 days to confirm, 3–5 days to fix + verify

2 Length-parameter block computes one extra OFDM symbol for a rare MU-OFDMA + LDPC + 996-tone RU combo DV, found by a new random test Deterministic; fix is a 6-line RTL change in a block with 100% coverage; costs ~1% airtime in that mode; Wi-Fi Alliance MU test plan includes a related but not identical case

3 Register-block read-clear race: FW can lose an interrupt status bit if it reads in the same cycle hardware sets it SW team Known for two generations; SW has a workaround (read twice); SW lead is asking for a HW fix "this time"

Available resources: you, one junior designer, DV has 1.5 engineers free, backend is
already running trial synthesis on the current RTL.

#	Issue	Source	Notes
1	TSF cross-chip sync drifts beyond 1 µs under a specific PLL-relock sequence seen once in 400 FPGA hours	FPGA team	Root cause not confirmed; suspected in the slew engine; 2 days to confirm, 3–5 days to fix + verify
2	Length-parameter block computes one extra OFDM symbol for a rare MU-OFDMA + LDPC + 996-tone RU combo	DV, found by a new random test	Deterministic; fix is a 6-line RTL change in a block with 100% coverage; costs ~1% airtime in that mode; Wi-Fi Alliance MU test plan includes a related but not identical case
3	Register-block read-clear race: FW can lose an interrupt status bit if it reads in the same cycle hardware sets it	SW team	Known for two generations; SW has a workaround (read twice); SW lead is asking for a HW fix "this time"

M10Q23 · C1. What do you need to know before deciding anything? Ask.

(3 min) What do you need to know before deciding anything? Ask.

Gemini Answer

Issue #1 (TSF >1 $μ s$ drift on PLL relock): Does a PLL relock ever happen during an active MLO/Co-TDMA data session in the real product, or only during band/channel switch (where TSF is re-synced anyway)?
Issue #2 (Length-param +1 OFDM symbol on MU-OFDMA + LDPC + 996-tone RU): Does adding 1 extra OFDM symbol cause the receiver's LDPC decoder to fail CRC (RX_ERROR), or is it merely a compliant $+ 1$ -symbol padding extension? (In 802.11ax/be, if the AP and STA disagree on LDPC_EXTRA_SYMBOL for a given L_LENGTH/PE, the STA computes a different N_punc/N_cw and every frame fails FCS—making it a hard interoperability/certification failure, not just 1% airtime!).
Issue #3 (Register read-clear race): Which exact register block—is it an isolated CSR leaf or the auto-generated CSR template shared by 50 blocks?

GPT Answer

Clarify: customer/certification impact, exact mode/frequency/severity, reproducibility, workaround proof, shared resources, actual signoff dates, verification owners, and whether each bug could corrupt data or hang. Ask which certification test is truly blocked and who accepts residual risk. 'Six lines' and '100% coverage' do not establish low risk.

Claude Answer

Questions first: Is the 1 µs drift customer-visible or a spec margin, and is the PLL
relock sequence realistic in a product? What exactly does the WFA MU test plan cover vs
the extra-symbol combo? Does backend have an ECO slot and spare cells reserved for my
block? Can the junior take issue 3 end to end? Who are the stakeholders for each: FPGA
lead, DV lead, SW lead, PM, backend?

M10Q24 · C2. For each issue: fix before freeze / fix as post-freeze ECO / SW workaround / defer to next generation — with the reasoning and the risk you are accepting.

(5 min) For each issue: fix before freeze / fix as post-freeze ECO / SW workaround /
defer to next generation — with the reasoning and the risk you are accepting.

Gemini Answer

Issue	Decision	Reasoning & Resource Allocation	Accepted Risk & Mitigation
#2: MU-OFDMA + LDPC + 996-tone extra symbol bug	FIX BEFORE FREEZE (Priority 1 — Day 1–2)	Deterministic, 6-line RTL fix in a well-isolated, 100%-covered block (`tx_len_param`). In 802.11, an `LDPC_EXTRA_SYMBOL` mismatch between AP and STA breaks LDPC codeword puncturing alignment and fails Wi-Fi Alliance MU certification.	Takes me 0.5 days + 0.5 DV engineer days to run full regression + LEC. Notify PD immediately (tiny 6-line delta inside existing synthesis block).
#1: TSF sync >1 $μ s$ drift on PLL relock (1 in 400 FPGA hrs)	TIME-BOX 2-DAY ROOT CAUSE NOW; Fix before freeze if localized, else Post-Freeze ECO + FW resync	I spend Days 2–3 with the other 1.0 DV engineer reproducing the PLL-relock sequence in sim. Why: Slew/CDC logic is painful to ECO by hand in gates, so if we find a clean 3-line RTL fix by Day 4, merge before freeze. If root cause takes >3 days, do not hold freeze: reserve spare cells in `tsf_sync` and have FW trigger a forced TSF re-capture immediately after any PLL relock event.	Even if unfixed in RTL at freeze, PLL relock is already a FW-initiated event where FW can issue a 1-write re-sync strobe.
#3: Register read-clear race (known 2 gens, SW workaround exists)	DEFER TO NEXT GEN (Do NOT touch 14 days before freeze)	Modifying read-clear (`RC`) to write-1-to-clear (`W1C`) 14 days before freeze breaks backward-compatible FW driver expectations and touches shared CSR logic across the MAC with high regression blast radius, for a bug that already has a proven 2-generation SW workaround and zero certification impact.	Log permanent ticket for Wi-Fi 9 CSR overhaul; assign junior engineer to prototype the `W1C` update on the next-gen branch after freeze.

GPT Answer

Issue 1: highest uncertainty/system risk. I lead the two-day root-cause effort with FPGA/clock owners and DV; preserve the relock trace, add an accuracy monitor, test containment, and hold a decision checkpoint. Aim for a verified pre-freeze fix if confirmed within the stated 3-5-day effort. Do not preselect a metal ECO before knowing the root cause. Defer only with a proven containment and accountable risk acceptance.
Issue 2: assign a scoped RTL/model review and boundary reproducer immediately, using the junior engineer with review. Fix before freeze if the mathematical/spec error is confirmed; run the whole affected LDPC/MU matrix, equivalence where applicable, and timing. A rare extra symbol may affect more than airtime, including advertised lengths and interoperability. Do not assume the related certification case guarantees coverage.
Issue 3: retain the workaround for this freeze only after validating it and documenting support. Reading twice can still lose a one-cycle set coincident with clear if no underlying event state persists; require a proof/test, not two-generation familiarity. If events can be lost with material impact, raise its priority and consider a small set-dominant fix with targeted concurrency tests. Otherwise plan the permanent register-semantics change for the next generation.

Claude Answer

Decisions:

Issue 2: fix before freeze. Deterministic, 6 lines, 100%-coverage block, new test
already exists, certification-adjacent. Risk accepted: the block is under trial
synthesis, so notify backend, re-run the block regression, LEC the delta.
Issue 1: start the 2-day root cause now, decide at day 2. If confirmed in the slew
engine and contained, fix before freeze — synchroniser/slew logic is a terrible hand-ECO
candidate. If not confirmed, freeze without it, reserve an ECO slot, and ship a FW
mitigation (force a hard resync after PLL relock). Risk accepted: a rare, FPGA-only
symptom with a mitigation.
Issue 3: not before freeze. Two generations of a working workaround, no certification
exposure, and the right fix touches a shared register block. Commit a written design
and a date for the next generation. If the junior genuinely has capacity, a scoped
W1C fix on that one register is possible, but I'd call it what it is: scope creep at
freeze-minus-14.

M10Q25 · C3. The PM says all three must be fixed before freeze or certification is at risk. Respond.

(3 min) The PM says all three must be fixed before freeze or certification is at risk.
Respond.

Gemini Answer

"I completely agree on protecting certification—that is why Issue #2 is our #1 priority and will be fixed, verified, and handed to backend within 48 hours, because an LDPC symbol-count mismatch directly impacts Wi-Fi Alliance MU interoperability. For Issue #1, we are putting our best debug resources on a 48-hour root-cause sprint right now, and we already have a firmware PLL-relock re-sync hook as a backstop so certification cannot be blocked even in the worst case. However, Issue #3 has zero certification exposure—we passed Wi-Fi 6E and Wi-Fi 7 certification with the existing software read-twice workaround, whereas rewriting shared interrupt register semantics 14 days before freeze risks destabilizing working driver interrupts and delaying freeze. Deferring #3 is what guarantees #1 and #2 land on schedule."

GPT Answer

PM says all three: "Let's tie each requirement to the certification exposure and a verified exit criterion. We can pursue the deterministic datapath fix and drift root cause in parallel. I cannot promise three signed-off fixes with current staffing; if all are mandatory, we need additional DV/design ownership or a schedule/scope decision today. An unverified fix is not risk retirement."

Claude Answer

To the PM: "Certification risk is issue 2, and it's being fixed. Issue 1 is product
risk with a decision on day 2 and a mitigation either way. Issue 3 is SW convenience with
a committed next-gen date. I'll give you the data on each, not a promise on all three."

M10Q26 · C4. Your manager asks for a one-paragraph status for the VP. Say it out loud.

(2 min) Your manager asks for a one-paragraph status for the VP. Say it out loud.

Gemini Answer

"We are on track for RTL freeze in 14 days with a clear triage plan for three late items. First, we identified a deterministic MU-OFDMA LDPC symbol-count corner case with Wi-Fi Alliance certification exposure; the 6-line RTL fix is in verification today and will merge by Wednesday with zero schedule impact. Second, we are running a time-boxed 48-hour root-cause investigation on a rare FPGA TSF drift seen during PLL relock, backed by both a firmware post-relock re-sync mitigation and a reserved ECO slot with Physical Design if a late patch is needed after Thursday. Third, we are deferring a legacy CSR read-clear enhancement requested by Software that already has a field-proven driver workaround from Wi-Fi 6E/7, avoiding unnecessary churn in shared register logic before freeze."

GPT Answer

VP status: "Fourteen days before freeze, the main uncertainty is rare cross-chip timing drift during PLL relock; root cause is due in two days, with a 3-5-day fix/verification estimate after confirmation. We are also correcting a deterministic MU/LDPC length error and expanding its boundary checks. The longstanding interrupt race remains under workaround validation; we will retain it only if event preservation is demonstrated. We need a named owner for each closure item and a decision on additional verification support if all three fixes are mandatory for freeze."

Claude Answer

VP paragraph: "MU extra-symbol bug is fixed and in regression before freeze. The
cross-chip drift is being root-caused with a decision by [date] and a firmware
mitigation in hand; it does not block freeze. The interrupt read-clear race is deferred
to the next generation with a design committed to SW. I need backend to hold one ECO slot
for the sync block through freeze plus two weeks."

M10Q27 · C5. Two days later issue 1 is confirmed to be a bug in a block you do not own, whose owner is on leave. What now?

(2 min) Two days later issue 1 is confirmed to be a bug in a block you do not own,
whose owner is on leave. What now?

Gemini Answer

Action: At T-minus-12 days to freeze, team ownership supersedes individual block boundaries.
1. I immediately step in to own the fix: pull the block's design spec and git history, pair with the DV engineer who reproduced the PLL-relock waveform, and craft the minimal surgical RTL fix (e.g., gating the slew accumulator while pll_locked == 0).
2. Ask a second Senior/Staff designer on the team (and the Clock/CDC lead) to peer-review my diff extra carefully since I am not the original author.
3. Run the full block + subsystem regression,lint/CDC, and LEC, merge before freeze, and leave a clean summary doc for the block owner when they return from leave.

GPT Answer

Issue 1 belongs elsewhere/owner absent: keep responsibility for end-to-end containment and closure, identify the correct technical/release owner with my manager, obtain an authorized backup and review, and transfer the reproducer/evidence. Replan DV and dates immediately. Do not leave it orphaned or silently edit unfamiliar clocking logic without cross-team review.

Claude Answer

Day-two twist: don't wait for the owner. Get access, pair with DV on a reproduction,
make the minimal fix with a second reviewer from that block's team, inform the owner and
my manager in writing, and leave a note in the block's log. At freeze-minus-12 the fix
landing is what matters, not who owns the directory.

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

M10Q28 · D. Questions for the hiring manager

Gemini Answer

"Looking at the next 6 to 12 months for your team, what is the biggest technical or schedule risk on the roadmap where this Senior RTL role needs to make an immediate impact?"
"On the last tapeout, what was the hardest late-stage tradeoff between RTL, Firmware, and Physical Design, and how was it resolved?"
"What distinguishes the engineers on your team who quickly grow from Senior to Staff/Principal?"

GPT Answer

What outcomes define success in the first 90 days? Where does the team most need senior ownership? Who resolves HW/FW risk decisions, and what changed after the last schedule escape?

Claude Answer

What does the first 90 days look like, and which subsystem has no owner today?
What took the last tapeout off schedule, and what changed afterward?
How is the HW/FW boundary decided here and who arbitrates when SW and HW disagree?
What is the biggest process gap in the team today?

Additional notes

Notes. Material not tied to a question

Gemini Answer

No answer in gemini_answer.md.

GPT Answer

Behavioral answers must be true. The resume establishes responsibilities/results but not private conversations, mistakes, mentoring incidents, or estimates. Where it does not support a historical story, the response below states a decision framework and names the missing evidence instead of fabricating an anecdote.

Claude Answer

These are frames to hang your own stories on. Every answer needs a real situation, the
decision you made, a result with a number, and what you'd change. Replace the bracketed
parts with the truth.

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

Contents

0. Resume probe

M10Q1 · "Of your six subsystems, which one would you hand off first and why?"

Gemini Answer

GPT Answer

Claude Answer

Part A — Behavioural / judgement Q and A (0:05–0:20, ~75 s each)

M10Q2 · 1. You own six subsystems. Describe the moment you realised you could not give all six the same attention. What did you de-prioritise, how did you communicate it, and what broke (if anything)?

Gemini Answer

GPT Answer

Claude Answer

M10Q3 · 2. You "took on DV when the team ran short." Who asked, what did you push back on, and how did you avoid verifying your own design with your own assumptions?

Gemini Answer

GPT Answer

Claude Answer

M10Q4 · 3. Tell me about an ECO triage where you argued against fixing a bug in hardware. What was the SW/PM reaction, and were you right?

Gemini Answer

GPT Answer

Claude Answer

M10Q5 · 4. Describe a disagreement with the backend team. How was it resolved, and what did you change in how you hand off RTL afterwards?

Gemini Answer

GPT Answer

Claude Answer

M10Q6 · 5. A time you were wrong about a technical call that others had to clean up. What was it, how did you find out, and what did you do in the next 48 hours?

Gemini Answer

GPT Answer

Claude Answer

M10Q7 · 6. You absorbed the TSF/beacon/TimeSync blocks when the RX lead left. What did you find in that code that you would not have written, and what did you leave as-is on purpose?

Gemini Answer

GPT Answer

Claude Answer

M10Q8 · 7. How do you estimate RTL effort for a new feature? Give the last estimate you made, what it actually took, and why they differed.

Gemini Answer

GPT Answer

Claude Answer

M10Q9 · 8. The VP feature summary: what did you include that engineering wanted and leadership did not care about, and vice versa? How did you decide?

Gemini Answer

GPT Answer

Claude Answer

M10Q10 · 9. Give an example of mentoring a junior engineer through a bug they could not find. What did you not tell them?

Gemini Answer

GPT Answer

Claude Answer

M10Q11 · 10. When is a software workaround the right permanent answer for a hardware bug? Give a case where you chose it, and one where you refused.

Gemini Answer

GPT Answer

Claude Answer

M10Q12 · 11. You built a parser, linter and language server in your own time. What problem at work did it solve, how did you get the team to adopt a tool one person maintains, and what is your plan if you leave?

Gemini Answer

GPT Answer

Claude Answer

M10Q13 · 12. What is the one process change you would make in your current team if you had the authority, and why haven't you been able to make it?

Gemini Answer

GPT Answer

Claude Answer

Part B — Design review simulation (0:20–0:40)

M10Q14 · B-overview. 12-minute presentation

Gemini Answer

GPT Answer

Claude Answer

M10Q15 · B1. Architect: "Why is this in hardware at all? Firmware has 2 ms before the beacon."

Gemini Answer

GPT Answer

Claude Answer

M10Q16 · B2. Backend: "You have a 64-bit comparator on a 640 MHz path. Show me the timing margin."

Gemini Answer

GPT Answer

Claude Answer

M10Q17 · B3. DV lead: "Your coverage says 100%. Which bug would it not catch?"

Gemini Answer

GPT Answer

Claude Answer

M10Q18 · B4. Architect: "Wi-Fi 8 adds a mode that changes this table. How many lines change, and who else has to change code?"

Gemini Answer

GPT Answer

Claude Answer

M10Q19 · B5. Backend: "If I have to do an ECO on this block in metal, where are your spare cells and which flops would I need?"

Gemini Answer

GPT Answer