Our Ambition: Rethinking Hardware Engineering with AI

Memdance began with a single core question: What parts of the hardware development stack would we design differently today if AI agents were first-class users of the system?

Memdance is building an AI-first hardware engineering stack spanning design capture, semantic IR, compilation and transformation, execution, netlist generation, verification evidence, and agent-facing interfaces. The key architectural idea is that these layers share consistent identities and semantics rather than behaving as loosely coupled tools.

The project grew out of experience spanning software systems engineering, silent data corruption, and chip verification and validation. That background led us to focus not just on hardware itself, but on the software infrastructure used to represent, verify, debug, and reason about hardware.

We are not starting from the premise that existing Electronic Design Automation (EDA) systems are primitive. Modern EDA tools are the result of decades of engineering and contain exceptionally sophisticated capabilities across simulation, formal verification, debugging, synthesis, and signoff.

Our central question is: Can these complex workflows become significantly easier to automate if semantic state and verification evidence are exposed directly to AI agents, rather than reconstructed indirectly from raw source code, log files, and tool output?

That is the architectural experiment behind Memdance.

The Premise: Beyond Generation

Much of the current discussion around AI and hardware focuses on generation:

• Can a model write RTL?
• Can it generate testbenches?
• Can it suggest localized code fixes?

While text generation is useful, generation alone does not yield an autonomous engineering workflow.

An agent must also understand the design, investigate failures, reason about verification status, distinguish assumptions from established facts, and verify whether a proposed repair actually resolves the underlying root cause. Our working hypothesis is that this reasoning becomes more reliable when design meaning, identity, and evidence remain connected across the whole engineering flow.

One Stack with Shared Meaning

Our architectural thesis is that the whole stack shares a common semantic substrate. The value comes from preserving the connection between design intent, transformed artifacts, observed behavior, and verification results as work moves between layers.

Rather than treating parsing, semantic analysis, transformation, execution, netlist generation, verification, and AI interaction as separate islands, we are designing them as parts of one system with shared semantic identity and evidence.

The current implementation exposes structured design facts including:

• Resolved types and value boundaries
• Drivers and dependency graphs
• Clock domain assignments
• Module hierarchy and instantiation contexts
• Provenance tracing back to source constructs
• Verification obligations and assertions
• Context across design transformations

The underlying design principle is straightforward: an agent should never need to reconstruct information the engineering stack already knows.

If an agent needs to identify what drives a signal, that relationship should be queryable directly. If it needs to determine which clock domain a state element belongs to, that should be an explicit attribute. When a design changes, an agent must be able to determine which engineering observations and results remain relevant.

The aim is to make compilation, execution, netlist analysis, and verification results useful together. An observation at one stage should remain connected to the design and the engineering requirement it concerns.

Scoped Verification Evidence

Another core principle in Memdance is that verification results must retain their exact operational scope:

• A passing simulation is not a proof.
• A bounded model check remains bounded.
• An environmental assumption remains an assumption.
• An unresolved obligation remains unresolved.

Rather than flattening verification outputs into a binary pass/fail status, Memdance records verification obligations alongside the exact boundary of evidence associated with them.

For AI-driven workflows, this distinction is critical. An agent must be able to ask not only "Did this check pass?" but also "What exactly was established, under what assumptions, and what obligations remain unproven?"

Case Study: A Semantic Debugging Loop

The FIFO case study tests one architectural property of this broader stack: whether an implementation-level failure can remain connected to the correct design behavior and verification requirement across transformations. It is a controlled experiment in identity and evidence, with the bounded scope described in the full case study.

In one experiment, an independent specification model monitors a lowered netlist and flags an output discrepancy. The system then executes an automated loop:

Observe → Localize → Investigate → Repair → Verify

1. Observe: The system captures the failing output bit, time step, and net.
2. Localize: Compiler infrastructure helps locate the relevant design behavior and hardware memory path.
3. Investigate: The engine links the origin to its source provenance and associated verification obligation.
4. Repair & Verify: Candidate repairs are evaluated, and the failing scenario is re-executed alongside broader checks.

Testing Identity vs. Coincidence

The key test is not whether an agent can fix a simple block. The test is whether the trace remains valid when the design representation is altered.

To verify this, we deliberately perturb test cases: flattening hierarchies, renaming internal signals, shifting source locations, and adding decoy structures. If the investigation engine still targets the correct semantic objects, it confirms the agent is navigating compiler-maintained identities rather than relying on textual patterns or naming conventions.

What We Believe Is Different

Existing EDA flows often have powerful tools at each stage. Modern tools already offer advanced debugging, formal engines, transformational guidance, and design databases. Memdance is experimenting with a more integrated model in which the layers are designed together and share engineering meaning throughout the workflow.

The whole stack shares a common semantic substrate. Design intent, transformations, execution, implementation artifacts, verification evidence, and agent interaction belong to one connected engineering system.

Designed for AI First

The frontend, IR, execution model, netlist machinery, verification model, and agent interfaces are being designed together so that AI agents can operate on structured engineering state throughout the flow.

AI interaction is part of the architecture from the start. An agent should be able to follow an investigation across stages, understand the scope of a result, and evaluate whether a repair addresses the relevant engineering requirement.

Compiler infrastructure is an important part of this work, alongside execution, verification, and the interfaces through which agents interact with the system. The FIFO experiment highlights the compiler's role because it specifically tests identity across transformations; the company ambition spans the whole stack.

Human Direction and Interoperability

Memdance is being designed for AI-first and cloud-first workflows while retaining interoperability with existing engineering tools and standard artifacts such as SystemVerilog.

Over time, our objective is to enable AI agents to assume responsibility for larger portions of the design, investigation, and verification loop, while human engineers direct architectural intent, system boundaries, and final signoff.

Looking Ahead

Memdance remains an ongoing engineering experiment. Scaling this architecture to production workloads presents major open challenges across design scale, physical implementation (PPA), compute economics, and toolchain integration.

We intend to address these challenges experimentally: making claims, building the underlying machinery, attempting to falsify our assumptions, and retaining only what survives contact with real hardware workloads.

As our reproducible demonstrations mature, we will continue sharing our progress, failed iterations, and architectural learnings publicly.

Welcome to Memdance.