Hi,
When you talk about buffers in the SLICC files, do you mean
MessageBuffers like m_L2Cache_responseFromL2Cache_vec for instance? I
went through the code when the a Chip was created and I found that the
L2, L1 and the directory all had 3 different inputs buffers and 3 output
buffers, and therefore the reason I had 3 virtual networks. Do you mean
that these buffers reside in the 12 switches on the first level? But
then I would expect that they have 3 inputs, but maybe that is exactly
the reason they are virtual, which means that only one can be used at
the time?
/Mladen
Greg Byrd wrote:
Yes, that makes sense. The buffers referred to in the SLICC files are actually
in the switch. Since the PerfectSwitch has infinite bandwidth internally, the
cache/directory components could see multiple packets in a single cycle, for
example.
So the extra switch+link allows packets to leave/arrive the components at a
feasible rate.
...Greg
Niket wrote:
HIERARCHICAL_SWITCH and CROSSBAR topologies are designed to provide a
"total order" to requests so that broadcast protocols can be simulated.
Hence this indirection through root switch.
As regards your earlier question of the extra level of up switched in
the HIERARCHICAL_SWITCH, looking at the makeHierarchicalSwitch function,
I find these comments :
// Make a row of switches with only one input. This extra row makes
// sure the links out of the nodes have latency and limited
// bandwidth.
I guess this explains it. If it were not for these links, the requesting
nodes would flood the network with requests assuming infinite buffering.
-Niket
Mladen Nikitovic wrote:
Hi,
I'm trying to understand the implementation of the network when using
the HIERARCHICAL_SWITCH and the CROSSBAR topology in the
MOESI_CMP_directory protocol.
I have a configuration of 4 processors, 1 processor per chip. My
understanding is that the L1 cache controller, L2 cache controller and
the directory are the entities that need access to the network. This
means 4x3 entities in total = 12 nodes.
When choosing the HIERARCHICAL_SWITCH topology with FAN_OUT_DEGREE of 4
i get the following implementation when tracing the
makeHierarchicalSwitch function:
19 switches and 42 links are created.
Nodes 0 to 11 are hooked up to a switch each, which means 12 switches in
total. These 12 switches are then connected to 3 switches (according to
fan-out-degree) and these are finally connected to a root switch.
Now, in the "down network", the root switch is connected to 3 new
switches, and these are then directly connected to nodes 12 to 23.
It seems that the switches have only one output on the way up to the
root switch, but why do you need to create 12 switches in the first
level? Do these switches only have one input as well? If the next-level
switches can handle 4 inputs, why couldn't those handle the 12 nodes in
the first place?
On the way down the switches have 4 outputs, according to
fan-out-degree, correct?
The result is a structure that is asymmetrical, the up-network has more
levels of switches than the down-network, so the question is why this is
implemented this way? Is there a reason why there are switches with
different number of in/out-ports?
In theory, the hierarchical switch topology looked symmetrical to me,
but here I don't see that. Would be nice to understand this. The same
asymmetry appears when using the CROSSBAR topology, but the only
diffrence is that there are fewer levels of switches, (if i remember
correctly there are 12 + 1 root switch = 13 switches in total).
Also, I expected local communication to be possible (by going up a level
through a switch and then directly down, thus not through a root switch)
, but I see from the topology printout that all latencies are the same
no matter the location of the communicating nodes. Is there a reason why
local communication is not possible?
Regards,
Mladen
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}