`syn` does not infer latches — silently emits a combinational loop

Summary

OpenROAD's integrated synthesis (sv_elaborate + synthesize) does not infer level-sensitive latches. A standard transparent-latch RTL pattern (always @* if (clk) q = d;) is treated as a combinational loop and "fixed" with a loop_breaker, producing a netlist with zero sequential elements and no warning. Yosys infers the latch correctly from the identical source.

Minimal reproducer

latchtest.v:

module latchtest (clk, d, q);
  input  clk, d;
  output q;
  reg    q;
  always @* if (clk) q = d;   // transparent-high D latch: q holds when clk==0
endmodule

Synthesize with the integrated flow:

read_liberty asap7sc7p5t_*.lib
sv_elaborate --top latchtest latchtest.v
synthesize

Observed

Build succeeded: 0 errors, 0 warnings
loop_breaker: 1 cells, 1 bits
[INFO SYN-0056] liveness: replaced 0 register bits, 0 combinational bits

The result is pure combinational logic — no latch cell (e.g. asap7 DHLx1) is instantiated. The latch's hold path is implemented as a combinational loop broken by a loop_breaker.

The identical result (loop_breaker / 0 register bits, no latch) occurs with an explicit sensitivity list, always @(clk or d) if (clk) q = d; — so this is not a sensitivity-list coding issue.

Expected

A latch cell is inferred (as the equivalent yosys flow does). On asap7, the same source through yosys yields exactly one DHLx1_ASAP7_75t_R.

Impact

Any latch-based design is silently mis-synthesized into combinational loops, with no synthesis-time error.

Workaround

Use the yosys synthesis path (in ORFS: SYNTH_USE_SYN=0, the default), which infers latches correctly.

Environment

• OpenROAD 4c26918f5a (26Q2-2270); also reproduces on master b442cabf87 (2026-06-26).
• Platform: asap7. Linux x86-64, gcc 13.3, RELWITHDEBINFO build.