 Here's an example of a timing diagram for a bus arbiter supporting three different masters, each of which has some priority. So our master one has the highest priority and master three has the lowest priority. As usual, we'll be able to read this diagram from left to right to see what's happening and when. We don't have any preemption in this diagram, however. The first thing that happens is that master three requests the bus. It asserts its bus request signal and it sits there for a bit. It takes a little bit for the arbiter to notice that yes, it's requested the bus. Nobody else has priority to access the bus. So the arbiter goes ahead and grants access to master three. Master three uses the bus for a while and then de-asserts its bus request signal. The bus arbiter then says, okay, you're done using the bus. So I'm going to disable your ability to use the bus. In the meantime though, the other two masters have decided they'd like to use the bus as well. So you can see master two has come in and wants to use the bus. And then master one has also come in and would like to use the bus as well. Since master one has priority to use the bus, the arbiter grants it access first. So it asserts the bus grant one signal. Master one uses the bus. And then when it's done, de-asserts its bus request signal. And the arbiter de-asserts the bus grant signal. Then the arbiter can finally grant access to master two. Master two has been sitting around waiting for the bus for quite a while. But the bus was either in use or somebody else had priority. So the arbiter finally grants access to master two. Master two uses the bus for a while. Once it's done, it de-asserts its bus request signal. And the arbiter again de-asserts the bus grant signal. So a basic arbiter is actually pretty simple. In this case, we do have some priority. We're not just using a round robin scheduling. But the basic concepts of requesting access to the bus and granting access to the bus are actually pretty straightforward.