[Gems-users] profileMsgDelay function

[Byn Choi <bynchoi1@xxxxxxxxxxxx>]

Hello-

I have a question regarding one of the profile functions.

void Profiler::profileMsgDelay(int virtualNetwork, int delayCycles)

which is defined in profiler.[Ch], seems to take the virtual network  
number that is associated with the MessageBuffer that is being  
profiled. However, in MESI_SCMP_bankdirectory*.sm files, I see some  
inconsistencies. I just wanted to confirm whether my understanding of  
this function is correct.
For instance,

MESI_SCMP_bankdirectory-L1cache.sm has...
...
  MessageBuffer requestToL1Cache, network="From",  
virtual_network="1", ordered="false";
...
  in_port(requestIntraChipL1Network_in, RequestMsg, requestToL1Cache) {
...
  action(l_popRequestQueue, "l", desc="Pop incoming request queue and  
profile the delay within this virtual network") {
    profileMsgDelay(2,  
requestIntraChipL1Network_in.dequeue_getDelayCycles());
  }
...

MESI_SCMP_bankdirectory-L2cache.sm has...
...
  MessageBuffer unblockToL2Cache, network="From",  
virtual_network="4", ordered="false";
...
  in_port(L1unblockNetwork_in, ResponseMsg, unblockToL2Cache) {
...
  action(k_popUnblockQueue, "k", desc="Pop incoming unblock queue") {
    profileMsgDelay(0, L1unblockNetwork_in.dequeue_getDelayCycles());
}
...

If my understanding is correct, requestIntrachipL1Network_in is  
associated with virtual_network="1", but the profiling code seems to  
insert the data into the virtual network #2. Similar story in L2 as  
well (actual network #4, but profiled into #0).
I'm using GEMS 2.1.1.

Byn