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

Relationship between PSEL and PENABLE signals in the APB Protocol.

Hello All,

I have some doubts related to the relationship between PSEL and PENABLE signals in the APB Protocol. The specification informs that:

The PENABLE signal is asserted the following clock after PSEL is asserted and de-asserted after a transfer takes place.

I would like to understand about the following conditions:

1) Can PENABLE toggle while PSEL is de-asserted?

2) Can PENABLE be asserted in the IDLE and/or SETUP phase?

3) Can PSEL go log in to the SETUP phase?

4) What happens when PSEL is asserted high in the ACCESS phase and PENABLE is not de-asserted?


Thanks

Parents
  • 1. Yes, PENABLE can toggle while PSEL is deasserted.

    The APB protocol supports multiple peripherals connected to one transfer initiator, and only one PSEL will be asserted at any one time to select the target peripheral. All peripherals connected to this transfer initiator will see the PENABLE/PWRITE/PWDATA controls for all transfers, and it is the PSEL that tells the target which transfer it should respond to.

    So when a peripheral is not selected, it will still see the APB control signals toggling, including PENABLE.

    2. No, PENABLE is only ever asserted in the ACCESS phase of an initiator transfer. 

    Note that the IDLE/SETUP/ACCESS phase state diagram is really from the initiators perspective. A peripheral design could implement something like these states, but stay in the IDLE state if not selected, so in that case the peripheral would see PENABLE high during this peripheral's IDLE state for an access to another peripheral moving to its ACCESS phase.

    3. Did you mean "Can PSEL go low in to the SETUP phase" ?

    If that was your question, no, PSEL must be high to go into a SETUP phase of a transfer.

    4. This would be a protocol violation, and the resulting behaviour would be undefined. This is the case with all AMBA protocols. If you don't follow the protocol, the system behaviour will be undefined.

    However it is possible that the selected peripheral might still complete the requested transfer as PENABLE doesn't actually need to be used. When a peripheral is selected, one cycle later it knows that it would move from SETUP to ACCESS (in a protocol compliant system), so PENABLE high doesn't need to be seen to be high for the peripheral to know it should now be in the ACCESS phase. So the behaviour very much depends on the peripheral implementation, hence the result of the protocol violation being undefined.

Reply
  • 1. Yes, PENABLE can toggle while PSEL is deasserted.

    The APB protocol supports multiple peripherals connected to one transfer initiator, and only one PSEL will be asserted at any one time to select the target peripheral. All peripherals connected to this transfer initiator will see the PENABLE/PWRITE/PWDATA controls for all transfers, and it is the PSEL that tells the target which transfer it should respond to.

    So when a peripheral is not selected, it will still see the APB control signals toggling, including PENABLE.

    2. No, PENABLE is only ever asserted in the ACCESS phase of an initiator transfer. 

    Note that the IDLE/SETUP/ACCESS phase state diagram is really from the initiators perspective. A peripheral design could implement something like these states, but stay in the IDLE state if not selected, so in that case the peripheral would see PENABLE high during this peripheral's IDLE state for an access to another peripheral moving to its ACCESS phase.

    3. Did you mean "Can PSEL go low in to the SETUP phase" ?

    If that was your question, no, PSEL must be high to go into a SETUP phase of a transfer.

    4. This would be a protocol violation, and the resulting behaviour would be undefined. This is the case with all AMBA protocols. If you don't follow the protocol, the system behaviour will be undefined.

    However it is possible that the selected peripheral might still complete the requested transfer as PENABLE doesn't actually need to be used. When a peripheral is selected, one cycle later it knows that it would move from SETUP to ACCESS (in a protocol compliant system), so PENABLE high doesn't need to be seen to be high for the peripheral to know it should now be in the ACCESS phase. So the behaviour very much depends on the peripheral implementation, hence the result of the protocol violation being undefined.

Children
No data