• State Accepted Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 90 subscribers
  • Views 892 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

The BUSY state of HTRANS, compared AHB 2.0 with AHB 5.0

E K

Hi，

I have a question about AHB protocal. I had read "AHB 5.0 Specification" and "AHB 2.0 Specification". Compared these specifications, the following pictures about BUSY state are from "AHB 5.0 Specification"，but cannot find the corresponding information in "AHB 2.0 Specification". So I would like to ask whether the BUSY(htrans) signal has the same behaviors in AHB 2.0?  Do BUSY states of HTRANS between AHB 2.0 and AHB 5.0 keep the same bus behaviors? If not, what is the difference about them?

 

Thanks

Regards

E.K.

Parents
  • +1

    The allowed use of BUSY transfers has not changed since the first protocol release. The only reason that you see this described in the AHB5 spec and not the original AHB2 is that we had requests to document a common (and sensible) usage of IDLE and BUSY transfers.

    An IDLE or BUSY indicates the AHB manager does not currently have a data transfer to request, but if the current ongoing data phase transfer is returning wait states, and during these wait states the manager realises that it does now have a new data transfer to request, it would be wasted cycles if the manager was forced to keep signaling the now redundant IDLE or BUSY.

    So the protocol text was extended to describe the limited times when HTRANS can be changed while HREADY is low, with this BUSY example being one example.

    The waited transfer sections were added in the AHB3 (AHB-lite) protocol specification back in 2006.

Reply
  • +1

    The allowed use of BUSY transfers has not changed since the first protocol release. The only reason that you see this described in the AHB5 spec and not the original AHB2 is that we had requests to document a common (and sensible) usage of IDLE and BUSY transfers.

    An IDLE or BUSY indicates the AHB manager does not currently have a data transfer to request, but if the current ongoing data phase transfer is returning wait states, and during these wait states the manager realises that it does now have a new data transfer to request, it would be wasted cycles if the manager was forced to keep signaling the now redundant IDLE or BUSY.

    So the protocol text was extended to describe the limited times when HTRANS can be changed while HREADY is low, with this BUSY example being one example.

    The waited transfer sections were added in the AHB3 (AHB-lite) protocol specification back in 2006.

Children