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?
I guess you say by seeing the 3.12.4 of AMBA™ Specification (Rev 2.0) [ARM IHI 0011A].
3.12.4 Bus handover with split transfersThe protocol requires that a master performs an IDLE transfer immediately after receiving a SPLIT or RETRY response allowing the bus to be transferred to another master. Figure 3-20 shows the sequence of events that occur for a split transfer.
As the result, there is no such rule as you mentioned wrt HGRANT.It would be a matter of the arbiter.
Best regards,Yasuhiko Koumoto.
Thanks for your reply.
when two clock cycle ERROR response is in progress, HGRANT signal in first cycle and 2nd cycle depends upon the arbiter.
That is there is no rule of hgrant must be low after first cycle of ERROR response.
May i know above understanding is correct?
yes, you may.
By the way, I wonder why you will care the HGRANT value.
I think you say about an AHB slave but HRGANT will be related to an AHB master.
It would be reasonable of an arbiter to make HGRANT low at the SPLIT response, because SPLIT means the the current target slave cannot perform the current master and the master should be changed to the other masters.
The AHB specification only says, the current master is recommended to make HTRANS IDLE if the response was SPLIT or RETRY.
Best regards,
Yasuhiko Koumoto.
Thanks a lot.
Hi pkoti0583,
Just wanted to comment on a couple of the points in your first posting.
If the slave returns a SPLIT response, the master MUST drive HTRANS=IDLE in the second of the 2 cycles of the SPLIT response. At the same time the arbiter will also sample HRESP=SPLIT while HREADY is low, and MUST drive HGRANT low to the current master in the second cycle of the SPLIT response so that this master then detects it is no longer granted at the end of the SPLIT transfer response (when its IDLE transfer address phase would have been sampled).
For RETRY responses again the master MUST drive HTRANS=IDLE in the second of the 2 cycles of RETRY response. But this time the arbiter will only de-assert HGRANT to the current master in the second cycle of the RETRY response IF a higher priority master is waiting to use the bus. If no other master is waiting to use the bus, or if only lower priority masters are waiting, HGRANT will remain asserted to the current master, and after the mandatory IDLE transfer the master can immediately repeat the failed access address phase transfer.
For both SPLIT and RETRY responses the master must repeat the previously indicated transfer sequence, so rebuilding and completing the remainder of any previously indicated burst, before performing any new transfers.
For ERROR responses the master can choose if it cancels the current transfer in the second cycle of the 2 cycle response, in which case it MUST issue an IDLE transfer on HTRANS as above. But the master can instead choose to ignore the ERROR response and continue with whatever transfers it wished to next perform (so no requirement for an IDLE transfer). ERROR responses have no effect on the operation of the arbiter, other than the 2nd cycle of the response having HREADY high, meaning that if the arbiter had decided to grant a different master (HGRANT to that new master driven high), the new master would then become the granted master at the end of the HREADY high cycle.
For ERROR responses, where the master has changed HTRANS to IDLE there is no requirement that it rebuilds the failed burst, and instead you would probably see it jump to an exception handler to fix the cause of that error response, before then perhaps eventually repeating the failed accesses.
ERROR responses mean nothing to the arbiter, only RETRY and SPLIT responses are relevant to how it functions.
JD
Hi jd_,
I cannot agree with your explanation of an arbiter behavior for SPLIT or RETRY response.I think your comment will be based on the "3.12.4 Bus handover with split transfers" of "AMBA™ Specification (Rev 2.0) (ARM IHI 0011A)".The description for an arbiter is only the following.
Also at time T3 the arbiter samples the response signals and determines that the transfer has been SPLIT. The arbiter can then adjust the arbitration priorities and the grant signals change during the following cycle, such that the new master can be granted the address bus after time T4.
I think the 'can' is not the 'MUST' but the 'had better'.I also think a normal arbiter would de-assert HGRANT but an abnormal arbiter might exist.
Best regards.Yasuhiko Koumoto.
Hello Yasuhiko Koumoto.
I agree that the protocol states "can" in this section, which certainly isn't a "MUST", but if the arbiter DOES NOT de-assert HGRANT as I described, the bus will not function as the protocol intends.
Section 3.9.5 "Split and retry" states "For a SPLIT transfer the arbiter will adjust the priority scheme so that any other master requesting the bus WILL get access", and later in the same section that the SPLIT transfer "has the advantage that it completely frees the bus for use by other masters". For RETRY the same statements are made regarding higher priority masters gaining access to the bus.
If the arbiter does not de-assert HGRANT in the second cycle of the 2 cycle SPLIT response as you are suggesting is allowed, that same master will remain granted for whatever transfer it signals immediately after the mandatory IDLE transfer, and as section 3.9.5 also states that the master "should continue to request the bus and attempt the transfer", you could then see that master re-attempt the SPLIT transfer again before the arbiter finally gets round to correctly de-asserting HGRANT. Not quite so critical for RETRY responses as the original master can still remain granted under some circumstances, but the intention of the protocol is not if higher priority masters are waiting to use the bus.
So my reply to "pkoti0583" is an accurate description of what MUST happen in the arbiter when SPLIT or RETRY responses are returned, in order for the arbiter to work correctly such that the slave's intentions of the SPLIT or RETRY responses are implemented, allowing other masters to access the bus in preference to the current master re-attempting the failed access.
Your description of what an "abnormal" arbiter could do is technically what the use of "can" in the protocol might allow, but to allow this "abormal" behaviour means you do not implement a SPLIT or RETRY correctly if the same master is left able to repeat the same access, and so defeats the point of the slave having returned the SPLIT or RETRY response.
Interpretting this 3.12.4 timing on when HGRANT changes in response to a SPLIT or RETRY as a "MUST" rather than "can" avoids any problems, and is what the protocol should have stated in my opinion.
My original reply stating "MUST" as the requirement is trying to avoid "pkoti0583" (or anyone else) designing a bad arbiter. Any attempt at justifying the use of "can" here will only lead to bad designs.
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.
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"