I checked the problem more detailed.
However, I think the problem is if we fix the VC for any same directional
routing then many packets remains in deadlock.
Hence, the best option is to make sure to fix the VC while we are making
the wrap-around routing and can choose any VC after the wrap
Dear Professor,
Thanks for the reply.
If I understand you correctly, I have update the OutputUnit.cc file as
below-
However, I am still facing the deadlock issue.
Please let me know if I am missing something or it requires any other file
to be updated.
// Check if the output port (i.e., input
The lectures on NoC deadlocks on my website might help understand the problem:
http://tusharkrishna.ece.gatech.edu/wp-content/uploads/sites/175/2016/10/L05-Deadlocks-I.pdf
http://tusharkrishna.ece.gatech.edu/wp-content/uploads/sites/175/2016/10/L06-Deadlocks-II.pdf
Plus...
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
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,
Hi Faisal,
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.
Dear All,
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
