AI-assisted design workflows in silicon engineering
August 1, 2026·78 min read·advanced
First, everything here comes from public sources: peer-reviewed papers, arXiv preprints, published benchmarks, vendor press releases and product pages, trade-press coverage, and published job descriptions…
First, everything here comes from public sources: peer-reviewed papers, arXiv preprints, published benchmarks, vendor press releases and product pages, trade-press coverage, and published job descriptions. Nothing comes from any employer's internal documents, and nothing describes any employer's internal tooling.
Second, the field moves faster than the note. Benchmark numbers quoted here were current when written and will be stale within months. Quote the shape of the argument, not the number, and if you must give a number, timestamp it out loud. Say "as of the middle of 2026, the reported figure was around X." An interviewer in this area knows the numbers move and will respect that framing far more than a stale figure delivered confidently.
Third, and most important, a large fraction of the strongest-sounding claims in this space are vendor-reported and not independently reproduced. Where that is true the text says so. Repeating a vendor's percentage as though it were a peer-reviewed result is the fastest way to lose an experienced interviewer, and Part 2.4 is a case study in exactly how badly that can go.
01.Part 1, three different technologies wearing one name
1.1 A worked example before any definition
Start with a concrete piece of arithmetic that has nothing to do with artificial intelligence, because it is the thing every claim in this note is ultimately about.
You own a synthesis and place-and-route flow, and the flow has knobs. Take just two of them. The first is an effort setting with three legal values, low, medium and high. The second is a target-delay offset you apply to the constraint before handing it to the tool, and you are willing to try five values of it. That is
Each configuration means a full run, and a full run takes two hours. Sweeping all fifteen serially is thirty hours, so you do it over a weekend and pick the best. This is not exotic. Every flow owner has done exactly this.
Now open the knob list properly. A real flow has dozens of settings that matter: placement effort, congestion effort, the clock-tree target skew, the useful-skew enable, the number of optimization passes, the buffer-insertion aggressiveness, the maximum-transition constraint, the multi-threshold-cell swap threshold, the floorplan aspect ratio, the macro halo width. Take six of them at five values each, which is a modest fraction of what is actually available:
Nobody sweeps that. What actually happens is that a senior engineer picks four or five configurations based on experience, runs those, and ships the best one. The design tapes out with a set of tool settings that were never compared against the 15,620 that were not tried.
That gap is the whole opportunity. It is not that the tool is bad or the engineer is bad. It is that the space is too large to enumerate and the evaluation is too expensive to repeat, so the search stops early and nobody knows how much was left on the table. An algorithm that decides which configuration to try next based on what the previous runs returned can search the same space far more efficiently than a human guessing, because it can run unattended for a thousand iterations and never gets bored.
Only now define the word. An optimizer is a procedure that repeatedly proposes a candidate, measures it, and uses the measurement to propose a better candidate. Notice what it is not. It has no understanding of your design, it has no opinion about microarchitecture, and it cannot tell you whether your pipeline depth is right. It is a search procedure pointed at a space you defined, scored by a metric you chose. Hold that sentence, because most of the calibration errors in this subject come from forgetting it.
1.2 The three strands, named separately
The phrase "AI in chip design" is used to mean at least three technically unrelated things. They have different mechanisms, different evidence bases, and different maturity levels, and an interviewer who works in this area will be listening specifically for whether you can tell them apart.
Strand one, machine learning inside the EDA tools. This is the oldest and it is where 1.1 lands. Reinforcement learning and other search methods driving placement, floorplanning, and tool-parameter selection. The subject of a real peer-reviewed literature going back years, of commercial products with published tape-out counts, and, in one prominent case, of a public scientific dispute that is worth knowing in detail.
Strand two, large language models on the text artifacts of the flow. RTL, testbenches, assertions, Tcl and Python scripts, specifications, documentation, code review comments, regression logs, bug reports. Very widely used, measured by public benchmarks, and genuinely uneven in a way the benchmarks systematically understate.
Strand three, agentic workflows. A model that does not just emit text but proposes actions, has those actions executed by a harness, observes the result, and iterates. This is the newest of the three. The EDA vendors began shipping agentic offerings during 2025 and 2026, and as of this writing essentially all of the quantitative claims about them are vendor-reported.
1.3 Why conflating them is the commonest mistake
The failure looks like this. A candidate reads that a reinforcement learning system placed macros as well as human engineers, reads separately that a language model scored 88 percent on a Verilog benchmark, and concludes that AI can design chips. Those two facts are about different technologies solving different problems, and neither of them supports that conclusion.
Run it the other way and it fails just as badly. A candidate tries a chat interface, asks it for a clock-gating cell, gets back a bare AND of clock and enable, correctly identifies that as the broken circuit from Part 3.1 of Power Fundamentals and Clock Gating, and concludes the whole field is hype. That is one data point about one strand on one prompt, and it says nothing at all about whether a reinforcement-learning optimizer can find a better set of synthesis knobs than you can.
The sentence to have ready, because it is the one that establishes calibration in about eight seconds:
"There are three different things people mean by this, they have three different maturity levels, and I would want to know which one you are asking about."
That is not a dodge. It is the correct opening, it demonstrates the distinction immediately, and it lets the interviewer aim the rest of the conversation at what they actually care about.
02.Part 2, learning inside the tools
2.1 What placement is, worked by hand
Do the small numerical version before any abstraction, because placement is one of those problems that sounds vague until you compute one.
A chip's floor is divided into legal sites. You have a set of blocks, and every block must sit at some site with no two blocks overlapping. Blocks are connected by nets, and a net is just a set of pins that must be electrically joined. The wire that joins them costs area, delay, and power, all three of which grow with its length, so the objective is to place the blocks so that the total wire is short.
Measuring "total wire" exactly requires actually routing, which is expensive, so placers use a cheap estimate called half-perimeter wirelength, or HPWL. Draw the smallest axis-aligned rectangle containing every pin of a net. The net's HPWL is half that rectangle's perimeter, which is its width plus its height. For a two-pin net that is simply .
Take a grid of sites with coordinates through in each direction, four blocks , , , , and four two-pin nets joining them in a ring: , , , .
Placement 1 puts the blocks at the four corners, , , , , and each net spans three units, so the total is 12. Placement 2 huddles them into the corner, , , , , and each net spans one unit, for a total of 4. A factor of three from nothing but rearrangement.
The catch is in the caption. Placement 2 concentrates four blocks in a region, which may violate a density limit, may create a routing hotspot the router cannot resolve, and may create a thermal hotspot. Real placement is therefore not "minimize HPWL" but "minimize a weighted combination of wirelength, congestion, density and timing, subject to legality," and the weights are themselves a judgement call. Notice that the objective is already a proxy for the thing you care about before any machine learning enters the picture. That observation is the hinge of Part 2.4.
2.2 Counting the search space
Four blocks on sixteen sites, all blocks distinguishable, gives
placements. A laptop enumerates that instantly. Now scale to something modest by industrial standards. Take 100 macros on a grid, which is 16,384 sites. The count is the falling factorial , and since the correction for the falling terms is small, it is close to
For scale, the number of atoms in the observable universe is usually put at around . The placement space is larger than that number raised to the fifth power. Exhaustive search is not slow here, it is not a thing that exists.
So every placer that has ever shipped is a heuristic: simulated annealing, analytical placement with force-directed spreading, partitioning-based methods. None of them find the optimum, none of them claim to, and the entire question of whether a new method is better is a question about which heuristic produces better results on which designs under which measurement. Keep that framing, because it is the framing in which the next section's dispute becomes comprehensible rather than sensational.
2.3 What reinforcement learning is, starting far too small
Begin with a problem so small it is not really learning at all. You have two synthesis strategies and no idea which is better. You run each five times on different blocks and record worst negative slack. Strategy one averages ps, strategy two averages ps. You pick strategy two. That is the entire idea of learning from measured reward, and it required no mathematics.
Now break it in the specific way that makes placement hard. Suppose instead of picking one strategy you must make a sequence of a hundred decisions. Place macro 1, then macro 2 given where macro 1 went, and so on. You only find out how good the result was after all hundred are placed. Now you have a score of, say, HPWL 12, and you do not know which of the hundred decisions was responsible for it. That is the credit assignment problem, and it is what separates reinforcement learning from the two-strategy comparison above.
The standard vocabulary, each term defined against that picture. The state is what the system knows when it must decide. That is which macros are already placed and where, plus a description of the connectivity. The action is the decision of which site to place the next macro at. The policy is the function mapping state to action, and it is what gets learned. The reward is the score at the end. An episode is one complete run from empty floor to full placement plus its reward. Learning means adjusting the policy so that actions leading to high-reward episodes become more likely.
Now the economics, which is the part that decides everything and which almost nobody states.
Reinforcement learning needs many episodes. Say ten thousand, which is modest. Now suppose the reward for an episode were the real one, meaning you run place-and-route, run the router, run static timing, and read out the actual post-route wirelength and slack. That costs eight hours, so
That is not a budget problem you solve with more machines. It is a structural problem. So every practical system replaces the real reward with a cheap proxy computed in a second or so: an approximate wirelength, an approximate congestion estimate, an approximate density penalty. Ten thousand episodes at one second is under three hours, and the method becomes possible.
And now the entire scientific question is whether the proxy is faithful. If the proxy correlates well with post-route reality, the policy learned against it is useful. If it does not, the policy is expert at scoring well on a metric nobody cares about. Everything contested in the next section reduces to that sentence.
2.4 The learned-placement result, and the public argument about it
This is worth knowing at citable detail, not because you will be asked to recite it, but because it is the single cleanest calibration test available in this subject and because being wrong about it in either direction is expensive.
The claim. In 2021, a team at Google published a paper in Nature, "A graph placement methodology for fast chip design," describing a deep reinforcement learning approach to macro placement. The headline claim was that the method produced placements comparable to or better than human experts on power, performance and area, in under six hours of compute. Google subsequently released an open-source implementation under the name Circuit Training, and later attached the name AlphaChip to the technique.
The dispute. The result was challenged publicly and in detail, and the challenge came from credible quarters.
A team at UC San Diego including Chung-Kuan Cheng and Andrew Kahng published an assessment at ISPD in 2023 that reimplemented the missing pieces in the open, built open testcases, and compared the reinforcement-learning placer against several alternatives: simulated annealing, an academic placer, a commercial placer, and human placement. Their reported conclusion was that the reinforcement-learning method did not outperform the alternatives on their benchmarks, with the commercial tool generally best on routed wirelength.
Separately, Igor Markov posted a critique titled "The False Dawn: Reevaluating Google's Reinforcement Learning for Chip Macro Placement," arguing among other things that key methodological steps and inputs had been withheld, that baselines were weak, and that the comparison as published could not be reproduced. A version of it appeared in Communications of the ACM in October 2024, under the different title "Reevaluating Google's Reinforcement Learning for IC Macro Placement," which is worth knowing, because citing "The False Dawn" as a CACM paper is slightly wrong. ACM subsequently attached an expression of concern to that article regarding the content and transparency of its disclosure, pending an investigation of its own, and recommended it not be cited until that investigation closes. So the critique is itself under a cloud. Treat the critique and the response to it as contested material rather than as findings.
Nature attached an editor's note to the original paper in September 2023 and retracted the accompanying News & Views commentary, whose author said that information about the methods which emerged after publication had changed his assessment. In September 2024 Nature published an addendum to the original paper supplying methodological detail that critics had said was missing, and removed the editor's note at the same time. Get that last part right, because it is the detail most often missed. There is no live editorial flag standing on the primary paper. Critics maintained that the inputs needed for full independent replication were still not public. Google's authors published a rebuttal, "That Chip Has Sailed," arguing that the criticisms rested on failures to follow the published methodology, in particular on skipped pre-training.
What to actually conclude. Three things, and say all three.
First, the paper was not retracted. The original result stands in the literature with an addendum attached. Anyone who tells you it was retracted is confusing it with the News & Views piece, which was.
Second, the independent replications available in public did not reproduce the headline advantage, and the strongest available reading is that learned macro placement is a live research area whose advantage over well-tuned classical methods is not settled in public.
Third, and this is the part with engineering content rather than gossip, the dispute is exactly the proxy-fidelity problem from 2.3 plus a baseline-selection problem. If your baseline is a weakly-tuned classical placer, almost anything beats it. If your reward is a proxy, you can win on the proxy and lose after routing. Those are the two questions to ask about any claim of this shape, including claims made about tools you would be asked to evaluate on the job.
The interview form of that last point is very short and lands well. "Which baseline, and measured on what? The proxy the optimizer was trained against, or the signoff metric?"
2.5 Design-space exploration, which is the sturdier ground
Strand one has a second branch and it is on considerably firmer footing, partly because it is a smaller claim and partly because the evaluation is honest by construction.
Return to 1.1. The task is not to invent a placement, it is to choose among tool configurations, and the score for a configuration is the actual output of the actual tool on the actual design. There is no proxy. There is just a very expensive evaluation and a very large space, which is precisely the regime where an optimizer that chooses its next sample intelligently beats a human choosing four points by intuition.
The commercial products here are Synopsys DSO.ai, announced in 2020, and Cadence Cerebrus, announced in July 2021, with equivalents from other vendors. Synopsys announced the first 100 commercial production tape-outs using DSO.ai in February 2023 and has since reported a cumulative count in the several hundreds, alongside customer-reported PPA and productivity gains. Every one of those figures is vendor-reported, and the tape-out count in particular moves fast enough that the safe form is "past a hundred by early 2023 and several hundred since" rather than any single number. There is no independent head-to-head comparison of the two products on a common design that I am aware of, and you should not repeat the percentages as though there were.
What you can say with confidence is the arithmetic, because it is yours and it does not depend on anybody's marketing. Take the six-knob space from 1.1, and price a run at the eight hours a full place-and-route plus signoff-timing pass costs rather than the two-hour lighter flow 1.1 used. Then 15,625 configurations at eight hours each is 125,000 core-hours to enumerate. If an optimizer reaches a near-best configuration in 200 runs, it has spent 1,600 core-hours, a factor of
less than enumeration, while examining vastly more of the space than the four-point manual sweep that is the real-world alternative. That is a believable claim with a believable mechanism, and it is the right level at which to discuss this in an interview. The tool is not being clever, it is being tireless, and tireless is what this problem needed.
Two honest caveats to volunteer. The optimizer needs a lot of compute, so the gain is real engineering time traded for machine time, which is only a win when machine time is cheap and the schedule is the constraint. And an optimizer will happily exploit a badly-specified objective. If you score only on timing it will hand you a configuration that closes timing and burns power. That makes the objective definition a design decision that stays firmly with the engineer.
2.6 What is actually true today, stated carefully
Machine learning inside EDA tools is real, shipping, and narrow. It searches spaces you defined against objectives you chose. Its strongest deployed form is parameter and design-space search, where the evaluation is the real tool. Its most-publicized form, learned macro placement, is a genuine research area whose published advantage has been publicly contested and which I would treat as unsettled rather than as either a triumph or a fraud.
None of it designs a microarchitecture, decides a pipeline depth, chooses a coherence protocol, or writes a specification. Those remain entirely human, and there is no published evidence pointing at them changing.
03.Part 3, language models on RTL and verification
3.1 What the model is actually doing
Strip this to the mechanism first, because the mechanism predicts every strength and every failure and saves you from memorizing lists.
A language model is trained to predict the next token given the preceding tokens. Nothing more. Given the text
| always_ff @(posedge clk) begin | |
| if (!rst_n) q <= '0; | |
| else if (en) q <= | |
| ```text | |
| the model produces a probability distribution over what comes next. In a corpus of real SystemVerilog, `d` follows that context overwhelmingly often, so `d` gets most of the probability mass, with `data`, `d_in`, and a long tail sharing the rest. The model emits a token, appends it, and repeats. | |
| There is no elaborator in there. No simulator, no timing engine, no netlist, no notion of a clock edge as a physical event. It has read a very large amount of text in which such things are discussed and it produces continuations that look like the text it read. | |
| Modern deployments add two things that matter. **Retrieval** puts relevant documents into the context before the model answers, which grounds it in your actual files rather than its recollection. **Tool use** lets the model call something (run a compiler, grep a repository, execute a test) and read the result. Both narrow the gap between plausible and correct, and both are why Part 5's discipline works. But neither changes the base mechanism, and when the retrieval misses or the tool is absent, the model falls back to producing the most plausible-looking text. | |
| ### 3.2 What the mechanism predicts, before looking at any benchmark | |
| Work it out rather than being told. | |
| Plausibility and correctness **coincide** where the corpus is dense and the conventions are strong. A parameterized FIFO, a one-hot to binary encoder, an AXI-Lite register block skeleton, a Makefile, a Tcl loop that reads a report file, a docstring for a function whose body is visible, an explanation of what an unfamiliar module does. These appear thousands of times in public code in nearly identical form, so the most plausible continuation is very often the correct one. | |
| Plausibility and correctness **diverge** in three specific ways, and each has a mechanism. | |
| They diverge where correctness depends on **facts not present in the text**: your design's actual signal names, your library's actual cell names, your tool's actual option list. The model produces a name that looks exactly like a name of that kind, because that is the job it was trained for, and being wrong about the specific string is invisible from inside the mechanism. | |
| They diverge where correctness depends on a **global property of a large artifact**. Whether a signal is driven from two places, whether this change breaks timing on paths through the block, whether the new state is reachable. Every one of those requires the whole design and usually the tools. The model sees a window of text. | |
| And they diverge where the **plausible-looking answer is a known trap**. If the training corpus contains many tutorial-quality examples of a construct alongside fewer correct industrial ones, the tutorial version is the more plausible continuation. Part 3.4 gives two examples of exactly this, chosen because they are both in your own area of strength. | |
| ### 3.3 The benchmark evidence, and why the headline number misleads | |
| The public benchmark for this is **VerilogEval**, released by NVIDIA in 2023 and built from HDLBits problems, with a human-described split of 156 problems and a machine-described split of 143. Version 2, published in 2024, extended the task from code completion to specification-to-RTL and dropped the machine split, keeping only the human problem statements. So a v1 number and a v2 number are not the same measurement, and quoting one against the other is a mistake worth not making. The metric is `pass@1`: sample one solution, run it against a reference testbench, and report the fraction that pass. | |
| The trajectory is worth knowing because it is genuinely fast. The original paper reported GPT-4 at 43.5 percent `pass@1` on the human split and 60.0 percent on the machine split, with GPT-3.5 down around 27 percent on the human split. Keep those two apart deliberately, because the GPT-3.5 figure is the one that circulates misattributed to GPT-4 and quoting it as GPT-4's is a small, checkable, expensive error. By 2024, the strongest models had risen through the fifties and low sixties on the v2 specification-to-RTL task, with GPT-4o reported at 63 percent. As of the middle of 2026, published reporting puts frontier models near 88 percent `pass@1` and multi-agent systems above 95 percent, and the benchmark is widely described in the literature as **saturating**. The scores no longer discriminate between models. | |
| Now the sentence that matters more than any of those numbers. VerilogEval problems are **self-contained modules**, and recent work characterizing the benchmark's limits puts them in the range of roughly ten to seventy-six lines. New benchmarks (ChipBench, RTL-BenchLS, ChipVerilog and others appearing through 2026) exist precisely because the old ones are too small to measure anything interesting, and they are built from multi-module and full-system targets for exactly that reason. The gap they expose is the whole point. A multi-agent system reported above 95 percent on VerilogEval has been reported in the thirties on the harder successor sets. | |
| So state it plainly. **A benchmark of self-contained modules under about seventy-six lines is not a measurement of whether a model can write a load-store unit.** The saturation is real and it is real for a task that is not the job. A module in a production CPU is embedded in a hierarchy, constrained by a timing budget, bound by a protocol contract to blocks it cannot see, and reviewed against a specification the benchmark has no analogue for. | |
| There is one more result worth knowing because it answers the "so what do companies actually do" question. NVIDIA's **ChipNeMo** work, published in 2023, took open base models and adapted them to the chip-design domain (domain-specific tokenization, continued pre-training on domain data, instruction tuning, and a domain-adapted retrieval model) and evaluated on three applications: an engineering assistant chatbot, EDA script generation, and bug summarization and triage. The reported headline was that domain adaptation let much smaller models match or beat far larger general models on those tasks. Note carefully which three applications those are. **None of them is "write the RTL."** The chosen applications are a question-answering assistant, script generation, and triage summarization, which is a fair signal about where the practitioners who published found the value. | |
| ### 3.4 Three failure classes, with worked examples | |
| **Failure one, subtle timing and protocol correctness.** Two examples, both squarely in your strength areas, both of which a model will produce readily because the wrong version is the more plausible continuation. | |
| Ask for a clock gate and you may well get | |
| ```systemverilog | |
| assign gclk = clk & en; | |
| ```text | |
| This is exactly the circuit dissected in Part 3.1 of [Power Fundamentals and Clock Gating](/learn/hardware-interview-prep/power-fundamentals-and-clock-gating). It is broken, because `en` is a data signal that can settle anywhere in the cycle, and a change during the clock's high phase produces either a spurious rising edge or a runt pulse. The correct answer is an integrated clock gating cell with a low-transparent latch in front of the AND. The model's version is what tutorials show, so it is what the mechanism produces. | |
| Ask for a synchronizer for a bus crossing clock domains and you may get a two-flop synchronizer instantiated per bit. Each bit is individually correct. The **bus** is catastrophically wrong, because the bits resolve independently and you can sample a value that never existed on the source side. The correct constructions are gray coding, or a valid-with-hold handshake, or an asynchronous FIFO, all covered in [Clocking Reset and Domain Crossing](/learn/hardware-interview-prep/clocking-reset-and-domain-crossing). Again the wrong answer is the plausible one. A two-flop synchronizer is what "synchronizer" most often follows in text. | |
| Both of these share a property that makes them dangerous rather than merely wrong. **They simulate fine.** In RTL simulation with a zero-delay model, the AND-gate clock gate behaves acceptably and the per-bit synchronizer usually behaves acceptably. They fail in silicon, or in gate-level simulation with timing, or under a CDC checker. That is the exact class of bug this note's Part 5 exists to catch. | |
| **Failure two, anything needing a global view.** Estimate the scale. A mid-size block of 50,000 lines of SystemVerilog, at something on the order of ten to fifteen tokens a line, is roughly 500,000 to 750,000 tokens. Treat that ratio as a rough estimate rather than a measured constant. Even where a context window can hold that, the SoC around it cannot fit, and more to the point the model still does not have the timing report, the coverage database, or the elaborated netlist. Questions like "does this change break any path in the block" are not hard for a model because the model is weak. They are unanswerable from text alone by anything. | |
| **Failure three, hallucinated names and options.** The mechanism from 3.2 in its purest form. Synthesis has `set_max_transition`. A plausible-sounding neighbour may not exist. Your design has `axi_aw_valid`. The model writes `i_axi_awvalid` because that is a more common spelling in public code. These are the **cheapest** failures in the whole taxonomy, because a compiler, an elaborator, or the tool itself rejects them in seconds, provided somebody actually runs it. If nobody runs it, they are as expensive as any other bug. | |
| ### 3.5 The verification-shaped point, which is the strongest thing you can say | |
| Suppose, generously, that a model makes RTL authoring twice as fast. What has changed about verification? | |
| Nothing at all. The testbench still has to be written. The assertions still have to be written. The coverage model still has to be defined and closed. The formal properties still have to be proved. Lint, CDC, and reset-domain checks still have to be clean. Synthesis still has to run and timing still has to close. Power-aware simulation still has to walk every power-state transition per Part 8 of [Power Fundamentals and Clock Gating](/learn/hardware-interview-prep/power-fundamentals-and-clock-gating). **Generated RTL requires the entire existing verification apparatus, unchanged, because none of that apparatus was there to catch typos.** It was there to catch the design being wrong, and a design can be wrong regardless of who or what typed it. | |
| Now make it quantitative, because this is where the argument becomes convincing rather than merely sensible. It is a straight Amdahl argument, the same reasoning you already apply to critical paths. If a fraction $f$ of the project is sped up by a factor $s$, the overall speedup is | |
| $$S = \frac{1}{(1-f) + f/s}.$$ | |
| Say RTL authoring is 20 percent of project effort and AI doubles it. Then | |
| $$S = \frac{1}{0.8 + 0.2/2} = \frac{1}{0.9} = 1.11,$$ | |
| an eleven percent schedule improvement, and that is with a generous factor of two on the authoring itself. Now take verification, which is commonly quoted as 50 to 70 percent of ASIC project effort, a figure worth hedging, since it is repeated far more often than it is rigorously sourced. Say 55 percent, sped up by a much more modest 1.3: | |
| $$S = \frac{1}{0.45 + 0.55/1.3} = \frac{1}{0.873} = 1.15.$$ | |
| **A modest gain on the large fraction beats a large gain on the small one**, which is the same conclusion you would reach about optimizing a non-critical path. So if you are going to point these tools anywhere, point them at verification: testbench scaffolding, assertion generation from a written specification, coverage-hole enumeration, regression failure clustering and triage summaries, waveform-to-hypothesis narration, and the tedious reformatting and reporting work around a regression. | |
| That is also, not coincidentally, exactly where ChipNeMo's authors pointed theirs. | |
| ### 3.6 A productivity claim you can defend | |
| Do not say "it makes me twice as fast." You cannot support it, and the follow-up will expose that. | |
| Say instead what is specific and checkable. It collapses the time to a **first draft** of things whose shape is conventional and whose correctness is machine-checkable, and it is very good at the reading-comprehension tasks (explaining unfamiliar code, summarizing a long log, drafting documentation for something that already works). It is not reliable on anything whose correctness depends on the surrounding system, and the discipline that converts the first kind into real throughput is the subject of Part 5. | |
| --- | |
| ## Part 4, agentic workflows | |
| ### 4.1 What an agent is, mechanically | |
| Demystify it in one paragraph, because the word carries far more mystique than the mechanism deserves. | |
| An agent is a loop. The model proposes an action rather than an answer (run this command, read this file, apply this edit). A harness executes the action. The result comes back as text and is appended to the context. The model proposes the next action. Repeat until a stopping condition. | |
| That is all. The one important difference from a chat window is that **the model can observe consequences**. And that difference immediately kills an entire failure class. A hallucinated tool option no longer survives, because the tool returns an error and the error goes straight back into the context. The mechanism that produced the plausible-but-wrong option is unchanged. What changed is that reality now gets a vote. | |
| A concrete five-step trace from ordinary use, which is small enough to check and is exactly the shape of the work: | |
| 1. Edit a LaTeX source file. | |
| 2. Run the build. It exits non-zero with an error at line 412. | |
| 3. Read line 412 and its surroundings. | |
| 4. Apply a fix. | |
| 5. Run the build. It exits zero. | |
| Nothing in that trace requires intelligence in any grand sense. It requires the ability to read an error message and act on it, in a loop, without getting bored. That is the same property that made the optimizer in 2.5 valuable, arriving in a different domain. | |
| ### 4.2 The loop is only as good as its gate | |
| Here is the failure that the enthusiasm around agents systematically hides. | |
| An agent optimizes for whatever ends the loop. If the stopping condition is "the build exits zero," the agent converges on something that **builds**. A document that builds cleanly can still say something false. RTL that elaborates cleanly can still be functionally wrong. If the gate is `make` returning success, you have automated your way to a compiling artifact and learned nothing about whether it is correct. | |
| This is precisely the lesson from [Verification Methodology](/learn/hardware-interview-prep/verification-methodology) about coverage versus correctness, arriving with new nouns. A passing regression proves what the regression checks. So the engineering question about an agentic workflow is never "how capable is the model," it is **"what does the gate check, and is that the property I care about?"** A candidate who reaches for that question unprompted has said something an interviewer in this area will remember. | |
| ### 4.3 Parallel sweeps and where they help | |
| The second thing an agentic harness buys is parallelism, and the constraint on it is the one you already know from hardware. Independent subtasks can run concurrently. Dependent ones cannot without a hazard. | |
| The pattern that works is to decompose a task into subtasks with no shared mutable state, dispatch them concurrently, and merge the results through a structure a human owns. Research sweeps fit this perfectly, because investigating twelve unrelated questions is twelve independent episodes. So does regression triage, where a hundred failures cluster into a handful of root causes and the clustering is embarrassingly parallel. So does a design-space sweep, which is 2.5 wearing agentic clothes. | |
| The pattern that fails is any decomposition where two subtasks write the same artifact, because you get exactly the write-after-write hazard you would expect and neither agent knows the other exists. The mitigation is the same as in hardware. Partition the state so that each worker owns its own region, and serialize the merge. | |
| ### 4.4 Where agents fail, with the arithmetic | |
| Long horizons compound error, and the arithmetic is brutal enough to be worth doing. | |
| Suppose each step of an agentic task succeeds with probability 0.97, which sounds excellent. A thirty-step task then succeeds end to end with probability | |
| $$0.97^{30} = 0.401,$$ | |
| so it fails about sixty percent of the time. To get a thirty-step task to 90 percent end-to-end you would need per-step reliability of | |
| $$0.9^{1/30} = 0.9965,$$ | |
| which is 99.65 percent. That is a much harder engineering target than it looks, and waiting for a better model to supply it is not a plan. | |
| The fix is not a better model, it is **checkpointing**, and hardware people recognize it instantly because it is retry at a pipeline boundary rather than restart from the top. Break the thirty steps into six segments of five with a verified gate between segments. Each segment succeeds with probability $0.97^5 = 0.859$, so the expected number of attempts per segment is $1/0.859 = 1.16$, and the expected total work is | |
| $$6 \times 1.16 \times 5 = 35 \ \text{steps.}$$ | |
| Compare with retrying the whole thirty-step task from scratch, which needs $1/0.401 = 2.49$ attempts on average, or | |
| $$2.49 \times 30 = 75 \ \text{steps.}$$ | |
| Checkpointing more than halves the expected work, and it does so without improving the model at all. **That is a design insight, not a tooling preference**, and it is the single most transferable thing in this part. | |
| Two other failure modes deserve naming. Agents are prone to **agreeing with themselves**. Ask a model whether its own output is correct and the answer skews positive, which is why the gate has to be external and mechanical rather than a second opinion from the same source. And agents accumulate context, so a long session drifts, because early constraints get diluted by thousands of tokens of intermediate output. The mitigation is the same: short segments, a fresh start per segment, and the specification re-supplied each time rather than remembered. | |
| --- | |
| ## Part 5, the discipline that makes it work | |
| This is the part where the practice is genuinely ahead of the average candidate, and it is the part to lead with in an interview, because it is the part that is about engineering rather than about tools. | |
| ### 5.1 Generated output is a proposal, not an answer | |
| The single mental shift that makes all of this safe is refusing to treat generated output as an answer. It is a **proposal**, and proposals are things you evaluate. | |
| This is not a novel discipline. It is exactly how you already treat a synthesis result. The tool proposes a netlist. You do not ship it because the tool produced it. You run timing, power, lint, formal equivalence, and DRC against it. The tool is trusted as a *generator* and distrusted as an *authority*, and the entire flow you own is the machinery of that distrust. Point the same posture at a language model and almost every problem in Part 3 becomes tractable. | |
| Say it in those words in an interview. **"I treat it the way I treat a synthesis result. I trust it to produce a candidate, and I trust the flow to tell me whether the candidate is any good."** That sentence does more work than any amount of enthusiasm, because it says the thing you already know how to do maps onto the new thing. | |
| ### 5.2 The gate must be automated, and here is why | |
| Why not simply review everything by hand? Because the arithmetic does not work. | |
| If a human must read and genuinely check every generated line before it counts, then throughput is capped by human reading speed, not by generation speed. And careful review of RTL is for many engineers **slower than writing it**, once you count reading it against a specification, thinking about the corner cases, and checking the reset behaviour and the protocol contract. So a workflow whose only gate is human review converts a generation speedup into no speedup at all, and possibly into a slowdown plus a new class of subtly-wrong code that got waved through because it looked fine. | |
| The only structure that works is **machine-check first, human-review what survived.** The gate runs lint, elaborates, simulates the directed and random tests, evaluates the assertions, runs the formal properties where they exist, runs the CDC and reset-domain checks, and runs synthesis far enough to see that it is implementable. Anything that fails goes back with the error text attached, which is the loop of 4.1. Only the survivors reach a human, and the human then spends their expensive attention on the thing machines cannot check, which is whether it does what the specification meant. | |
| <Figure src="/figures/hardware-interview-prep/iv-38-AI-Assisted-Design-Workflows-fig03.svg" alt="The specification is human-owned and sits outside the loop. Everything generated re-enters the loop until the automated gate passes, and only survivors reach human review, because human attention is the scarce resource and must be spent on intent rather than on syntax." caption="The specification is human-owned and sits outside the loop. Everything generated re-enters the loop until the automated gate passes, and only survivors reach human review, because human attention is the scarce resource and must be spent on intent rather than on syntax." id="fig:38-AI-Assisted-Design-Workflows-3" /> | |
| ### 5.3 The specification stays human-owned | |
| The gate is necessary and not sufficient, because a gate can only check against something. If the only statement of what the design is supposed to do lives inside a conversation, then there is no ground truth, and the design drifts toward whatever the model most recently said. | |
| So the specification is written by a human, stored as a durable artifact, version controlled, and treated as the authority in every disagreement. When the model produces a bare AND gate and the specification says the enable must be latched through a low-transparent latch, **the specification wins and the model is wrong**, and that adjudication has to be mechanically possible. | |
| There is a stronger version of this that is worth knowing because it is where the two halves of your background meet. If the specification is expressed as **assertions and formal properties**, then the adjudication is not a human reading two documents, it is a tool proving or disproving a property. That is the highest-value place to spend specification effort in an AI-assisted flow, and it is the direct answer to "what would you do differently if a lot of your RTL were generated." You would push more of the specification into machine-checkable form, because the volume of things needing checking went up and the cost of checking mechanically did not. | |
| ### 5.4 Structuring a codebase so a model can navigate it | |
| Performance-modelling roles of this vintage explicitly name structuring a model codebase for AI-assisted development, so this is not a hypothetical concern, it is a named responsibility. It is also, pleasingly, indistinguishable from good engineering hygiene, which is the disarming thing to say about it. | |
| What actually helps, and why each item helps: | |
| **One concept per file, with a name that says what it is.** A model finds code the same way `grep` does, by matching names. A file called `utils.py` is invisible to retrieval. A file called `dram_timing_tracker.py` is findable. | |
| **An index document that maps the repository.** A short file naming every directory and what lives in it. This is the single highest-leverage artifact, because it converts a search problem into a lookup. | |
| **Interface contracts stated in text next to the code.** What this function assumes, what it guarantees, what units its arguments are in. A model reading a function with a stated contract can check its own proposal against the contract. A model reading an undocumented function guesses. | |
| **Small modules with explicit interfaces and no hidden global state.** Hidden state is exactly the thing a windowed reader cannot see, so it is exactly the thing that produces confidently wrong edits. | |
| **A machine-runnable check per unit, fast enough to run constantly.** This is 5.2's gate at the granularity where it is cheap. If the unit test for a module runs in two seconds, the loop of 4.1 closes in two seconds. | |
| **Conventions applied uniformly.** Uniformity means the most plausible continuation is also the correct one, which turns the mechanism of 3.1 from an enemy into an ally. | |
| Every one of those is something a good engineer wants anyway for human readers. The honest framing, and the one that will land best, is **"structuring a codebase for AI-assisted development is mostly the same work as structuring it for a new team member who joins on Monday, with the difference that the model reads a smaller window and never asks a clarifying question, so the discipline has to be tighter."** | |
| ### 5.5 What this looks like in practice, concretely | |
| The reason this part is the strongest in the note is that it is not theory here. | |
| The practice is a single version-controlled engineering hub with a root instruction file, a companion state-and-history file, per-subproject instruction and state files, and a README that maps the whole tree, precisely the index structure of 5.4. It carries a set of encoded procedures for repeatable tasks, so that a recurring workflow is executed the same way every time instead of being re-improvised. Agent-based workflows are used daily inside it for real technical work: multi-agent research sweeps of the kind in 4.3, automated document generation, and a build-and-verify discipline applied to LaTeX manuscripts and long technical notes, where the gate is the actual build plus a review pass rather than the author's satisfaction with how the text reads. | |
| The most checkable example available is the one you are reading. **This note set was produced with exactly that workflow**, and it is the right example to offer because it can be inspected. It has an index note, a consistent structure per note, cross-references that resolve, a per-note prerequisite declaration, hedging where facts were uncertain, and an explicit sourcing policy of the kind at the top of this file. Those are not decorations. They are the artifacts of the discipline in 5.1 through 5.4 applied to writing instead of to RTL. | |
| Two disciplines worth naming when you describe it, because they are the parts that show judgment rather than enthusiasm. The first is that **uncertainty is hedged in the text rather than resolved by invention**. A hedged sentence is acceptable, a confident wrong number is a defect. The second is that the material is **checked against public primary sources** rather than against the model's recollection, which is the retrieval principle of 3.1 applied by hand. | |
| --- | |
| ## Part 6, data, security and IP hygiene | |
| This is the question a hardware interviewer **will** ask, and it is the one most candidates fumble, usually by answering with a policy they half-remember instead of with the mechanism. Get the mechanism right and the policy answer becomes obvious. | |
| ### 6.1 What actually crosses the boundary | |
| Be concrete about what leaves your machine, because vagueness here reads as not having thought about it. | |
| Three things cross. **The prompt**, meaning everything you typed. **Everything the tool read on your behalf**, and with an agentic harness this is the big one, because a tool that greps a repository and pastes matches into context has moved that source across the boundary whether or not you looked at it. And **the outputs the tool captured**: compiler errors, simulation logs, waveform dumps converted to text, tool reports. A synthesis log can contain module names, hierarchy, cell counts, and timing paths. It is not obviously sensitive until you notice it describes your microarchitecture. | |
| The framing sentence is the one to say out loud. **The risky operation is not "using AI," it is moving text across a trust boundary, and an agentic tool moves far more text than you typed.** | |
| ### 6.2 Local versus hosted, and the middle ground | |
| <Figure src="/figures/hardware-interview-prep/iv-38-AI-Assisted-Design-Workflows-fig04.svg" alt="Three deployment shapes with three different answers to the only question that matters, which is where the tokens end up. The middle tier is where most large employers actually land, and knowing that it exists is what separates a considered answer from a slogan." caption="Three deployment shapes with three different answers to the only question that matters, which is where the tokens end up. The middle tier is where most large employers actually land, and knowing that it exists is what separates a considered answer from a slogan." id="fig:38-AI-Assisted-Design-Workflows-4" /> | |
| **Locally-run** means the model's weights sit on hardware you or your employer control and inference happens there. Tokens never leave. The cost is capability and infrastructure. You are limited to models you can host, and you have to host them. | |
| **Hosted** means the tokens travel over a network to a third party who runs the model. Faster to adopt, generally more capable, and the data has left. | |
| **The middle tier is where most large employers actually land**, and knowing it exists is what makes an answer sound considered. Enterprise agreements with contractual terms on training, retention, and tenancy. Private deployments inside a company's own cloud tenancy. On-premises deployments of vendor models. NVIDIA's ChipNeMo is the published example of the furthest version of this (build and adapt your own model on your own data), and both the domain-quality and the data-control motivations are cited in that line of work. | |
| Notice that the EDA vendors' 2026 agentic offerings are being announced with named cloud platforms and named customers, which tells you the industry answer to this is contractual and architectural rather than abstinent. | |
| ### 6.3 Why the policies exist | |
| Because it has already gone wrong publicly and the case is well documented. In 2023, within weeks of Samsung Semiconductor permitting employees to use ChatGPT, multiple separate incidents were reported in which engineers pasted confidential material into it (proprietary source code while debugging, an internal test sequence, and a transcript of a confidential meeting being turned into notes). Samsung restricted generative AI tools internally in response and said it would pursue an internal system with proper controls. | |
| Three things about that story are worth extracting, and all three are more useful than the headline. | |
| **Nobody was being reckless.** Each of those three uses is a completely reasonable engineering instinct: debug this, optimize this, summarize this. The failure was not judgment, it was that the tool's boundary was invisible at the moment of use. | |
| **The meeting-notes case is the one people miss.** It was not code. Most engineers who would never paste RTL into a web form will happily paste a design-review transcript, and the transcript may contain more unreleased microarchitecture than the code would. | |
| **The response was a policy plus a plan to build an internal capability**, not a permanent ban. That is the shape of nearly every large employer's answer, and describing it that way shows you understand the actual industry posture rather than a caricature of it. | |
| ### 6.4 How to talk about it, in four sentences | |
| The posture that works, and the order matters. | |
| First, **the rule**. Proprietary RTL, unreleased microarchitecture, unfiled invention material, and confidential design discussions do not go into any external service, full stop. Second, **the mechanism**, which is what separates you from someone reciting a rule. You know what a prompt contains, you know that an agentic tool reads files you did not individually approve, and you know that logs and reports carry design information. Third, **the deference**. You would use whatever tooling the employer has approved and expect there to be a policy, and if there is not one yet you would want to help write it rather than proceed on your own judgment. Fourth, **your own position**, stated plainly and without hedging. | |
| That fourth one is clean and you should say it in exactly this shape. **"My own practice is entirely on personal projects and public data. My own hub, my own study material, published specifications and open-source repositories. None of it touches employer material, and that constraint is written into the project's own rules rather than being something I keep in my head."** A written policy is a stronger claim than a verbal assurance and it is checkable, which is the whole point. | |
| ### 6.5 The two adjacent issues worth knowing exist | |
| **Provenance of generated code.** Code generated by a model trained on public repositories raises questions about licence contamination that most large employers have taken a position on, usually through tooling that flags near-duplicates of known open-source code. You do not need a legal opinion. You need to know the question exists and that it is answered by the employer's counsel, not by you. | |
| **Export control and program-specific restrictions.** Some programs carry restrictions that go beyond ordinary confidentiality and that constrain where data may be processed and by whom. Again the correct depth is knowing that this class of constraint exists and defers to the employer, and I would not go further than that without knowing the specific programme. | |
| --- | |
| ## Part 7, answering "how do you use AI in your work" | |
| ### 7.1 The four beats | |
| The question will be asked, in one of its forms, in at least six of the conversations ahead. Answer it in four beats and it will be better than nearly every answer the interviewer hears that week. | |
| **Beat one, a specific workflow, not a category.** Not "I use it for coding." A named task, in a named context, with a named artifact. | |
| **Beat two, the gate.** What catches it when it is wrong. This is the beat everyone skips and it is the beat that establishes you as an engineer rather than an enthusiast. | |
| **Beat three, where you do not use it, and why.** A boundary shows judgment. An unbounded claim shows the absence of it. | |
| **Beat four, something checkable.** One number, or one artifact you could show, or one concrete instance of it being wrong and being caught. | |
| ### 7.2 The two failure modes, named | |
| **The hype merchant.** "It writes most of my code now, it has made me three times faster, it is going to change everything." The interviewer's next question is the one that kills it. *"What did it get wrong last week?"* Anyone who has genuinely worked this way has three answers ready. Anyone who has not, has none, and the silence is the whole evaluation. | |
| **The dismisser.** "I tried it, it hallucinated, I do not use it." In a year when a role lists this as a responsibility, that reads as incuriosity, and it also implicitly criticizes a decision the hiring team has already made. It is the worse of the two errors for exactly that reason. | |
| The calibrated position sits between them and is genuinely the truth. **Be specific about where it helps, specific about where it fails, and disciplined about the boundary between them.** | |
| ### 7.3 A worked answer, roughly ninety seconds | |
| Adapt the nouns. Keep the structure. | |
| > "I use it daily, but in a fairly disciplined way, so let me describe the shape rather than just say yes. | |
| > | |
| > The main thing I run is an agent-based workflow over a personal engineering repository. It handles multi-step tasks (research a topic across a set of public sources, draft a long technical document, then build and check it), and the key part is that nothing is accepted because it looks right. There is a build-and-verify step that runs before any change is accepted, and anything that fails goes back with the error attached. The specification of what the document is supposed to contain is mine and written down. The model does not get to amend it. | |
| > | |
| > The reason I structure it that way is that the failure mode I care about is not the obvious one. Wrong tool options and wrong identifiers are cheap, because a compiler catches them instantly. The expensive one is output that is plausible and subtly wrong. If you ask for a clock gate you can get a bare AND of clock and enable, which is a textbook broken circuit, and it simulates fine at RTL. It fails in silicon. So the gate has to check the property, not the syntax. | |
| > | |
| > Where I do not use it is anything involving my employer's material. Proprietary RTL, unreleased microarchitecture, and unfiled invention work never go into an external service, and my personal practice is deliberately confined to my own projects and public data. | |
| > | |
| > The checkable version of all this is that I built a set of close to forty long technical study notes this way, with an index, cross-references, and an explicit rule that uncertain facts get hedged rather than invented. I would be happy to walk through how the verification loop on that actually works." | |
| Four beats, a real failure named, a boundary stated, and an artifact offered. Note that the clock-gate example does double duty. It demonstrates calibration about the tools **and** it demonstrates that you know what an integrated clock gating cell is, which is a technical credential smuggled into a methodology answer. | |
| --- | |
| ## Part 8, the interview questions, with answers | |
| Fourteen questions of the kind actually asked when a role names this subject, each with a model answer written the way a strong candidate would speak it, the follow-up the interviewer reaches for next, and the trap where there is one. These are shorter than the answers in the other notes because the honest answers here are shorter. Read them out loud. | |
| ### Q1. How do you use AI in your work? | |
| **Model answer.** Part 7.3 is the answer, spoken. Name the workflow, name the gate, name the boundary, offer the artifact. | |
| The one adjustment worth making on the fly is to the **register** of the first sentence. If the interviewer asked casually, answer casually and briefly and let them pull. If they asked in the context of a role that lists this as a responsibility, go straight to the workflow and the gate, because they are evaluating rather than making conversation. | |
| **The follow-up.** "What did it get wrong recently?" | |
| Have three ready, and pick the one closest to their domain. A hallucinated tool option, caught by the tool erroring, which is the cheap class. A wrong identifier that looked exactly like the right identifier, caught by elaboration. And one substantive one, a construct that was plausible, that simulated, and that was wrong for a reason requiring domain knowledge, such as the bare AND clock gate or the per-bit bus synchronizer from Part 3.4. The third one is the answer that lands, because it shows you caught something the machine could not. | |
| **The trap.** Having no failure to name. It is the single fastest way to reveal that the practice is claimed rather than real, and interviewers ask it precisely for that reason. | |
| ### Q2. Where does AI genuinely help in a silicon flow today, and where is the marketing ahead of the evidence? | |
| **Model answer.** I would separate three things, because they get conflated and they have completely different evidence behind them. | |
| The first is machine learning inside the tools, design-space exploration and tool-parameter search. That is real and shipping, the commercial products have public tape-out counts, and the mechanism is easy to believe because the thing being automated is a search over a space that is far too large to enumerate and far too expensive to evaluate exhaustively. Six knobs at five values is fifteen thousand configurations. Nobody sweeps that, so today a senior engineer tries four points and ships the best. An optimizer that tries two hundred is straightforwardly better and it is better for a boring reason, which is that it does not get bored. | |
| The second is language models on the text artifacts, meaning RTL, testbenches, scripts, docs, triage. Genuinely useful and genuinely uneven, and the public benchmarks overstate it because they measure small self-contained modules. | |
| The third is agentic workflows that chain steps together. Newest, most interesting to me personally, and the one where almost every number in circulation is vendor-reported. | |
| Where the marketing runs ahead is any claim of the form "AI designs chips." Nothing published designs a microarchitecture, chooses a pipeline depth, or writes a specification. And the most publicized single result, reinforcement learning for macro placement, is genuinely contested in public, which I think is worth knowing rather than repeating. | |
| **The follow-up.** "What would convince you that a claim in this area is real?" | |
| Two things. An independent replication rather than a vendor benchmark, and a measurement on the **signoff** metric rather than on the proxy the optimizer was trained against. Those are also the two questions that make the placement dispute comprehensible, so they generalize. | |
| **The trap.** Giving one enthusiastic undifferentiated answer. The question is a calibration test and the differentiation is the answer. | |
| ### Q3. What do you make of reinforcement learning for placement? | |
| **Model answer.** I would say the history plainly, because it is instructive. | |
| Google published a *Nature* paper in 2021 claiming a deep reinforcement learning approach produced macro placements comparable to or better than human experts in under six hours. It got a great deal of attention. It was then challenged. A UC San Diego group including Kahng published an open reimplementation and assessment at ISPD in 2023 comparing it against simulated annealing, an academic placer, a commercial placer and human placement, and reported that it did not outperform them. A separate critique argued that key methodology and inputs were withheld. *Nature* added an editor's note in September 2023, the accompanying commentary was retracted, and in September 2024 an addendum was published supplying more methodological detail and the editor's note was removed at the same time. The Google authors published a rebuttal. The paper itself was not retracted, and the critique has since picked up an expression of concern of its own at ACM. | |
| My reading is that this is unsettled in public rather than settled either way, and the mechanism of the disagreement is the interesting part. Reinforcement learning needs thousands of episodes, and a full place-and-route plus timing run per episode is impossible. Ten thousand episodes at eight hours is nine years of serial compute. So every practical system trains against a cheap proxy reward. That makes proxy fidelity the whole question. You can win on the proxy and lose after routing. Combine that with the fact that baseline strength dominates any comparison of heuristics, and you have exactly the two axes the dispute is on. | |
| **The follow-up.** "So would you use it?" | |
| I would evaluate it the way I would evaluate any new tool in a flow I owned: run it against my existing best-tuned flow on my own designs, measure on post-route signoff numbers rather than on the tool's own objective, and count total compute as part of the cost. That is not scepticism about machine learning, it is the same evaluation I would run on a new placer from any vendor. | |
| **The trap.** There are two, symmetric. Saying "Google's AI beat human chip designers" reveals you read a headline in 2021 and stopped. Saying "that was debunked, it was retracted" is factually wrong about the retraction and reveals you read a different headline and stopped. The credible answer names the dispute and the mechanism. | |
| ### Q4. Would you let a language model write RTL for a production block? | |
| **Model answer.** For parts of it, under a gate, yes. For the block, no, and the reason is not about trust, it is about where the correctness lives. | |
| The parts where I would use it happily are the ones where the shape is conventional and the correctness is machine-checkable: a parameterized FIFO skeleton, a register block from a register description, a decoder, the scaffolding of a testbench, the boilerplate of an interface. Those are dense in the training data and cheap to check. | |
| The parts where I would not are the ones where correctness depends on properties the model cannot see. Anything where the timing matters, anything crossing clock domains, anything where the protocol contract lives in a block the model is not looking at, anything where the answer depends on the whole design rather than on this file. | |
| Concretely, two things I would expect to have to catch. Ask for a clock gate and you can get a bare AND of clock and enable, which is broken because the enable is a data signal and any change during the high phase gives you a spurious edge or a runt pulse. Ask for a bus synchronizer and you can get a two-flop synchronizer per bit, where each bit is right and the bus is wrong because the bits resolve independently. Both of those simulate acceptably at RTL. They fail in silicon or under a CDC checker. That is the class I actually worry about, not the typos. | |
| **The follow-up.** "If the code is generated, does verification get easier?" | |
| No, it gets more important and it does not change at all in kind. The testbench, the assertions, the coverage closure, the formal properties, lint, CDC, synthesis and timing were never there to catch typos, they were there to catch the design being wrong, and a design can be wrong regardless of who typed it. If anything I would push more of the specification into assertions and formal properties, because the volume of things needing checking went up and the cost of checking them mechanically did not. | |
| **The trap.** Answering "no, never" or "yes, it is fine." The interesting content is the boundary and the reason for it. | |
| ### Q5. Tell me about a time it was confidently wrong and you caught it. | |
| **Model answer.** Give a real one, with the mechanism of the catch. | |
| The pattern worth telling has four parts: what was asked for, what came back, why it looked right, and what caught it. The best story is one where the catch was **mechanical**, because that demonstrates the gate rather than your vigilance, and vigilance does not scale. | |
| Here is a representative one from my own practice. I asked for content in a technical document and got a confidently stated figure with a plausible attribution. It did not survive checking against the primary source, and the reason it looked right is that a number of that magnitude in that context is entirely plausible. What caught it was a rule I apply rather than an instinct I had. Every quantitative claim gets checked against a public primary source before it is accepted, and anything that cannot be checked gets hedged in the text instead of stated. The general principle is that **a hedged sentence is acceptable and a confident wrong number is a defect**, and once that is a rule rather than a preference it catches things independently of how tired I am. | |
| **The follow-up.** "How do you know you caught all of them?" | |
| I do not, which is why the answer is a policy rather than a claim. Anything I could not verify is visibly hedged in the text, so the reader can see exactly where the uncertainty is. That is the same reason a design review flags known-marginal paths rather than asserting the design is clean. | |
| **The trap.** Telling a story where the catch was that you happened to notice. That says the process depends on your attention, which is exactly the thing that fails at volume. | |
| ### Q6. If AI doubles RTL authoring speed, how much sooner does the chip tape out? | |
| **Model answer.** This is Amdahl's law, and the answer is much less than people expect. | |
| If a fraction $f$ of the effort speeds up by $s$, the overall speedup is $1/((1-f) + f/s)$. If RTL authoring is twenty percent of project effort and it doubles, that is $1/(0.8 + 0.1) = 1.11$, so eleven percent, and that is with a generous factor of two. | |
| Now put the same tool on verification. Verification is commonly quoted as something like half to two thirds of ASIC project effort, and I would hedge that figure because it is repeated much more often than it is carefully sourced. Take fifty-five percent and a much more modest speedup of 1.3, and that is $1/(0.45 + 0.423) = 1.15$, fifteen percent, from a far smaller improvement. | |
| So a modest gain on the large fraction beats a large gain on the small one, which is the same conclusion I would reach about optimizing a path with slack. The design conclusion is that if I were deciding where to point these tools in an organization, I would point them at verification (testbench scaffolding, assertions from a written spec, coverage-hole enumeration, regression triage and failure clustering) rather than at RTL authoring, and I would be suspicious of a plan that did the opposite. | |
| **The follow-up.** "What would you measure to know whether it worked?" | |
| Not lines generated and not developer satisfaction, because both go up regardless. I would measure the things that already exist in the project's own metrics: time from RTL freeze to regression clean, number of respins of a block, escape rate to the next verification stage, and coverage closure rate. If the tool is helping, those move. If they do not move, it is a pleasant experience rather than a productivity gain, and I would want to be honest about that distinction. | |
| **The trap.** Accepting the premise and multiplying. The question is testing whether you apply the quantitative reasoning you already have to a topic where people usually stop applying it. | |
| ### Q7. Our RTL is proprietary. How do you use these tools without leaking it? | |
| **Model answer.** I would start by being precise about what actually crosses the boundary, because the rule follows from that and most people state the rule without the mechanism. | |
| Three things leave: what I typed, everything the tool read on my behalf, and the tool outputs it captured. The second one is the big one with an agentic tool, because a tool that searches a repository and pulls matches into context has moved that source whether or not I looked at it. The third is the one people forget. A synthesis log carries hierarchy, module names, cell counts and timing paths, and that describes the microarchitecture even though it is not code. | |
| So the operating rule is that proprietary RTL, unreleased microarchitecture, unfiled invention material, and confidential design discussions never go into an external service. In practice that means I would use whatever the company has approved, and I would expect there to be a policy, because every large employer has been through this. If the answer is a locally hosted or contractually bounded deployment, that is a different risk profile and I would use it inside whatever scope is approved. | |
| I would also say plainly that my own practice is on personal projects and public data (my own repository, published specifications, open-source material) and that this is written into the project's own rules rather than being a habit I maintain by memory. | |
| **The follow-up.** "Why do you think companies have these policies?" | |
| Because it has gone wrong publicly. In 2023 Samsung Semiconductor reportedly had several incidents within weeks of permitting a public chatbot: source code pasted in during debugging, a test sequence, and a confidential meeting transcript being turned into notes. What I take from it is that none of those three was reckless. Each is a completely natural engineering instinct. The failure was that the boundary was invisible at the moment of use, which is why the answer has to be a policy plus tooling rather than an appeal to everyone being careful. | |
| **The trap.** Saying "I would just be careful." That is exactly the answer the Samsung case refutes, and it signals that you are thinking about intent rather than about mechanism. | |
| ### Q8. What is the difference between a locally-run model and a hosted one, and when does the difference matter? | |
| **Model answer.** Locally run means the weights are on hardware you control and inference happens there, so no tokens leave. Hosted means the tokens travel to a third party. The trade is capability and convenience against data control. | |
| But the important part of the answer is that it is not a binary. The middle tier is where most large employers actually land. It might be an enterprise agreement with contractual terms on training, retention and tenancy. It might be a private deployment inside the company's own cloud tenancy. It might be an on-premises deployment of a vendor model. NVIDIA's published ChipNeMo work is the furthest version of the same instinct (adapt your own models on your own domain data), and both data control and domain quality show up in the stated motivation. | |
| The reason to know the middle tier exists is that it is the shape of the real answer. A candidate who thinks the only options are "public chatbot" or "nothing" has not looked at what companies actually do, and the EDA vendors' current agentic offerings, which are being announced with named cloud platforms and named silicon customers, are the evidence. | |
| **The follow-up.** "Which would you recommend for a design team?" | |
| I would not recommend without knowing the constraints, and I would say so. The questions I would ask are what the data classification of the material is, whether there is an existing approved deployment I should be using rather than proposing a new one, what the latency and throughput requirements are, and whether domain adaptation on internal data is on the table, because that changes the calculus substantially. I would be wary of proposing infrastructure in an interview for a design role, since that decision belongs to people with information I do not have. | |
| **The trap.** Confusing "hosted" with "insecure" and "local" with "safe." A local deployment with no access controls on a shared machine is not obviously better than a contractually bounded private tenancy. The property that matters is who can read the tokens, not where the GPU is. | |
| ### Q9. Where would you apply this in verification specifically? | |
| **Model answer.** Verification is where I would point it first, for the Amdahl reason. It is the biggest fraction of the schedule, so a modest gain there beats a large gain on RTL authoring. | |
| Four places, roughly in order of how confident I am. | |
| **Triage and summarization.** A regression with a hundred failures usually has a handful of root causes. Clustering failures by signature, summarizing what a long log says, and producing a first-pass narrative of what a waveform shows are tasks where the output is a hypothesis that a human immediately checks, so the cost of being wrong is low and the time saved is real. This is also one of the three applications NVIDIA's published ChipNeMo work chose, which I take as a signal. | |
| **Testbench and scaffolding generation.** Stimulus generators, scoreboards, the boilerplate around a new agent. Conventional shapes, machine-checkable. | |
| **Assertions from a written specification.** This one is interesting because it inverts the usual concern. Normally I worry about generated artifacts needing verification. An assertion is not a design artifact, it is a check, so a wrong assertion fails loudly rather than shipping silently. It either fires on correct behaviour, which you notice immediately, or it is vacuous, which a vacuity check catches. That asymmetry makes it a comparatively safe target. | |
| **Coverage-hole enumeration and documentation.** Reading a coverage report and proposing which scenarios are missing, and writing the verification plan documentation that nobody wants to write. | |
| Where I would not use it is deciding what the coverage model should be, because that is a statement about what the design is supposed to do, and that stays human. | |
| **The follow-up.** "Does an AI-written assertion count as verification?" | |
| Only if it is independent of the thing it checks. The same principle as a reference model. If the checker's understanding came from the same source as the design's, a shared misunderstanding is invisible. So an assertion generated from the **specification** is legitimate, and an assertion generated from the **RTL** is close to circular. It will faithfully assert whatever the RTL happens to do, including the bug. That distinction is the whole answer and it is the one I would want to be sure of before adopting the practice. | |
| **The trap.** Reaching for RTL generation as the first answer. Verification is the bigger fraction and the safer target, and saying so shows you did the arithmetic instead of following the marketing. | |
| ### Q10. What does an automated verification gate for generated output have to check, and what does it prove? | |
| **Model answer.** It has to check the property you care about, and it proves exactly what it checks and nothing more. That sounds trite until you see how gates actually get built, because the default gate is "it compiles," and an agent optimizing against "it compiles" converges on something that compiles. | |
| For RTL the gate is the flow you already have: lint, elaborate, simulate the directed and constrained-random tests, evaluate the assertions, run formal where properties exist, run CDC and reset-domain checks, and synthesize far enough to know it is implementable. Anything failing goes back with the error text attached, which is what makes the loop close automatically. | |
| The two design decisions in building one are worth naming. First, **the gate must be independent of the generator**, for the same reason a checker's counter must be independent of the design's counter. Otherwise a shared misunderstanding hides itself. Asking the model whether its own output is correct is not a gate. Second, **the gate has to be fast enough to run constantly**, because the value comes from closing the loop in seconds, not from a nightly regression. That usually means a tiered gate: a two-second unit check per module, a two-minute block check, and the full regression on a slower cadence. | |
| And the honest limit is that the gate cannot check intent. It can prove the design does what the assertions say. It cannot prove the assertions say what the specification meant. That is what human review is for, and it is why human attention should be spent there rather than on syntax. | |
| **The follow-up.** "How is that different from what you already do?" | |
| Structurally it is not, which is the point, and I would say so directly. It is my existing verification flow with a new kind of input and a much higher rate of proposals arriving at it. What changes is throughput and therefore priorities: the checks have to get faster, more of the specification wants to be in machine-checkable form, and the human review budget shifts from reading code to reasoning about intent. | |
| **The trap.** Describing the gate as a code review. A code review is a human process with human throughput, and if it is the only gate then the generation speedup does not convert into anything. | |
| ### Q11. What is an agent, mechanically, and why do long agentic tasks fail? | |
| **Model answer.** Mechanically it is a loop with no mystery in it. The model proposes an action instead of an answer, a harness executes the action, the result comes back as text, and the model proposes the next action. The only important difference from a chat window is that the model observes consequences, which kills an entire failure class immediately. A hallucinated tool option no longer survives, because the tool errors and the error goes back into the context. | |
| Long tasks fail because errors compound multiplicatively. If each step succeeds with probability 0.97, which sounds excellent, a thirty-step task succeeds with probability $0.97^{30}$, which is about 0.40. To get a thirty-step task to ninety percent you need per-step reliability of $0.9^{1/30}$, about 99.65 percent, which is a much harder target than it looks. | |
| The fix is not a better model, it is checkpointing, and it is retry at a pipeline boundary rather than restart from the top. Break thirty steps into six verified segments of five. Each segment succeeds at $0.97^5 = 0.86$, so it takes 1.16 attempts on average, and the expected total work is about thirty-five steps. Retrying the whole task from scratch takes $1/0.40 = 2.5$ attempts at thirty steps each, so about seventy-five. Checkpointing more than halves the expected work without improving the model at all. | |
| **The follow-up.** "What else fails?" | |
| Two things. Agents agree with themselves. Ask a model to check its own work and the answer skews positive, so the gate has to be external and mechanical. And long sessions drift as context accumulates, because early constraints get diluted by thousands of tokens of intermediate output. Both point at the same mitigation, which is short segments with a fresh start and the specification re-supplied rather than remembered. | |
| **The trap.** Treating the reliability problem as something that will be solved by the next model release. Even at 99.65 percent per step, a three-hundred-step task is back to 35 percent. Composition is the structural issue and it wants a structural answer. | |
| ### Q12. How would you structure a model codebase so it is amenable to AI-assisted development? | |
| **Model answer.** Mostly the same way I would structure it for a new team member joining on Monday, with the difference that the model reads a smaller window and never asks a clarifying question, so the discipline has to be tighter. | |
| Concretely: one concept per file with a name that says what it is, because retrieval finds code by name and a file called `utils` is invisible. An index document mapping the repository, which is the highest-leverage single artifact because it turns a search problem into a lookup. Interface contracts written next to the code (what this assumes, what it guarantees, what units the arguments are in), so a proposal can be checked against the contract rather than guessed at. Small modules with explicit interfaces and no hidden global state, because hidden state is exactly what a windowed reader cannot see and therefore exactly what produces confidently wrong edits. A fast machine-runnable check per unit, so the propose-verify loop closes in seconds. And conventions applied uniformly, which matters for a subtle reason. A language model produces the most plausible continuation, so if your codebase is internally consistent the most plausible thing is also the correct thing. | |
| I would be honest that none of that is new engineering advice. It is standard hygiene, and the reason it is worth restating is that the cost of not doing it changed. Inconsistent naming used to cost a new hire a week. Now it also degrades every automated proposal continuously. | |
| **The follow-up.** "What would you do first on an existing codebase that does not look like that?" | |
| Write the index, because it is cheap, it is useful to humans immediately, and it multiplies the value of everything else. Then make the fast per-unit check exist, because without a gate none of the rest converts into throughput. I would not start with a renaming sweep, because it is expensive, it is disruptive to everyone's mental model and to `git blame`, and it delivers the least per unit of effort. | |
| **The trap.** Answering as though this were about prompt formatting. The question is about software architecture, and the answer is architectural. | |
| ### Q13. This role names AI-assisted design workflow as a responsibility. What would you do in your first ninety days? | |
| **Model answer.** I would want to spend the first part of it finding out what already exists, because the failure mode here is arriving with a solution. | |
| **Weeks one to three, inventory.** What tooling is approved, what the data-handling policy is, what is already deployed and who owns it, and what people are actually doing versus what is sanctioned. Shadow usage is real and it is more informative than the policy document. | |
| **Weeks three to six, find the largest boring fraction.** Not the most exciting application, the one that eats the most hours. In most organizations that is regression triage, log analysis, and the documentation and reporting that surrounds a verification cycle. I would measure before proposing, because the Amdahl argument says the target should be chosen by size rather than by novelty. | |
| **Weeks six to ten, build one thing end to end with a gate.** One workflow, small, with an automated check, instrumented so I can tell whether it helped. I would deliberately choose something where being wrong is cheap and detection is mechanical (triage summarization or testbench scaffolding rather than RTL for a critical block), because the first deployment's job is to establish that the discipline works, not to be impressive. | |
| **Weeks ten to thirteen, measure honestly and write it down.** Against project metrics that already exist (time to regression clean, escape rate, coverage closure rate) rather than against lines generated or how people feel. And I would write up what did not work as well as what did, because in a field this noisy the negative results are the more valuable contribution. | |
| **The follow-up.** "What if you find the team is sceptical?" | |
| That is a reasonable prior and I would not argue with it. The productive response is to pick something where the sceptic's objection is not applicable (a task where the output is a hypothesis a human immediately checks and the cost of being wrong is a wasted minute), and to be scrupulous about reporting failures. Credibility here is built by being the person who says "this one did not work," and it is destroyed instantly by overselling a first result. | |
| **The trap.** Arriving with a plan to have the model write RTL. It is the highest-risk, lowest-fraction target, it will attract the strongest resistance, and the arithmetic says it is not where the hours are. | |
| ### Q14. What would you refuse to use AI for? | |
| **Model answer.** Four things, and each for a different reason. | |
| **Anything that puts proprietary material across a trust boundary**, for the reasons in the data-handling answer. That is a hard line and it does not trade against convenience. | |
| **Deciding what the design is supposed to do.** The specification is the ground truth the gate checks against, so if it is generated there is nothing left to adjudicate disagreements and the design drifts toward whatever was most recently said. I will use a model to help me *write down* a specification I already decided. I will not use it to decide. | |
| **Anything where I cannot construct a check.** If I cannot tell mechanically whether the output is right, then I have added an unverified artifact to the design and the only thing standing between it and silicon is my attention, which does not scale. Where a check is genuinely impossible, that is a signal to do the work by hand. | |
| **Signing off.** Someone owns the block and that ownership is not delegable to a tool. This is not sentimental. It is the same reason a synthesis tool's report does not tape a chip out. | |
| **The follow-up.** "Is there anything you have changed your mind about?" | |
| Yes, and it is worth saying because the answer sounds like a limitation and is not. I started out thinking the risk was mostly wrong outputs, so the discipline should be vigilance. It is actually mostly wrong *plausible* outputs, so the discipline has to be structural. It needs a gate that runs whether or not I am paying attention, and a specification that exists outside the conversation. That shift is what moved my practice from ad hoc to something I would be willing to describe as a workflow. | |
| **The trap.** Having no refusals. An unbounded answer to this question reads as an absence of judgment, and this question exists specifically to find out whether you have any. | |
| --- | |
| ## Part 10, check yourself | |
| Answer out loud, in full sentences, as an interviewer would hear them. If you cannot, reread the section named. | |
| 1. Name the three strands of "AI in chip design," say what technology each is, and state what kind of evidence supports each. (1.2) | |
| 2. Compute the size of a six-knob, five-value tool configuration space, the serial time to enumerate it, and explain what an optimizer is actually buying you. (1.1, 2.5) | |
| 3. Compute HPWL for two placements of four blocks on a $4 \times 4$ grid and explain why the better one may still be illegal. (2.1) | |
| 4. Count the placement space for 100 macros on a $128 \times 128$ grid and say what that implies about every placer that has ever shipped. (2.2) | |
| 5. Explain reinforcement learning from a two-strategy comparison up to credit assignment, then derive why a proxy reward is unavoidable and why that is where the scientific dispute lives. (2.3) | |
| 6. Give the timeline of the learned-placement dispute accurately, including what was and was not retracted, which editorial flags were added and which were later removed, and state the two questions that make it comprehensible. (2.4) | |
| 7. Explain what a language model is doing mechanically, and derive from that mechanism where plausibility and correctness coincide and where they diverge. (3.1, 3.2) | |
| 8. State the current shape of the VerilogEval evidence and then explain precisely why the headline number does not measure the job. (3.3) | |
| 9. Give two examples of plausible-but-wrong generated RTL in your own strength areas, and say why both are more dangerous than a hallucinated tool option. (3.4) | |
| 10. Work the Amdahl arithmetic for a doubling of RTL authoring speed and for a 1.3× gain on verification, and state the design conclusion. (3.5) | |
| 11. Describe an agent mechanically in three sentences, then derive the thirty-step reliability figure and the checkpointing result. (4.1, 4.4) | |
| 12. Explain why the verification gate must be automated rather than human, using the reading-speed argument. (5.2) | |
| 13. Explain why the checker must be independent of the generator, and apply it to the question of whether an AI-written assertion counts as verification. (5.3, Q9) | |
| 14. List what a navigable codebase needs and say why each item helps a model specifically. (5.4) | |
| 15. Enumerate the three things that cross the trust boundary, say which one people forget, and state your own position in one sentence. (6.1, 6.4) | |
| 16. Distinguish local, private-deployment, and hosted models, and say why "local equals safe" is the wrong framing. (6.2, Q8) | |
| 17. Give the four beats of the answer to "how do you use AI in your work," and name the two failure modes it is designed to avoid. (7.1, 7.2) | |
| --- | |
| ## Part 11, related notes | |
| - [Verification Methodology](/learn/hardware-interview-prep/verification-methodology) for the assertion, coverage, and formal discipline that Part 5's entire gate is built from, and for the reference-model independence argument that Q9 and Q10 both reuse | |
| - [STA Synthesis and Physical Design](/learn/hardware-interview-prep/sta-synthesis-and-physical-design) for placement, wirelength, and the tool-knob vocabulary Part 2 assumes, and for the flow-ownership credential Part 9.4 maps onto design-space exploration | |
| - [Power Fundamentals and Clock Gating](/learn/hardware-interview-prep/power-fundamentals-and-clock-gating) for the bare-AND clock gate in Part 3.4, which is the best single worked example of a plausible-and-broken generated construct | |
| - [Clocking Reset and Domain Crossing](/learn/hardware-interview-prep/clocking-reset-and-domain-crossing) for the per-bit bus synchronizer failure in Part 3.4, and for why it simulates cleanly and fails in silicon | |
| - [RTL Design and SystemVerilog](/learn/hardware-interview-prep/rtl-design-and-systemverilog) for the coding conventions that decide whether the most plausible continuation is also the correct one | |
| - [Performance Modeling](/learn/hardware-interview-prep/performance-modeling) and [Cpp and Performance Model Construction](/learn/hardware-interview-prep/cpp-and-performance-model-construction) for the model codebases that Part 5.4 and Q12 are about structuring, which is where Apple's role language points | |
| - [Programming and Tooling](/learn/hardware-interview-prep/programming-and-tooling) for the scripting and flow-automation context that most of the safe, high-value applications in Part 3.5 sit in | |
| - [ML Accelerator Microarchitecture](/learn/hardware-interview-prep/ml-accelerator-microarchitecture) for the hardware that runs these models, which is a different subject from this one and should not be conflated with it in an interview | |
| - [Whiteboard and Coding Playbook](/learn/hardware-interview-prep/whiteboard-and-coding-playbook) for the delivery mechanics of the Part 8 answers under time pressure | |
| - *Apple Context and Behavioral* for the Apple-specific framing, and *Cross Company Context and Behavioral* for the role-snapshot caveat that Part 9.1 depends on and for the per-company clusters that decide how much of this note to spend |