Hello All,
Here at IP Level verification we have no issues as the Master APB does not latch the PREADY, but at SOC Level with multiple APB Slaves
The Master performs some transaction with APB SLAVE 1 and before switching to APB SLAVE 2 , it disables the PSEL = 0 & PENABLE = 0 after a clock cycle PREADY = 1 from that Slave.
This puts the SLAVE 1 in SETUP State or Undefined State and not in IDLE State as Master should drive PSEL = 0 & PENABLE = 0 on the same cycle as PREADY = 1 .
I am guessing the issue here is because PREADY is latched , master and slave are not in Sync.
Also from ARM Spec ACCESS to IDLE is allowed but not SETUP to IDLE.
As my slave when asserting PREADY =1 , would see PSEL = 1 , it would go to SETUP not IDLE, and later in SETUP when we de-assert PSEL to 0 , its a violation / undefined from Master.
Please do let me know how to resolve this.
Regards
I'm not sure I understand the sequence of events, but perhaps you are looking at these transitions in a combinatorial manner rather than only looking at events (state machine transition) on PCLK rising edges when signals will be sampled.
If the APB master sees active slave APB1 completing a transfer by sampling PREADY high on PCLK rising, and the master then drives PSELx=0 and PENABLE=0, this would be the path from ACCESS to IDLE on the left side of figure 4-1 in the APB protocol spec (PREADY=1 and no transfer).
You would only move from ACCESS back to SETUP if the master had a further transfer to perform to APB1 (PREADY=1 and transfer) - this then keeps PSELx asserted to APB1.
Or perhaps it is how you are interpreting the conditions on the state transition arrows.
The intention is that "PREADY=1 and no transfer" means the master samples PREADY high on the next PCLK rising edge and it currently has no further transfer to peform to that slave, so the slave's state machine would go to its IDLE state.
At the same time the master might have further transfers to perform TO A DIFFERENT SLAVE, so it could go from ACCESS to SETUP in its own state machine, but with a different PSELx line asserted. That new slave newly selected by PSELx would then move from IDLE to SETUP.
One of the things which is not very clear is how does the Slave know if its a last master Transaction or Back to back while asserting the PREADY = 1 , because at the very same moment Slave has to make a decision to Go back to Setup State or else have to go to IDLE. Should we add a intermediate state while implementing ?. Theoretically they say we cannot stay in Access when we assert PREADY , but then spec says If Transfer or No Transfer ...Which signal can indicate this and How can this be ready even before Slave has concluded the current transaction . Or Can Master de-assert PSEL earlier to show it was the last transaction ?