Hi Arseniy,
The router pipeline should definitely be paused in case the link
cannot take additional flits. Buffering flits at the source is not a
practical design. And you are correct that the SA stage should not allow
the switch to be won for output ports that are "busy."
Regarding your proposal:
1) The source queue of the output link is full, OR
2) There is only one emty place in the source queue AND there is one
flit at ST stage AND there is no flit which is going to leave the
In hardware, source queue is like a latch and at all times there
would be only one flit present in it. The reason it is a queue in my
design is because of the event-driven nature of GEMS: another flit might
be put in the source queue while the one supposed to go out the current
cycle hasn't left. I suppose you can assign a maximum sourceQueue size
of 2 and do checks in SA to model back-pressure in pipeline.
In hindsight, I should have thought about this issue and included
in the release.
-Niket
On 4/1/2010 8:58 AM, Arseniy Vitkovskiy wrote:
Hi Niket,
I think I found a solution for the first question. After rescheduling
the link for the current flit I also reschedule the link for all flits
that are waiting in the source cure. This is something similar to your
check_for_wakeup function. I hope this operation is eligible. I put the
code below so that other people could use it to serialize (de-pipeline)
link latency.
However the second question concerning pipeline pausing is not resolved
still.
void NetworkLink_d::wakeup()
{
if(link_srcQueue->isReady())
{
if (linkBuffer->isEmpty() ||
linkBuffer->isReady())
{
flit_d *t_flit = link_srcQueue->getTopFlit();
t_flit->set_time(g_eventQueue_ptr->getTime() + m_latency);
linkBuffer->insert(t_flit);
g_eventQueue_ptr->scheduleEvent(link_consumer, m_latency);
m_link_utilized++;
m_vc_load[t_flit->get_vc()]++;
}
else
{
g_eventQueue_ptr->scheduleEvent(this, 1);
}
}
//Reschedule all flits in the source queue
for (int i = 0; i< link_srcQueue->get_size(); i++)
g_eventQueue_ptr->scheduleEvent(this, 1);
}
Kind regards,
Arseniy.
-----Original Message-----
From: gems-users-bounces@xxxxxxxxxxx [mailto:gems-users-
bounces@xxxxxxxxxxx] On Behalf Of Arseniy Vitkovskiy
Sent: Wednesday, March 31, 2010 5:56 PM
To: Gems Users
Subject: Re: [Gems-users] Garnet Network parameters
Hi Niket,
I reschedule the link for the next cycle if linkBuffer is not empty
and
there are no outgoing flits (please, see the code below). However, I
checked the traces and I saw that several last flits are lost. Maybe
this happens when link rescedulings for the flits that are waiting in
the source queue are overlapped? Could you suggest a solution?
void NetworkLink_d::wakeup()
{
if(link_srcQueue->isReady())
{
if (linkBuffer->isEmpty() ||
linkBuffer->isReady())
{
flit_d *t_flit = link_srcQueue->getTopFlit();
t_flit->set_time(g_eventQueue_ptr->getTime() +
m_latency);
linkBuffer->insert(t_flit);
g_eventQueue_ptr->scheduleEvent(link_consumer,
m_latency);
m_link_utilized++;
m_vc_load[t_flit->get_vc()]++;
}
else
{
g_eventQueue_ptr->scheduleEvent(this, 1);
}
}
}
Another thing is that the source queue grows infinitely because flits
arrive in the source queue every cycle but they leave it ever N cycles
(where N is downstream link latency).
Therefore, the router pipeline must be paused (I think, during SA
stage). In my opinion the pipeline should be paused at SA stage if
either of the two following points is true:
1) The source queue of the output link is full, OR
2) There is only one emty place in the source queue AND there is one
flit at ST stage AND there is no flit which is going to leave the
source
queue next cycle.
There is a function which manages transition from SA to ST stage: void
SWallocator_d::arbitrate_outports(). Probably the changes should be
implemented here.
Could you please comment about this pipeline pausing mechanism and how
it can be implemented.
Kind regards,
Arseniy.
-----Original Message-----
From: gems-users-bounces@xxxxxxxxxxx [mailto:gems-users-
bounces@xxxxxxxxxxx] On Behalf Of Niket Agarwal
Sent: Friday, March 26, 2010 5:17 PM
To: Gems Users
Subject: Re: [Gems-users] Garnet Network parameters
I think the link can reschedule itself the next cycle by something
like g_eventQueue_ptr->scheduleEvent(this, 1).
On Mar 26, 2010, at 5:17 AM, Arseniy Vitkovskiy wrote:
Hi Niket,
I have similar problem. I performed the linkBuffer checking and
now
I
need to reschedule the link to the next cycle. How should I do
that?
Kind regards,
Arseniy.
-----Original Message-----
From: gems-users-bounces@xxxxxxxxxxx [mailto:gems-users-
bounces@xxxxxxxxxxx] On Behalf Of Niket Agarwal
Sent: Thursday, October 15, 2009 6:58 AM
To: Gems Users
Subject: Re: [Gems-users] Garnet Network parameters
You should check if the linkBuffer is empty or has a flit which
will
leave this cycle. You are checking the link_srcQueue!
If neither of the condition is true, which means that no flit is
being
picked up form the link_srcQueue, I think you would also need to
reschedule the link the next cycle.
-Niket
On Oct 14, 2009, at 11:16 PM, Edward Lee wrote:
Thanks for the tip. I followed the guidelines as suggested in
the
link
and came up with the following. Anything I am missing?
void NetworkLink_d::wakeup()
{
if(link_srcQueue->isEmpty())
{
flit_d *t_flit = link_srcQueue->getTopFlit();
t_flit->set_time(g_eventQueue_ptr->getTime() + m_latency);
linkBuffer->insert(t_flit);
g_eventQueue_ptr->scheduleEvent(link_consumer, m_latency);
m_link_utilized++;
m_vc_load[t_flit->get_vc()]++;
}
else
{
flit_d *t_flit = link_srcQueue->getTopFlit();
if((t_flit->get_time())<= (g_eventQueue_ptr->getTime()))
{
t_flit->set_time(g_eventQueue_ptr->getTime() +
m_latency);
linkBuffer->insert(t_flit);
g_eventQueue_ptr->scheduleEvent(link_consumer,
m_latency);
m_link_utilized++;
m_vc_load[t_flit->get_vc()]++;
}
}
}
-- Ed
On Wed, Oct 14, 2009 at 7:52 PM, Niket Agarwal
<niketa@xxxxxxxxxxxxx> wrote:
You can model lower bandwidth links as you said. Please follow
https://lists.cs.wisc.edu/archive/gems-users/2009-April/
msg00076.shtml
-Niket
Edward Lee wrote:
Hi all,
I would like to verify the meaning of some simulation
parameters
to
come up with realistic network parameters.
I am running a 2GHz serengeti machine with 16 processors using
MOESI_SMP_directory protocol to simulate a 16-core CMP with
private
caches.
Here are some configuration values:
SIMICS_RUBY_MULTIPLIER: 4 --> does this mean Ruby clock is
2GHz/4
= 0.5GHz?
network is 4x4 MESH via GARNET
g_FLIT_SIZE: 16
a snapshot of network parameters:
....
ext_node:L1Cache:0 int_node:0 link_latency:1
ext_node:Directory:0 int_node:0 link_latency:4
int_node:0 int_node:1 link_latency:8 link_weight:1
...
So, since FLIT_SIZE refers to bytes/cycle and it is suggested
to
tune
the latencies for lower bandwidths. Would it be accurate to
make
the
following assumtions?
16 bytes/cycle * 0.5 Ghz / link_latency = link_bandwidth
Accordingly,
bandwidth to caches 8GB/s, bandwidth to memory/directory 2
GB/s,
bandwidth between cores is 1GB/s
Thanks for any input in advance,
Ed
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding
"site:https://lists.cs.wisc.edu/archive/gems-users/
" to your search.
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding
"site:https://lists.cs.wisc.edu/archive/gems-users/
" to your search.
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding
"site:https://lists.cs.wisc.edu/archive/gems-users/
" to your search.
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding
"site:https://lists.cs.wisc.edu/archive/gems-users/"; to your
search.
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding
"site:https://lists.cs.wisc.edu/archive/gems-users/
" to your search.
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding
"site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding
"site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}