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.
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}