The lectures on NoC deadlocks on my website might help understand the problem:
By default any VC can be selected as you rightly pointed out.
This means a cyclic dependence can form leading to a deadlock.
To avoid it, one technique is to partition the VCs into 2 halves, and require all flits crossing a specific link to switch from the first half to the second half. Flits can cross from VC 0 to VC 1, but not from VC 1 to VC 0, thereby ensuring no cyclic dependence.
To implement this, you need to hack into the VC select code.
[The same holds true in Garnet1.0 as well - it will also deadlock with a Torus].
If you want to use a Torus topology, this is something that needs to be implemented and not supported out of the box in garnet (yet).
On Jul 24, 2017, at 10:36 AM, F. A. Faisal <***@gmail.com<mailto:***@gmail.com>> wrote:
The default weight based routing selects the free VC.
If so, then why I need to do the VC partitioning as you mentioned in the Torus network.
VC Selection (VS): The winner of SA selects a free VC (if HEAD/HEAD_TAIL flit) from its output port.
I think this is a very important issue for all the users of garnet 2,0.
I would like to solve this.
On Mon, Jul 24, 2017 at 11:21 PM, F. A. Faisal <***@gmail.com<mailto:***@gmail.com>> wrote:
Thanks a lot for reply.
This is little bit terrible news for me.
However, as far I know garnet1.0 don't have the deadlock issue with Torus.
Please let me know how can I implement a VC partitioning scheme. Is it possible?
I can configure the routing algorithm with particular channel selection, but I have no idea of VC partitioning in gem5.
Please help me.
On Mon, Jul 24, 2017 at 10:33 PM, Krishna, Tushar <***@ece.gatech.edu<mailto:***@ece.gatech.edu>> wrote:
The Torus topology deadlocks as it has rings in each dimension unless one implements a VC partitioning scheme or bubble flow control. That's why I removed torus from the default topologies provided by garnet2.0. If you implement torus, you will have to implement deadlock freedom.
On Jul , 2017, at 5:56 PM, F. A. Faisal <***@gmail.com<mailto:***@gmail.com>> wrote:
I like to simulate the synthetic traffic analysis for Torus for 256 nodes with uniform traffic.
However, the network is showing latency degradation after 0.14 injection rate (flit latency = 33.044985 for 0.14 and flit latency = 38.244770 for 0.13 ), which could be the possible case of network deadlocked.
I configured the garnet 2.0 with all the default settings (4 vc + 16 bandwith factor) and Mesh network is also performing properly. As the number of VC is 4, Torus should not be in a deadlock.
I also like to share the network file as attachment.
And please consider the simulation condition as below-
./build/Garnet_standalone/gem5.debug configs.py/example/garnet_synth_traffic --num-cpus=256 --num-dirs=256 --network=garnet2.0 --topology=Torus_XY --mesh-rows=16 --sim-cycles=20000 --synthetic=uniform_random --injectionrate=0.14 --routing-algorithm=0 --vcs-per-vnet=4
Please let me know how to resolve this issue for Garnet 2.0.
Thanks and best regards,
gem5-users mailing list