Can NONSEQ in first cycle of HRESP change to IDLE? Can that happen if NONSEQ is targeting a different peripheral?

The spec clearly indicates that cancelling SEQ during HRESP is legal but seems a bit ambiguous about cancelling NONSEQ during HRESP. If NONSEQ can be cancelled, is there any rule that NONSEQ targeting a different peripheral (not the one giving HRESP) cannot be cancelled? Or can any NONSEQ be cancelled by the manager when the manager gets an HRESP (regardless of which peripheral provided it)?

Parents
  • If HRESP is returning a non-OKAY response, the manager can change the current HTRANS address phase value to IDLE. No other restrictions.

    It does not make any difference whatsoever which subordinate target HADDR was targeting before HTRANS was changed to IDLE. HREADY was low in the first cycle of the 2-cycle ERROR response, so no subordinate target will have sampled the address phase transfer that was being signaled, so the values that were on HTRANS, HADDR, etc. are irrelevant. Subordinates do not sample address phase inputs while HREADY is low.

    In the second cycle of the 2-cycle ERROR response HREADY will now be high, so as HTRANS can now be IDLE this is what the subordinates next see, and the previous value of HTRANS essentially never happened. HADDR might also have changed when HTRANS changed to IDLE, so it is this new HADDR value that determines which subordinate is selected for this IDLE transfer address phase.

    The idea behind having a 2-cycle ERROR response is to give the manager the opportunity to cancel the next indicated transfer address phase, and thus preserve the order of event it wants to perform. So if the transfer after the one that is causing the ERROR response was going to target a different subordinate, that is what you are cancelling, so the manager can look at fixing the transfer that failed, before then moving on to any subsequent transfers.

Reply
  • If HRESP is returning a non-OKAY response, the manager can change the current HTRANS address phase value to IDLE. No other restrictions.

    It does not make any difference whatsoever which subordinate target HADDR was targeting before HTRANS was changed to IDLE. HREADY was low in the first cycle of the 2-cycle ERROR response, so no subordinate target will have sampled the address phase transfer that was being signaled, so the values that were on HTRANS, HADDR, etc. are irrelevant. Subordinates do not sample address phase inputs while HREADY is low.

    In the second cycle of the 2-cycle ERROR response HREADY will now be high, so as HTRANS can now be IDLE this is what the subordinates next see, and the previous value of HTRANS essentially never happened. HADDR might also have changed when HTRANS changed to IDLE, so it is this new HADDR value that determines which subordinate is selected for this IDLE transfer address phase.

    The idea behind having a 2-cycle ERROR response is to give the manager the opportunity to cancel the next indicated transfer address phase, and thus preserve the order of event it wants to perform. So if the transfer after the one that is causing the ERROR response was going to target a different subordinate, that is what you are cancelling, so the manager can look at fixing the transfer that failed, before then moving on to any subsequent transfers.

Children
No data