Hello,
I am using an Alpha cpu so I didn't experience the deadlock issue that you
said.
I am using the flexible pipeline model as I want to process each packet in a
few cycles. Looking at the pipeline code briefly, I saw two places which I need
to modify (I believe) to select the VNET I want. I am wondering if there is any
easy method to determine which packet is the oldest. I am thinking that I will
have to add a time-stamp to each flit and determine which VNET has the flit
with the lowest time stamp. That method may take a while to implement, so I am
wondering if there is a faster way to determine which flit is the oldest.
Also, do you know if it will be easier to enforce this ordering on the
non-Garnet Ruby network?
Best regards,
Alex
________________________________
From: "Castillo Villar, Emilio" <[email protected]>
To: Alex Tomala <[email protected]>
Sent: Wednesday, February 12, 2014 5:13:06 PM
Subject: Garnet
Hello,
If you are using the fixed pipeline model there is some code in the VCallocator
and SWAllocator that for arbitrate the VCs within a VNet selects the older
packet in the router. Flexible model limits the usage of VCs per ordered to 1,
that way it ensures that
messages will be always ordered.
A way to achieve what you want would be that the VC allocator and the SW
allocator could select the VNet with the oldest package on it. Currently VNet
arbitration is done with Round Robin, you would need to change this as it is
not too much code. It could be
simpler in the flexible router model as everything is in only one file.
I'd recommend you that at the network interface code, when the packet is
flitisized and injected in the network, to put an injection timestamp in the
flit header to avoid some corner cases that I've experienced in the past.
Are you using x86 cpu? I have some deadlocks with x86 & ruby & the detailed
cpu, would be nice to know if some other people is experiencing the same.
Kind regards and hope this could have been of help.
------------------------------
Emilio Castillo
Barcelona Supercomputing Center
________________________________
De: [email protected] [[email protected]] en nombre de Alex
Tomala [[email protected]]
Enviado: miércoles, 12 de febrero de 2014 22:54
Para: gem5 mailing list
Asunto: [gem5-users] Make Garnet network or Regular Ruby network process
messages in order
Hello,
I am working on a Ruby cache coherence protocol but I am encountering some
problems that I need to solve. My current problem is that the inter-cache
network doesn't process messages from different virtual networks in order.
An example of my problem is this: a L2 cache controller sends a message to a L1
cache controller on a certain cycle; the next cycle the same L2 cache
controller sends another message to the same L1 cache controller but on a
different vnet. It is important that the first message reaches the L1
controller before the second message reaches in order for the system to work,
but in the simulation, the second message reaches the L2 cache controller
first.
I am wondering if there is anyway I can modify my cache controller or the
network to insure that the first message is received by the L1 cache before the
second message is received.
Best regards,
Alex
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users