This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Regarding retry response

Im new to the ahb protocol can  any on give me an idea about retry response, when a retry response is generated from slave side.

Parents
  • Are you really using the AHB protocol, or is this just a theoretical question ?

    The reason I ask is that most designs have now moved away from this first release of AHB with RETRY (and SPLIT) reponses, and instead are looking at AHB-lite or AHB5 where each master is on its own bus, so not needing RETRY (or SPLIT responses only relevant to multi-master buses), so if you are new the the AHB protocol, should you instead be looking at these newer releases ?

    To answer your question a RETRY or SPLIT response would be given by a slave when it knows that a requested transfer could take a large number of cycles to complete. If the slave was to simply hold HREADY low to add wait states, this would stall the bus, and as AHB supports multiple masters all sharing a single bus, all those other masters would also be stalled.

    So by issuing a RETRY response the slave tells the master to repeat the failed transfer, but importantly then allows the bus arbiter to grant any higher priority master trying to use the bus, minimising the effects on the system of this slow access.

    A SPLIT response would also tell the master to repeat the failed transfer, but tells the arbiter to NOT grant this master again until the slave indicates it CAN complete the failed transfer (by asserting a bit of the HSPLIT bus), so even better for performance, but requiring more logic to implement in the arbiter and slave.

    As to when the slave decides to generate the RETRY ro SPLIT response, that would be a system designer's decision, deciding how many cycles you could afford one slave to stall the bus before the performance loss becomes significant. The slave can either wait for those X cycles before issuing the RETRY/SPLIT response, or if it knows the requested access will always take many cycles it can issue the SPLIT/RETRY response immediately.

Reply
  • Are you really using the AHB protocol, or is this just a theoretical question ?

    The reason I ask is that most designs have now moved away from this first release of AHB with RETRY (and SPLIT) reponses, and instead are looking at AHB-lite or AHB5 where each master is on its own bus, so not needing RETRY (or SPLIT responses only relevant to multi-master buses), so if you are new the the AHB protocol, should you instead be looking at these newer releases ?

    To answer your question a RETRY or SPLIT response would be given by a slave when it knows that a requested transfer could take a large number of cycles to complete. If the slave was to simply hold HREADY low to add wait states, this would stall the bus, and as AHB supports multiple masters all sharing a single bus, all those other masters would also be stalled.

    So by issuing a RETRY response the slave tells the master to repeat the failed transfer, but importantly then allows the bus arbiter to grant any higher priority master trying to use the bus, minimising the effects on the system of this slow access.

    A SPLIT response would also tell the master to repeat the failed transfer, but tells the arbiter to NOT grant this master again until the slave indicates it CAN complete the failed transfer (by asserting a bit of the HSPLIT bus), so even better for performance, but requiring more logic to implement in the arbiter and slave.

    As to when the slave decides to generate the RETRY ro SPLIT response, that would be a system designer's decision, deciding how many cycles you could afford one slave to stall the bus before the performance loss becomes significant. The slave can either wait for those X cycles before issuing the RETRY/SPLIT response, or if it knows the requested access will always take many cycles it can issue the SPLIT/RETRY response immediately.

Children
No data