Re: [Gems-users] Dynamic link latency changein FILE_SPECIFIEDtopology

["Arseniy Vitkovskiy" <arseniy.vitkovskiy@xxxxxxxxx>]

Hi Niket,

Thanks for your feedback.

> How would this happen in real life and what is the event in which you
> foresee a link dynamically changing it's latency? Depending on that,
one
> can implement either (a) or (b).

I work on a project which deals with fault-tolerance for NoCs. So I need
to simulate different scenarios and FT mechanisms when faults
dynamically appear in communication links.

> If you think that this update can be done in a single cycle, you need
> not freeze the entire simulation. You can just do all the work in the
> update cycle. But, if you think this will take longer you need to
stall
> the processing that is going on. I don't know how that can be done.
May
> be someone else has done it earlier.

Maybe this can be implemented even locally. When it is time for a link
to update its latency, the upstream router pauses its pipeline for one
or few cycles required in order to update the respective record in the
link_latency table, while the entire simulator keeps its normal
functionality. After such local update, the router resumes its pipeline.

Kind regards,
Arseniy 
 

> -----Original Message-----
> From: gems-users-bounces@xxxxxxxxxxx [mailto:gems-users-
> bounces@xxxxxxxxxxx] On Behalf Of Niket Agarwal
> Sent: Tuesday, July 06, 2010 11:31 AM
> To: gems-users@xxxxxxxxxxx
> Subject: Re: [Gems-users] Dynamic link latency changein
> FILE_SPECIFIEDtopology
> 
> Hi Arseniy,
> 
>      Below is my comments on your proposals.
> 
> -Niket
> 
> > 1. In the topology specification file instead of writing only link
> > latency value, a time-and-latency pair should be stated for each
link.
> > The time in cycles would refer to the moment when link latency must
be
> > updated, e.g.
> >
> > ...
> > int_node:0 int_node:1 time: 0 link_latency:1 time: 100000
link_latency:
> > 3 link_weight:1
> > ...
> >
> > 2. Then all these pairs are written in array in a timeline manner in
> > order to schedule the update events.
> >
> Yes, this is the cleanest way to do if you know in advance when the
link
> latencies will change.
> 
> > 3. The first difficulty may appear if link_latency must be updated
while
> > a flit is in flight in this link. Here I see two solutions:
> >
> > a) A solution that seems to be easier to implement. If link buffer
is
> > occupied with a flit we reschedule the link_latency update time for
a
> > later moment when the link buffer is released.
> > b) More difficult solution would be to implement a retransmission
scheme
> > which would require an output buffer with depth not smaller than max
> > link_latency.
> >
> 
> How would this happen in real life and what is the event in which you
> foresee a link dynamically changing it's latency? Depending on that,
one
> can implement either (a) or (b).
> 
> > 4. During the latency update event, first SIMICS must be paused
(what is
> > the mechanism to pause SIMICS?), then all events in GEMS must be
frozen
> > (this probably can be done with scheduling?). After that the
> > link_latency table (maybe also routing table) is updated and
simulator
> > returns to its normal functionality with the updated link_latency
> > values.
> >
> If you think that this update can be done in a single cycle, you need
> not freeze the entire simulation. You can just do all the work in the
> update cycle. But, if you think this will take longer you need to
stall
> the processing that is going on. I don't know how that can be done.
May
> be someone else has done it earlier.
> _______________________________________________
> 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.