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 .