Clarification Required on AHB hrdata Error Response Timing During Read Transaction

Hello,

I have a question with the error response. 

We intend to utilize the HRDATA signal even when a transaction results in an error response.

Our question is when the master initiates a read transaction and the slave provides an error response, at what point is the HRDATA signal expected to be valid? Should the HRDATA signal be assigned when the HREADY signal transitions to high, or can it be assigned before the HRESP signal transitions to indicate an error?

For example, in Figure 3-17, Assume the first transaction(0x24) is read transaction. Does ahb allow slave to provide the hrdata for address 0x24 at T1? Is it allowed for the master to sample the HRDATA when the HRESP signal transitions to indicate an error at T3, or is the master required to sample the HRDATA when the HREADY signal transitions to high at T4?

Could you please help review this and provide clarification?

Thank you!

Parents
  • Ignoring the ERROR issue for now, HRDATA is undefined by the protocol until HREADY is driven high by the subordinate to indicate the read data phase can complete and the requested read data sampled by the manager. The main reason why the subordinate would be adding wait states would be because it was not able to drive valid data any sooner. If it is adding wait states and driving HRDATA valid at the same time, that would just be a pointless latency increase.

    Next looking at the ERROR response, the subordinate would return a non-OKAY response if it could not complete the requested read transfer, so there wouldn't be any valid HRDATA value driven, or you might just return a default 0x0 value if you didn't want HRDATA undriven.

    In your case presumably you want to use HRDATA to give more information back regarding the ERROR response, so as long as the manager knew to sample HRDATA even when HRESP is ERROR, you could do that, but it's not something most bus components would expect. And so if your transfers go via any bridges or interconnects, you would need to check that they return the subordinate driven HRDATA value regardless of what HRESP indicates.

    So in a simple system where this subordinate is directly connected to the manager, and the manager knows to check HRDATA during ERROR responses, this should work, but as soon as there is any component (other than a simple MUX) between the subordinate and manager, you need to check that this interim component will pass the ERROR HRDATA value back. It's not what the protocol expects to see done during ERROR responses.

Reply
  • Ignoring the ERROR issue for now, HRDATA is undefined by the protocol until HREADY is driven high by the subordinate to indicate the read data phase can complete and the requested read data sampled by the manager. The main reason why the subordinate would be adding wait states would be because it was not able to drive valid data any sooner. If it is adding wait states and driving HRDATA valid at the same time, that would just be a pointless latency increase.

    Next looking at the ERROR response, the subordinate would return a non-OKAY response if it could not complete the requested read transfer, so there wouldn't be any valid HRDATA value driven, or you might just return a default 0x0 value if you didn't want HRDATA undriven.

    In your case presumably you want to use HRDATA to give more information back regarding the ERROR response, so as long as the manager knew to sample HRDATA even when HRESP is ERROR, you could do that, but it's not something most bus components would expect. And so if your transfers go via any bridges or interconnects, you would need to check that they return the subordinate driven HRDATA value regardless of what HRESP indicates.

    So in a simple system where this subordinate is directly connected to the manager, and the manager knows to check HRDATA during ERROR responses, this should work, but as soon as there is any component (other than a simple MUX) between the subordinate and manager, you need to check that this interim component will pass the ERROR HRDATA value back. It's not what the protocol expects to see done during ERROR responses.

Children
No data