[hlstool] `noAlwaysComb` lowering option does not seem to work with `hlstool`

[thoughtpolice]

While exploring the toolset and fiddling around with Calyx/CF code, I found this:

func.func @main(%arg0 : i32, %arg1 : i32) -> i32 {
  %0 = arith.cmpi slt, %arg0, %arg1 : i32
  cf.cond_br %0, ^bb1, ^bb2
^bb1:
  cf.br ^bb3(%arg0 : i32)
^bb2:
  cf.br ^bb3(%arg1 : i32)
^bb3(%1 : i32):
  return %1 : i32
}

$ ./bin/hlstool --calyx-hw --verilog test02.mlir --lowering-options=noAlwaysComb | grep always_comb
  always_comb begin     // test02.mlir:1:1
  end // always_comb

The above was done with a download of firtool-1.112.0 from the releases page.

This is problematic because unfortunately yosys is very anal about this issue and absolutely refuses to synthesize if this is the case:

3.4.8. Executing PROC_DLATCH pass (convert process syncs to latches).
ERROR: Latch inferred for signal `\control_main.\state_next' from always_comb process `\control_main.$proc$control_main.sv:0$2'.

Though it's unclear to me if it's actually a yosys bug (other synthesis tools apparently accept it?) I also might be holding hlstool wrong too.

[thoughtpolice]

I edited the title because on second thought I'm not sure if this is --calyx-hw specific, it's just what I was testing.

[KelvinChung2000]

The problem with the current hlstool is that some options do not apply to the all flow. Likely, those options only work for the dynamic-hw flow (did some quick check and it seems to be the case).

always_comb implies the "process" will not have any latches. So it is right that yosys will not throw an error. A quick fix would be to just replace the always_comb with always @(*).

But it is also likely that the lowering process is generating that error. It does not set a value in all possible combinatorial paths (which lead to latches). The Calyx backend is primarily maintained in a separate repo. If you generate the Verilog from there, it is more likely to work.