• State Accepted Answer
  • Replies 2 replies
  • Subscribers 350 subscribers
  • Views 229 views
  • Users 0 members are here
Options
Related
How was your experience today?

[AHB] When should master assert htrans=IDLE once hresp=ERROR occured from slave?

Vishal Moladiya

I have some doubts regarding start of new transaction after error response from slave.

In specs after error response, master should first driver HTRANS to IDLE and then start new transaction.

AHB Lite IHI0033A: Error response 

Here, when master detects ERROR response from Slave, it changes the HTRANS to IDLE. Without waiting for HREADY to be asserted i.e completing ERROR Response by Slave. (In specs it is written that, "To start the ERROR response, the slave drives HRESP HIGH to indicate ERROR while driving HREADY LOW to extend the transfer for one extra cycle. In the next cycle HREADY is driven HIGH to end the transfer and HRESP remains driven HIGH to indicate ERROR.").

 

AHB IHI0011A: Error Response.

In this version of Specs from waveforms, Master Changes HTRANS state after completion of ERROR response by Slave.

Doubts:

  1. It is not mentioned in Specs that when master should driver HTRANS to IDLE after ERROR response, so there are two scenarios:
    • Master changes HTRANS to IDLE while ERROR is HIGH and HREADY is LOW.
    • or Master changes HTRANS to IDLE while, both ERROR and HREADY are HIGH.
  2. Should this support be provided in master driver by configs or transaction ?
Parents
  • +1

    The diagram in the original AHB specification (IHI-0011A) does not show what HTRANS does (HTRANS wouldn't be considered one of the "control" signals), so it isn't a good example to look at. However you would see the required timing for the previous figure 3-13 diagram demonstrating a RETRY response (the HRESP and HTRANS timing requirements are the same in both).

    The requirement for the 2-cycle ERROR response is that as this is a pipelined protocol we need to ensure that the AHB manager has the opportunity to cancel the next indicated transfer address phase (to preserve the order of execution) before the ERROR response completes.

    Referring the to IHI-0033A AHB-lite specification diagram (figure 5-1) we see the AHB subordinate decide to return an ERROR response after T2. HREADY is driven low by the subordinate at this point, so the current data phase operation has not completed and the next transfer address phase request will not be sampled (only happens when HREADY is high).

    At T3 the AHB manager samples HREADY low and HRESP=ERROR, so it can decide now if it wants to cancel the next transfer address phase and change HTRANS to IDLE (essentially cancelling whatever transfer was being signaled to address B). At the same time the subordinate is now in the second cycle of the 2-cycle ERROR response, so drives HREADY high.

    Then at T4 the manager samples HREADY high and HRESP=ERROR and knows the NONSEQ transfer to A failed. And importantly HTRANS is now sampled by the next selected subordinate as IDLE, so no operation is required (the transfer that was signalled to address B has been cancelled, so allowing the manager to go away and try to fix whatever was wrong with A before presumably re-attempting A and then B).

    Note that the AHB-lite manager can also choose to continue with the next transfer (see the comment at the foot of page 5-4 in the AHB-lite spec), so in that case HTRANS would not change and the 2-cycle ERROR response would just look like an additional wait state.

Reply
  • +1

    The diagram in the original AHB specification (IHI-0011A) does not show what HTRANS does (HTRANS wouldn't be considered one of the "control" signals), so it isn't a good example to look at. However you would see the required timing for the previous figure 3-13 diagram demonstrating a RETRY response (the HRESP and HTRANS timing requirements are the same in both).

    The requirement for the 2-cycle ERROR response is that as this is a pipelined protocol we need to ensure that the AHB manager has the opportunity to cancel the next indicated transfer address phase (to preserve the order of execution) before the ERROR response completes.

    Referring the to IHI-0033A AHB-lite specification diagram (figure 5-1) we see the AHB subordinate decide to return an ERROR response after T2. HREADY is driven low by the subordinate at this point, so the current data phase operation has not completed and the next transfer address phase request will not be sampled (only happens when HREADY is high).

    At T3 the AHB manager samples HREADY low and HRESP=ERROR, so it can decide now if it wants to cancel the next transfer address phase and change HTRANS to IDLE (essentially cancelling whatever transfer was being signaled to address B). At the same time the subordinate is now in the second cycle of the 2-cycle ERROR response, so drives HREADY high.

    Then at T4 the manager samples HREADY high and HRESP=ERROR and knows the NONSEQ transfer to A failed. And importantly HTRANS is now sampled by the next selected subordinate as IDLE, so no operation is required (the transfer that was signalled to address B has been cancelled, so allowing the manager to go away and try to fix whatever was wrong with A before presumably re-attempting A and then B).

    Note that the AHB-lite manager can also choose to continue with the next transfer (see the comment at the foot of page 5-4 in the AHB-lite spec), so in that case HTRANS would not change and the 2-cycle ERROR response would just look like an additional wait state.

Children