Login

Important information

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.

ARM websites use two types of cookie: (1) those that enable the site to function and perform as required; and (2) analytical cookies which anonymously track visitors only while using the site. If you are not happy with this use of these cookies please review our Privacy Policy to learn how they can be disabled. By disabling cookies some features of the site will not work.

ARM Community: AHB Master during RETRY/SPLIT response - ARM Community

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

AHB Master during RETRY/SPLIT response Rate Topic: ***-- 1 Votes

#1 User is offline   sreenath 

  • Member
  • Pip
  • Group: Members
  • Posts: 3
  • Joined: 26-July 11

Posted 02 August 2012 - 11:22 AM

When a AHB Master is doing an burst and it gets an SPLIT/RETRY response, from the Spec I see that there is a general statement saying - "it can re-attempt the transfer".
What I would like to know specifically is:
  • Is it compulsory for the Master to re-attempt the transfer?
If the answer to above question is YES, then I would like to know if all below possible scenarios are as per the protocol behavior:
  • Does the Master need to re-attempt the same transfer where it got SPLIT/RETRY?
  • Can the Master go ahead with some other new transfer without trying to re-attempt the same transfer at any point of time?
  • Can the Master just try a new transfer and later at some point try to re-attempt the transfer for which it got SPLIT/RETRY?

Please clarify.

--Sreenath
1

#2 User is offline   JD 

  • Regular Contributor
  • PipPipPip
  • Group: Members.
  • Posts: 260
  • Joined: 17-November 06

Posted 02 August 2012 - 02:56 PM

In most places in the spec it uses words like "should" for what the master must next do, but there is one use of a mandatory "must" and that is in section 3.9.2 where the description of the SPLIT response in table 3-5 says that the master must retry the transfer.


I have always thought that this was a mandatory requirement, that the master must re-attempt the failed transfer (and any remaining transfers in the previously indicated burst).

If you think about it, both responses are given to allow the slave time to prepare to complete the requested transfer, so if the next thing the master did when it finally got access to the slave again was a completely new transfer, you have just wasted lots of cycles.

So I would assume that the "compulsory" question is a "yes" reply.

1. The master needs to perform the same transfer that caused the SPLIT/RETRY response, as that is what the slave has been preparing to complete.

2. The master cannot go ahead with other transfers until it completes the original failed transfer (or burst).

3. The master cannot complete this failed transfer at some later point, it must be the first thing the master does when it next gets access to the bus.

Admittedly I can only find one use of "must" to imply that this behaviour is compulsory, but especially in the case of a SPLIT response it would be a bit of a waste of time waiting until the slave indicates your master can be regranted, only to then ignore the transfer it has been preparing to accept during this time. RETRY the arguments are less strong as the master can remain granted after a RETRY response, but you would think that the slave will be attempting to receive the failed transfer again rather than forget it and then face the same number of wait states again should the master still want the uncompleted transfer.

Perhaps a lot of reading between the lines, but that's how I read it.

JD
1

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic