Can the AMBA AHB Slave give multiple SPLIT response again to the AHB Master that has been given SPLIT response before and after updating hsplit signal for that Master by the Slave?
Vishal,
The slave can't give another SPLIT response to the same master before the HSPLIT pulse because the master cannot be granted by the arbiter until the HSPLIT bit has been pulsed.
Once the arbiter is allowed to grant that master again (following the HSPLIT pulse), the slave can give another SPLIT response to the master when it next requests a transfer.
JD
Yes, the Slave can not give SPLIT response again if the Master hasn't been granted by the Arbiter; but if the Master is granted the bus just after hsplit being updated by the Slave; then can the Slave give SPLIT response to the same Master?
Thanks,
Vishal
Yes, that was what the second part of my earlier reply tried to explain.
To give you an example of this happening
This could happen if a slave received requests from multiple masters in turn, where it gives a SPLIT response to the first master, storing the full transfer request details so that it can prepare to complete that transfer request, and then SPLIT responses to subsequent master requests because it is busy working on the first master's request. Note that in a minimal complexity slave design, it is not also preparing to handle those subsequent requests, it only notes the subsequent master numbers, not the transfer request details, so that it knows which HSPLIT bits to pulse when it is next able to look at a new transfer request.
When the slave is ready to complete the first master's request, it pulses the relevant HSPLIT bit, the arbiter can then grant that master, the master repeats the request, and the slave can then complete it.
Now the slave is free to consider the second master's request, so it pulses the next relevant HSPLIT bit for one of the masters it previously received a request from, that second master can be granted, it repeats the earlier SPLIT request, and this time the slave can store that transfer request details and possibly give a second SPLIT response to the second master if it cannot complete the requested transfer immediately.
A more complex slave design might also be able to store the full details of the second and subsequent transfer requests so that it can pulse HSPLIT to each master only when it is able to complete that transfer (so the masters wouldn't see multiple SPLIT responses for the same transfer), but this is adding a lot of complexity to the slave design.
So a master could see multiple SPLIT responses for the same transfer, depending on the slave design complexity.
Yes, if the Slave is capable for storing transfer details then it would not give the SPLIT response again to the same Master whose transfer was given SPLIT response earlier.
But if the Slave is not capable for storing transfer details, then should the Master be capable of storing transfer details for splitted transfer as it has to resume the splitted transfer?
It doesn't matter whether the slave is capable or not, the master MUST repeat the failed transfer address phase.
The master behaviour to a SPLIT response is exactly the same as for a RETRY, it must repeat the failed transfer address phase until it completes with an OKAY or an ERROR response (section 3.9.5 in the AHB spec).
So the master doesn't need to know what the slave is capable of.