#
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.
|