Discussion:
Network Message and Memory Message
(too old to reply)
tejasi pimpalkhute
2012-09-26 06:17:34 UTC
Permalink
Hi Tushar,

I had resumed working on this again, so was going through your
emails(please see email below). I am still getting this error:

gem5.debug: build/ALPHA_SE_MOESI_hammer/base/cast.hh:49: T safe_cast(U)
[with T = const MemoryMsg*, U = Message*]: Assertion `ret' failed.
Program aborted at cycle 10
Aborted

My code looks like this in SWallocator.cc file(I have included all the
necessary files) in the arbitrate_outports() function:

flit_d *t_flit = m_input_unit[inport]->peekTopFlit(invc);

MsgPtr msg_ptr = t_flit->get_msg_ptr();

const MemoryMsg* memMess = safe_cast<const MemoryMsg*>(msg_ptr.get());

physical_address_t addr = memMess->getAddress().getAddress();
MemoryRequestType type = memMess->getType();

However, the typecast fails. Could you please let me know what could be the
problem here? I just want to extract the information from the flit if it is
a memory message or network message and if it is memory message, I want to
know its physical address and memory request type (e.g. read/write, etc).
Can you please suggest the correct way of getting this information from the
flit?

I appreciate your guidance.

Thanks!


---------- Forwarded message ----------
From: Tushar Krishna <***@csail.mit.edu>
Date: Thu, Jan 5, 2012 at 9:09 AM
Subject: Re: Network Message and Memory Message
To: Krishna <***@gmail.com>


Hi Krishna,
My answers are inline.

cheers,
Tushar
Hi Tushar,
We are trying to implement an SDRAM aware router that re-orders
packets based on their row address and bank address so as to minimize
time.
In order to implement this, we are modifying the code in
Swallocator_d.cc where the packets are re-ordered as per priority. To
determine the priority we need the row address and bank address. So we
tried to implement the logic similar to the below function
void
MemoryControl::enqueue(const MsgPtr& message, int latency)
{
Time current_time = g_eventQueue_ptr->getTime();
Time arrival_time = current_time + latency;
const MemoryMsg* memMess = safe_cast<const MemoryMsg*>(message.get());
physical_address_t addr = memMess->getAddress().**getAddress();
MemoryRequestType type = memMess->getType();
bool is_mem_read = (type == MemoryRequestType_MEMORY_READ)**;
MemoryNode thisReq(arrival_time, message, addr, is_mem_read,
!is_mem_read);
enqueueMemRef(thisReq);
}
Here the value returned by message.get() is type-casted into MemoryMsg
and later this is used to retrieve address and type of request.
Your approach is absolutely correct.


We tried to implement similar logic in Swallocator_d.cc. Here the
virtual channel buffers have flits.
flit_d *t_flit = m_input_unit[inport]->**getTopFlit(invc);
MsgPtr msg_ptr = flit_d->get_msg_ptr();
Shouldn't it be MsgPtr msg_ptr = t_flit->get_msg_ptr(); ?

const MemoryMsg* memMess = safe_cast<const MemoryMsg*>(message.get());
Shouldn't it be msg_ptr.get() ?

const NetworkMessage* memMess = safe_cast<const
NetworkMessage*>(msg_ptr.get()**);
Here the code in bold line throws an assertion error, but is being
successfully type-casted into Network Message.
Didn't see anything in bold but I assume you meant the MemoryMsg* line ...
Try fixing the two things I mentioned and see if it works. It should.

Please let us know if it is possible to retrieve address and type of
request from Network Message or any other possible way to extract the
address and memory request type information from flit.
To summarize, we are trying to schedule input requests at a router
according to certain prioritizing criteria and store it in output port
buffers. But our prioritizing criteria needs to know certain
information from the flit (which is address and memory request type).
Please let us know if there is any way to get this information.
Thank You.
Tushar Krishna
2012-09-26 14:24:21 UTC
Permalink
Hi Tejasi,
I tried it too and yeah it fails, not sure why...
The same code works in src/mem/ruby/system/RubyMemoryControl.cc
A cast into NetworkMessage has been done in places like RoutingUnit_d but that won't give you the message type.
You'll have to dig in and see why the cast fails…

- Tushar
Post by tejasi pimpalkhute
Hi Tushar,
gem5.debug: build/ALPHA_SE_MOESI_hammer/base/cast.hh:49: T safe_cast(U) [with T = const MemoryMsg*, U = Message*]: Assertion `ret' failed.
Program aborted at cycle 10
Aborted
flit_d *t_flit = m_input_unit[inport]->peekTopFlit(invc);
MsgPtr msg_ptr = t_flit->get_msg_ptr();
const MemoryMsg* memMess = safe_cast<const MemoryMsg*>(msg_ptr.get());
physical_address_t addr = memMess->getAddress().getAddress();
MemoryRequestType type = memMess->getType();
However, the typecast fails. Could you please let me know what could be the problem here? I just want to extract the information from the flit if it is a memory message or network message and if it is memory message, I want to know its physical address and memory request type (e.g. read/write, etc). Can you please suggest the correct way of getting this information from the flit?
I appreciate your guidance.
Thanks!
---------- Forwarded message ----------
Date: Thu, Jan 5, 2012 at 9:09 AM
Subject: Re: Network Message and Memory Message
Hi Krishna,
My answers are inline.
cheers,
Tushar
Hi Tushar,
We are trying to implement an SDRAM aware router that re-orders
packets based on their row address and bank address so as to minimize
time.
In order to implement this, we are modifying the code in
Swallocator_d.cc where the packets are re-ordered as per priority. To
determine the priority we need the row address and bank address. So we
tried to implement the logic similar to the below function
void
MemoryControl::enqueue(const MsgPtr& message, int latency)
{
Time current_time = g_eventQueue_ptr->getTime();
Time arrival_time = current_time + latency;
const MemoryMsg* memMess = safe_cast<const MemoryMsg*>(message.get());
physical_address_t addr = memMess->getAddress().getAddress();
MemoryRequestType type = memMess->getType();
bool is_mem_read = (type == MemoryRequestType_MEMORY_READ);
MemoryNode thisReq(arrival_time, message, addr, is_mem_read, !is_mem_read);
enqueueMemRef(thisReq);
}
Here the value returned by message.get() is type-casted into MemoryMsg
and later this is used to retrieve address and type of request.
Your approach is absolutely correct.
We tried to implement similar logic in Swallocator_d.cc. Here the
virtual channel buffers have flits.
flit_d *t_flit = m_input_unit[inport]->getTopFlit(invc);
MsgPtr msg_ptr = flit_d->get_msg_ptr();
Shouldn't it be MsgPtr msg_ptr = t_flit->get_msg_ptr(); ?
const MemoryMsg* memMess = safe_cast<const MemoryMsg*>(message.get());
Shouldn't it be msg_ptr.get() ?
const NetworkMessage* memMess = safe_cast<const
NetworkMessage*>(msg_ptr.get());
Here the code in bold line throws an assertion error, but is being
successfully type-casted into Network Message.
Didn't see anything in bold but I assume you meant the MemoryMsg* line ... Try fixing the two things I mentioned and see if it works. It should.
Please let us know if it is possible to retrieve address and type of
request from Network Message or any other possible way to extract the
address and memory request type information from flit.
To summarize, we are trying to schedule input requests at a router
according to certain prioritizing criteria and store it in output port
buffers. But our prioritizing criteria needs to know certain
information from the flit (which is address and memory request type).
Please let us know if there is any way to get this information.
Thank You.
Nilay Vaish
2012-09-26 14:39:32 UTC
Permalink
If the Message* is not a MemoryMsg*, then safe cast will fail.

--
Nilay
Post by Tushar Krishna
Hi Tejasi,
I tried it too and yeah it fails, not sure why...
The same code works in src/mem/ruby/system/RubyMemoryControl.cc
A cast into NetworkMessage has been done in places like RoutingUnit_d but that won't give you the message type.
You'll have to dig in and see why the cast fails…
- Tushar
Post by tejasi pimpalkhute
Hi Tushar,
gem5.debug: build/ALPHA_SE_MOESI_hammer/base/cast.hh:49: T safe_cast(U) [with T = const MemoryMsg*, U = Message*]: Assertion `ret' failed.
Program aborted at cycle 10
Aborted
flit_d *t_flit = m_input_unit[inport]->peekTopFlit(invc);
MsgPtr msg_ptr = t_flit->get_msg_ptr();
const MemoryMsg* memMess = safe_cast<const MemoryMsg*>(msg_ptr.get());
physical_address_t addr = memMess->getAddress().getAddress();
MemoryRequestType type = memMess->getType();
However, the typecast fails. Could you please let me know what could be the problem here? I just want to extract the information from the flit if it is a memory message or network message and if it is memory message, I want to know its physical address and memory request type (e.g. read/write, etc). Can you please suggest the correct way of getting this information from the flit?
I appreciate your guidance.
Thanks!
tejasi pimpalkhute
2012-09-26 19:39:17 UTC
Permalink
Hi Nilay and Tushar,

Thanks for your response. I thought so earlier but I tried running pure
memory test (e.g. ruby_mem_test.py) as well as ruby_random_test. Shouldn't
the memory test inject only memory request packets in the network? In that
case why should the type cast fail? Please correct me if I am wrong. Is
there any way of determining whether a flit corresponds to a memory message
or a network message?

I am using this command line to run the test

./build/ALPHA_SE_MOESI_hammer/gem5.debug configs/example/ruby_random_test.py
--num-cpus=4 --num-dirs=4 --topology=Mesh --mesh-rows=2 --garnet-network=fixed
-l 100

./build/ALPHA_SE_MOESI_hammer/gem5.debug configs/example/ruby_mem_test.py
--num-cpus=4 --num-dirs=4 --topology=Mesh --mesh-rows=2 --garnet-network=fixed
-l 100

Looking forward to your guidance. Thanks!
Post by Nilay Vaish
If the Message* is not a MemoryMsg*, then safe cast will fail.
--
Nilay
Hi Tejasi,
Post by Tushar Krishna
I tried it too and yeah it fails, not sure why...
The same code works in src/mem/ruby/system/**RubyMemoryControl.cc
A cast into NetworkMessage has been done in places like RoutingUnit_d but
that won't give you the message type.
You'll have to dig in and see why the cast fails…
- Tushar
Hi Tushar,
Post by tejasi pimpalkhute
I had resumed working on this again, so was going through your
gem5.debug: build/ALPHA_SE_MOESI_hammer/**base/cast.hh:49: T
safe_cast(U) [with T = const MemoryMsg*, U = Message*]: Assertion `ret'
failed.
Program aborted at cycle 10
Aborted
My code looks like this in SWallocator.cc file(I have included all the
flit_d *t_flit = m_input_unit[inport]->**peekTopFlit(invc);
MsgPtr msg_ptr = t_flit->get_msg_ptr();
const MemoryMsg* memMess = safe_cast<const MemoryMsg*>(msg_ptr.get());
physical_address_t addr = memMess->getAddress().**getAddress();
MemoryRequestType type = memMess->getType();
However, the typecast fails. Could you please let me know what could be
the problem here? I just want to extract the information from the flit if
it is a memory message or network message and if it is memory message, I
want to know its physical address and memory request type (e.g. read/write,
etc). Can you please suggest the correct way of getting this information
from the flit?
I appreciate your guidance.
Thanks!
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Nilay Vaish
2012-09-27 11:46:37 UTC
Permalink
Post by tejasi pimpalkhute
Hi Nilay and Tushar,
Thanks for your response. I thought so earlier but I tried running pure
memory test (e.g. ruby_mem_test.py) as well as ruby_random_test. Shouldn't
the memory test inject only memory request packets in the network? In that
case why should the type cast fail? Please correct me if I am wrong.
You are wrong in your assumption.
Post by tejasi pimpalkhute
Is
there any way of determining whether a flit corresponds to a memory message
or a network message?
There is an obvious check given the behavior of dynamic_cast in C++. You
might want to figure it out on your own.

--
Nilay
tejasi pimpalkhute
2012-10-02 18:34:37 UTC
Permalink
Hi Nilay and Tushar,

I got rid of that error by writing a check for memory message and network
message in the SWallocator_d.cc. However, I am getting a deadlock error now
when I run the same test. I get this error:

panic: Deadlock detected: current_time: 50001 last_progress_time: 0
difference: 50001 processor: 0
@ cycle 50001
[checkForDeadlock:build/ALPHA_SE_MOESI_hammer/cpu/testers/rubytest/RubyTester.cc,
line 182]
Memory Usage: 170696 KBytes
Program aborted at cycle 50001
Aborted

I am attaching my code file here. It will be great if you could have a look
to see if I am making any obvious error here (method -
priority_arbitrate_outports), I am unable to find out what could have gone
wrong. Thanks for your guidance and time.
Post by tejasi pimpalkhute
Hi Nilay and Tushar,
Post by tejasi pimpalkhute
Thanks for your response. I thought so earlier but I tried running pure
memory test (e.g. ruby_mem_test.py) as well as ruby_random_test.
Shouldn't
the memory test inject only memory request packets in the network? In that
case why should the type cast fail? Please correct me if I am wrong.
You are wrong in your assumption.
Is
Post by tejasi pimpalkhute
there any way of determining whether a flit corresponds to a memory message
or a network message?
There is an obvious check given the behavior of dynamic_cast in C++. You
might want to figure it out on your own.
--
Nilay
--
Thanks and Regards,
Tejasi
Tushar Krishna
2012-10-02 19:48:00 UTC
Permalink
Hi Tejasi,
Try testing your code with the NetworkTest protocol and inject a fixed number of packets and see if they get delivered. If not, see why some flits might be stuck at some routers.
While I didn't go through your entire code in detail, I see you have some wait cycles etc for each input port (which i presume is to delay some flits). Make sure that the SWallocator/Switch do wake up at the end of your wait cycles to send the flit out.

- Tushar
Post by tejasi pimpalkhute
Hi Nilay and Tushar,
panic: Deadlock detected: current_time: 50001 last_progress_time: 0 difference: 50001 processor: 0
@ cycle 50001
[checkForDeadlock:build/ALPHA_SE_MOESI_hammer/cpu/testers/rubytest/RubyTester.cc, line 182]
Memory Usage: 170696 KBytes
Program aborted at cycle 50001
Aborted
I am attaching my code file here. It will be great if you could have a look to see if I am making any obvious error here (method - priority_arbitrate_outports), I am unable to find out what could have gone wrong. Thanks for your guidance and time.
Hi Nilay and Tushar,
Thanks for your response. I thought so earlier but I tried running pure
memory test (e.g. ruby_mem_test.py) as well as ruby_random_test. Shouldn't
the memory test inject only memory request packets in the network? In that
case why should the type cast fail? Please correct me if I am wrong.
You are wrong in your assumption.
Is
there any way of determining whether a flit corresponds to a memory message
or a network message?
There is an obvious check given the behavior of dynamic_cast in C++. You might want to figure it out on your own.
--
Nilay
--
Thanks and Regards,
Tejasi
<SWallocator_d_.cc>
tejasi pimpalkhute
2012-10-03 05:32:47 UTC
Permalink
Hi Tushar,

Thanks for looking into the code, I tried running the Network_test protocol
and got this error:

Global frequency set at 1000000000 ticks per second
info: Entering event queue @ 0. Starting simulation...
gem5.debug:
build/ALPHA_SE_Network_test/mem/ruby/network/garnet/fixed-pipeline/InputUnit_d.cc:78:
virtual void InputUnit_d::wakeup(): Assertion `m_vcs[vc]->get_state() ==
IDLE_' failed.
Program aborted at cycle 30
Aborted


I used this command to run the test-
./build/ALPHA_SE_Network_test/gem5.debug
configs/example/ruby_network_test.py --num-cpus=16 --num-dirs=16
--topology=Mesh --mesh-rows=4 --sim-cycles=1000 --injectionrate=0.01
--synthetic=0 --fixed-pkts --maxpackets=1000 --garnet-network=fixed


On a side note, I also wanted to ask you if Ruby_random_test and
Ruby_mem_test do inject any memory flits in the network. Because, I tried
to dynamic cast the msgptr of these flits to MemoryMessage msgptr so that I
can extract the information about its memory address and type, but it
fails. Do you see any reason why it could be failing? I want to deal with
both network packets and off-chip memory packets in the network. Can you
please guide me which test will be appropriate for the same?

Thanks for your help.
Post by Tushar Krishna
Hi Tejasi,
Try testing your code with the NetworkTest protocol and inject a fixed
number of packets and see if they get delivered. If not, see why some flits
might be stuck at some routers.
While I didn't go through your entire code in detail, I see you have some
wait cycles etc for each input port (which i presume is to delay some
flits). Make sure that the SWallocator/Switch do wake up at the end of your
wait cycles to send the flit out.
- Tushar
Hi Nilay and Tushar,
I got rid of that error by writing a check for memory message and network
message in the SWallocator_d.cc. However, I am getting a deadlock error now
panic: Deadlock detected: current_time: 50001 last_progress_time: 0
difference: 50001 processor: 0
@ cycle 50001
[checkForDeadlock:build/ALPHA_SE_MOESI_hammer/cpu/testers/rubytest/RubyTester.cc, line 182]
Memory Usage: 170696 KBytes
Program aborted at cycle 50001
Aborted
I am attaching my code file here. It will be great if you could have a
look to see if I am making any obvious error here (method -
priority_arbitrate_outports), I am unable to find out what could have gone
wrong. Thanks for your guidance and time.
Post by tejasi pimpalkhute
Hi Nilay and Tushar,
Post by tejasi pimpalkhute
Thanks for your response. I thought so earlier but I tried running pure
memory test (e.g. ruby_mem_test.py) as well as ruby_random_test.
Shouldn't
the memory test inject only memory request packets in the network? In that
case why should the type cast fail? Please correct me if I am wrong.
You are wrong in your assumption.
Is
Post by tejasi pimpalkhute
there any way of determining whether a flit corresponds to a memory message
or a network message?
There is an obvious check given the behavior of dynamic_cast in C++. You
might want to figure it out on your own.
--
Nilay
--
<SWallocator_d_.cc>
--
tejasi pimpalkhute
2012-10-04 21:44:03 UTC
Permalink
Thanks a ton for explaining this, I think I was mistaken earlier. In that
case, can I know beforehand the physical address of the request flits which
will be going to the directory controller? Can I calculate the rank and
bank address of that flit as done in the memory controller (if the router
has information about the physical memory)? I could see some mapping
functions in the directory controller to map the address to the physical
address of memory. Can I use those to get final main memory address?
Sorry for bombarding you with questions , but I really need to understand
this well as I am implementing a memory-aware arbitration technique at the
router. I appreciate your patience.
Hi Nilay,
Thanks for throwing light on this. I want to arbitrate request packets
originated the core (requiring off-chip memory access) at the router. Do
you think this is possible in Gem5?
My understanding was that both the memory request flits as well as network
flits are routed via interconnection networks. So, I modified the
SWallocator_d code. But now I am confused, if the memory request flits
don't travel through the GARNET network towards the main memory, what path
do the take to access main memory? I would really appreciate if you could
elaborate more on this. Thanks!
In a typical case a core would generate load/store requests for the
caches. The cache controllers and the directory controllers are connected
using a network. So, if a controller is unable to handle some request, it
forwards it to the next level controller. The forwarded message goes
through the on-chip network. If a request reaches the directory controller,
it forwards it to the memory controller. A Memory Msg (in gem5's
terminology) is message from a directory controller to a memory controller
or vice-versa. These message travel on dedicated links between directory
controllers and memory controllers. These links are not part of Garnet.
--
Nilay
--
Thanks and Regards,
Tejasi
Nilay Vaish
2012-10-04 22:22:25 UTC
Permalink
Post by tejasi pimpalkhute
Thanks a ton for explaining this, I think I was mistaken earlier. In that
case, can I know beforehand the physical address of the request flits which
will be going to the directory controller? Can I calculate the rank and
When router forwards a flit, it knows the final destination of the flit.
So it should be possible to figure out if a flit is meant for the
directory controller.
Post by tejasi pimpalkhute
bank address of that flit as done in the memory controller (if the router
has information about the physical memory)? I could see some mapping
functions in the directory controller to map the address to the physical
address of memory. Can I use those to get final main memory address?
A flit holds pointer to a message that holds the physical address. You
would need to read the memory controller code to figure out how to map the
physical address to ranks and banks.

--
Nilay
tejasi pimpalkhute
2012-10-09 23:16:25 UTC
Permalink
Thanks, Nilay. I can know the ranks and banks from the physical address
(datatype physical_address_t) which I get from MemoryMsg or RubyRequest but
my main issue is how to extract that information from a single flit. As per
the current code, I can only get a msg_ptr from it of type Message*. I am
able to typecast the message ptr to NetworkMessage msg_ptr safely and can
get destination of the flit of the type NetDest, I can also extract the
message type from it using MessageSizeType() (please see code below) but
that doesn't quite serve my purpose. I need to know at the router if the
request flit is memory_read or memory_write and its physical address at the
memory. I am assuming I can schedule the memory request flits at the switch
allocator(please correct me if I am wrong).

Code at SWallocator_d.cc

// remove flit from Input Unit
flit_d *t_flit = m_input_unit[inport]->getTopFlit(invc);

MsgPtr& msg_ptr = t_flit->get_msg_ptr();

const NetworkMessage* netMess = dynamic_cast<const
NetworkMessage*>(msg_ptr.get());
const MessageSizeType& type = netMess->getMessageSize();
const NetDest& dest = netMess->getDestination() ;


Also, could you please help me in understanding the journey of memory
packets better, e.g. if a request originates at a node and if that request
is memory writeback, in that case what is the typical itinerary of a flit
of that request message to get to the main memory? Sorry for pestering you
with a lot of questions.
Thanks a lot for your guidance.
Post by tejasi pimpalkhute
Thanks a ton for explaining this, I think I was mistaken earlier. In that
Post by tejasi pimpalkhute
case, can I know beforehand the physical address of the request flits which
will be going to the directory controller? Can I calculate the rank and
When router forwards a flit, it knows the final destination of the flit.
So it should be possible to figure out if a flit is meant for the directory
controller.
bank address of that flit as done in the memory controller (if the router
Post by tejasi pimpalkhute
has information about the physical memory)? I could see some mapping
functions in the directory controller to map the address to the physical
address of memory. Can I use those to get final main memory address?
A flit holds pointer to a message that holds the physical address. You
would need to read the memory controller code to figure out how to map the
physical address to ranks and banks.
--
Nilay
--
Thanks and Regards,
Tejasi
Nilay
2012-10-10 03:14:50 UTC
Permalink
Post by tejasi pimpalkhute
Thanks, Nilay. I can know the ranks and banks from the physical address
(datatype physical_address_t) which I get from MemoryMsg or RubyRequest but
my main issue is how to extract that information from a single flit. As per
the current code, I can only get a msg_ptr from it of type Message*. I am
able to typecast the message ptr to NetworkMessage msg_ptr safely and can
get destination of the flit of the type NetDest, I can also extract the
message type from it using MessageSizeType() (please see code below) but
that doesn't quite serve my purpose. I need to know at the router if the
request flit is memory_read or memory_write and its physical address at the
memory. I am assuming I can schedule the memory request flits at the switch
allocator(please correct me if I am wrong).
Code at SWallocator_d.cc
// remove flit from Input Unit
flit_d *t_flit = m_input_unit[inport]->getTopFlit(invc);
MsgPtr& msg_ptr = t_flit->get_msg_ptr();
const NetworkMessage* netMess = dynamic_cast<const
NetworkMessage*>(msg_ptr.get());
const MessageSizeType& type = netMess->getMessageSize();
const NetDest& dest = netMess->getDestination() ;
Also, could you please help me in understanding the journey of memory
packets better, e.g. if a request originates at a node and if that request
is memory writeback, in that case what is the typical itinerary of a flit
of that request message to get to the main memory? Sorry for pestering you
with a lot of questions.
Thanks a lot for your guidance.
I strongly suggest that you read the documentation on Ruby memory system
available on gem5.org.

--
Nilay
tejasi pimpalkhute
2012-10-26 20:22:36 UTC
Permalink
Hi Nilay,

I have gone through the whole documentation of gem5 but I am still unable
to figure out why the flit_d lacks information about its destination's
physical address and data request type(i.e. if the request is read/write)
and if that is correct, from where can I retrieve this information? Can you
please clarify this? Thanks for your time.
Post by tejasi pimpalkhute
Post by tejasi pimpalkhute
Thanks, Nilay. I can know the ranks and banks from the physical address
(datatype physical_address_t) which I get from MemoryMsg or RubyRequest but
my main issue is how to extract that information from a single flit. As per
the current code, I can only get a msg_ptr from it of type Message*. I am
able to typecast the message ptr to NetworkMessage msg_ptr safely and can
get destination of the flit of the type NetDest, I can also extract the
message type from it using MessageSizeType() (please see code below) but
that doesn't quite serve my purpose. I need to know at the router if the
request flit is memory_read or memory_write and its physical address at the
memory. I am assuming I can schedule the memory request flits at the switch
allocator(please correct me if I am wrong).
Code at SWallocator_d.cc
// remove flit from Input Unit
flit_d *t_flit = m_input_unit[inport]->getTopFlit(invc);
MsgPtr& msg_ptr = t_flit->get_msg_ptr();
const NetworkMessage* netMess = dynamic_cast<const
NetworkMessage*>(msg_ptr.get());
const MessageSizeType& type = netMess->getMessageSize();
const NetDest& dest = netMess->getDestination() ;
Also, could you please help me in understanding the journey of memory
packets better, e.g. if a request originates at a node and if that
request
Post by tejasi pimpalkhute
is memory writeback, in that case what is the typical itinerary of a flit
of that request message to get to the main memory? Sorry for pestering
you
Post by tejasi pimpalkhute
with a lot of questions.
Thanks a lot for your guidance.
I strongly suggest that you read the documentation on Ruby memory system
available on gem5.org.
--
Nilay
--
Thanks and Regards,
Tejasi
Nilay Vaish
2012-10-26 21:18:49 UTC
Permalink
Hi Nilay,
I have gone through the whole documentation of gem5 but I am still unable
to figure out why the flit_d lacks information about its destination's
physical address and data request type(i.e. if the request is read/write)
and if that is correct, from where can I retrieve this information? Can you
please clarify this? Thanks for your time.
I have told you before that a flit holds pointer to a message that holds
the physical address. The message also has the type of the request. What
is it that is to be clarified in this statement?

--
Nilay

tejasi pimpalkhute
2012-10-04 18:07:07 UTC
Permalink
Hi Nilay,

Thanks for throwing light on this. I want to arbitrate request packets
originated the core (requiring off-chip memory access) at the router. Do
you think this is possible in Gem5?
My understanding was that both the memory request flits as well as network
flits are routed via interconnection networks. So, I modified the
SWallocator_d code. But now I am confused, if the memory request flits
don't travel through the GARNET network towards the main memory, what path
do the take to access main memory? I would really appreciate if you could
elaborate more on this. Thanks!
Post by tejasi pimpalkhute
Hi Tushar,
Post by tejasi pimpalkhute
Thanks for looking into the code, I tried running the Network_test protocol
Global frequency set at 1000000000 ticks per second
build/ALPHA_SE_Network_test/**mem/ruby/network/garnet/fixed-**
virtual void InputUnit_d::wakeup(): Assertion `m_vcs[vc]->get_state() ==
IDLE_' failed.
Program aborted at cycle 30
Aborted
I used this command to run the test-
./build/ALPHA_SE_Network_test/**gem5.debug
configs/example/ruby_network_**test.py --num-cpus=16 --num-dirs=16
--topology=Mesh --mesh-rows=4 --sim-cycles=1000 --injectionrate=0.01
--synthetic=0 --fixed-pkts --maxpackets=1000 --garnet-network=fixed
On a side note, I also wanted to ask you if Ruby_random_test and
Ruby_mem_test do inject any memory flits in the network. Because, I tried
to dynamic cast the msgptr of these flits to MemoryMessage msgptr so that I
can extract the information about its memory address and type, but it
fails. Do you see any reason why it could be failing? I want to deal with
both network packets and off-chip memory packets in the network. Can you
please guide me which test will be appropriate for the same?
First, the Network test protocol does not access memory. Second, even
other protocols do not send messages to the memory via the network that you
are trying to modify. There are dedicated links between the directory
controllers and the memory controllers.
The test to be used depends on what you want to test for.
--
Nilay
--
Tejasi
Nilay Vaish
2012-10-04 20:23:32 UTC
Permalink
Hi Nilay,
Thanks for throwing light on this. I want to arbitrate request packets
originated the core (requiring off-chip memory access) at the router. Do
you think this is possible in Gem5?
My understanding was that both the memory request flits as well as network
flits are routed via interconnection networks. So, I modified the
SWallocator_d code. But now I am confused, if the memory request flits
don't travel through the GARNET network towards the main memory, what path
do the take to access main memory? I would really appreciate if you could
elaborate more on this. Thanks!
In a typical case a core would generate load/store requests for the
caches. The cache controllers and the directory controllers are connected
using a network. So, if a controller is unable to handle some request, it
forwards it to the next level controller. The forwarded message goes
through the on-chip network. If a request reaches the directory
controller, it forwards it to the memory controller. A Memory Msg (in
gem5's terminology) is message from a directory controller to a memory
controller or vice-versa. These message travel on dedicated links between
directory controllers and memory controllers. These links are not part of
Garnet.

--
Nilay
Nilay Vaish
2012-10-04 15:46:52 UTC
Permalink
Post by tejasi pimpalkhute
Hi Tushar,
Thanks for looking into the code, I tried running the Network_test protocol
Global frequency set at 1000000000 ticks per second
virtual void InputUnit_d::wakeup(): Assertion `m_vcs[vc]->get_state() ==
IDLE_' failed.
Program aborted at cycle 30
Aborted
I used this command to run the test-
./build/ALPHA_SE_Network_test/gem5.debug
configs/example/ruby_network_test.py --num-cpus=16 --num-dirs=16
--topology=Mesh --mesh-rows=4 --sim-cycles=1000 --injectionrate=0.01
--synthetic=0 --fixed-pkts --maxpackets=1000 --garnet-network=fixed
On a side note, I also wanted to ask you if Ruby_random_test and
Ruby_mem_test do inject any memory flits in the network. Because, I tried
to dynamic cast the msgptr of these flits to MemoryMessage msgptr so that I
can extract the information about its memory address and type, but it
fails. Do you see any reason why it could be failing? I want to deal with
both network packets and off-chip memory packets in the network. Can you
please guide me which test will be appropriate for the same?
First, the Network test protocol does not access memory. Second, even
other protocols do not send messages to the memory via the network that
you are trying to modify. There are dedicated links between the
directory controllers and the memory controllers.

The test to be used depends on what you want to test for.

--
Nilay
Continue reading on narkive:
Loading...