Combinational loop causes a forward referencing compile error in C++ simulation

[ascenium]

This sample code is greatly chopped down from the actual reconfigurable logic design the bug was found in.

This bug is a showstopper for reconfigurable logic designs of anything but trivial complexity.

testelement.scala.txt

[donggyukim]

C++ simulators cannot be compiled with comb loops.

[ascenium]

That's simply not true. Many simple examples containing hardware that could be configured in a combinatorial fashion work just fine.

The problem I indicate with this bug report is trivially simple to fix. All you have to do is move all wire definitions to the top of the function.

[ascenium]

It's been over a month since I opened this bug and actually told you guys specifically what you needed to change in your C++ behavioral model generator to fix it, and nobody has even been assigned to work on this. Do you guys just not care about the workability of the C++ models you generate? Do you mostly go straight to testing the generated Verilog on the Synopsis tools you have? I'm just trying to understand whether the C++ model back end is actually supported at all. Thanks in advance for any response.

[albert-magyar]

Moving declarations or definitions might fix compile-time errors, but the Chisel C++ simulation model depends on the ability to provide a linearization of the update graph for one clock cycle at elaboration time. This is how Chisel avoids the need for event queues or other sensitivity logic.

Therefore, fixing your compile-time problem would not guarantee correct operation -- this is why Donggyu correctly stated that we do not aim to support hardware with combinational loops in C++ simulation.

We do care about the workability of C++ models for RTL that does not contain combinational loops. However, the output of either C++ or Verilog is not guaranteed to be correct for circuits violating this principle.

[ascenium]

Thanks for your explanation. It was unclear to me from earlier comments that this was the breakdown.

I'm willing to work towards adding a new or alternative event-based C++ simulation generator that also handles circuits that can be configured to be combinational and therefore are not linearizable. I envision it containing settable limits to prevent runtime oscillations from locking up the simulation.

I see there is already some preliminary info in the Google group page regarding how to approach adding an alternative C++ model generator.

I've updated my profile to make it easier to contact me directly.