History log of /gem5/src/mem/ruby/network/garnet2.0/NetworkInterface.cc
Revision Date Author Comments
# 13736:e678df1f0bf2 22-Feb-2019 Srikant Bharadwaj <srikant.bharadwaj@amd.com>

ruby: Fix garnet's round robin arbitration for vc selection

Garnet utilizes round robin policy to select a VC for
transmission ar Network Interface and Routers. The current logic
for round robin is only fair if all the virtual networks are active
at a given router. If the router or network interface is not
receiving traffic in from any vnet then the priority is always taken
up by the next vnet in numerically (or loops back to 0).

This fix changes the way we perform round robin arbitration. When
a VC is selected in a cycle, the round robin pointer is set to the VC
next to it and is iterated from there on. If any VC does not have a
flit in a given cycle, it will lose its turn until the next round.
At maximum traffic this will model round robin correctly even if
a certain VNET is not active at that unit.

Change-Id: I9bf805221054f9f25bee14b57ff521f4ce4ca980
Reviewed-on: https://gem5-review.googlesource.com/c/16688
Reviewed-by: Jieming Yin <Jieming.Yin@amd.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>


# 11797:f61fbb7ceb88 19-Jan-2017 Matthew Poremba <matthew.poremba@amd.com>

ruby: Check MessageBuffer space in garnet NetworkInterface

Garnet's NetworkInterface does not consider the size of MessageBuffers when
ejecting a Message from the network. Add a size check for the MessageBuffer
and only enqueue if space is available. If space is not available, the
message if placed in a queue and the credit is held. A callback from the
MessageBuffer is implemented to wake the NetworkInterface. If there are
messages in the stalled queue, they are processed first, in a FIFO manner
and if succesfully ejected, the credit is finally sent back upstream. The
maximum size of the stall queue is equal to the number of valid VNETs
with MessageBuffers attached.


# 11795:588a45268ce4 19-Jan-2017 Matthew Poremba <matthew.poremba@amd.com>

ruby: Check all VNETs for injection in garnet NetworkInterface

The NetworkInterface wakeup currently iterates over all VNETs and breaks the
loop if a VNET is unable to allocate a VC. This can cause a deadlock if a
lower numbered VNET is unable to allocate a VC while a higher numbered VNET
has idle VCs. This seems like a bug as Garnet 1.0 uses a while loop over an
if-statement, suggesting the break was intended for this while loop. This
patch removes the break statement, which allows up to one message to be
dequeued from a VNET and injected into the network.


# 11762:29d401db3746 15-Dec-2016 Jieming Yin <jieming.yin@amd.com>

ruby: Detect garnet network-level deadlock.

This patch detects garnet network deadlock by monitoring
network interfaces. If a network interface continuously
fails to allocate virtual channels for a message, a
possible deadlock is detected.


# 11666:10d59d546ea2 06-Oct-2016 Tushar Krishna <tushar@ece.gatech.edu>

ruby: garnet2.0
Revamped version of garnet with more optimized single-cycle routers,
more configurability, and cleaner code.