Hello everyone,
Please describe me the transfer continuation process after ERROR response from the slave.
As shown in the above figure at cycle T4 if MASTER identifies the ERROR response from the SLAVE. Now, if the MASTER wants to continue the current transfer then how can it?
Does it need to insert SEQUENTIAL transfer for the continuation of the current transfer or it has to insert IDLE transfer then NONSEQUENTIAL transfer to complete the current transfer?
Regards,
Vishal
Hello Vishal,
If the MASTER want to continue the current transfer, the MASTER must not make HTRANS ILDE but keep it SEQ (or change to BUSY).
There is no description in the specs what will happen if SEQ comes after IDLE.
In the case, the behavior might be unpredictable.
Both will be possible.
Best regards,
Yasuhiko Koumoto.
So to continue the current transfer ; can the MASTER change the address (here 0xCO) with SEQ transfer at tick T4 though the hready signal is low (during the first cycle of ERROR response)?
Hello,
No, the MASTER cannot change the address with SEQ transfer at tick T4 but continue the previous address.
As you say, because ERROR response is 2 cycle transactions, HREADY will became high (i.e. ready) at every two cycle.
The MASTER can act as if the responses will be always OK even if the ERROR responses are returned.
For the MASTER, ERROR response will be a notification of it to cancel the rest transaction but it needs not to always cancel it.
As shown in the above figure at tick T3 SLAVE identifies address 0x28 ; which has been served by SLAVE at tick T2 (hence the SLAVE has driven OKAY response at T2).
So at T3 the address must be 0x2C (according to INCR4 burst scheme); but here it is 0x28; hence SLAVE drives ERROR response. MASTER identifies it at tick T4.
Now is it wrong if MASTER drives 0x2C (according to INCR4 burst scheme) with SEQ transfer though HREADY is low at tick T4? How can the MASTER continue the current transfer?
your understanding is wrong. The address 0x28 has not been accepted by the SLAVE because of low HREADY.
The HRESP has no meaning with low HREADY.
Therefore, the MASTER should issue address 0x28 at T3 and should issue 0x2C at T4 (of course HTRANS should be SEQ) if the MASTER want to continue the transaction.
Sorry Yasuhiko,
I forgot that HREADY is already low since tick T1. But yes, if HREADY is low than the transfer is not completed from the SLAVE side i.e MASTER has no meaning for HRESP with HREADY low. You are absolutely right.
But if we assume that at tick T3 the HREADY is driven low by the SLAVE with ERROR response (HREADY = high before T3); then can the MASTER drive upcoming address (0x2C) at T4 with SEQ transfer (though HREADY = low with ERROR response) to continue the current transfer?
Warm regards,
you are right, I'm very sorry,
As you say, the MASTER should drive address 0x2C at T4 and HTRANS=SEQ in order to continue the current transder.
If the SLAVE could not accept address 0x2C, the HREADY would be low and HRESP would be ERROR at T5, and HREADY would be high and HRESP would keep ERROR at T6.
So finally can the summary be:
" If the SLAVE gives ERROR response (due to any reason for example wrong address) for any transfer; the MASTER can change address information during the second cycle of ERROR response (though the HREADY signal is low) with SEQ transfer to continue the current transfer."
Thanks,
I could not found the statement in the "AMBA® 3 AHB-Lite Protocol Specification v1.0 (ARM IHI 0033A)".
From where do you bring it?
Is it your own statement?
Anyway, I fully agree with you.
For your information, in addition to your statement, I would show the following statements from "AMBA® 3 AHB-Lite Protocol Specification v1.0 (ARM IHI 0033A)".
3.5.2 Early burst termination Slave error responseIf a slave provides an ERROR response then the master can cancel the remaining transfers in the burst. However, this is not a strict requirement and it is also acceptable for the master to continue the remaining transfers in the burst.If the master does not complete that burst then there is no requirement for it to rebuild the burst when it next accesses that slave. For example, if a master only completes three beats of an eight-beat burst then it does not have to complete the remaining five transferswhen it next accesses that slave. 5.1.3 ERROR response If a slave provides an ERROR response then the master can cancel the remaining transfers in the burst. However, this is not a strict requirement and it is also acceptable for the master to continue the remaining transfers in the burst.
3.5.2 Early burst termination
Slave error responseIf a slave provides an ERROR response then the master can cancel the remaining transfers in the burst. However, this is not a strict requirement and it is also acceptable for the master to continue the remaining transfers in the burst.If the master does not complete that burst then there is no requirement for it to rebuild the burst when it next accesses that slave. For example, if a master only completes three beats of an eight-beat burst then it does not have to complete the remaining five transferswhen it next accesses that slave.
5.1.3 ERROR response
If a slave provides an ERROR response then the master can cancel the remaining transfers in the burst. However, this is not a strict requirement and it is also acceptable for the master to continue the remaining transfers in the burst.
The ERROR response only indicates a convenience of the SLAVE side. The MASTER can sometimes continue the transferring (while caring about HREADY). The ERROR response is only a sign that the MASTER can cancel the current transaction.
Thanks Yasuhiko,
The conclusion regarding "the MASTER changing the address during the second cycle of ERROR response to continue the current transfer" ; I thought it from the specification sheet named "AMBA® 3 AHB-Lite Protocol Specification (ARM IHI 0033A)" (Page No 3-10). Here I have mentioned it :
Slave error responseIf a slave provides an ERROR response then the master can cancel the remaining transfers in the burst. However, this is not a strict requirement and it is also acceptable for the master to continue the remaining transfers in the burst.
You can see the bold statement : "However, this is not a strict requirement and it is also acceptable for the master to continue the remaining transfers in the burst."
But in the specification it is not explained through detailed diagram ; hence I thought regarding the continuation of the burst and posted it on the forum to check whether it is appropriate or not.
Of course I got the correct understanding and endorsement from your side ; thanks for that.