We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I do have a question on legal 'htrans' value after an error response in AHB protocol.
The specification says that "If a slave provides an ERROR response then the master may choose to 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."
In above case, the slave responded with an error and thus the master can choose to cancel or continue the transfer.
When cancelling, it can transmit an IDLE transfer.
But what if it wants to continue the transfer? Can it send anything?
What would be the legal 'htrans' type?
For me, it seems NONSEQ, SEQ, and BUSY are legal when continuing the transfer and want to check it this is correct.
Hi Joon,
Joon Hong said:For me, it seems NONSEQ, SEQ, and BUSY are legal when continuing the transfer
Your understanding is not completely correct. In AMBA 5 AHB spec 3.6.1, “When the slave is requesting wait states, the master must not change the transfer type, except as described in IDLE and BUSY transfer.” AMBA 5 AHB spec can be accessed at https://developer.arm.com/documentation/ihi0033/latest/
Let’s take your waveform for example, the HTRANS at T2 is SEQ, which means master already sent a SEQ beat when slave is in wait state. In this case if master is going to continue the burst, HTRANS in T3 should also be SEQ, which is strictly regulated in AMBA spec. Meanwhile, if master is going to cancel the transfer, HTRANS at T3 should be IDLE.
In general, the situation at an ERROR response can be divided into four situations:
Hence, the HTRANS at T3 depends on HTRANS at T2 and current transaction type. In your case, HTRANS at T3 only has two options, SEQ or IDLE.
Hi Steve,
Thank you for looking into this.
But I am not sure if your statement is the case I am talking about. When the specification says "wait state" it means that HREADY is low and HRESP is OKAY. But, as you can see from T2, HRESP is an ERROR, thus we can't say that it is in wait state.
The “wait state” rule is applicable in this case. When master is going to ignore the ERROR response in a transfer, which is the case you mentioned
Joon Hong said:But what if it wants to continue the transfer? Can it send anything?
It is considered as a wait state from the master side. Therefore, the restriction of HTRANS is applicable in this case. If master is going to cancel the unfinished transfer, it can change HTRANS to IDLE regardless of the restriction in “wait state”.
I am afraid but I don't agree. If you go through the specification, it only mentions "wait state" only for the case where the slave is delaying the transaction by inserting HREAD low. But, when the slave gives an ERROR response, actually it is not supposed to delay the transaction.
Also, if you look at the link below, you would notice that NONSEQ can come at T3 as a new transfer regardless of the transaction type in T2. It doesn't make sense if your statement is true.
https://community.arm.com/developer/ip-products/system/f/soc-design-forum/47143/ahb-lite/166826#166826
If the master ignores the ERROR, the only effect of the ERROR response is that it holds HREADY low for a cycle, so has the effect only of a wait state
Joon Hong said:Also, if you look at the link below, you would notice that NONSEQ can come at T3 as a new transfer regardless of the transaction type in T2. It doesn't make sense if your statement is true. https://community.arm.com/developer/ip-products/system/f/soc-design-forum/47143/ahb-lite/166826#166826
This old forum post was looking at NONSEQ already signaled in T2, so the previous burst has already ended. In this way, HTRANS at T3 should be kept NONSEQ to continue the new transfer. Feel free if you have any other question.