how to wait on multiple timed events and determine the event

[scottf]

I am fairly new to SystemC and am looking for a better way to solve my problem.

 

In my simulation, I have a set of "resources".  I also have a process that accepts requests (using a sc_fifo) and if there is an available resource, farms it out to that resource.  The resource "works" on the request for a set of time, then gives it back to the dispatcher.  The thing is, for the simulation, the "resource" doesn't actually have to do any work, I just need it to delay for a set amount of time (the time can be different per request).

 

A way to do this is have each resource be a process.  The dispatcher would send the request to the resource, which would wait the required time, then send the request back.  In this way the dispatcher would do nb_read on each response sc_fifo and could do a wait on all sc_fifo written events.  The problem is this seems like a lot of overhead just to have something delay and then tell the dispatcher the delay is done.

 

I was looking at the sc_event, and have each resource just be an event.  However, you can't determine which event triggered.

 

So, is there a lightweight way to have my "resources" just wait and then notify my dispatcher when the time has expired, and allow my dispatcher to have multiple of these outstanding and know which one triggered, without making each resource a process?

 

Thanks.

[dakupoto]

I am fairly new to SystemC and am looking for a better way to solve my problem.

 

In my simulation, I have a set of "resources".  I also have a process that accepts requests (using a sc_fifo) and if there is an available resource, farms it out to that resource.  The resource "works" on the request for a set of time, then gives it back to the dispatcher.  The thing is, for the simulation, the "resource" doesn't actually have to do any work, I just need it to delay for a set amount of time (the time can be different per request).

 

A way to do this is have each resource be a process.  The dispatcher would send the request to the resource, which would wait the required time, then send the request back.  In this way the dispatcher would do nb_read on each response sc_fifo and could do a wait on all sc_fifo written events.  The problem is this seems like a lot of overhead just to have something delay and then tell the dispatcher the delay is done.

 

I was looking at the sc_event, and have each resource just be an event.  However, you can't determine which event triggered.

 

So, is there a lightweight way to have my "resources" just wait and then notify my dispatcher when the time has expired, and allow my dispatcher to have multiple of these outstanding and know which one triggered, without making each resource a process?

 

Thanks.

Hello Sir,

There are two types of events -- explicit and implicit. For the first

type, a 'wait - notify' pair is used, in which a process 'waits' on a

specified event, and then does some operations. The second

involves sensitivity lists. The explicit event tracking scheme

depends works fine if the programmer has very carefully and

manually tracked each event -- with a large number of events

in the event queue, a few might be lost.. Implicit event handling

is far less demanding on the programmer, and depends on the

runtime kernel for tracking events. So, one would have to first 

decide which scheme to use. Hope this helps.

[Dineshkumar]

Hi,

 

You can try any of these options

1) Use of TLM 2.0 PEQ. It provides a very simple way to deal with your requirements at the cost of bringing in extra tlm headers/libraries

2) Use of sc_event _queue. Requester can schedule this event queue with resource specific delay and dispatcher can be made sensitive to this event. With the use of sc_event_queue, you can ensure new event schedule is not overriding prev ones.Identification of resource at dispatcher side is possible if  the resource object carries an extra filed of initiated time stamp and dispatcher simply compares current time stamp with resource initiated time stamp+resource specific delay. 

 

Regards,

Dinesh.