Why AI Hardware Engineering Needs Precise Unknowns

A device was supposed to drive a shared connection high. The expected 1 never appeared.

An experienced hardware engineer immediately has several possibilities to investigate. The device may be driving the wrong value. It may have released its output. Another device may be driving against it. Those possibilities lead to different checks and different repairs.

An AI agent needs the same distinctions. If its observations collapse them into a convenient binary value, its investigation starts with information already missing.

At Memdance, we are building an AI-first hardware engineering environment, and we spend time on details this small. How uncertainty reaches an engineering decision matters. A single signal can carry the clue that separates a useful repair from a change that merely makes a test pass.

Four-state logic is established engineering practice. Verilog has long modeled 0, 1, X, and Z, and SystemVerilog's distinction between binary and four-state types goes back to its early design. VHDL's standard logic package defines nine values, including distinctions for initialization and drive strength. These concepts have decades of engineering history behind them.

The question for an AI-operated workflow is whether those distinctions remain available when an agent needs to use them.

One Missing Bit, Different Investigations

Consider two devices sharing a connection. Each can drive a value or release its output. In a simple digital model with equal-strength drivers and no pulls, the outcomes include:

These are digital modeling rules. A physical connection also depends on electrical characteristics such as pulls and receiver thresholds.

Suppose the intended behavior requires B to drive 1, but the observation is Z. An investigation should examine whether B enabled its output and whether the expected connection exists. If the observation is X, conflicting drivers are one possibility worth checking. Other sources of indeterminacy remain possible, so the symbol alone is not a diagnosis.

When Conversion Erases the Clue

Now suppose a conversion replaces both observations with 0. The agent sees a definite low value. It might investigate the data calculation while overlooking the output enable or competing driver. A more capable model cannot reconstruct information that was discarded without obtaining additional evidence.

For the engineer reviewing a proposed repair, the distinction is practical. Did the device actually drive zero, or did the execution model substitute zero? Did a competing driver disappear, or did the check stop observing it? Did the repair restore the intended behavior, or change the assumptions under which the behavior was judged? A passing result is useful only in the context of what was checked.

An Unknown Bit Is Not the Same as X

There is another distinction beneath the word “unknown.” A binary variable whose value is unknown still has a consistent value: for either possible assignment, b XOR b is zero. Applying a four-state logic table to X XOR X can instead produce X. The first calculation reasons about correlated binary possibilities; the second evaluates an indeterminate logic symbol. They answer different questions. An engineering workflow needs to know which question its tools answered.

Dancer and Verilator: Different Execution Semantics

This is a useful point of comparison between Dancer, our simulation and emulation technology, and Verilator.

Verilator documents that it is mostly a two-state simulator. Explicit X assignments are replaced with binary values according to the selected policy, with options for randomization that can help expose initialization bugs. It also supports some tri-state constructs, with specific handling of high impedance. Verilator explains these behaviors, including the options controlling substitution.

Dancer's supported gate-level simulation uses four-state values. An indeterminate result can remain X, and high impedance is modeled separately from a binary zero or one. Operations determine how those symbols propagate. For an investigation that depends on observing uncertainty, this gives the engineer or agent an observation to investigate without first treating that uncertainty as a definite bit.

Randomized binary execution and four-state execution can reveal different problems. Keeping X visible does not guarantee that every initialization defect will be detected, and a successful randomized run does not establish behavior for every initial state. The useful comparison starts with the question being tested and the meaning of each result.

We have previously described Dancer's role in carrying a hardware experiment across execution and replay. Our checkpoint and resume experiment examines how to preserve execution and its observations across interruption. In both settings, an observation must retain enough meaning to support the decision that follows it.

A Better Basis for the Next Decision

Our view is that AI agents make these contracts more consequential. When an agent can inspect a result, propose an edit, and launch another run, an unnoticed assumption can influence several successive decisions. Keeping uncertainty visible gives that loop a better basis for choosing what to inspect and whether a change is justified. It does not, by itself, establish that the agent will diagnose the problem correctly.

This is the level of care we are putting into Memdance. We want AI-assisted engineering to preserve the distinctions a careful hardware engineer would use to investigate a failure. That ambition reaches all the way down to a single observed bit, and to knowing when the available evidence does not establish whether it is zero or one.