 This time, we're going to look at the asynchronous bus protocol. So our asynchronous bus protocol still has a couple similar things that we're used to. We still have the address and control. We still have some data. We're still interested in doing a read operation. So we still need to know that we want to do a read operation and where we're going to read from. And we still want to go collect our data when we're done. But this time, we don't have a clock signal. So instead, we are going to use what's called a handshake protocol. In this case, we have a couple of different signals, our master ready and our slave ready signals, that indicate when a device has put some useful information on the bus. And that information is ready to be consumed. So again, we'll begin from the left hand side. And at the very beginning of our bus cycle, the master will go ahead and put the address and the control onto the bus. And make them available for all the other devices to potentially find it. But none of the devices are just immediately going to start trying to work with that data. Instead, they're going to wait until they see this master ready signal. Once the device sees the master ready signal, then it will try to decode the address. If the request applies to that device, then it will go handle it. There's a short delay between when the master actually puts the data on the bus, and when the master actually asserts its master ready signal. This is designed to handle bus skew. Bus skew arises because different lines can take different amounts of time to transmit their data. Some will be longer, some will be shorter, some may actually just have a faster transport. So we want to make sure that the data on the address and the control is good by the time it gets to all of the various devices. So we delay the master ready signal long enough that we're sure that the master ready signal will never reach one of the IO devices before the address and control does. We don't actually have to wait until the address and control signals have been propagated to every device. Just long enough that we know that they will arrive before the master ready signal does. So in between, say, T1 and T2, a whole lot of things are going to happen. All of this information is propagating down the bus. Once it actually reaches the device in question, the device needs to pull off the address. Notice that the request applies to this device and go handle that. Once it has the data that's been requested, then it will encode it in a format that can be put on the bus. Then it will actually go put the data onto the bus and assert the slave ready signal. Depending on the actual implementation of the bus protocol, we could allow some room for bus skew here. Delay the slave ready signal slightly. Or we could make the master accommodate that when it reaches the master. So in that case, the master would see the slave ready signal in the data. And it would just wait a bit before it actually takes the data off the bus and uses it. So we've got some time here for propagation. We have to wait for the data to be propagated back to the master. Then once it reaches the master, the master is going to pull it off and stick it into a register. So that will take a little bit as well. Once that's finished, then the master will de-assert its master ready signal. It's finished this request and it doesn't need the slave to continue sending this data anymore. So this will be the signal for the slave to stop sending the data. But the master is still going to leave the address and control signals on the bus for just a little bit longer. Again, this is designed to allow for some bus skew. Because we want to make sure that the master ready signal is never asserted when we have some random value for the address and control. We don't want the master ready to get into some device while we've got some weird values on the address and control that just happened to match something that this device can do. Or worse, yet something that this device recognizes but can't actually do and may end up actually damaging the device. So we leave just a little bit of time here to ensure that any device that sees the master ready signal asserted will also see the old address and control. Once we know that the de-asserted master ready signal will reach all the devices before any changes in the address and control, we can go ahead and change that data. But it will take a little bit for the master ready signal to propagate back to the slave. Once it does, then the slave will stop sending data and it will de-assert its slave ready signal.