HackStack

Project Info

Etch

Devpost

Inspiration

AI-generated code is everywhere, but hardware design has a uniquely unforgiving constraint: if a software script fails, you patch it; if a chip fails, you've wasted millions of dollars. We noticed that while LLMs can generate plausible-looking SystemVerilog that compiles, it often violates subtle safety properties. We were inspired by the gap between generation and trust. We didn't want to build just another AI wrapper that spits out code; we wanted to build a system where the AI's work is relentlessly interrogated and formally proven before it ever sees silicon.

What it does

Etch is a verification-first hardware design cockpit. You give it a natural-language hardware requirement (like a synchronous FIFO), and Etch doesn't just give you one answer—it generates multiple candidate designs. Crucially, it then acts as a rigorous judge. It runs these candidates through a gauntlet of actual, industry-standard EDA (Electronic Design Automation) tools for simulation, formal verification, and synthesis. If a candidate has a bug (like an underflow error), Etch disqualifies it and shows you exactly why. It then ranks the surviving, proven designs by physical metrics like area size, and packages the entire run into an inspectable "proof dossier." It turns an ambiguous AI output into a falsifiable, trustworthy hardware artifact.

How we built it

We designed Etch from the ground up to prioritize evidence over claims. We built a polished, Apple-like desktop workbench (using React) that makes the complex chip design loop feel legible. Instead of focusing purely on the LLM prompt engineering, we focused on the evaluation pipeline. We integrated real open-source verification tools (like SymbiYosys and Icarus) and created strict rules: correctness is a hard eligibility gate. Area or timing metrics cannot rescue a candidate that fails formal verification. We also intentionally separated the AI generation from the "oracle" that tests it, ensuring the system grades the AI's homework honestly.

Challenges we ran into

Building trust in an automated hardware workflow is incredibly difficult. Hardware engineers are naturally (and rightfully) skeptical of AI. Our biggest product challenge was designing an interface that didn't hide failures or overclaim success. We had to figure out how to clearly communicate complex states—like when a tool is missing, when a design is formally falsified, or when evidence is just a proxy—without overwhelming the user with a generic, unreadable dashboard. We had to resist the urge to use "fake green success states" and ensure every UI element pointed directly to the underlying proof.

Accomplishments we're proud of

We're incredibly proud that Etch actually catches AI mistakes. In our demo, we purposefully introduce a candidate with a subtle underflow defect, and the system successfully catches it, formally falsifies it, and provides a counterexample—exactly what a human verification engineer would demand. We are also proud of the cockpit's design. We achieved our goal of making the interface feel premium, exacting, and calm. We proved that you can take the incredibly dense, noisy world of hardware verification and make it accessible to a technical founder while remaining rigorous enough for an EDA-fluent engineer.

What we learned

We learned that in the era of AI, generation is cheap, but evaluation is invaluable. The true durable product isn't the AI model writing the Verilog; it's the evidence-producing pipeline and the trust rules wrapped around it. We also learned how critical "evidence-first design" is—users only trust the automation if they can instantly click through to see the exact logs, gates, and constraints that produced the result.

What's next

Right now, Etch is a polished vertical slice. Next, we want to expand it to handle a wider array of complex hardware components. We also plan to integrate the final stages of physical signoff (like OpenROAD for place-and-route and Magic for DRC/LVS) so that Etch can take a natural language prompt all the way to a routed, signoff-ready GDS file. Ultimately, we see Etch becoming the default desktop workbench where the next generation of silicon is designed, proven, and trusted. For the Token Company track, we extended this same evidence-first philosophy to agent context itself. Etch's hardware-agent traces — specs, RTL, testbenches, formal properties, failed checks, counterexamples, logs, and synthesis reports — are exactly the kind of evidence-heavy history where sloppy compaction is dangerous: dropping the wrong invariant or failure leaves a future agent continuing from a false view of the design. We used these traces as the substrate for exploring hardware-aware compaction, comparing behavior against systems like Caveman, OpenCode, and Codex-style workflows, with DiffusionGemma as our model direction since its bidirectional attention is well suited to judging which facts and relationships across a long trace are worth preserving. The goal is a learned compressor that treats compaction not as a token-saving trick but as a correctness problem — one where the compacted state still preserves the proof-relevant facts an agent needs to continue correctly.

Analysis

Compare with all teams

View

Metric

Figures cover GitHub contributors during the hackathon window. A co-authored commit counts in full for each author, so per-member totals add up to more than the whole-team figures.

Technology

Found in codeClaimed only
  • CSSIn code
  • FastAPIIn code
  • HTMLIn code
  • JavaScriptIn code
  • PythonIn code
  • ReactIn code
  • Tailwind CSSIn code
  • TypeScriptIn code
  • AnthropicClaimed
  • DockerClaimed
  • Google GeminiClaimed
  • OpenAIClaimed

8 of 12 appear in the indexed code. 4 claimed on Devpost could not be matched to code, which may simply mean the tool leaves no trace in the repository.

AI coding agents

  • Claude CodeCommits
  • CursorCommits

Detected from committed agent config files and commit authorship. Absence of a signal is not proof an agent was unused.

Codebase size

Source size

5.7 MB

Source files

593

Counts recognized source files only; vendored directories, binaries and lockfiles are excluded, so this is smaller than the repository on disk.

0 stars