Okay. So that finishes what I was talking
about, . And now we get to move onto a, a
fun subject. And how to go about
implementing shared memory in a small
symmetric multiprocessor. So to recap, the
multiprocessor has processors and memory.
And all the processors are equidistant
away from the memory. Hence, the name,
symmetric. you also have . And, . The
things here are fists, and graphics, and
networks. And these also end up living on
your or your processor bus. Now, lets take
a look at one of these processor buses.
And see, roughly, what, what one of these
things looks like. So here, we have two
processors and some memory. It's all
hanging off of a bus. And when I say a
bus, I actually mean a multi-prop bus. So
any of these entities can drive different
wires. On this bus. Now, of course, you
need to be careful here to not have
multiple entities driving the wires at the
same time. And hence, you need some sort
of arbitration to prevent that. You could
have a, pull down style bus. Where
multiple people can be trying to drive the
bus at the same time. And nothing will set
on fire. Because there's basically, some
sort of resistor which pulls the bus up to
a certain value. And then, when the entity
wants to not assert anything onto the bus.
It just floats its output. Or when it
wants to drive something on the bus, it'll
actually pull it down to value inside. So
that'll be a zero pulled down and if it
doesn't drive anything, you just pull it
out, point to y. But of course you can
have multi, multi-drop buses. And, I
wanted to sorta talk a little bit about
arbitration for a bus. Cuz even if you
have a multi-drop bus you still have
multiple people screaming on this bus at
the same time. It's a shared medium. It's
like if everyone in this room were trying
to scream at the same time. Trying to
communicate. . Figure out what's going on.
And this is in contrast to sort of point
to point systems. which we will be talking
about in a few lectures. Where we'll be
talking about other coherent systems that
you can implement over switch networks.
But for right now let's assume that you
just have a set of wires. Everyone can
basically drive these wires. Everyone can,
receive from these wires. And usually,
arbitration actually is done as a pull
down style bus. So let's, let's think real
hard, a couple ways how to do this. How,
how do you do arbitration? people, once
you scream at the same time and say, I
want the bus. Anyone have any thoughts?
So, , one way to do this, and this is
actually relatively common for
arbitration, is you have . And, , let's
say there are, . Your three request wires.
And then three grant wires. So, this is a,
a valid way of going, doing this, and
actually this is not too uncommon. As to
how it should, which has however many
requesters coming in, someone, search the
request wire and. And a signal comes back
from the arbitrator check. And, In fact,
in something like the PCIE or . There's a,
there's a, something that's very similar
to this. There's a PCI post controller.
You, each device that's plugged into the
multi drop bus pulls the wire down request
a bus. And within one cycle, the
arbitrator makes a decision. And if you
have priority inside there, it could .
There's different ways to go about doing
this. Today we'll assert one of the grant
wires coming back and that's who wins the
arbitration. So that's one way to go about
doing this. Another way is actually to
have a, let's say you have three different
entities on this bus, you view it in a
more distributed fashion. You could have a
multi-drop bus. And if you have three
entities, you actually have three wires on
your arbitration bus. And when someone
wants to use the bus, they just pull down.
And there's, there's pull up resistors.
What happens now is everyone can see who's
requesting at the same time and if you
have a fixed priority, let's say if all
three wires are pulled down then question
one always wins or the lower number of one
always wins. You could do something like
that, so you can do it without having a
specific active entity you can dis tribute
fashion. So that's actually pretty common
in some of these clusters and, and but you
also see this where there is operator
check if you want to do handsier
operation. Okay so let's split up our.
From control here. So control is going to
be. I'm doing a load, or I'm doing a
store. it's like a request. It's, it's ,
probably not actually, I'm doing a load
and I'm doing a store. It's probably, load
and store are cut into smaller
transactions. Like, as we'll, as we'll see
soon. Our protocols, there might be a
request for a line or something like that.
Or a request to have exclusive access to
data. And that will go across our control.
but it could also just be a load and
restore. .... From the process of memory
is the same. There's addresses, there's
some data, of course you hopefully your
probably not going to talk on your bus.
You can do it when you talk but it's
probably what you don't want to do. Okay,
so the easy contisioner of some multidrop
buses scream at the same time and whatever
you say on the bus everyone else hears.
One of the interesting things is that you
may not want to... The bus, arbitrate the
bus, and then own the bus for a long
period of time, and then release the bus.
Instead, you actually might want to
pipeline these operations. So, such that,
you can be arbitrating for the next use of
the bus while the current use of the bus
is currently still going on. So, to sort
of show this graphically let's say this is
a transaction here for a close that
Processor one is doing. So Processor one
puts on the arbitration bus, saying, I
want to use this bus sometime in the near
future. And it wins. Then, let's say it
actually, the bus is designed so that each
subsequent cycle is, have, the, the next
thing happen. So it's actually these four
cycles . Now. It's probably not this
simple. But I kind of want to get the idea
across here that you can pipeline access
to the bus and be. And, and there's good
reason to do this. Because, for instance,
if you're trying to do a load from memory.
It takes time for the data to come back.
So the other option is you drive the
address. And, you just wait for the memory
to respond to the, to the load data or
something like that. But instead, if you
pipeline it, some other entity can start a
different transaction here. And you have
another transaction happening there on the
address bus. While you're waiting for the
memory to basically look up and get back.
Yeah.
So you'ld overlap nineteen pipeline buses.
one other thing I wanted to say is that
this is a pretty simple pipe like bus
model. You can go to much more advance
things that are called split phase
transaction buses. Where what you'll
actually do is you'll basically arbitrate
for a bus, drive a request onto the bus,
and then the, the outcome of that may take
tens of cycles to release. meantime. And
the entity which has to respond, then,
rearbitrates for the , and gives the
response. So a good example of this is one
processor is trying to loot both the main
memory. very far away. It's going to take
hundreds of cycles to respond. So it the
bus. This load transaction, and the
address. And the transaction was designed
such that the bus, engineer designed it
such that data doesn't come back, in the
load transaction. Sometime in the future,
the memory controller, will arbitrate from
the bus . Well instead of having p1
arbitrate as the memory controller and it
will have something like load response.
And then load response will say maybe it
will the address. Maybe it won't. Probably
has to drive something here so that it
knows, so that the system knows which
response that it is memory transactions
happening. And then finally . So to sum up
here you can actually have multiple
transaction to the bus and have what we
think of as one transaction just a load
from memory actually split into multiple
transactions. They call the split paid
transaction .