Jump to content

sc_vector and sc_event_queue


tjd

Recommended Posts

Hello,

 

I am trying to use the following structure to set up a set of event queues:

sc_vector<sc_event_queue> event_lists;

and then have the following structure within my module

SC_METHOD(writer);
for (int i=1; i <= NMAX; ++i)
  sensitive << event_lists[i];

to define the sensivity list for my writer method (yes, I know I indexed from 1...index 0 is used in a different method).

 

With this in mind, some questions:

Is there any way in "writer" to identify which list item (or items) in the sc_vector triggered the execution of the process?

 

Assuming multiple items in event lists may be triggered to occur in a given delta cycle (e.g, both event_lists[2] and event_lists[5] should trigger the method in cycle t), is this an appropriate method of handling them or would they occur in cycles t and t+1?  If not, what is the proper/best approach for handling this?

 

As a bit of further background, I am essentially trying to create an NxN crossbar network where when a packet arrives on input X, I put an event on the queue (via notify) to write a packet to output Y after some delay.  My main goal is to have N be parameterizable as I will want/need to check different values of N.

 

Thanks,

Tim

Link to post
Share on other sites

Is there any way in "writer" to identify which list item (or items) in the sc_vector triggered the execution of the process?

 

No, unfortunately, there is no API to determine which events have fired and triggered the execution of a given process.  You need to add additional information to your system, e.g. by storing the value of sc_delta_count for each event notification and check its value in the triggered process (which is how the event() method of sc_signal works internally).  Immediate notifications are even more difficult to track reliably.

 

Assuming multiple items in event lists may be triggered to occur in a given delta cycle (e.g, both event_lists[2] and event_lists[5] should trigger the method in cycle t), is this an appropriate method of handling them or would they occur in cycles t and t+1?  If not, what is the proper/best approach for handling this?

 

Yes, the method would be evaluated once, even if multiple events from the sensitivity list fired in the same update phase (notify(SC_ZERO_TIME);).  So this could be an appropriate modeling style. Again, immediate notifications are more difficult to handle reliably: Here, the method may be triggered twice in the same evaluation phase, depending on the (implementation-defined) order of evaluation of runnable processes.

 

hth,

  Philipp

Link to post
Share on other sites

Thanks for the assist.  I was assuming that I would need to track additional information, but given that I'm relatively new to SystemC, I was hoping I had missed a shortcut.  Alas, no such luck.

 

I shouldn't be dealing with any immediate notifications, so those won't be an issue.

Link to post
Share on other sites

From spending a few minutes with the LRM, it looks like that could be a possible solution.  As I am pretty ignorant regarding TLM, I might need some extra assistance.

 

My first question would be how to use/structure the payload and transaction type?  For my current needs, I would just need an integer to identify which of the incoming ports my data packet was coming in on (we are using a custom packet structure).  Is this doable, and if so, how would one acutally implement it?

 

To develop the idea further, it seems like I would replace the event_lists.notify(t) with m_peq.notify(in_port, t).  Then, the SC_METHOD(writer) would become a SC_THREAD(writer) with a clk.pos sensitivity and the writer function would handle event checking (m_peq.get_event()) and read the transaction type (from m_peq.get_next_transaction()) to know which incoming ports have a valid message at the current clock.  Is this a resonable starting point or am I way off base?

 

Thanks,

Tim

Link to post
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...