abc_new traps (wasm 'unreachable') on a design with zero primary I/O

[robtaylor]

Found running the origins flow on real input via Jacquard's RTL on-ramp, which uses the patched stack (gpu-eda/yowasp-yosys → robtaylor/yosys@src-retention-y-ext → robtaylor/abc@origin-tracking-clean). Logging here since this repo is the real-world harness for berkeley-abc/abc#487.

Symptom

A design that reaches abc_new with no primary inputs and no primary outputs hard-traps:

16. Executing ABC_NEW pass.
...
27: 0x116f4 - <unknown>!<wasm function 27>: wasm trap: wasm `unreachable` instruction executed

The invocation (from Jacquard's synth.rs):

scratchpad -set abc9.origins_max 100
abc_new -script +&dch,-f;&nf -liberty aigpdk_nomem.lib

Minimal reproducer

module noports_constclk ();
  wire a = 0; wire b = 0; reg q = 0;
  always_ff @(posedge a) q <= b;
endmodule

(This is chipsalliance/sv-tests tests/chapter-9/9.2.2.4--always_ff.sv, an expected-pass test. slang reports Build succeeded: 0 errors, 0 warnings; the design then optimizes away because nothing is observable.)

Bisected: the trigger is zero primary I/O

Not the constant clock, and not "empty design" — both of my first two hypotheses were wrong:

variant	ports	clock	result
as above	none	const	TRAP
+ output reg q	1 out	const	fine
+ input a as clock, no output	1 in	real	fine
input a, input b, output reg q	2 in, 1 out	real	fine

• The constant clock is irrelevant — the output reg q variant keeps the same dead constant clock and survives.
• "Empty" isn't it either — that surviving variant synthesizes to 0 mapped cells (just assign q = 1'h0) and does not trap.

One port of either direction is enough to avoid it. So abc9 appears to be handed a network with 0 PIs, 0 POs, 0 nodes, and &dch,-f;&nf hits unreachable on it.

Open question: is this ours or stock?

Unknown, and it matters — if &origins isn't implicated, this shouldn't go anywhere near #487.

I tried to A/B against a stock YoWASP wheel and the comparison is blocked, which is worth recording on its own: stock yowasp-yosys 0.67 won't load under the consumer's wasmtime config —

failed to parse WebAssembly module: exception refs not supported without
the exception handling feature (at offset 0x50)

— so it ran 0 passes and never reached abc_new. It failed for an unrelated reason, not because it's immune.

Ways to settle it:

• build a stock-abc wasm from this flake (same wasmtime feature set) and run the reproducer, or
• run the reproducer against native stock abc with &dch,-f;&nf on an empty network, outside wasm entirely.

If stock also traps, it's an upstream empty-network bug and belongs to berkeley-abc rather than #487. If only the patched abc traps, it's the origins work and should be fixed before #487 lands.

Severity

Low for real designs — a portless module is testbench-shaped, and any real DUT has ports. Its practical effects are:

• it rules out chipsalliance/sv-tests as a corpus (its tests are overwhelmingly portless compile-only modules); and
• a wasm trap gives the consumer ~27 frames of <wasm function 32210> with nothing indicating synthesis failed. That's being fixed consumer-side (synth: abc_new wasm-traps on a design that optimizes to empty gpu-eda/Jacquard#211), but a clean abc-side error would be better than a trap regardless.

Downstream tracking: gpu-eda/Jacquard#211.

[robtaylor]

Triage: ruled out "it's the wasm build, not abc"

Worth recording, because it's a reasonable first theory and it's now excluded.

The theory. Our yosys.wasm has no TAG section — confirmed by walking the binary's sections:

sections: type, import, func, table, mem, global, export, elem, code, data
TAG section (wasm exception handling) present: False

Stock yowasp-yosys 0.67, by contrast, is built with wasm EH — which is why it won't even load under our wasmtime config (exception refs not supported without the exception handling feature). In a build without EH, a C++ throw lowers to unreachable — exactly the trap we see. So the trap could plausibly have been abc raising an ordinary error that our build simply couldn't unwind, making it a packaging bug rather than an abc bug.

The test. If that were the mechanism, any yosys error would trap too, since log_error is the same C++ machinery. Forcing a mundane one:

$ jacquard sim ok_mod.sv … --top-module no_such_module
ERROR: Module `no_such_module' not found!
exit 1

Clean error, no trap, same no-EH wasm.

Conclusion. Yosys's error path doesn't depend on unwinding here, so the absent TAG section isn't what turns the abc_new failure into unreachable. The trap is a genuine abort() / failed assert / crash inside abc, on a network with 0 PIs / 0 POs / 0 nodes.

Ours-vs-stock abc remains the open question — this only rules out the packaging explanation.

One build detail still worth checking, since it changes what the fix looks like: whether abc's assert()s are compiled in (i.e. NDEBUG unset) in this wasm. If the trap is an assert firing, abc is detecting the bad state and the fix is a graceful rejection. If asserts are compiled out and it still traps, something is dereferencing off the end of an empty network — a worse bug, and one that could be silently corrupting rather than trapping in an NDEBUG build elsewhere.

[robtaylor]

Narrower culprit: ABC9, not abc_new top level

Consumer-side error reporting now reads Yosys's own log on a trap (gpu-eda/Jacquard#213), which pins the failure one level deeper than my hand-bisection did:

the synthesis engine crashed (wasm trap: wasm `unreachable` instruction executed)
  it died in: 16.5.4. Executing ABC9.

So the trap is inside the ABC9 sub-pass under abc_new, rather than abc_new's own driver code. That should narrow where to look when settling the ours-vs-stock question — and it's consistent with the &dch,-f;&nf script being handed a 0-PI/0-PO network.