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

AHB Split and Retry

  • I am trying to write a generic task for AHB. If the response is Split or retry, how should the testbench flow. 
  • I'm not sure what your generic task is modelling, is it the master receiving the SPLIT/RETRY, the arbiter, or the slave issuing the response ?

    If a master receives a SPLIT or RETRY response it cancels the current transfer address phase to IDLE, and then re-attempts the access address phase transfer that caused the SPLIT/RETRY response.

    The arbiter receiving a SPLIT response will not grant that master again until the slave that gave the SPLIT response drives the relevant bit of HSPLIT high to signal that master can be regranted again.

    For a RETRY response the arbiter just looks at all the requesting masters and grants the highest priority requesting master (which might not be the master that received the RETRY response).

    If it is the slave you are modelling, if it gives a RETRY response because it couldn't quickly complete the requested transfer and wanted to free up the bus for other masters, it could work on preparing to complete the failed access so that it is able to complete it next time that master is granted. Or it coul djust forget that transfer and maybe next time the master requests that previously failed access it can now be completed.

    If the slave has given a SPLIT response, the slave should drive the HSPLIT[x] bit corresponding to the original master's HMASTER number only once the slave can complete the failed transfer.

    However as I'm not too sure what you are actually trying to do, the above might not be helpful, so it might help if you give a bit more detail on what you are modelling, and what area you don't understand.

    Also note that the AHB spec is now relatively old and most users will be using the newer AHB-lite or AHB5 protocols, neither of which have SPLIT or RETRY responses, so your question might not need answering if you were to use a newer version of the protocol.

  • Hi

    Just for your information I have moved your thread to the SoC forum where it should live.

    Thanks!