Open rachitnigam opened 3 years ago
Looks like the resource-sharing
pass causes this problem. Running the benchmark with -d resource-sharing
generates valid verilog and generates the right values.
Minimal test case:
import "primitives/core.futil";
component main(@go go: 1, @clk clk: 1, @reset reset: 1) -> (@done done: 1) {
cells {
add10 = std_add(32);
add7 = std_add(32);
add8 = std_add(32);
add9 = std_add(32);
r1 = std_reg(32);
r2 = std_reg(32);
}
wires {
group upd33 {
add7.left = 32'd0;
add7.right = 32'd0;
add8.left = 32'd0;
add8.right = add7.out;
r1.write_en = 1'd1;
r1.in = add8.out;
upd33[done] = r1.done ? 1'd1;
}
group upd34 {
add9.left = 32'd0;
add9.right = 32'd0;
add10.left = 32'd0;
add10.right = add9.out;
r2.write_en = 1'd1;
r2.in = add10.out;
upd34[done] = r2.done ? 1'd1;
}
}
control {
seq {
upd33;
upd34;
}
}
}
https://github.com/verilator/verilator/issues/3146 could be the potential problem
Argh, resource sharing might be a fundamentally broken pass. It might only make sense to share sequential components.
@sampsyo @EclecticGriffin and I discussed this problem and we agree that the generated code is "valid" in that the combinational loop is stable. However, we need to do some digging before we can decide what the right steps are here.
Two things to do:
The unrolled MVT benchmarks generates invalid verilog: