• State Accepted Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 90 subscribers
  • Views 14448 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

AHB-lite Slave Burst Operation

eugch

Hi all,

I am trying to optimize the throughput of an AHB-lite slave by taking advantage of INCR4, INCR8, INCR8 burst transactions from the master (only issues SINGLE, INCR4/8/16). The slave is running at half of the bus speed but with double the read width so I am trying to perform prefetch by generating the next addresses locally instead of sampling the HADDR on the bus when HREADY is high. 

Is this safe?

Only sampling the begin haddr during the non-seq/burst add phase. Insert initial waitstate, self generate subsequent addresses and then internally align the data output such all subsequent data outs are aligned without required additional wait states.

Are there any signals that I should qualify at every cycle (or at least when hready is HIGH) to ensure that the slave response is still valid and related to the transactions of the master? Or it is ok to just go ahead ?

Thanks in advance.

Parents
  • 0 in reply to Colin Campbell

    Hi Colin,

    Thanks for the info.

    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.

Reply
  • 0 in reply to Colin Campbell

    Hi Colin,

    Thanks for the info.

    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.

Children