Hi,
We are designing an Asynch slave operating over Multi Layer AHB Lite 3.0.
I have come across some case which I am not sure how it should be handled.
I am getting a predefined burst INCR16 , and the following occurs :
Cycle : 1 | 2 | 3 | 4 | 5 | ...
HBURST: INCR16 | INCR16 | NA | INCR16 | INCR16 | ...
HSELS : 1 | 1 | 0 | 1 | 1 | ...
HTRANS: NONSEQ | SEQ | IDLE | SEQ | SEQ | ...
Actually, I get early burst termination using IDLE transfer in cycle #3, however, I am not sure whether this is a legal state to return to sequential transfer with predefined burst after that, or should the master re-start with nonseq transfer of undefined length ?
What is the expected behavior a slave would see in case in early termination with IDLE Transfer ?
Thanks,
Guy
Is the multi-layer interconnect from ARM (if yes, which one) ?
- if it is an ARM interconnect, you'd be better opening a support case if you have a support contract for that IP, and I'd supply waveforms for all the signals on at least the input and output ports involved in this transfer, so that correct protocol stimulus can be checked.
The IDLE suggests the burst has been terminated (which isn't illegal), but you should not have IDLE changing to SEQ. What were the HREADY and HRESP values during cycle 3 ?
Thanks Colin !
The HREADY was high , HRESP was not in error
I wonder how slaves should handle themselves under such situation, is there any limitation on returning to SEQ or shall the slave expect NONSEQ after that ?
So is this an ARM designed interconnect, or your own ?
The Interconnect is ARM, the master in question is some legacy IP here
As I suggested in my first reply, you'd be better submitting a support case to ARM if this is IP you have licensed and have a support contract for.
The first thing you will be asked for is waveforms showing the problem, so I'd supply those when asking.
And I'd tell them which ARM interconnect.
Thanks for your assistance. Most appreciated
Did you submit a support case to ARM ?
Not needed, We found the issue in AHB Master IP
Thanks