AI-Driven Layout-Aware RTL Optimization Workflow

This work came out of the NYU and CogniChip hackathon in February 2026, which focused on AI-assisted chip design and practical RTL workflows. Our team explored how to make the iteration loop around RTL design less manual by connecting simulation, synthesis, timing analysis, and patch suggestions in one tighter workflow.

Hackathon context

The hackathon was organized with CogniChip as an industry collaboration around AI-first semiconductor design. Teams were asked to work at the RTL level, use modern EDA workflows, and submit simulation results, a presentation, a demo video, and a repository link as part of the final evaluation.

What we built

We built a workflow that runs Verilator, Yosys, and OpenSTA in sequence, collects the relevant outputs, and uses an LLM-guided patching step to propose the next edit candidates. The goal was not to replace hardware reasoning. It was to reduce repeated setup work and make each design iteration easier to inspect.

How the loop worked in practice

The useful part of the workflow was that each tool fed the next one without forcing the person debugging the design to keep rebuilding context from scratch. Verilator handled linting and simulation, Yosys turned the RTL into a synthesizable netlist, OpenSTA surfaced timing pressure, and the Python wrapper collected those outputs into one reviewable packet before the next patch was proposed.

In a normal short hackathon cycle, a lot of time disappears into small repeated actions: rerunning simulation, opening different logs, figuring out whether a failure is functional or timing-related, and translating that context into the next change. The workflow compressed that into one repeatable pass. Instead of “run one tool, open another, copy notes, then think,” the loop became “run the stack, inspect one summarized result, decide what to patch next.”

How the loop worked

Each pass ran linting and simulation, then synthesis and timing analysis, and finally packaged the most useful feedback into a form that was easier to review. That structure mattered more than a single benchmark number because it made the next engineering decision clearer during a short hackathon window.

Why the workflow mattered

The project was not trying to claim a solved optimization engine in one weekend. What it did show was that the manual design loop around RTL work can be shortened meaningfully if the verification, synthesis, and timing steps are treated as one tooling surface instead of three separate chores. That is the part that made the project worth keeping on the site.

It also fit a pattern that shows up in the rest of my work. Whether the system is a backend API, an ML workflow, or an RTL toolchain, I tend to care about the same question: where is the actual bottleneck in the loop, and how do we remove the unnecessary coordination cost around it?

What I would improve next

A stronger version of this project would track loop-time reduction explicitly, separate simulation failures from timing failures more cleanly in the summary layer, and keep a history of candidate patches so the next suggestion can build on what already failed. I am intentionally not claiming a precise percentage reduction here because the hackathon version was more about workflow compression than about a stable benchmark.

Why I kept it on the site

I keep this write-up because it reflects one part of my systems interests that does not show up in the rest of the portfolio as often: developer tooling around hardware workflows. Even though it was a hackathon build, it connects naturally to the same instinct behind my backend and ML systems work.