Verified Silicon from Plain English: Building a Chip Design Orchestrator

A senior chip design engineer spends one to three days taking a standard logic block from specification to a verified, manufacturable layout. Most of that time is not creative work. It is lint loops, testbench scaffolding, formal verification setup, and checklist discipline. We built a system on AWS that does the whole journey, English specification in, GDSII file out, in three to fifteen minutes for one to two dollars per run. This post explains how it works, and more importantly, why you can trust its output.

Anyone who has pointed a frontier model at Verilog knows it can write a plausible FIFO. That was never the hard part. The hard part is that in semiconductors, plausible is worthless. A single escaped bug means a re-spin that costs millions of dollars and months of schedule. So the question that actually matters is not “can AI write chip design code” but “what would it take for a verification lead to sign their name under AI generated silicon.” 

Our answer: the AI must never be the judge of its own work. Not “rarely.” Never, structurally, in a way that is enforced by cloud architecture rather than by prompt engineering. 

That single decision shaped everything else in the system. 

What a run actually produces 

One invocation takes a plain English specification like this: 

• # spec.md 
• Design a SPI master controller supporting modes 0 through 3. 
• Configurable 8 bit clock divider, MSB first transfers, 8/16/32 bit 
• frames, TX and RX FIFOs of depth 16, interrupts on transfer complete 
• and RX FIFO threshold. AXI4 Lite register interface. 

• Formal property: no FIFO overflow or underflow is reachable for any 

legal bus sequence. 

and returns a complete engineering package: synthesizable Verilog RTL, a self checking testbench, Verilator lint results, Icarus simulation results, SymbiYosys formal proofs, a Yosys gate level netlist, an OpenROAD place and route layout with timing closure, a foundry ready GDSII file, and a sign off report that states exactly what was verified and how. Every artifact lands in S3 inside the customer’s own AWS account. Nothing crosses the account boundary, ever. 

The system is thirteen specialized agents hosted on Amazon Bedrock AgentCore, orchestrated by an AWS Step Functions state machine that owns the entire RTL to GDSII flow:

Our first architecture, the one we superseded, used a supervisor LLM to decide “what happens next.” It worked most of the time, which in this domain means it failed. Prompt based routing discipline is weaker than structural enforcement, and an orchestrator that mis-routes one run in two hundred is an orchestrator you cannot certify. Moving control flow into Step Functions eliminated that entire failure class and gave us three things for free: native retry, catch, and timeout semantics; a complete execution history; and an audit trail where you can see exactly which gate produced which verdict on which path. 

The agents that remain are deliberately narrow: an intake agent, a requirements analyst, a design agent, a testbench agent, one runner agent per EDA stage, a fix loop supervisor, a schema validator, a sign off writer, and a notifier. Thirteen agents instead of three is not an aesthetic choice. Each one carries exactly the IAM permissions its job requires. The lint agent can read S3 but cannot invoke Bedrock models. The design agent can invoke models but cannot submit Slurm jobs. If any single agent is ever compromised, its blast radius is its own narrow scope and nothing more.

Here is the heart of the system, and it is almost embarrassingly boring. Every pass or fail decision is made by a Lambda function that parses tool exit codes and log files. No model is in the loop. Same input, same verdict, every time, forever.

# gate_lambda_lint.py — the entire verdict logic for gate λ1 

def handler(event, context): 

  result = read_json_from_fsx(event["lint_result_path"]) 

  verdict = ( 

    result["exit_code"] == 0 

    and result["error_count"] == 0 

    and result["warning_count"] == 0 

    and result["latch_count"] == 0 

  ) 

  record_verdict(run_id=event["run_id"], stage="lint", 

          verdict=verdict, evidence=result)  # → DynamoDB 

  return {"verdict": "PASS" if verdict else "FAIL"}

That is it. The Step Functions Choice state that follows routes on the string this function returns. There is no code path by which LLM output can influence the verdict, because the gate never reads LLM output. It reads what Verilator, Icarus, SymbiYosys, Yosys, and OpenROAD actually did. 

The one sentence version of this whole post: the AI writes the code, and mathematics and EDA tools render every verdict. The separation of powers is enforced in Step Functions and IAM, not in prompts. This is what turns generative AI from a productivity toy into production infrastructure for silicon. 

A useful side effect: model quality regressions become a throughput problem instead of a correctness problem. If we swap Bedrock models via the MODEL_ID variable and generation quality drops, the gates simply fail more designs and trigger more fix loops. A worse model can slow the pipeline down. It cannot produce a false positive verdict, because it was never asked for one.

Simulation tells you the design works for the test cases you thought of. Formal verification tells you a property holds for every possible input sequence, which is a different epistemic category. Each run configures SymbiYosys with the z3 solver against the properties extracted from the spec: 

SBY [prv] base case:   step 0..1         PASS 

SBY [prv] induction:   step 2..8         PASS 

SBY [prv] assertion p_no_overflow   ... PROVEN (depth 20) 

SBY [prv] assertion p_no_underflow   ... PROVEN (depth 20) 

SBY [prv] assertion p_latency_exact  ... PROVEN (depth 20) 

SBY [prv] cover c_full_throughput   ... REACHED (step 11) 

“PROVEN to depth 20” means the solver has mathematically verified the property for all input sequences up to twenty clock cycles. And when the solver instead finds a counterexample, that counterexample is a gift: a constructive proof of a bug, with the exact input sequence that triggers it. The gate Lambda extracts it and hands it to the fix loop, which brings us to failure handling. 

Failure is the normal case for generated code, so the pipeline treats it as a first class path rather than an exception: 

• A gate returns FAIL with evidence: a lint error, a simulation mismatch, a formal counterexample, or an inferred latch. 
• The supervisor agent classifies the failure and produces correction guidance. The design agent revises the RTL. 
• Before the pipeline re-enters expensive stages, two cheap validation gates run: a schema validator confirms the payload is well formed, and a compile check gate confirms the revised files are syntactically valid. No burning Slurm hours on code that does not parse. 
• The loop is bounded at three iterations by default. On exhaustion, the run escalates via SNS to a human instead of looping forever. 

One deliberate asymmetry: place and route failures do not auto retry at all. Timing violations and congestion usually require human design decisions, a floor plan change or a constraint relaxation, so they escalate immediately. An honest system knows which failures it should not try to fix.

An AES-128 place and route run wants 32+ GB of RAM and sustained CPU for twenty minutes. That is HPC class compute, and pretending otherwise is how demos die on contact with real designs. Heavy stages run as Slurm jobs on AWS Parallel Computing Service: simulation on c7g.4xlarge nodes, place and route on m7g.8xlarge nodes, both auto scaling from zero to a configured cap and back to zero when idle. 

The quiet hero is FSx for Lustre. Place and route performs thousands of small random reads and writes; S3’s per request latency of 50 to 100 milliseconds would make it ten to one hundred times slower. FSx gives every PCS node and every agent the same POSIX filesystem at /fsx with sub millisecond latency, so the simulation stage writes results and the place and route stage reads them with zero copying between stages. Lightweight operations, lint, compile checks, small design synthesis, skip the cluster entirely and run in-image on the agent container to keep latency down.

Everything above runs on open source EDA: Verilator, Icarus, SymbiYosys, Yosys, OpenROAD, all validated against the SkyWater Sky130HD open PDK. But enterprises run Synopsys and Cadence, so every tool invocation goes through a single adapter contract. Swapping Verilator for VCS, or SymbiYosys for JasperGold, is a configuration change. Zero modifications to the state machine, the agents, or the prompts. You bring the license and the endpoint; the system routes jobs there.

All three pass lint, simulation, formal verification, synthesis, and place and route with timing closure on Sky130HD. Against the manual baseline of one to three days per block, that is a 100 to 300 times speedup on wall clock time for the routine majority of front end work. 

Ninety percent or more of the variable cost is Bedrock reasoning tokens, which is exactly the shape you want: you pay for intelligence, and the infrastructure scales to zero around it.

For calibration: a senior design engineer costs $200K to $400K per year fully loaded and produces one to three verified blocks per week. The system produces a verified block in minutes for the price of a coffee. It does not replace the architect who decides what to build. It removes the queue behind that decision.

We are precise about the boundary because the trust model depends on it. Novel microarchitecture, complex timing closure, custom analog, and bleeding edge process node optimization still require human judgment. The system targets the routine 60 to 70 percent of front end block work, the FIFOs, bus interfaces, encryption cores, and state machines that follow well understood patterns, and its sign off report states explicitly what was verified and what was not. An optional human approval gate can be enabled for regulated or first silicon flows, pausing the pipeline before sign off for explicit review. 

Move control flow out of the model. If an LLM routes your pipeline, your pipeline’s reliability is bounded by prompt adherence. A state machine’s is not. 

Make verdicts deterministic and separate. The component that judges must have no code path to the component that generates. Enforce it with IAM, not instructions. 

Buy proofs where they are cheap. Formal verification looks exotic, but for standard blocks it is a solved toolchain and it upgrades “passed our tests” to “cannot fail for any input.” 

Bound your loops and escalate honestly. Three fix iterations, then a human. Systems that know when to stop are systems people learn to trust. 

Respect physics. Some stages need HPC compute and a real filesystem. Slurm on PCS plus FSx Lustre is not glamorous; it is why the AES core actually routes. 

Try it. The Chip Design Orchestrator deploys into any AWS account with Bedrock model access in us-east-1 or us-west-2 in roughly 25 minutes via a single script. If you want a live walkthrough of the pipeline, the deterministic gate design, or the path to running it against your commercial EDA stack, write to[email protected]. 

Amazon Bedrock AgentCore for the 13 agents. AWS Step Functions for control flow, with pure Python Lambda gates and Choice states rendering every verdict. AWS Parallel Computing Service running Slurm for simulation (c7g.4xlarge) and place and route (m7g.8xlarge). FSx for Lustre as the shared POSIX filesystem at /fsx. S3, DynamoDB, and SNS for artifacts, verdict records, and escalation. Open source EDA throughout: Verilator, Icarus, SymbiYosys with z3, Yosys, and OpenROAD, validated on the SkyWater Sky130HD open PDK, with an adapter contract for commercial Synopsys and Cadence tools. 

CodeNinja builds production AI infrastructure that customers own, customize, and harden inside their own boundary. The Chip Design Orchestrator is part of our AWS practice; it was validated end to end on the SkyWater Sky130HD open PDK.

This is a live demonstration built on the Hyper Anthologies ecosystem. If you wish to request one for your business fit, please reach out to us at [email protected], or visit our website.