Mladen Nikitovic wrote:
When you talk about buffers in the SLICC files, do you mean
MessageBuffers like m_L2Cache_responseFromL2Cache_vec for instance?
Yes. If you look at Chip.C in your ruby/generated/... directory, you'll
see calls to m_net_ptr->getToNetQueue or getFromNetQueue to populate
those vectors. The getXXX methods return a pointer to a MessageBuffer,
so it's the same MessageBuffer that's in the switch to which the Chip is
directly connected.
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.
Yes. There are separate buffers for each virtual network.
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?
Messages on the physical link are multiplexed among the different
virtual networks. Each virtual network has its own buffers. There is
one physical link between the "leaf" switches and the global switch (in
the case of crossbar).
What I meant was this: Let's consider the crossbar topology -- one
global switch, with individual "leaf" switches connected to the chip.
On the global switch, assume that messages arrive on input ports 0 and
1, and they are both destined for output port 2. In the PerfectSwitch
implementation, these input messages are copied immediately to the
outgoing MessageBuffer (for the appropriate virtual network) at port 2.
If the consuming cache/directory is looking at that MessageBuffer, it
will "see" the messages on the same cycle (or perhaps on successive
cycles). By putting a Throttle (link) between this buffer and the
consumer, it insures that the second message won't be seen until enough
time has elapsed to model the transmission of the first message over the
link.
...Greg
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}