APB Interconnect Operations

Based on the APB protocol, a successful APB transfer starts with asserting a group of APB signals such as PSEL, PWRITE, PADDR, PWDATA, PWDATA_PAR, PSTRB, and PSTRB_PAR. The PENABLE signal needs to assert at 1 clock cycle after asserting these signals. All these signals need to maintain their states throughout the entire transfer. The assertion of PREADY from the slave indicates that the active APB request is completed and marks the end of the APB transfer. At the end of the APB transfer, the master needs to de-assert the PENABLE signal and may change the signal state of PSEL, PWRITE, PADDR, PWDATA, PWDATA_PAR, PSTRB, and PSTRB_PAR for the next APB transfer (or no APB request).

The assertion of apb_eval signal indicates that the APB Interconnect core is in an EVALUATION state, where it evaluates all available assertions of PSEL from any master. It then decides and selects which master to be granted the APB request based on the selected priority.

To comply with the APB protocol, the APB Interconnect core evaluates the granted master's PENABLE at 1 clock cycle after the assertion of the master's PSEL, to determine the start of the APB transfer. There are two situations:
  • If the granted master's PENABLE is 1, it marks the start of APB transfer, where the APB Interconnect core exits the EVALUATION state to enter the TRANSFER state. Concurrently, the grant_o signal updates to indicate which master is being granted a request.
  • If the granted master's PENABLE is 0, there is no APB transfer. The apb_eval signal maintains 1, but the APB Interconnect core starts to evaluate the master of next priority. If the master of the next priority fulfills the PENABLE criteria, the APB Interconnect core exits the evaluate state and updates grant_o. Otherwise, the APB Interconnect core stays in the EVALUATION state and moves to the master of next priority.

The assertion of PREADY from the slave indicates the end of active APB transfer. If the slave does not assert PREADY, the APB Interconnect core continues to wait since there is no timeout mechanism in the APB Interconnect core. When this occurs, you may need to reset this deadlock by asserting the rst_n.

Tip: You may implement an independent timeout mechanism to determine whether a deadlock has occurred and to decide when to perform the reset.