Closed ucbjrl closed 4 years ago
We should also debate whether the right thing to do is to drop the --noCombLoop option instead.
@aswaterman Dropping the --noCombLoop option would not be a good choice in my opinion, since many designs that make use of combinational loops actually still work fine in the emulator. (I myself have a project that requires them, and with some workarounds it actually functions) Removing the option would also discourage progress toward a new emulator which actually can emulate combinational loops.
@JackDavidson I was actually arguing for the opposite (make checking for combinational loops mandatory), but you make a valid point.
Making a C++ emulator that supports combinational loops isn't on the radar, but there are, of course, plenty of event-driven Verilog simulators that can cope.
retest this please
Closed due to chisel2 retirement.
If we enable the --noCombLoop option, the generated C++ code fails to compile since we emit local declarations as they are encountered and we end up with forward references. One can argue that we shouldn't support simulation of designs with combinational loops, but if we're going to allow the code to be generated, we shouldn't impede its compilation.