Writing RTL is getting easier. Getting from RTL to hardware/chips that actually work is the tough part. I spent some time going through openTPU by @BonettoSens... basically an open-source AI accelerator built with AI agents, running around 10 modern LLMs on a Kintex-7 FPGA. It has a Python simulator, ISA/compiler, RTL, FPGA implementation and actual tokens coming out of the card. For essentially a one-person project, really impressive work. A few thoughts on what I think the next steps would look like if something like this were taken further... 1. FPGA prototype vs ASIC/SoC implementation: Taking this into an ASIC/SoC would be a fairly large engineering step... Right now the implementation is naturally shaped around the Kintex-7 FPGA, DSPs/BRAMs, DDR3 + LiteDRAM etc, and currently closes around 133 MHz with WNS +0.032 ns. The ISA/compiler ideas can obviously move over, but the actual implementation would need quite a bit of rethinking. SRAM macros, memory hierarchy, clocks/resets, DFT/MBIST, power, floorplanning, timing, IR/EM, physical sign-off etc etc. And once you remove the FPGA constraints, you also get a lot more parameters to play with... different compute architecture? different buffering? different memory hierarchy? same quantization datapath? same compute/memory balance? This is basically the design-space/search-space problem I wrote about in my previous post. Once you give yourself more freedom, the number of possible implementations grows VERY quickly. So there is a pretty large architecture + design-space exploration problem here before you even get to implementation. 2. Verification + coverage closure: The verification setup is already pretty useful... the RTL is checked against the Python simulator with random + model-level workloads, and having that executable reference is a good foundation. If this were being pushed toward ASIC/SoC though, I would probably add a much deeper verification layer around it. Matching the simulator tells you the executions you ran were correct, but you still want to know what you DIDN'T hit. Back-pressure, arbitration, reset sequences, unusual instruction combinations, less-used modes, boundary conditions etc. I couldn't find a systematic assertions/formal/coverage closure flow in the repo, so it is difficult to know how much of that state space has actually been exercised. There is also the X-state side of this... most of the flow relies on Verilator, which is mostly 2-state. For an ASIC/SoC flow I would still want an X-sensitive 4-state pass somewhere, along with assertions, coverage, some formal, CDC/RDC etc on top of what is already there. 3. Engineering + scaling the workflow: The project is also clearly optimized around one person moving quickly... which makes sense, and honestly makes the amount that has been built here more impressive. If this eventually became a project with 5 or 10 engineers changing the RTL/compiler/microarchitecture at the same time, the surrounding engineering infrastructure would naturally have to grow with it. Faster presubmit tests, deeper regressions, reproducible environments, CI, coverage tracking etc. Not really a criticism of the current setup, just a different problem once a project goes from one person moving fast to a larger team working on it. 4. AI agents + the hardware loop: This is actually my main takeaway from the project... the interesting part is not really that an AI agent can write RTL. Claude, Codex and other coding agents can already do that, and they will obviously keep getting better. What matters is the loop around them. Agent changes the hardware, simulator gives you a reference, RTL gets checked, synthesis/PPA gives you another signal, implementation gives you another, and the agent goes back and changes the design again. That is where I think specialized hardware tooling starts to matter. Not necessarily because we need a completely different model for hardware, but because the agent needs hardware-specific feedback. Did it preserve functionality? Did coverage improve? Did timing get better? Did area go down? Did power get worse? Did the change still survive synthesis and physical implementation? If your only feedback is "did this match the simulator on these tests?" then that is basically the problem the agent will learn to solve. Give it assertions, coverage, formal, X-sensitive simulation, timing/PPA and physical implementation feedback... and now you are actually giving it a much better definition of what a good hardware design is. Overall though, really impressive proof of concept, especially for one person. A lot of the things above are really just the next set of problems you run into when moving from a working FPGA prototype toward a larger ASIC/SoC engineering effort. If you want to understand how an AI accelerator goes from Python/software all the way down to RTL and actual FPGA hardware, this is a really good repo to go through end to end: github.com/FeSens/openTPU