On Feb 27, 2017, at 3:32 PM, raziye deylamsalehi 
<raziye.deylamsal...@gmail.com<mailto:raziye.deylamsal...@gmail.com>> wrote:


Hi Tushar

as I see in mailing list and documentation the num_dir is equal with number of 
memory controllers. That is correct?


As far as I know, in most coherence protocols (e.g., MOESI_CMP_directory), the 
“directory” and the memory controller are the same.
In other words, the directory also simulates the behavior of the memory 
controller.
Some of the folks working on the coherence protocols may have a better idea.


So what is the meaning of num_dir in moesi_cmp_directory protocol? For example, 
if we want to simulate an n*n NoC (that has less than n*n memory controller), 
what is the meaning of equality between num_dir and number of memory 
controllers?

In this file: configs/topologies/MeshDirCorners_XY.py,  the network based on 
this topology has 4 dir. Then what does happen in its cache coherency protocol?


This just means that there are 4 memory controllers, one at each corner.
Each core in MOESI_CMP_directory is connected to a private L1 + shared L2 
slice. So each router is connected to a L1 and a L2.
The corner routers are also connected to the directories (memory controllers).


L1 is private in protocol. is there any directory for L1 ?


The directories are at the 4 corners in MeshDirCorners ...


On Fri, Feb 24, 2017 at 1:38 AM, Krishna, Tushar 
<tus...@ece.gatech.edu<mailto:tus...@ece.gatech.edu>> wrote:
No. You can run any protocol with any network topology.


On Feb 23, 2017, at 5:06 PM, raziye deylamsalehi 
<raziye.deylamsal...@gmail.com<mailto:raziye.deylamsal...@gmail.com>> wrote:

Thank you very much Tushar, I read most of them but you defined those very 
clear.
I have some more question: could this redundant link make us to change protocol 
file or another files?

On Thu, Feb 23, 2017 at 8:40 AM, Krishna, Tushar 
<tus...@ece.gatech.edu<mailto:tus...@ece.gatech.edu>> wrote:


On Feb 22, 2017, at 7:03 AM, raziye deylamsalehi 
<raziye.deylamsal...@gmail.com<mailto:raziye.deylamsal...@gmail.com>> wrote:

I read the following paragraph from “on-chip networks” book:
“Inoff-chip networks, channel widths are limited by pin bandwith; this 
limitation causes flits to be broken down into smaller chunks called phits. To 
date, in on-chip networks, flits are composed of a single phit and are the 
smallest subdivision of a message due to wide on-chip channels.”
“In some networks the flit size equals the phit size and thus, there is no need 
to split into smaller phits.” How I can know it for alpha processor?
You are getting confused between packets, flits and phits.

For a processor with cache coherence traffic, in gem5 the size of control 
packets (e.g., coherence requests) is 8B (64b) and data packets (e.g., 
coherence response) is 64B + 8B = 72B (576b).
Default flit (i.e., link) size is 16B (128b).
This means control packets fit in 1-flit, data packets fit in 5-flits.
Data packets are automatically split into 5-flits at the NI.

[Note: In off-chip networks, due to thinner links off-chip, a 64b flit might 
have to be sent over multiple cycles through the pins. Thats where phits come 
in, but you don’t need to worry about those].



Yes, I want to have some links to be wider. Do I need break flits into phits 
For adding multiple links in topology file?
If you want to make some links in the NoC wider, then those routers need to 
dynamically merge multiple flits into a packet, or vice versa, which you can 
imagine is hard.
If you want wider links just to give some parts of the NoC more bandwidth, you 
can add multiple links between the same routers (for e.g, adding 2 links will 
make the overall width 256b, allowing 2 flits to traverse in parallel).




On Wed, Feb 22, 2017 at 3:08 AM, Krishna, Tushar 
<tus...@ece.gatech.edu<mailto:tus...@ece.gatech.edu>> wrote:
All links are equal sized in garnet.
If you have unequal widths, then you need a way to break flits into phits 
mid-way in routers.
If you want to have some links to be wider, I would recommend adding multiple 
links in the topology file.


On Feb 21, 2017, at 6:33 PM, raziye deylamsalehi 
<raziye.deylamsal...@gmail.com<mailto:raziye.deylamsal...@gmail.com>> wrote:


I want to assign variation on some of links (with link id) not all of links. do 
I can change it in my topology with ni_flit_size?

On Feb 22, 2017 2:53 AM, "Krishna, Tushar" 
<tus...@ece.gatech.edu<mailto:tus...@ece.gatech.edu>> wrote:
For that you will use --link-width-bits
ni_flit_size is set to link_width_bits / 8 inside configs/network/Network.py
You can see this file for other options as well.


On Feb 21, 2017, at 4:48 PM, raziye deylamsalehi 
<raziye.deylamsal...@gmail.com<mailto:raziye.deylamsal...@gmail.com>> wrote:

Thank you for answering.
I saw this page. ni_flit_size is "network interface flit size in bytes", I want 
to change width of internal links (links between router) so I must use 
ni_flit_size?

On Mon, Feb 6, 2017 at 11:50 PM, Krishna, Tushar 
<tus...@ece.gatech.edu<mailto:tus...@ece.gatech.edu>> wrote:
http://www.gem5.org/Garnet2.0#Configuration

ni_flit_size changes flit size.

On Feb 6, 2017, at 2:14 PM, raziye deylamsalehi 
<raziye.deylamsal...@gmail.com<mailto:raziye.deylamsal...@gmail.com>> wrote:

Hi
I use garnet2.  which files must be change for modifing flit size?
I searched in mailing list and I understood that need to edit flit size for 
changing int_link in garnet, that is correct??

Thanks

_______________________________________________
gem5-users mailing list
gem5-users@gem5.org<mailto:gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users


_______________________________________________
gem5-users mailing list
gem5-users@gem5.org<mailto:gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

_______________________________________________
gem5-users mailing list
gem5-users@gem5.org<mailto:gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users


_______________________________________________
gem5-users mailing list
gem5-users@gem5.org<mailto:gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org<mailto:gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users


_______________________________________________
gem5-users mailing list
gem5-users@gem5.org<mailto:gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

_______________________________________________
gem5-users mailing list
gem5-users@gem5.org<mailto:gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users


_______________________________________________
gem5-users mailing list
gem5-users@gem5.org<mailto:gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

_______________________________________________
gem5-users mailing list
gem5-users@gem5.org<mailto:gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users


_______________________________________________
gem5-users mailing list
gem5-users@gem5.org<mailto:gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

_______________________________________________
gem5-users mailing list
gem5-users@gem5.org<mailto:gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to