Hi ,
In AHB specs, There is one note as below.
Note
Every slave must have a predetermined maximum number of wait states that it will insert before it backs off the bus, in order to allow the calculation of the latency of accessing the bus. It is recommended, but not mandatory, that slaves do not insert more than 16 wait states to prevent any single access locking the bus for a large number of clock cycles.
we have to care for this while design or in verification, if this scenario has to be checked then ??? If yes then after 16 wait state , slave must be give HREADY high after 16 wait state. Right?
Kindly do needful.
Thanks in advance.
Hi ajoo
I have moved your questions to ARM Processors where I hope you will get your answer.
Okay
Hi Ajoo,
The maximum 16 cycles before possibly giving a RETRY or SPLIT response (during which HREADY will be driven high) is only a protocol recommendation, 16 cycles seen as possibly a reasonable maximum time you might be able to accept your bus stalled to other master accesses.
If you only had one master on your bus you could simply ignore this recommendation (unless you wanted to consider if the slave was sensibly designed - does it really need that many wait states to respond ? - is the slave still functioning ?)
Or if it was imperative that this slave access completed before anything else could sensibly happen in your system, regardless of how many wait states that was, you as the system designer would decide whether this 16 cycle recommendation was appropriate.
If you are using some sort of protocol checker, it might report if the 16 cycle "maximum" is exceeded, but this should only be reported as an advisory "warning", not a "protocol violation".
So the 16 cycle recommendation is an advisory point, at which time you need to consider if the slave is sensibly designed, and if you need to consider responding with a SPLIT or RETRY response to allow other masters to access the bus.
Remember it is a design "recommendation", not a protocol "requirement", so use the figure of 16 as appropriate for your application.
JD
Thanks a ton
Hello , Apart from that I have one more confusion that can HTRANS be busy in between fixed length burst ? (i.e. in between INCR4, INCR8 and INCR16) and also after completion of burst?
Hi ajoo,
HTRANS can signal BUSY in between transfers in any defined length burst, but not after the final transfer.
BUSY means the master is not yet able to commit to the next transfer in a burst, but if you have signalled an 8-beat burst, and have completed the 8th NONSEQ/SEQ access address phase, there is no "next transfer in the burst" because you have already completed that defined length burst.
So BUSY can be used anywhere during bursts, but a burst can only end on a BUSY transfer if the burst type was undefined length INCR.