• State Accepted Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 90 subscribers
  • Views 2372 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Valid data about busy state in HTRANS signal

micky.kim

I am having trouble understanding the behavior of the HTRANS busy state mentioned in the specification(ARM IHI 0033A), and I am feeling confused. I would like to explain my situation and request assistance in understanding it. I will explain a detailed situation based on the diagram below.

T0 - T1 The 4-beats read operation start with a NONSEQ Transfer
T1 - T2 Master inserts a busy trasnsfer and slave asserted the HREADY signal from 1 to 0 in order to handle the data read operation.
T2 - T3 The slave asserts HREADY to 1 when the data is ready, while the HTRANS of the master remains in the busy state.

In my opinion, during the T2-T3 interval, HREADY is asserted to 1 as a response to the transaction that occurred between T0-T1, indicating that D0_a1 is valid.

However, accoding to the spec description , this transfer must be ignored by slave.
Therefore, from the master's perspective, since Htrans is in a busy state, the value of D0_a1 will be considered invalid and ignored.
In other words, during the T4-T5 interval when Hready is 1 and Htrans is not in a busy state, the value of D2_a1 becomes the valid data for NSEQ.

so, I have a question about the behavior of MASTER in HTRANS busy state when designing a slave.
Which interval's value in the given diagram is considered valid for the response of HTRANS=NSEQ in the T0-T1 interval?

Parents
  • +1

    As you know, each transfer in the AHB protocol works in two phases; the address phase when the transfer required is indicated, and the data phase when the selected target will perform the requested data transfer. So when looking at transfers you see the address and data phases of transfer appear in a pipelined manner, with the data phase response only relating to the earlier address phase transfer it is responding to, and not the currently indicated address phase transfer.

    So looking at your waveform you have the NONSEQ transfer address phase at T0-T1, and the data phase from T1-T3 (extended by the wait state signaled on HREADY in T1-T2).

    The wait state in T1-T2 is the selected target indicating it needs an extra cycle to generate the requested NONSEQ read data. As HREADY is low at this time, the HTRANS=BUSY address phase value is never sampled by the system.

    So in T2-T3 when HREADY is then high, HRDATA of D0_a1 is sampled by the requester. The fact that HTRANS is BUSY in T2-T3 is irrelevant to this data phase operation.

    Then at T3 the selected target will sample the BUSY transfer on HTRANS (T2-T3 is this transfer's address phase), but as a BUSY transfer does not require any data transfer the selected target must return an HREADY high and HRESP OKAY response in the data phase of the BUSY from T3-T4.

    T3-T4 is the address phase of the second BUSY, with T4-T5 the data phase.

    Note that as the two BUSY transfers do not have any associated data values, HRDATA is undefined in T3-T5 (there are no D1_a1 or D2_a1 values).

    T4-T5 is then the address phase of a SEQ transfer, with T5-T6 being the data phase when HRDATA is driven with D_a1.

    I think your confusion relates to the specification saying that a BUSY transfer must be ignored and a default response of HREADY high and HRESP OKAY returned. This requirement only applies to the data phase of the BUSY transfer, and not the current data phase transfer seen while the BUSY transfer is in the address phase.

Reply
  • +1

    As you know, each transfer in the AHB protocol works in two phases; the address phase when the transfer required is indicated, and the data phase when the selected target will perform the requested data transfer. So when looking at transfers you see the address and data phases of transfer appear in a pipelined manner, with the data phase response only relating to the earlier address phase transfer it is responding to, and not the currently indicated address phase transfer.

    So looking at your waveform you have the NONSEQ transfer address phase at T0-T1, and the data phase from T1-T3 (extended by the wait state signaled on HREADY in T1-T2).

    The wait state in T1-T2 is the selected target indicating it needs an extra cycle to generate the requested NONSEQ read data. As HREADY is low at this time, the HTRANS=BUSY address phase value is never sampled by the system.

    So in T2-T3 when HREADY is then high, HRDATA of D0_a1 is sampled by the requester. The fact that HTRANS is BUSY in T2-T3 is irrelevant to this data phase operation.

    Then at T3 the selected target will sample the BUSY transfer on HTRANS (T2-T3 is this transfer's address phase), but as a BUSY transfer does not require any data transfer the selected target must return an HREADY high and HRESP OKAY response in the data phase of the BUSY from T3-T4.

    T3-T4 is the address phase of the second BUSY, with T4-T5 the data phase.

    Note that as the two BUSY transfers do not have any associated data values, HRDATA is undefined in T3-T5 (there are no D1_a1 or D2_a1 values).

    T4-T5 is then the address phase of a SEQ transfer, with T5-T6 being the data phase when HRDATA is driven with D_a1.

    I think your confusion relates to the specification saying that a BUSY transfer must be ignored and a default response of HREADY high and HRESP OKAY returned. This requirement only applies to the data phase of the BUSY transfer, and not the current data phase transfer seen while the BUSY transfer is in the address phase.

Children