Wait for all other processes

[plafratt]

I am facing a dilemma with the scheduling of SystemC processes. I have a feeling it is because I have erred in my design approach and wanted to see if someone could offer some guidance.

Say that you have a SystemC thread that arbitrates transactions that arrive through multiple FIFOs. The threads that enqueue the transactions into the FIFOs are untimed. When a request arrives at an input FIFO of the arbiter, the arbiter gets notified. At this point, the arbiter does not know which of the FIFOs will eventually get a transaction in it at this time stamp. We'd like to wait until all of the other threads have executed before the arbiter proceeds to make its arbitration decision.

As I understand, one way to do this would be just to make a bunch of wait(SC_ZERO_TIME) calls. But this seems a bit like a hack, for various reasons (e.g., what if later, there are more untimed processes added upstream from the input threads? Then the arbiter has to add more wait(SC_ZERO_TIME) calls to account for these).

I am wondering if this would just be considered a bad design. Since real hardware takes time for activity to occur, perhaps this is not the intended use of the delta scheduling in SystemC. Or, maybe I am just approaching this in the wrong way? Any help is appreciated.

[David Black]

Create:

sc_event arbiter_event;

All arriving processes push to their respective fifo and immediately post:

queue.push(data);
arbiter_event.notify(SC_ZERO_TIME);

Arbiter waits for the event and processes all fifo’s upon receipt. 

[David Black]

Due to the design of sc_event there will only be one event for a given delta cycle. 

[plafratt]

Thank you for the helpful response.

I believe I need to think this over a little more. I am still not entirely clear on how the arbiter should handle the case where one of the input threads may not check in during a given arbitration cycle, as the arbiter cannot make its arbitration decision until it is sure that all of the input threads that will check in have done so.

[Bas Arts]

On 9/27/2021 at 5:56 PM, plafratt said:

the arbiter does not know which of the FIFOs will eventually get a transaction in it at this time stamp

22 hours ago, plafratt said:

as the arbiter cannot make its arbitration decision until it is sure that all of the input threads that will check in have done so

I deduct from this that somewhere in your design, timing is involved, most probably in the part that triggers/feeds the input threads. If not, your simulation would finish in zero time + x delta cycles, which "at this time stamp" seems to contradict.

So, you have to define what "at this time stamp" means. Is it exactly the simulation time at which the first FIFO notifies the arbiter? In that case, David's solution applies. Do you have clocks (e.g. wait statements with time indication) in your design? Maybe your arbiter can only be sure at the end of a clock cycle? Maybe another part of your design must tell the arbiter that "at this time stamp" has finished, and the arbiter can assume that no new transactions will come in?

[plafratt]

Your logic is sound in your conclusion that there is some time in the model. For the purpose of the example, we can assume that after the arbiter thread makes a decision, it waits a fixed amount of time, say sc_time(1,SC_NS). The intent is to have the arbiter wait to be sure that all input threads that will insert into their input FIFOs at this timestamp have done so.

I think I understand what you are saying about having another part of the design (call it the "notifying_thread") tell the arbiter that "at this time stamp" has finished. But, if the requirement is that this notifying_thread waits until all of the input threads that will be activated have been activated, I don't know that SystemC natively provides a way to do this, since the order in which the notifying_thread and the input threads get activated is non-deterministic.

One approach that I think might work, given the guidance provided above, would be to design the input threads such that when one wakes up, they will all wake up, even if some of them don't insert into their corresponding FIFOs. Each thread sets a "done" variable to indicate that it has woken up. The notifying_thread executes wait() statements in a loop until all of the "done" variables are set. Then the notifying_thread clears all the threads' "done" variables.

Although, I admit that it seems not very elegant. I suspect there might be a better way.

Thanks to both of you for the helpful input.

[Bas Arts]

Using the "notifying_thread" as you describe, simply shifts the issue from the arbiter to the notifying thread and therefore doesn't solve it. The fixed amount of waiting time in the arbiter is also arbitrary (no pun intended) as you indicated that the input FIFOs are untimed.

Hence, we need more details about your design to solve it elegantly. Can you share a picture of all modules involved, their interconnections and their inner timings?