Hi,
In AMBA AHB:-
For two clock cycle SPLIT or RETRY response, hgrant must be low after 1st clock cycle of SPLIT or RETRY response.
q) For two clock cycle ERROR response, is it mandatory of hgrant must be low after 1st clock cycle of ERROR response?
q) May i know the state(low/high) of hgrant signal in two clock cycle response?
q) If i want to continue the remaining transfers after receiving ERROR response of a burst, is it necessary to rebuild the transaction or not?
q) with out of rebuild transaction, is it possible to continue the transfers w.r.to ERROR response?
Hi JD,
if the arbiter DOES NOT de-assert HGRANT as I described, the bus will not function as the protocol intends.
I think so, too. But I think it might be OK because the dead lock would not occur although it would against the protocol intention.
The slave which had issued SPLIT response would issue the same response if the accessing master is the same as the previous one.
However, the slave finally will issue OK or ERROR response for the master after issuing SPLIT several times if the HGRANT kept asserted.
My opition is only that a master or a slave should be designed under the expectation or assumption that an arbiter would de-assert HGRANT in the case of receiving SLPIT or RETRY.
Best regards,
Yasuhiko Koumoto.
Hello Yasuhiko Koumoto
We are straying away from pkoti0583's original question relating to ERROR responses, and instead are looking only at SPLIT and RETRY responses which in my experience very few designers even consider, never mind actually implement, especially not now that AHB-lite is more commonly used. So I will post a final reply to try to explain why I believe "MUST" is the requirement, and then you can end with a final closing comment on "CAN" if you still believe an arbiter can be implemented that way.
I understand what you are describing, and it does agree with what the loose wording in that section of the protocol allows, but it just results in more complex slave designs, and less efficient use of the available bus bandwidth, and isn't what was intended.
By your description the slave now has to be able to respond if it gets a second (or possibly more) repeat of the previously SPLIT transfer, whereas it shouldn't have to if the arbiter is designed correctly. There isn't any functional reason why the arbiter is not able to change HGRANT when it samples HRESP=SPLIT and HREADY=0, that way ensuring that the affected master sees it is no longer granted in time to stop it issuing a repeat of the SPLIT transfer after the mandatory IDLE transfer, so the slaves should not have to consider this possibility.
Plus a comment from another section of the protocol, section 3.12.2 "Multiple split transfers" where it states "The bus protocol only allows a single outstanding transaction per bus master". By remaining granted as you describe, the master that has received an uncompleted SPLIT response (no corresponding HSPLIT pulse) now starts a second transaction on the bus (I agree it is a repeat of the previous failed access, but it is still another transaction), and so does not comply with this section of the protocol. Therefore it cannot be allowed by the arbiter.
As they would say in a TV courtroom drama, "I rest my case"
JD