 This time we're going to be looking at a multi-cycle synchronous bus protocol. It's not going to be too different from the single cycle bus protocol we had before. You can see we've still got our clock cycle. But now, instead of having our operations spend the entire clock cycle, we've got several clock cycles in there. So now our operation can span several clock cycles. This will give us a number of advantages. As for the other element in our protocol, we still have the address and control lines. We still have our data, but we've added this slave ready signal. So the multi-cycle synchronous bus protocol allows our operation to span several clock cycles. This means that if one device takes far longer than another device, the fast device can still respond quickly. Maybe it only takes a couple clock cycles where the slow device can take 10 or 20 clock cycles. In the single cycle synchronous bus protocol, we would have had to adapt our clock cycle to handle that really long request. But in the multi-cycle protocol, we can set our clock cycle to be the smallest possible element, and then each device can just take as many clock cycles as it needs. So this means that at the very beginning of our operation, our master puts the information on the bus still. And it's just going to stay there until the very end of the operation. Until the master knows it's gotten its data, it's stored it, everything is okay. In this example, that's taking five clock cycles total. The slave will see that request very early on in the first clock cycle. But it may take it several clock cycles to actually manage to act on that request. It may have to decode the request, go look through its hardware to find this piece of data that the master device is interested in, encode it, load it onto the bus. And then in the last clock cycle, it can actually post this data on the bus where it will just sit there for the entire clock cycle. This time, the master isn't just going to automatically know that the data is available at the end of the clock cycle, because we now have several clock cycles where that data isn't available. So this time, the slave is going to assert a slave ready signal. This indicates to the master or anything else on the bus that the slave has put some data on the bus, and anybody that's interested in this data can read it off. Our write operation is pretty similar. In this case, the master will put the request on the bus. It will also put the data to be stored on the bus, and that will just take however many clock cycles it needs. And at the end, the slave will assert its slave ready signal to indicate that, yes, it has completed the request, and the master can go on with whatever else it needs to do.