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 behaviour after an error response - ARM Community

Jump to content

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

AHB: Master behaviour after an error response Rate Topic: -----

#1 User is offline   THO 

  • Member
  • Pip
  • Group: Members
  • Posts: 3
  • Joined: 23-April 12

Posted 23 April 2012 - 08:46 AM

Hi,
I have a question regarding the behaviour of a master after an error response.

The specification is clear in the point what should happen if the master is cancelling a burst. But what should be the behaviour of the master if HTRANS is already IDLE?

Is the master allowed to start a new transfer if HRESP is ERROR (T4)? If this is the case, where can I find this statement.

Thanks a lot for your support

Thorsten

Attached File(s)

  • Attached File  Case.png (8.86K)
    Number of downloads: 19

0

#2 User is offline   JD 

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

Posted 09 May 2012 - 09:30 AM

Your diagram shows HTRANS was IDLE in the address phase of the transfer (T1) to which you are returning the ERROR response, so that would be a protocol violation - see AHB-lite protocol, page 3-5, definition of an IDLE cycle.

If HTRANS had been NONSEQ or SEQ in cycle T1, that would allow an ERROR response to be returned in T3-T4, so looking at this revised scenario...

If the master decides to immediately react to an ERROR response it must cancel the currently indicated address phase transfer and change HTRANS to IDLE. The protocol doesn't make any reference to the current value of HTRANS at this time, so IDLE/BUSY/NONSEQ/SEQ are all treated in the same way, HTRANS must be IDLE in the second of the 2 cycle ERROR response.

The master doesn't know that it is seeing an ERROR response until the start of T4 when it samples HRESP, so at this point it IMMEDIATELY has to decide what to drive on HTRANS/HADDR/HWRITE etc. if it was to be able to IMMEDIATELY respond to the ERROR. This would almost certainly become a critical timing path as there is a lot for the master to do to work out the transfer it needs, so the simpler option is the default IDLE cycle to be indicated.

So you definitely cannot signal a NONSEQ access in T4 if that is the master's response to seeing the ERROR.

However if a master chose not to "cancel a burst", it could signal a NONSEQ in T4 as this would simply be the IDLE-NONSEQ change described in "Waited transfers" on p3-16.

JD
1

Share this topic:


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