 This time we're going to be looking at bus arbitration. So we could actually have multiple masters on a bus. Maybe we have multiple processors, or we might actually have an IO device that might also like to access the bus. Some IO devices actually want to be able to pull things off of the bus. They want a request of themselves. So we could end up with multiple masters on our bus. But our bus is a limited resource. We only have one set of lines for all of the fields that we need, the satellite line, the control line. So we have to have some way of determining who gets to use the bus. A bus arbiter will allow us to do this. It will allow us to choose who gets to use the bus. We're going to be looking at four different types of bus arbitration, and we'll mostly focus on this first type, which is a centralized parallel architecture. In this case, we have a centralized bus arbiter which determines who gets to use the bus. Any of the masters that might want to use the bus will send a request to the bus arbiter. There's a bus request one line here, a bus request two line there, and they will directly request the bus arbiter to give them access to the bus. If the bus arbiter decides this is a good idea, we'll let you use this, then it asserts the bus grant signal for that product. If the bus arbiter agrees, decides that yes, this master can use the bus, then it will assert the corresponding bus grant signal. If a bus grant one, a bus grant two, get one of those for each of the masters that we've got. The other masters will just sit there and wait, but whichever master has been granted access to the bus can go ahead and use it however it needs to. But there's three other ways we could use to allocate the bus. With daisy chain arbitration, we'd have one master connected to the arbiter and all of the others would be connected to another master. We just have one long string of masters all connected, and any time any one of the masters wants to use the bus, they would send a request down the single bus request line to the arbiter. The arbiter would say, hey, something wants to use the bus, and if it hasn't already granted access to the bus, then it's going to just grant access to the bus. That bus grant signal, though, will travel between each one of those masters. I'm just going to walk down the list of masters, and as soon as it gets to the master that's requested the bus, it will stop passing that signal on. But if a master comes along and wants to use the bus when it's already in use, it will look at the bus request signal and say, hey, somebody's already requested the bus. I'm going to have to wait. So it will wait to actually assert that bus request signal and potentially preempt the bus grant signal from being passed on to the master that's already using it. Instead, it will just sit there and wait until that bus request signal has been turned off. Once it's de-asserted, then it will assert that it would like to use the bus as well and wait for the bus grant signal to be sent back down the line. So in this case, we have one bus request line that's shared by all of the masters in the computer and a daisy chain of bus grant signals that passes from one master to another. Whichever master has highest priority will grab the signal first and never allow it to be propagated down to one of the lower priority masters. But there's also a couple of distributed methods we could use. Each of those methods requires a bus arbiter. We have to physically put an arbiter into the machine, but sometimes we can't do that. We might like to have a distributed arbitration system because we may not have a place to put an arbiter. We may be trying to communicate between multiple machines or other things that just can't really contact an arbiter for us. So distributed arbitration schemes don't have a fixed arbiter. They're set up in such a way that any one of the masters can do the arbitration all by itself. With self-selection, each of the machines has some number assigned to it. Whenever it would like to use the bus, that machine will send its number out onto the bus request line, which would be broadcast to all of the other masters on the system. All of the masters on the bus will be able to see all of those numbers coming in, indicating who all wants to use the bus. Then whoever has the highest priority number gets to use the bus first, and everybody else waits. So all of them will be able to tell, hey, either I do or I don't have the highest priority here, so if I have the highest priority, I'll go ahead and use it. If not, I just wait. Distributed arbitration by collision detection is a little different. This method is actually used for Ethernet communication, and the way it works is you listen on the bus. You see if anybody else is using the bus at the moment. If nobody else is using the bus, then maybe it's available for you. So you start putting your message onto the bus and you listen. If you hear anything else on the bus, then you just stop. Somebody else also wanted to use the bus. Now you have to decide who gets to go first. This time, we don't have any way to tell who has priority because we don't have anybody counting our priorities. So this time, we'll just wait for a random amount of time and then try again. If we don't hear anything on the bus, then we'll try putting our message back on again. If we hear somebody, then we'll back off and we'll wait again for a while. Since it's unlikely two machines will repeatedly pick the same random number, this works reasonably well, which is why it gets used for Ethernet communications. There, we have no concept of what a bus arbiter could be. We just have multiple machines which are laid out in various different places and they need to be able to communicate. So these are the four main methods of bus arbitration. Well, all of them have seen some use. So we're mostly going to be looking at the centralized architecture because this gives us something useful to work with. It's designed for systems inside machines and we can do a lot of really interesting things with this.