Extras

AI in EDA

Programs that learn from examples are starting to help design chips. Some guess early where trouble will come. Some search for better tool settings, and some write code from a request in plain English. Here is where that help is real, and why every answer still has to be checked.

Machine learning enters chip design in two ways: models inside the design software that predict, tune and place, and chatbot-style language models that write hardware code, tests and tool scripts. This page covers what the open papers show, what the benchmarks actually measure, and why checking the output is still the slow part.

Prediction models, Bayesian and reinforcement-learning flow tuning, GPU placement, learned macro placement, and LLMs for RTL, verification and tool scripting. For each: the open evidence, the disputes, and the ways a results table misleads, from proxy objectives and weak baselines to benchmark contamination and pass@k, each explained step by step.

A chip is designed with a long chain of software tools. The tools decide where billions of tiny parts go and how wires join them. Some of these tools now use : programs that learn patterns from past examples, instead of following rules a person wrote down.

The help comes in two kinds. Some lives inside the design tools, making quick guesses and searching for good settings. The other kind is a chatbot-style , like the ones you may have tried. It can write the code that describes a chip from a request typed in plain English.

Both kinds can be wrong in ways that look right. A chip can’t be fixed after it is made. So anything an AI makes has to pass the same checks as work done by a person.

Chips are designed almost entirely in software, known as (electronic design automation). Engineers first describe what the chip does in a such as Verilog, at a level of detail called (register-transfer level). A synthesis tool turns that description into a : a list of logic gates and the wires between them. Placement and routing tools then decide where each gate sits on the silicon and draw the metal wires that connect them, which gives the layout. Finally, checks confirm the layout is fast enough, follows the factory’s rules and still matches the design before it is sent for manufacture. On a large chip, each of these steps can run for hours.

(ML) is software that learns patterns from examples instead of following rules a person wrote. A survey of ML for EDA traces the idea back to the 1990s and sorts most of the work into four roles: helping a tool choose among its own algorithms or settings, predicting the result of a slow later step from an earlier one, searching for good tool settings by trial (black-box optimization), and producing designs directly. Since about 2023 a second wave has added (LLMs), the technology behind chatbots, which write RTL, the test code that checks it, and the scripts that drive the tools.

Two facts shape both waves. First, everything a model produces has to be checked. A bug that reaches the factory means a : a corrected design, new manufacturing masks and months of delay. Second, there is little data to learn from. Chip designs are trade secrets and tool licenses restrict sharing, so until recently there were almost no public datasets for training these models. The big EDA vendors also sell ML-based features in their tools, but their methods aren’t published in full, so this page covers work whose papers or code anyone can read.

A useful way to sort the field is by where the model sits relative to the checks that guard correctness. Verification (simulating the RTL and proving properties about it) guards what the chip does. Signoff (timing, power and manufacturing-rule checks on the finished layout) guards the physical result. A congestion predictor, a settings tuner or a learned macro placer only proposes something; the normal tools then build it and signoff checks it. A bad proposal costs runtime and quality of results (QoR: the speed, power and area achieved), but correctness is still guarded downstream. An LLM writing RTL sits before verification, so its mistakes are functional bugs, and they are caught only as well as the verification plan catches them.

The survey’s four categories (decision making inside tools, performance prediction, black-box optimization, automated design) are ordered by increasing automation. Risk grows along the same axis, because each step hands the model more of the decisions a person used to review.

The evidence is uneven. Prediction and tuning papers are numerous but mostly trained and tested on small, often internal, datasets. Learned macro placement is disputed in the open literature. LLM results come mostly from benchmarks of small modules whose problems may have leaked into training data. Commercial ML features exist in the major EDA tools, but this page covers only work whose method and results can be read in full.

AI helpersthe design flowRTLVerifySynthLayoutSignoffFactoryLLMTunerPlacerForecasterror: a real bugerror: slower or bigger chipno undo

Tap a helper to see where it works and which check guards it. Tap a step of the flow to read about it.

Where AI sits in the design flow. ML helpers only propose; the normal tools build and signoff checks. An LLM writing RTL sits before verification, so its errors are bugs.Share freely with credit: ‘Figure from chipfieldguide.com’

Forecasting traffic jams. Late in the design, a tool lays out all the wires, which can take hours. If one area is too crowded, the step fails and engineers start over. So researchers ran six chip designs through the tools thousands of times, each with different settings. They kept more than 10,000 finished layouts to train programs on. Now a program can look at an early, rough plan and point out spots likely to jam. It’s like spotting a traffic bottleneck on a map.

Searching for good settings. Each design tool has dozens of knobs. A search program runs the tools again and again. It learns which knobs matter and picks each next try more cleverly.

Borrowing AI hardware. A tool called DREAMPlace decides where parts go on the chip. It runs on graphics chips, using software built for AI, and does its main job more than 30 times faster than an older tool. But it doesn’t learn anything from past chips. It just uses the AI software as a fast calculator.

Learning like a game player. Google researchers trained a program to arrange a chip’s biggest blocks the way an AI learns a video game: try a layout, get a score, try again. Other researchers who re-ran it found that older methods did better. The original team says those re-runs left out key steps. The Floorplanning page tells the whole story.

Predicting before the expensive step

Routing, the step that draws every wire, and signoff are slow. A cheap early guess of how they will go lets a team reject a bad layout in minutes instead of hours. Two kinds of trouble are worth predicting. means more wires want to pass through a small area than there is room for. violations are breaks of the factory’s design rules (DRC stands for design-rule checking), such as two wires placed closer together than allowed.

The usual approach treats the placed layout as an image. Cut it into a grid of tiles and record a few numbers for each tile: how densely the gates are packed, where the large pre-built blocks sit, how many connection pins there are, and an estimate of how much wiring the area will need. Then train a (CNN), the kind of model used to recognize photos, to output a map with one predicted congestion or DRC value per tile. RouteNet was the first to use a CNN this way to find DRC hotspots, with a quick wiring estimate called (rectangular uniform wire density) among its inputs. CircuitNet, an open dataset for these tasks, ran six RISC-V processor designs through synthesis, placement and routing in a 28 nm manufacturing process with many different settings, and kept 10,242 finished layouts.

Timing prediction works on the netlist instead. A chip’s work is paced by a clock, and on every tick each signal has to travel from one storage element (a ) through the gates to the next one before the following tick. is the time to spare on such a path: positive means the signal arrives in time, negative means the chip can’t run at its target speed. The trusted answer comes from (STA) after routing, once the wire delays are known. A (GNN) treats each gate as a node and each wire as a link, and predicts arrival times and slack before routing. PreRoutGNN reports an R2R^2 of 0.93 for slack on 21 circuits, against 0.59 for the previous best model. (R2R^2 measures how much of the spread in the true values a prediction explains: 1 is perfect, 0 is no better than always guessing the average.) Numbers like these help rank options early. Signoff STA still decides.

Tuning the flow

The tools have dozens of settings: the target clock period (the time per clock tick; shorter means faster), the core (the share of the chip’s area the gates fill), how tightly the placer packs cells, and many more. They interact in ways no one can predict exactly, so teams search for good combinations. This is , and results are scored on : power, performance (speed) and area.

OpenROAD-flow-scripts, an open-source flow that goes from RTL to finished layout, includes a tuner called AutoTuner. It runs many flow jobs in parallel, offers several search methods (from plain random or grid search to Bayesian optimization and evolutionary search), and scores each trial on PPA, weighted by coefficients the user sets for performance, power and area. The settings to search and their ranges go in a small JSON file:

autotuner.json (illustrative)json
{
  "_SDC_FILE_PATH": "constraint.sdc",
  "_SDC_CLK_PERIOD": { "type": "float", "minmax": [2.0, 3.0], "step": 0 },
  "CORE_UTILIZATION": { "type": "int", "minmax": [40, 70], "step": 5 },
  "PLACE_DENSITY": { "type": "float", "minmax": [0.55, 0.85], "step": 0 }
}
  1. 1L2The timing-constraints file (SDC) that AutoTuner copies and edits for each trial.
  2. 2L3Clock period, in the cell library’s time unit, anywhere between 2.0 and 3.0. Step 0 on a decimal setting means any value in the range may be tried.
  3. 3L4Core utilization in percent, tried in steps of 5. (Step 0 on a whole-number setting would hold it constant.)
  4. 4L5How densely the placer packs cells. Any flow setting that can be given on the command line can be tuned this way.

fits a , a cheap stand-in, to the trials run so far, and uses it to choose the next trial: somewhere the stand-in predicts a good result, or somewhere it is unsure. It suits problems where each evaluation takes minutes or hours, which describes a placement-and-routing run.

AutoDMP applies a version with several goals at once to placement. Macros are large pre-built blocks, such as memories, that sit inside a chip. AutoDMP tunes the settings of the DREAMPlace placer against quick estimates of wire length, packing density and congestion, and sends only the best trade-offs (the ) through a commercial flow to get routed results. Its authors report a design with 2.7 million cells and 320 macros optimized in 3 hours on one GPU workstation.

(RL) has been tried for tuning too. During logic synthesis the tool improves the gate network with a sequence of small rewriting steps, and the order of those steps matters. DRiLLS trains an agent to choose that sequence in ABC, an open-source synthesis tool. It reports a 13% average area reduction compared with the starting design, while meeting the speed target on all ten EPFL arithmetic benchmark circuits it tested.

GPU placement is not a learned model

Placement decides where each of up to millions of cells goes. An analytical placer does this by numerical optimization: it writes one formula for total wire length plus a penalty for cells piling up, then nudges every cell a little at a time in the direction that lowers the formula. Training a neural network uses the same math, reducing a “loss” formula step by step. DREAMPlace therefore runs placement in PyTorch, a deep-learning library, on a graphics processor (GPU). It reports more than 30× faster global placement than RePlAce, a placer running on many processor cores, with no loss of quality, and about a minute for a million-cell design. Its authors stress that using a deep-learning toolkit to solve placement is a different thing from using deep-learning models for placement. The Placement page covers the algorithm.

Learned macro placement and the dispute

Mirhoseini et al. at Google trained an RL agent to place macros one at a time on a grid, scoring each finished placement, and reported results that matched or beat human experts in under six hours. Cheng et al., a UC San Diego group, rebuilt the undocumented parts of Google’s open-source code (Circuit Training) and compared it with other methods. Simulated annealing (a classic method based on random moves), analytical placers and human experts often did better, and the score the agent was trained on tracked the final routed results poorly. Markov’s review of the evidence reached a harsher conclusion. The original authors reply that the reproductions skipped pre-training (training on other chips first), used less computing power and stopped training early, and that the method has produced layouts used in three generations of Google’s TPU chips. The Floorplanning page walks through the details.

Lithography and test

Two uses sit close to manufacturing. Chips are printed by shining light through a , a stencil of the layout. The features are smaller than the light’s wavelength, so the printed shapes blur. (OPC) pre-distorts the mask so the printed result comes out right. GAN-OPC trains a generative adversarial network (a pair of networks, one producing candidates and one judging them) to turn a target layout into a corrected mask, then hands that mask to conventional OPC, which needs fewer steps to finish. CNNs trained on small snippets of layout flag , spots likely to print badly, faster than a full optical simulation.

After manufacture, every chip is tested by applying patterns to its inputs and checking its outputs. is the share of possible manufacturing defects those tests would catch. Some internal points are hard to see from outside, so designers add observation points, extra connections that make them visible to the tester. A graph convolutional network (a kind of GNN) trained to spot hard-to-observe points chose where to add them. Measured with a commercial test tool, the result had similar fault coverage to that tool’s own choices with 11% fewer observation points and 6% fewer test patterns.

Prediction: the label and the split

In supervised learning every training example needs a label, the right answer. Here the label is the outcome of a full tool run (the routed congestion map, the signoff slack), so each example costs hours of compute and datasets stay small. CircuitNet’s authors note that most earlier studies could only validate on small internal datasets. CircuitNet itself is six RISC-V designs in one 28 nm technology, built with one commercial synthesis tool and one commercial place-and-route tool, each design run with 2,160 combinations of settings.

That shapes what a result means. If the test set holds other runs of the same designs (a split by run), the model has already seen those circuits and only has to interpolate between settings. If it holds circuits never seen in training (a split by design), the test is closer to real use, where the next chip is always new. Check which split a paper used.

For timing, the model has to imitate STA. STA computes the arrival time at each pin in signal order: a gate’s output time is its latest input time plus its own delay, so each pin can be numbered by its depth in that order, its topological level. PreRoutGNN shows that in an earlier GNN the arrival-time error grew with level, because small errors at early pins were passed on and added up along long paths. Pre-training a graph autoencoder to summarize the whole circuit, and splitting large graphs in a way that keeps signal order, raised slack R2R^2 from 0.59 to 0.93. But R2R^2 averages over every timing endpoint, and the chip’s speed is set by the few worst paths, so also ask for the error on the most critical endpoints.

Flow tuning: sample budgets and noise

Each trial is a partial or full run of placement and routing, so a search gets tens to hundreds of samples, not millions. That is why sample-efficient methods dominate. Bayesian optimization is built for slow, noisy evaluations. The tree-structured Parzen estimator (TPE) sorts past samples into good and poor groups, models where each group falls, and proposes new points that look like the good ones.

AutoTuner records PPA for every trial in a standard metrics format (METRICS2.1), has a sweep mode that tries every combination on a grid, and can tune any flow variable that can be set on the command line, plus values in the timing-constraint (SDC) file and global-routing layer adjustments. AutoDMP evaluates in two levels because, in its authors’ words, the estimated PPA after placement “might not correlate precisely” with PPA after routing. Only placements on the Pareto front of the cheap estimates go through the commercial router.

Baselines matter as much as the method. DRiLLS’s headline 13% is relative to the starting design. In the same table, expert-written ABC scripts met the delay target on nine of ten designs while increasing average area by 26%, because they trade area for speed. That is the kind of detail a single average hides.

Macro placement: what the dispute is about

The question sounds simple: does Google’s RL placer beat the alternatives? Answering it needs the code, test designs and an agreed final metric. Circuit Training was released as open source, which is what made independent assessment possible. Cheng et al. reimplemented its undocumented pieces, released their test designs and evaluation scripts, and compared it on routed results against simulated annealing, RePlAce (an analytical placer), AutoDMP, a commercial macro placer and human experts. Among the good solutions, the agent’s training score, its “proxy cost,” had weak rank correlation with routed wire length, power and timing: sorting solutions by proxy cost did not sort them by routed quality.

Markov concludes that the method lags humans, annealing and commercial software; his paper’s author note lists a role at Synopsys, an EDA vendor. Goldie et al., the original authors, are at Google DeepMind, Google Research and Stanford. They argue that the reproductions removed pre-training, used 20× fewer RL experience collectors (the parallel workers that play out placements to learn from) and half the GPUs, and did not train to convergence. The open question is narrow and technical: how much pre-training and compute the method needs to beat strong baselines on routed metrics, on designs anyone can rerun.

Lithography and test: a model as a starting point

GAN-OPC is pre-trained together with inverse lithography technology (ILT), a slow, accurate method that computes a mask by optimizing it against a model of the printing process. The trained network produces a near-optimal starting mask, and conventional OPC finishes the job.

The test example works the same way. The GCN labels each node from four numbers: its logic level and the three SCOAP testability scores, which estimate how hard it is to force the node to 0 (C0), to force it to 1 (C1), and to see its value at an output (O). A loop inserts observation points where the model points, and the same commercial tool then reports fault coverage and pattern count. In both cases a physics- or fault-based engine checks the model’s output. That is why ML is easy to adopt here: a wrong guess costs extra iterations and gets caught before silicon.

score (PPA) ↑0.550.700.85placement densitynext trialtrials: 2 / 12
Search method

Two trials so far; each is one full flow run. Run more and compare random with guided search.

Illustrative: one setting and a made-up score curve. Guided search fits a cheap stand-in to the trials so far (the band is its uncertainty) and runs the next trial where it expects the most improvement.Share freely with credit: ‘Figure from chipfieldguide.com’

Chatbots learned from huge amounts of text and code, including some chip-design code. Ask one for “a counter that counts to ten and starts over,” and it often writes working code.

How often? Researchers build tests to find out: they run the AI’s code and check whether it works. In 2023, the best AI solved fewer than half of one test’s problems on its first try. In 2025, a harder test written by experienced engineers found top AIs solving at most about a third of its coding problems.

Chip companies use these AIs in other ways too. One company trained a chatbot on its own design papers, so it could answer its engineers’ questions. Others let an AI run the design tools from a typed request.

Writing RTL, and what the benchmarks measure

To measure how well models write hardware code, researchers build benchmarks: sets of problems, each with a description, a correct reference design and an automatic check. VerilogEval takes 156 problems from HDLBits, a Verilog practice website. It has two sets of problem descriptions: 143 written by GPT-3.5 and 156 rewritten by hand. Each answer is run in a simulator (software that imitates the hardware clock tick by clock tick; here the open-source Icarus Verilog) on hand-picked and random inputs, and its outputs are compared with the reference. Results are reported as , the chance that at least one of kk attempts passes. In the original paper GPT-4 scored 43.5% pass@1 (first try) on the hand-written set and 60.0% on the machine-written one.

RTLLM has 30 larger designs and scores three things: whether the code is valid, whether it works, and design quality, measured by synthesizing it and comparing power, speed and area with a human-written version. Its authors caution that passing all test cases does not prove a design correct, because the tests only sample the possible inputs. CVDP, from 2025, has 783 problems written by experienced hardware engineers across 13 categories, including debugging, writing checks and multi-step tasks in which the model uses tools. The best models it tested passed no more than 34% of the code-generation problems on the first try.

Most of these benchmarks test one small block of code at a time. They say little about joining many blocks together, about signals passing between parts of a chip that run on different clocks, about making a design fast enough, or about turning a vague specification into a correct design, which is where much of the real effort goes.

Domain-adapted models

ChipNeMo, from NVIDIA, started from Meta’s open LLaMA2 models and adapted them to chip design in four steps: a (the part that chops text into word pieces) adjusted for chip-design text; , meaning more training on 23.1 billion tokens of NVIDIA’s internal design documents and code; on instructions; and a search component tuned to find the right internal documents for each question. It targeted an engineering-assistant chatbot, writing scripts for EDA tools, and summarizing bug reports. Its 70-billion-parameter model beat GPT-4 on the first two in the authors’ evaluations, and the domain pretraining cost under 1.5% of the computing used to pretrain the base model. Because the data is NVIDIA’s own, outside groups can’t rebuild the model, and the authors cite keeping proprietary design data away from other companies’ AI services as one motivation.

Testbenches and assertions

Verification code is a second target. An is a small rule written into the checking code, such as “whenever a request arrives, a grant must follow within four clock cycles,” which a simulator or a formal tool checks continuously. Kande et al. asked Codex, an OpenAI code model, to write security assertions in SystemVerilog and compared them with correct reference assertions. With enough context in the prompt it reached 93.55% correct, but it averaged 26.54% across 2,268 prompt variations, so results depended heavily on how the request was put.

Tests also need stimulus, the inputs fed to the design. Coverage measures which interesting situations (called bins) the tests have reached. The traditional way to fill bins is testing: generate huge numbers of random but legal inputs. LLM4DV instead tells the model which bins are still empty and asks it for inputs that reach them. Across eight designs the authors report that it matched or beat plain random stimulus, though results on the processor designs varied widely from model to model.

Scripts and agents

An works in a loop: plan a step, call a tool, read the result, decide what to do next. ChatEDA fine-tunes a model to break a request into sub-tasks, write Python scripts against a programming interface wrapped around the OpenROAD tools, and run them. On its own 50-task benchmark, graded by human judges who didn’t know which model wrote each answer, the fine-tuned model earned the top grade on 82% of tasks, against 62% for GPT-4. VerilogCoder gives a team of agents three tools: a syntax checker, a simulator, and a waveform tracer that follows a wrong output back through the signals that feed it. It reports 94.2% correct on the newer version of VerilogEval’s hand-written set. Tool feedback is the main difference from one-shot generation: the simulator, not the model, reports whether the code works.

Reading the RTL benchmarks

VerilogEval’s testbench feeds the model’s answer and the reference the same inputs, hand-picked cases plus random patterns lasting from a few hundred clock cycles for simple problems to several thousand for complex ones, and compares outputs on clock edges for sequential circuits and on every input change for combinational ones. The authors note that the simulator limits which Verilog syntax can be evaluated. They also found that during , pass@1 kept rising with more training passes while pass@5 and pass@10 fell: the model grew more confident and less varied. They recommend reporting both. RTLLM’s caution that passing every test does not prove correctness applies to all of these benchmarks: a pass means agreement on the stimulus the benchmark happened to apply.

Contamination

VerilogEval’s problems come from a public website, so solutions to them may sit in any training set scraped from the web. The HumanEval authors hand-wrote their problems for exactly this reason, noting that public code repositories already held solutions to existing problem sets. VeriContaminated applied two detection methods to VerilogEval and RTLLM across open and commercial models. CDD checks whether a model’s repeated samples for a problem are suspiciously alike, a sign of memorization. Min-K% Prob looks at the least likely 20% of tokens in a benchmark text: unseen text usually contains a few words the model finds very unlikely, so if even those score high, the model has probably seen the text. The paper concluded that is a critical concern, found the highest rates in commercial models such as GPT-3.5 and GPT-4o, and showed that mitigation costs some accuracy. Detection is statistical and imperfect, so these results are warning signs, not proof for any single model. The practical answer is evaluation on problems written after a model’s training cutoff, or on private sets.

Comparing agent and one-shot numbers

VerilogCoder’s 94.2% comes from a tool-using agent on small modules. CVDP’s 34% ceiling is first-try pass@1 on harder problems written by engineers, and the paper reports that agentic tasks involving reuse of existing RTL and verification were especially hard. Both groups are at NVIDIA and both numbers can be right. Together they show that small-module benchmarks leave little headroom, and that the hard part of RTL work sits in tasks those benchmarks don’t contain.

Cost and data in domain adaptation

ChipNeMo internal training corpus
23.1B tokens
DAPT, 70B model (A100 GPU-hours)
20,500
Pretraining the 70B base model (A100 GPU-hours)
1,720,320

Those figures come from ChipNeMo’s cost table; a GPU-hour is one A100 data-center GPU running for an hour, and all models trained on 128 of them. Its script benchmarks cover timing-analysis tasks in an in-house Python tool and a Tcl-based EDA tool, scored partly automatically and partly by engineers. The authors report more than 70% correctness on simple scripts, and 1,400 extra domain instructions improved script correctness by 18%. Running domain pretraining directly on a chat-tuned model badly degraded its instruction following, so the instruction tuning had to come after domain training.

Agents and graded evaluations

ChatEDA first tests whether each generated script runs, then has human judges grade task decomposition and script quality blind, on 50 tasks split between simple flow calls, complex flow calls and calls that set parameters. That is a reasonable design for a small benchmark, but a script that runs is not a design that meets its goals, and 50 tasks give wide error bars. For assertions, the Kande et al. spread from 26.54% average to 93.55% best shows how much prompt context matters. A generated assertion also has to be checked for vacuity (an assertion whose trigger never fires passes without testing anything) and for encoding the intended property. In LLM4DV’s results table, coverage on the Ibex CPU ranged from about 11% to 100% depending on the model, and a formal tool reached near-full coverage on seven of the eight designs.

RTLerrorsRequestModelSimulatorEngineercounter.v (model output)(waiting for the model)
Generation
1 / 6

The request: a counter that counts 0 to 9 and wraps to 0.

Illustrative scenario. Tool feedback is the main difference from one-shot generation: VerilogCoder’s agent reports 94.2% on small modules, where GPT-4 alone scored 43.5% pass@1 in VerilogEval’s 2023 paper (different benchmark versions).Share freely with credit: ‘Figure from chipfieldguide.com’

Checking is the slow part. An AI can write code in seconds. But making sure the code is right still takes the same tests as before.

There isn’t much to learn from. Companies keep their chip designs secret. So AIs learn from only a small number of public examples.

Tests can leak. If the test questions were in what the AI studied, a high score may just be memory. It’s like a student who saw the exam the night before.

When you read that an AI method “beats” something, ask three questions:

  • Better than what? Beating a weak rival is easy.
  • Checked how? A quick guess is not the same as a finished, tested chip.
  • Can others repeat it? Shared code lets other people check.

Verification is still the bottleneck

Generated RTL is unchecked RTL. The strongest check is available when a trusted earlier version exists, as in a cleanup, a rewrite to save area, or a translation between coding styles. Formal then proves mathematically that the new version behaves exactly like the old one for every possible input, instead of trying a sample of inputs as a simulation does. Yosys EQY, an open-source equivalence checker, compares a trusted “gold” design with a new “gate” design, splits the problem into smaller pieces (partitions), and proves each piece with a chosen strategy, such as SymbiYosys driving an SMT solver, a general-purpose logic-proof engine. Here is an illustrative setup for checking a model’s rewrite of a FIFO, a first-in, first-out queue:

fifo_rewrite.eqy (illustrative)text
[gold]
read_verilog -sv fifo_ref.sv
prep -top fifo

[gate]
read_verilog -sv fifo_llm.sv
prep -top fifo

[strategy sby]
use sby
depth 2
engine smtbmc bitwuzla
  1. 1L1Gold: the verified, human-written version.
  2. 2L3Load the file and prepare it with fifo as the top-level block, as in the EQY quickstart.
  3. 3L5Gate: the model’s rewrite. It needs the same top-level name and ports, or the two can’t be lined up.
  4. 4L9Each partition is handed to SymbiYosys with an SMT solver (here Bitwuzla), as in the EQY quickstart.
  5. 5L11How many clock cycles each proof step spans. A partition that can’t be proven is reported as a failure, never passed silently.

For new functionality there is no earlier version to compare against. Then the generated code goes through the same plan as human code: a (code that drives inputs and checks outputs in simulation), assertions, coverage closure (running tests until every planned situation has been reached) and review. The Verification page covers that plan.

Data, IP and reproducibility

A company’s designs are its intellectual property (IP), and it rarely shares them. CircuitNet’s authors blame the near-absence of public datasets on license restrictions and the expertise needed to generate data, and list the consequences: results are hard to compare, hard to reproduce, and hard for new researchers to build on. Domain-adapted language models need large private collections of design documents and code. Open code is what makes a claim checkable. Cheng et al. could assess learned macro placement because Circuit Training was released, and they published their own flows in turn.

Compute

Costs vary widely. AutoDMP optimized a 2.7-million-cell design in three hours on one GPU workstation. Adapting a 70-billion-parameter language model took about 20,500 GPU-hours (one data-center GPU running for 20,500 hours, or 128 of them for about a week). In the macro-placement dispute, the amount of compute and pre-training is itself one of the points argued.

Reading a results table

Here is a made-up table of the kind many papers print, with the questions to ask. “Proxy cost” is a quick estimated score, not a measurement of the finished chip. Placement and routing tools also use random numbers inside, so running them again with a different random seed gives a slightly different result.

results.txt (hypothetical)text
Design   Baseline   Ours    Impr.   Metric
cpu_a    1.000      0.88    12%     proxy cost
cpu_b    1.000      0.91     9%     proxy cost
dsp_c    1.000      0.95     5%     proxy cost
Avg.                         8.7%
(best of 8 runs; baseline: default settings, 1 run)
  1. 1L1Is “Baseline” a well-tuned competing method or just the tool’s default settings?
  2. 2L2Proxy cost, not the routed wire length, speed or power. Does the proxy track them?
  3. 3L6The best of 8 tries against a single baseline run inflates the gap. Ask for averages and spread over several random seeds.

Beyond the table: were the test designs also used in training? Are the designs public? For language models, which kk, how many samples, what settings, and could the problems be in the training data? Who ran the baselines, and how much effort went into tuning them?

What equivalence checking can and can’t guard

Equivalence checking proves that two designs match. It says nothing about whether the reference matches the spec. It suits LLM uses where the intent is to keep behavior the same: refactors, lint cleanup, area or power rewrites, translation between coding styles.

EQY lines up matching signals in the two designs and proves each partition separately. A change that re-encodes stored state, such as renumbering a state machine’s states, breaks that matching. The .eqy file then needs a “recode” section that maps old state codes to new ones, or the state registers are left unmatched and the state machine is proven as a whole with sequential-equivalence strategies. The proof strategies use kk-induction: show the two partitions agree for the first kk cycles, then show that kk cycles of agreement always imply agreement on the next. Some equivalent partitions can’t be proven this way at a given depth. EQY reports every partition it fails to prove and writes a trace of the failing case, so a failure has to be read: it may be a real difference, as in the EQY quickstart’s example of a deliberately broken shifter, or a proof that needs a larger depth or another engine.

Proxy objectives

Learned placers and tuners optimize what is cheap to compute. Cheng et al. found weak rank correlation between Circuit Training’s proxy and routed results among good solutions, so a lower proxy did not reliably mean a better routed design. AutoDMP’s authors say the same of their post-placement estimates and check Pareto points in a commercial flow. Any claim that stops at proxy metrics is a claim about the proxy.

Baselines and compute parity

The macro-placement exchange shows both ways a comparison can go wrong. Critics argue the method loses to strong baselines such as simulated annealing and commercial placers; the original authors argue the reproductions under-trained their method. A fair comparison gives every method a similar budget of wall-clock time and compute, tunes the baselines, and states both. DRiLLS’s table is a good model of disclosure: it lists a greedy search, expert scripts and the benchmark’s best published results alongside its own, with whether each met the delay constraint.

Noise and selection

Placement and routing results move with the random seed and with small changes to settings. A best-of-N result against a single baseline run can report luck as gain. So can a tuner that searches over the seed itself: AutoTuner can tune the global router’s random seed, along with any command-line flow variable. Ask for the spread over reruns of the chosen settings.

A short checklist

  • Baseline: named, tuned, and given comparable compute?
  • Metric: measured after routing or at signoff, or a proxy? If a proxy, is its correlation shown?
  • Split: unseen designs, or held-out runs of training designs?
  • Data and code: released, so the result can be rerun?
  • LLMs: kk, number of samples, temperature, prompt, and benchmark age relative to the model’s training cutoff?
  • Conflicts: who built the method, who built the baseline, and who funds each?
“Ours”Baseline0.900.951.001.051.10← better (lower cost)reported: 6.9%
Reporting rule

Reported improvement 6.9%, from the best of 8 runs against one baseline run. The true difference is 0%: both rows use the same method.

Illustrative: both rows run the same method; each run differs only by its random seed (about 3% spread). The thick mark is the number a table would report. Lower cost is better.Share freely with credit: ‘Figure from chipfieldguide.com’

The work shifts from typing toward checking and deciding. An AI can draft code or try a thousand settings overnight. A person still has to say what “good” means, and catch the mistakes the AI makes with confidence.

That makes the basics more valuable, not less. You can only spot a wrong answer if you know what a right one looks like. Clear instructions matter more too, because an AI builds just what it is told, gaps and all.

  • Flow engineers, who run the chain of tools from RTL to layout, spend less time trying settings by hand and more time deciding what the tuner should aim for (the weights on power, speed and area), how many runs it may use, and keeping every run’s results logged so they can be compared.
  • RTL designers, who write the hardware code, can hand routine code, small blocks, style fixes and scripts to a language model, then review the output and keep the previous version so an equivalence check can compare the two.
  • Verification engineers, who write the tests, get help drafting assertions and test inputs, and take on the job of checking that generated assertions test something real and that coverage reflects the test plan.
  • Everyone has to handle design data with care. Pasting a company’s design code into an outside AI service is a decision about its intellectual property, which is one reason companies train or host their own models.

Public benchmarks are small, possibly contaminated, and unlike most production work, so teams that adopt these tools build internal evaluation sets from their own designs, past bugs and scripts, and rerun them whenever a model or prompt changes. CVDP’s mix of task types (debugging, assertion writing, checking code against a specification, agentic tasks) is a reasonable template for what such a set should cover.

Learned prediction and tuning depend on data the team already generates. Logging per-run metrics in a consistent format, as AutoTuner does with METRICS2.1, is what makes later learning possible. Treat every model output as an untrusted input to the existing signoff and verification gates, and measure the total cost (compute, review time, re-verification) against the engineer time saved.

AI draftsEngineer decides, checks(no AI helper)Type first draftsTry settings overnightDefine what good means+ Catch confident errors+ Write precise specs
Role

Without AI help, every task sits with the engineer. Turn the helper on to see what moves.

Which tasks move when an AI helper arrives, by role, from the text above. Drafting moves; deciding stays; checking grows. Not measured hours.Share freely with credit: ‘Figure from chipfieldguide.com’

This part goes deeper, into the math, models and algorithms behind the chapter. It’s written for the Expert level.

Graph neural networks on netlists

A netlist maps naturally to a directed graph: cells are nodes, wires are edges, the chip’s inputs are sources and its outputs are sinks. A gives every node a vector of numbers (an embedding) and updates it layer by layer by combining the embeddings of its neighbors, so after L layers a node carries information from L hops away. In the testability GCN, each node starts with four features, its logic level and the SCOAP scores [LL, C0, C1, O]. Two aggregation layers produce the embeddings, and fully connected layers then classify each node as hard to observe or not. The authors stress speed, because commercial netlists have millions of gates.

Timing models update nodes in signal order, as STA does. PreRoutGNN shows the weakness of that choice: in an earlier model, arrival-time error grew with topological level as errors piled up along the path. It adds a pre-trained graph autoencoder for whole-circuit context, models the delay between adjacent pins as a correction on top of the previous pin’s time, uses attention (a learned weighting) over each cell’s delay lookup tables, and splits the graph in a way that preserves signal order so large circuits fit in memory. Mirhoseini et al. used an edge-centric variant: each edge updates its embedding with a small fully connected network over its two endpoint nodes, and each node then takes the mean of its edges’ embeddings.

RL formulation of placement

Reinforcement learning is framed as a Markov decision process: at each step the agent sees a state, picks an action, moves to a new state and receives a reward, and it learns a policy (a rule for picking actions) that maximizes total reward. Mirhoseini et al. pose macro placement this way:

  • State: a graph embedding of the netlist (placed and unplaced nodes), an embedding of the macro to place next, facts about the netlist and technology, and a mask of the grid cells where that macro may legally go.
  • Action: the grid cell for the current macro. The chip area is divided into at most 128 × 128 cells, about 30 rows and columns on average. Cells that would push local density over the target are masked out, so density is a hard constraint.
  • Order: macros sorted by size, largest first, with ties broken by signal order. The millions of standard cells are grouped into a few thousand clusters with hMETIS, a partitioner that cuts as few connections as possible, and placed by a force-directed method (wires act like springs pulling connected cells together) once all macros are down.
  • Reward: zero at every step except the last, then the negative weighted sum of proxy wire length and congestion. Wire length is , half the perimeter of the smallest box around each net’s pins; congestion is the mean of the 10% most congested grid cells.
  • Training: PPO (proximal policy optimization), a standard algorithm that nudges the policy toward actions that earned more reward while limiting how far each update can move it. Pre-trained across many blocks, the policy gives a zero-shot placement of a new block in under a second, and further training on that block improves it.

These design choices explain where the dispute bites. The reward is sparse and arrives only at the end, so learning needs many episodes, which is why compute and pre-training are at issue. The reward is a proxy, so its agreement with routed results limits what the policy can achieve. DRiLLS shows a smaller formulation for comparison. Logic synthesis in ABC works on an and-inverter graph (), a network made only of two-input AND gates and inverters. The state is a vector of statistics about that graph, the action is one of seven ABC transformations (resub, resub -z, rewrite, rewrite -z, refactor, refactor -z, balance), the reward favors area reduction under a delay constraint, and an advantage actor-critic (A2C) agent learns the policy.

Surrogates and Bayesian optimization for flow tuning

Bayesian optimization treats the flow as an unknown function f(x)f(x) of its settings xx. It places a Gaussian process prior on ff: a statistical model in which settings close together are expected to give similar results. After nn runs the model gives, at every untried xx, a predicted mean μn(x)\mu_n(x) and an uncertainty σn2(x)\sigma_n^2(x). An acquisition function turns those into a score for where to sample next. Expected improvement is the most common:

EIn(x)=En ⁣[max⁡ ⁣(f(x)−fn∗, 0)]\mathrm{EI}_n(x) = \mathbb{E}_n\!\left[ \max\!\left( f(x) - f^*_n,\, 0 \right) \right]

Here fn∗f^*_n is the best value so far. It favors points that are either predicted to be good or highly uncertain. Entropy search and knowledge gradient are alternatives. The method suits fewer than about 20 continuous settings, evaluations that take minutes to hours, and noisy results, and has extensions for parallel batches, cheaper low-fidelity evaluations and constraints.

TPE models the problem the other way round. It splits past samples into good and poor groups, fits a probability density to each, and proposes the candidate where the ratio of good to poor density is highest. AutoDMP’s multi-objective TPE decides which samples count as good by their position relative to the current Pareto front over wire length, density and congestion, and runs 16 DREAMPlace jobs in parallel on the GPUs. In place-and-route tuning the settings mix whole numbers and decimals, the goals conflict, and seed noise is large, so a multi-objective search followed by reruns of the chosen points is safer than a single weighted score.

pass@k and its pitfalls

is the probability that at least one of kk samples passes. Drawing exactly kk samples per problem gives a noisy estimate, so Chen et al. draw n≥kn \ge k (they used n=200n = 200, k≤100k \le 100), count the cc samples that pass, and compute, averaged over problems:

pass@k=Eproblems ⁣[1−(n−ck)(nk)]\text{pass@}k = \mathbb{E}_{\text{problems}}\!\left[ 1 - \frac{\binom{n-c}{k}}{\binom{n}{k}} \right]

The ratio (n−ck)/(nk)\binom{n-c}{k} \big/ \binom{n}{k} is the chance that kk samples picked from the nn all come from the failing ones. The tempting shortcut 1−(1−p^)k1 - (1 - \hat{p})^k, from the measured pass@1 p^\hat{p}, consistently underestimates the true value.

pass_at_k.py (from Chen et al., 2021)text
def pass_at_k(n, c, k):
    if n - c < k:
        return 1.0
    return 1.0 - np.prod(1.0 - k / np.arange(n - c + 1, n + 1))
  1. 1L2Fewer than k failures means any k samples include a pass.
  2. 2L4Product form of C(n−c, k)/C(n, k), stable where the binomials would overflow.
n = 20 samples, c pass0%50%100%15101520attempts k60%solid: unbiased · dashed: shortcut

n = 20, c = 3, k = 5: pass@5 = 60.1%; shortcut 1 − (1 − 0.15)^5 = 55.6% (4.5 points low). pass@1 = 15%.

pass@k for one problem with n = 20 samples (Chen et al. used n = 200). Solid: the unbiased estimator; dashed: the shortcut from pass@1, which samples with replacement and underestimates. Either way, k > 1 assumes something can pick the passing sample.Share freely with credit: ‘Figure from chipfieldguide.com’
  • The oracle assumption. pass@k for k>1k > 1 counts a problem solved if any sample passes, as if something could pick the right one. In real design work the only way to pick is to verify each candidate, which is the expensive step.
  • Test strength. A pass means the sample agreed with the reference on the applied stimulus. Weak tests inflate every pass@k.
  • Sampling settings. Temperature, prompt and in-context examples shift results; a number without them can’t be compared.
  • pass@1 vs. pass@10. Fine-tuning can raise pass@1 while lowering pass@10, so report both.
  • Contamination. A public benchmark may be in the training data, and detection is statistical.
Novice · 0 of 5 correct
  1. Q1How does the VerilogEval benchmark decide whether a model’s hardware code is correct?

  2. Q2A language model rewrites a block of hardware code that was already verified, to make it smaller. Which check gives the strongest guarantee that its behavior didn’t change?

  3. Q3Why are there so few open datasets for training machine-learning models on chip layouts?

  4. Q4A paper reports that its tool-settings tuner shrank chip area by 13% on average. What is the first question to ask?

  5. Q5In an agent setup such as ChatEDA, what does the language model do that a one-shot code generator does not?

Sources

Show Hide 27 sources
  1. Machine Learning for Electronic Design Automation: A SurveyGuyue Huang, Jingbo Hu, Yifan He, et al., Bei Yu, Huazhong Yang, Yu Wang · ACM TODAES (arXiv version) · 2021ML in EDA dates to the 1990s; four roles (decision making, performance prediction, black-box optimization, automated design); RouteNet as the first CNN for DRC hotspot detection with RUDY input; CNNs for lithography hotspot detection.
  2. CircuitNet: An Open-Source Dataset for Machine Learning Applications in Electronic Design Automation (EDA)Zhuomin Chai, Yuxiang Zhao, Yibo Lin, Wei Liu, Runsheng Wang, Ru Huang · Science China Information Sciences (arXiv version) · 2022Almost no public ML-for-CAD datasets because of license restrictions; 6 RISC-V designs at 28 nm, 10,242 layouts; congestion, DRC-violation and IR-drop prediction from image-like features.
  3. PreRoutGNN for Timing Prediction with Order Preserving PartitionRuizhe Zhong, Junjie Ye, Zhentao Tang, et al., Junchi Yan · AAAI 2024 (arXiv version) · 2024Pre-routing slack, slew and delay prediction with a GNN; error in earlier models grows with topological level; R² of 0.93 for slack on 21 circuits vs. 0.59 for the previous best.
  4. DREAMPlace: Deep Learning Toolkit-Enabled GPU Acceleration for Modern VLSI PlacementYibo Lin, Shounak Dhar, Wuxi Li, Haoxing Ren, Brucek Khailany, David Z. Pan · DAC 2019 (author version, UT Austin) · 2019Analytical placement cast as neural-network training in PyTorch on GPUs; over 30× faster global placement than multi-threaded RePlAce without quality loss; a million-cell design in about a minute; orthogonal to using learned models for placement.
  5. Instructions for AutoTuner with RayThe OpenROAD Project · OpenROAD-flow-scripts documentationNo-human-in-loop tuning of flow parameters with Ray; random/grid, PBT, HyperOpt TPE, Ax, Optuna, Nevergrad; PPA weights coeff_perform, coeff_power, coeff_area; JSON search space; sweep and tune modes.
  6. A Tutorial on Bayesian OptimizationPeter I. Frazier · arXiv · 2018Surrogate model with Gaussian process regression plus an acquisition function (expected improvement, entropy search, knowledge gradient); suited to expensive, noisy, derivative-free objectives under about 20 dimensions.
  7. AutoDMP: Automated DREAMPlace-based Macro PlacementAnthony Agnesina, Puranjay Rajvanshi, Tian Yang, et al., Haoxing Ren · ISPD 2023 (author copy, NVIDIA Research) · 2023Multi-objective TPE over DREAMPlace parameters; Pareto points on wirelength, density and congestion proxies evaluated in a commercial P&R flow; 2.7M cells and 320 macros in 3 hours on one DGX Station A100.
  8. DRiLLS: Deep Reinforcement Learning for Logic SynthesisAbdelrahman Hosny, Soheil Hashemi, Mohamed Shalan, Sherief Reda · ASP-DAC 2020 (arXiv version) · 2019A2C agent picks among seven ABC transformations; state from AIG statistics; reward targets area under a delay constraint; 13% average area improvement on EPFL arithmetic benchmarks, delay met on 10 of 10.
  9. Chip Placement with Deep Reinforcement LearningAzalia Mirhoseini, Anna Goldie, et al., Jeff Dean · arXiv (preprint of the 2021 Nature paper) · 2020MDP formulation: macros placed one per step on a grid, density mask, reward zero until the last step then negative proxy wirelength plus congestion; edge-based GNN encoder; PPO; pre-training and zero-shot placement.
  10. Assessment of Reinforcement Learning for Macro PlacementChung-Kuan Cheng, Andrew B. Kahng, Sayak Kundu, Yucheng Wang, Zhiang Wang · ISPD 2023 (author-hosted, UCSD VLSI CAD Lab) · 2023Open reimplementation of Circuit Training’s black-box parts, new open testcases, comparison with annealing, analytical placers, a commercial placer and humans; all flows and scripts public; proxy cost poorly correlated with post-route results.
  11. The False Dawn: Reevaluating Google’s Reinforcement Learning for Chip Macro PlacementIgor L. Markov · arXiv · 2023Meta-analysis concluding the RL method lags humans, simulated annealing and commercial software; author biography lists a role at Synopsys.
  12. That Chip Has Sailed: A Critique of Unfounded Skepticism Around AI for Chip DesignAnna Goldie, Azalia Mirhoseini, Jeff Dean · arXiv · 2024Method open-sourced on GitHub; reproductions skipped pre-training, used 20× fewer experience collectors and half the GPUs, did not train to convergence; layouts used in three TPU generations.
  13. GAN-OPC: Mask Optimization with Lithography-guided Generative Adversarial NetsHaoyu Yang, Shuhe Li, Yuzhe Ma, Bei Yu, Evangeline F. Y. Young · DAC 2018 (author-hosted, CUHK) · 2018GAN learns a target-to-mask mapping, pre-trained jointly with ILT; its quasi-optimal masks need fewer conventional OPC steps afterward.
  14. High Performance Graph Convolutional Networks with Applications in Testability AnalysisYuzhe Ma, Haoxing Ren, Brucek Khailany, Harbinder Sikka, Lijuan Luo, Karthikeyan Natarajan, Bei Yu · DAC 2019 (author-hosted, CUHK) · 2019Netlist as a directed graph with [logic level, SCOAP C0, C1, O] node features; two aggregation layers plus FC classifier; GCN predicts hard-to-observe nodes; the same commercial tool reports similar fault coverage with 11% fewer observation points and 6% fewer patterns.
  15. VerilogEval: Evaluating Large Language Models for Verilog Code GenerationMingjie Liu, Nathaniel Pinckney, Brucek Khailany, Haoxing Ren · ICCAD 2023 (arXiv version) · 2023156 HDLBits problems; machine (143) and human (156) descriptions; Icarus Verilog simulation against a reference; pass@k; GPT-4 pass@1 of 43.5% on the human set; pass@1 vs. pass@10 trade-off after fine-tuning.
  16. RTLLM: An Open-Source Benchmark for Design RTL Generation with Large Language ModelYao Lu, Shang Liu, Qijun Zhang, Zhiyao Xie · ASP-DAC 2024 (arXiv version) · 202330 designs; syntax, functionality and design-quality (PPA vs. human reference) goals; passing all test cases does not guarantee correct functionality.
  17. VeriContaminated: Assessing LLM-Driven Verilog Coding for Data ContaminationZeng Wang, Minghao Shao, Jitendra Bhandari, et al., Johann Knechtel · arXiv · 2025CDD and Min-K% Prob applied to VerilogEval and RTLLM; contamination is a critical concern, highest in commercial models such as GPT-3.5 and GPT-4o; mitigation trades off against accuracy.
  18. Comprehensive Verilog Design Problems: A Next-Generation Benchmark Dataset for Evaluating Large Language Models and Agents on RTL Design and VerificationNathaniel Pinckney, Chenhui Deng, Chia-Tung Ho, et al., Haoxing Ren · arXiv · 2025783 engineer-authored problems in 13 categories, agentic and non-agentic; state-of-the-art models reach no more than 34% pass@1 on code generation.
  19. VerilogCoder: Autonomous Verilog Coding Agents with Graph-based Planning and Abstract Syntax Tree (AST)-based Waveform Tracing ToolChia-Tung Ho, Haoxing Ren, Brucek Khailany · AAAI 2025 (arXiv version) · 2024Multi-agent system with syntax checking, simulation and waveform-tracing tools; 94.2% syntactically and functionally correct on VerilogEval-Human v2.
  20. ChipNeMo: Domain-Adapted LLMs for Chip DesignMingjie Liu, Teodor-Dumitru Ene, Robert Kirby, et al. · arXiv · 2023Domain tokenizer, continued pretraining on 23.1B tokens of internal data, SFT, adapted retrieval; chatbot, EDA script and bug-summary uses; DAPT under 1.5% of pretraining compute; A100-hour table.
  21. (Security) Assertions by Large Language ModelsRahul Kande, Hammond Pearce, Benjamin Tan, Brendan Dolan-Gavitt, Shailja Thakur, Ramesh Karri, Jeyavijayan Rajendran · IEEE Transactions on Information Forensics and Security (arXiv author version) · 2024Codex writing SystemVerilog security assertions against golden references; up to 93.55% correct with enough context, 26.54% average across 2,268 prompt types.
  22. LLM4DV: Using Large Language Models for Hardware Test Stimuli GenerationZixi Zhang, Balint Szekely, Pedro Gimenes, et al., Yiren Zhao · arXiv · 2023Coverage-feedback prompting loop for stimulus generation on eight designs; matches or beats naive constrained-random coverage; results vary widely by model on CPU designs.
  23. ChatEDA: A Large Language Model Powered Autonomous Agent for EDAHaoyuan Wu, Zhuolun He, Xinyun Zhang, Xufeng Yao, Su Zheng, Haisheng Zheng, Bei Yu · arXiv · 2023Fine-tuned LLM decomposes requests, writes scripts against an API over OpenROAD and executes them; 50-task benchmark graded blind by human judges; 82% grade A vs. 62% for GPT-4.
  24. Evaluating Large Language Models Trained on CodeMark Chen, Jerry Tworek, Heewoo Jun, et al. · arXiv · 2021HumanEval (164 hand-written problems) and the unbiased pass@k estimator with n ≥ k samples; the 1 − (1 − p̂)^k shortcut underestimates.
  25. EQY: Equivalence Checking with Yosys (Quickstart)YosysHQ · EQY documentationFormal equivalence between a gold and a gate design; partitions the problem; proving strategies such as SymbiYosys with an SMT engine; failing partitions reported with a trace.
  26. EQY StrategiesYosysHQ · EQY documentationThe sat and sby strategies prove partitions by k-induction up to a set depth; k-induction can fail to prove some equivalent partitions; engine and depth options.
  27. Reference for .eqy file formatYosysHQ · EQY documentationRecode sections map FSM state encodings between gold and gate; alternatively state registers are left unmatched and sequential equivalence strategies prove the FSM as a whole.