I am not too familiar with the current state of the debug flags.
The ruby README might be outdated. Try to search for how the debug flags
work within the other modules.
On 03/22/2012 05:57 PM, Dean Michael Ancajas wrote:
On Thu, Mar 22, 2012 at 3:41 PM, Tushar Krishna <[email protected]
<mailto:[email protected]>> wrote:
Hi Dean,
My answers are inline.
- Tushar
On 03/22/2012 05:31 PM, Dean Michael Ancajas wrote:
Hi Tushar,
Thanks for the prompt reply. I have a follow up
question/clarifications though. Let's say I have successfully
deflected a HEAD_ flit to a different output port (from what was
calculated in the RC stage) all the BODY_ and TAIL_ flits will
automatically follow right since they would use the same input
VC? At least that is how I understood the code in
InputUnit_D::wakeup().
As long as you make sure that the new output port is updated in
the "route" variable in that VC after the head deflects, the BODY
and TAIL will follow that same output port.
Another question is, if we have deflected a flit to a
non-optimal path, is there a way to update its new path without
diving into the details of how the path is embedded into the
message during the NetworkInterface::flitisize ( ) part? What I
would want to do is update the shortest path to the source that
is embedded in the flit/network message based on its current
deflected location. If I don't update the path/NetDest inside the
flit i think it would just go back to the router where it came
from since that would be the only node that would match in its
routing table.
Hmm depends. Suppose a flit could go out of N or E for minimal
routing (and E had been computed by RC for XY routing). You
deflected it out of S. Now at the new router, it can either go out
of N to come back to the old router, or it can go out of E. I
think it will go out of E if XY routing is enforced (if you use a
Mesh, all X links have a weight of 1 and Y links have a weight of
2 to enforce XY routing).
But on the other hand, if a flit could only go out of N and you
deflected it to W, S or E, it will come back to the same router.
This last case is what I am actually worried about since it would have
a pingpong effect whichever way I deflect it.
I'd also like to ask if there is an online guide on how to enable the
debug mechanisms embedded in the garnet code? The instructions
included in the ruby README file apparently does not actually work for
garnet.
cheers!
dean
On Thu, Mar 22, 2012 at 12:40 PM, Tushar Krishna
<[email protected] <mailto:[email protected]>> wrote:
Hi Dean,
The OutputUnit does not wake up when the flit has to leave
the router (it only wakes up to receive credits).
It is the switch that wakes up and schedules the output link.
The SWallocator_d removes winning flits from their respective
input VCs and places them in the switch buffer.
The Switch_d reads from the switch buffer and pushes flits
into the out_buffer of the particular output unit.
The NetworkLink_d wakes up and reads flits out of the output
buffers.
If you want to implement locking, I think you will need
changes in the SwitchAllocator_d where input flits place
requests for output ports and output ports arbitrate among
these requests.
You need ensure that an output port only favors packets of
the same input VC, before it can serve other VCs/ports.
The Switch and Link are dumb units that just transfer flits.
- Tushar
On 03/22/2012 09:47 AM, Dean Michael Ancajas wrote:
Hi,
I want to implement deflection routing in garnet. At the
InputUnit_d::wakeup() I lock the output port of the router
(everytime a HEAD flit or HEAD_FLIT_ is encountered) so that
no other flit will be scheduled thru this output port. My
question is, when do I release the lock? Is it in the
OutputUnit_d::wakeup() when a TAIL flit is about to traverse
the link (i.e. when it puts the flit on the network link)?
-dean
_______________________________________________
gem5-users mailing list
[email protected] <mailto:[email protected]>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected] <mailto:[email protected]>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected] <mailto:[email protected]>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected] <mailto:[email protected]>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
