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