Running ruby_mem_test.py With bufferless router

21 views
Skip to first unread message

Xiyue Xiang

unread,
Apr 22, 2015, 5:17:26 PM4/22/15
to topaz-...@googlegroups.com
Hi,

I've directly pull a copy from your TOPAZ repository. I can successfully run ruby_mem_test.py with network = T44-CT-UC.

However, when I run ruby_mem_test.py with network = T44-BLESS-NOC (all settings are the same), the TOPAZ interface through error as following:

info: Entering event queue @ 0.  Starting simulation...
gem5.debug: build/ALPHA_token_topaz/mem/ruby/network/topaz/TopazSwitchFlow.cc:350: void TopazSwitchFlow::wakeUpTopaz(): Assertion `topaz_message->destinations>0' failed.
Program aborted at tick 214
Aborted

As you can see, topaz interface complains about the message destination which is less than 0. The program aborted at very early stage. How is that possible? I change neither the Gem5 nor TOPAZ. Do you have any idea?

Thanks in advance.

Xiyue Xiang

Xiyue Xiang

unread,
Apr 22, 2015, 9:45:28 PM4/22/15
to topaz-...@googlegroups.com
In TOPAZ, I know the coordinate of a router is defined as (X,Y) tuple. I just have one more questions out of curiosity, what is this destination address? Why it is 0? Is it the core ID?

Valentin Puente

unread,
Apr 23, 2015, 3:45:47 AM4/23/15
to topaz-...@googlegroups.com
The assertion says that there is a packet with no destinations. Somehow the pointer returned by topaz is broken. The numline of the assert in the original code is 353, which makes me think that you are modifying the code. It is much faster to dig this by yourself an see what is happening with the debugger. I can`t help more from here...

Note that to use BLESS you need separate physical networks per class of traffic in the coherence protocol (I think that those routers don't support virtual networks).



2015-04-23 3:45 GMT+02:00 Xiyue Xiang <anders...@gmail.com>:
In TOPAZ, I know the coordinate of a router is defined as (X,Y) tuple. I just have one more questions out of curiosity, what is this destination address? Why it is 0? Is it the core ID?

--
You received this message because you are subscribed to the Google Groups "topaz-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topaz-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
--
vpuente

Xiyue Xiang

unread,
Apr 23, 2015, 10:17:56 AM4/23/15
to topaz-...@googlegroups.com
Hi, Valentin,

Thank you so much for the reply.

In terms of line number, I just insert a print line before the assertion to see if indeed the destination is 0. I am actually tracking the problem right now using gdb.

For the second point you made, I agree with you that BLESS does not support virtual networks. But why does it need a separate network for each class of traffic? To avoid protocol level deadlock? Can I send all packets through the same network? Is this possible to cause topaz return a 0 destination address? Thanks a lot.

Valentin Puente

unread,
Apr 23, 2015, 10:59:43 AM4/23/15
to topaz-...@googlegroups.com
yep... protocol deadlock. Consumer overflow by low order traffic can block the delivery of higher priority messages. In the simulator it might be not a problem (if buffering at NI is unlimited) but in "real life" will be.
Reply all
Reply to author
Forward
0 new messages