About event-driven simulation

[chensx00]

Hello, may I ask if this simulator is parallel event-driven or serial event-driven?

[whitequark]

I don't understand the question, sorry. Can you explain what you mean by those terms?

[chensx00]

"Serial event-driven" refers to events being executed strictly in the order they are triggered, even if they are triggered at the same timestamp. In this case, there are no conflicts or race conditions between events.

"Parallel event-driven" refers to multiple events being scheduled and processed simultaneously. The simulator may need to utilize multithreading, and it will need to address the concurrent issues that come with it.

I apologize if my questions seem a bit unusual, as I am new to the field of HDL simulators. :>

[whitequark]

I am still unsure exactly how to classify Amaranth's simulator between the two, so I'll attempt to explain how it works instead. The following explanation is slightly simplified to omit an aspect that's not critical to your question.

During each simulation step (which may advance time, or may happen in zero time), two phases are run:

1. Eval. In this phase, all of the scheduled computations are executed, and their results are written down but do not yet affect the simulation state.
2. Commit. In this phase, no simulation behavior happens. Only the written down results are used to update the simulation state. The updates may trigger additional computations, which are scheduled to be executed in a future eval phase.

Generally, the eval/commit loop is repeated while there is still anything to update, then the time is advanced to the next closest delay.

Hope this helps!

[whitequark]

Ah, I should mention that the purpose of doing it in two phases is that this way, the order of scheduled computation does not matter. They could happen in any order, or in fact they could happen in parallel. There is no real advantage to computing them in multiple threads in Python, so they're done serially in an arbitrary order. The order can change between runs because it is a set() data structure which doesn't guarantee iteration order, but because of the construction of the simulator, the results are deterministic anyway.

This construction is inspired by VHDL, though VHDL does it a bit differently (there is a guaranteed mapping in VHDL from HDL constructs to how many delta cycles they take, whereas in Amaranth this is undefined).

[chensx00]

Thank you for your explanation of Amaranth's mechanism, it has been very helpful! I think I will categorize it as "parallel" because, logically, the events being executed can be considered "parallel," as you mentioned, the order in which computations are scheduled doesn’t matter.

Thank you for your response!