About Simulator

[chykon]

Hello! There are two questions:

1. Why is Simulator not an abstract class? Is there any use case for the Simulator object?
2. Why is Simulator a static class? So the user is limited to one simulation context. If the state of the simulation were stored in an object, the user could create as many simulation contexts as needed.

[mkorbel1]

Why is Simulator not an abstract class? Is there any use case for the Simulator object?

It should be abstract, good point! I'm not sure how that was missed. Opening an issue/PR for it would be a good idea, which I can do if you don't feel like it

Why is Simulator a static class? So the user is limited to one simulation context. If the state of the simulation were stored in an object, the user could create as many simulation contexts as needed.

There are a variety of constructs during a simulation that need to reference a single central simulator. For example, sequential logic (e.g. Sequential) needs to know when to sample a signal and when to drive an output based on clock edges. The event based simulation in ROHD is inherently "glitchy" in that signals will often have multiple intermediate incorrect values before settling to a final correct value. The simulator phases allow the sequential logic to know when it's safe to sample and drive values. If the simulator was an object instead of globally accessible, we'd need a mechanism to communicate the correct Simulator instance to each instantiated sequential object. Any other object that the Simulator would also need a reference. This could also extend to portions of testbenches which would then need to pass references to the Simulator object throughout.

There are some other ways to implement this that could support multiple instances, but interaction between Simulator objects would be complicated or broken, since coordination wouldn't be there for signals crossing domains owned by different instances.

There are some nice benefits to having different Simulator objects independently running simultaneously. If you have some elegant ideas to implement this architecture change we could consider them! The solution implemented in ROHD should be easy for developers who just want to develop hardware. A default behavior should probably look a lot like it currently looks, unless there's something even simpler.

I think if you use Dart isolates you could have multiple safe and independent Simulators running simultaneously effectively on separate threads without any changes to current architecture.

[chykon]

Thanks for answers! Opened issue with a suggestion to make the Simulator class abstract.

After your explanation, the motivation for choosing such an architecture became clear. In case you're wondering, I was thinking something like this:

• Create an instance of Simulator (final sim = Simulator();)
• Register Logic to be simulated by sim (sim.addLogic(logic);)
• Iterate through all associated Logic and find all elements that need to pass a reference to sim (sim.trace();)
• That's it - now sim is responsible for simulating that part of the circuit that was passed to it.

But this is all very superficial and naive. There is also the problem of resolving conflicts when interacting with several instances of Simulator, which you wrote about, and the developer will have to spend more effort explicitly setting up the simulator.

[mkorbel1]

Perhaps the build step could be a reasonable place to expect the user to pass an instance of a Simulator, if desired. It's an interesting suggestion and maybe sometime it would be worth implementing if we have a good use case for it.