link latency / jitter simulation

[charlesdaniels]

It should be possible to simulate links with a particular latency and jitter. Links should have an ordered queue used to store the flits that are in-flight. Additionally, flits should have a time to arrival counter which can be used to simulate an arbitrary additional delay. Consider the following example, where 3,1,1,2 would indicate that the head of the queue (next arriving flit) has a delay of 2 cycles, the second from the head has a delay of 1 cycle, and the tail a delay of 3 cycles. An X in the dequeued column indicates that the head of the queue is popped off on that cycle.

cycle	queue state (head →)	dequeued
n	3,1,1,2
n+1	3,1,1,1	X
n+2	3,1,1	X
n+3	3,1	X
n+4	3
n+5	2
n+6	1	X
n+7

Additionally, these features should be exposed via the TCL scripting interface. I propose that the route command should be extended to add an optional argument for the delay field, with the default being 1. This would allow the user to use any arbitrary TCL procedure to define the additional delay induced at any given link.

Note that the delay should be cleared in between hops (i.e. setting a flit's delay before it traverses some particular link has no bearing on it's delay while traversing any other link before or after).

[charlesdaniels]

Actually, the jitter information should probably be stored in the links.

There should be a new method in simulation.c named nocsim_link_enqueue() which unconditionally enqueues a given flit to a given link. Links need to be annotated with an additional char* behavior field which will store a procedure name. If the behavior field for the link is non-null when a flit is enqueued, then the flit's time to arrival field should be set to the return value (of the behavior), and otherwise to a default that preserves the current behavior.

Information about the current link should be exposed to the TCL interpreter via a new currentlink procedure, which should return a list of the [src, dest] node IDs for the link the behavior pertains to (this procedure would be specific to link behaviors). A currentlink member may need to be added to nocsim_state to facilitate this.

Additionally the link procedure should be updated with an optional argument to specify a link behavior, and the behavior procedure should be updated to also allow re-configuring link behaviors at run-time.

This is all in lieu of the route changes.