AHB-lite Slave Burst Operation

The main thing to check is that HTRANS doesn't signal BUSY cycles in the middle of the defined length burst, as they will stall the burst progression, so will delay when the prefected read data is needed. So check HTRANS sampled on HCLK rising edges when HREADY is high to confirm it follows the expected NONSEQ-SEQ-SEQ-SEQ... sequence for the length of burst expected.

One problem you might face (again HTRANS related) is that Early Burst Termination can still occur, so you might not see the HBURST indicated number of transfers completed. This can happen when you have arbitration logic selecting which of multiple masters in your system is allowed access to your slave (usually implemented in a multi-layer BusMatrix). As this arbitration logic might switch part way through a burst, your slave might see only 5 beats of an INCR8 burst completed before a new master starts accessing the slave.

So nothing wrong with prefetching the read data as you describe, but make sure that you check the HTRANS cycle sequence. BUSY transfers just tell you the read data return needs to be stalled, but an unexpected IDLE or NONSEQ transfer will indicate that early burst termination has occured, and so any prefetched data must be discarded (the original master will still need that data when it is next allowed access, but you might need your read data buffer for the new master's transfer request). 

Probably unlikley, but if the memory being accessed is read sensitive (i.e. a FIFO), you can't dump the prefetched read data as it will then be lost forever.

Those would be the main things to check in this design I think.

The main thing to check is that HTRANS doesn't signal BUSY cycles in the middle of the defined length burst, as they will stall the burst progression, so will delay when the prefected read data is needed. So check HTRANS sampled on HCLK rising edges when HREADY is high to confirm it follows the expected NONSEQ-SEQ-SEQ-SEQ... sequence for the length of burst expected.

One problem you might face (again HTRANS related) is that Early Burst Termination can still occur, so you might not see the HBURST indicated number of transfers completed. This can happen when you have arbitration logic selecting which of multiple masters in your system is allowed access to your slave (usually implemented in a multi-layer BusMatrix). As this arbitration logic might switch part way through a burst, your slave might see only 5 beats of an INCR8 burst completed before a new master starts accessing the slave.

So nothing wrong with prefetching the read data as you describe, but make sure that you check the HTRANS cycle sequence. BUSY transfers just tell you the read data return needs to be stalled, but an unexpected IDLE or NONSEQ transfer will indicate that early burst termination has occured, and so any prefetched data must be discarded (the original master will still need that data when it is next allowed access, but you might need your read data buffer for the new master's transfer request). 

Probably unlikley, but if the memory being accessed is read sensitive (i.e. a FIFO), you can't dump the prefetched read data as it will then be lost forever.

Those would be the main things to check in this design I think.

Colin Campbell said:

One problem you might face (again HTRANS related) is that Early Burst Termination can still occur, so you might not see the HBURST indicated number of transfers completed. This can happen when you have arbitration logic selecting which of multiple masters in your system is allowed access to your slave (usually implemented in a multi-layer BusMatrix). As this arbitration logic might switch part way through a burst, your slave might see only 5 beats of an INCR8 burst completed before a new master starts accessing the slave.

You do bring up a point of multiple masters on the matrix where by the arbiter may switch to another master that is driving the transactions. In this case how would the HTRANS change for early termination I'm reading Section 3.5.2 in the AMBA AHblite manual regarding this but its doesn't really specify.

Colin Campbell said:

So nothing wrong with prefetching the read data as you describe, but make sure that you check the HTRANS cycle sequence. BUSY transfers just tell you the read data return needs to be stalled, but an unexpected IDLE or NONSEQ transfer will indicate that early burst termination has occured, and so any prefetched data must be discarded (the original master will still need that data when it is next allowed access, but you might need your read data buffer for the new master's transfer request). 

In section 3.5.1 in the AMBA AHB lite manual, it says that for INCR4, 8, 16 is not allowed to terminate with a BUSY but should only terminate with SEQ. So for for an INCR4 early termination it would look like NONSEQ, BUSY, SEQ, NON-SEQ (new)? Did I get that correct?  To me it would seem that we would get at least 2 burst transfers with early termination.

Contrasting with an early termination INCR (undefined burst length) it would be NONSEQ, BUSY, NON-SEQ (new).  We would only get one burst transfer. While we are in this topic, what would the usual application of a burst with undefined burst length?

Per your recommendation, we will look into sampling HTRANS every time the HREADY is high to check that the burst is still valid and has not been terminated.

Thanks.