APB stands for Advanced Peripheral Bus. It is an AMBA protocol used for simple, low-bandwidth, low-power peripheral register access.
APB is used when the design does not need pipelining, bursts, or multiple outstanding transactions. It provides a simple two-phase transfer mechanism that is easy to implement for control/status registers in peripherals.
APB is a practical peripheral bus, not a high-performance data bus. Its simplicity is its advantage. It reduces design complexity, reduces switching activity, and makes register access timing easy to verify.

2. Which peripherals are commonly connected to APB?

APB is commonly used for peripherals such as UART, SPI, I2C, GPIO, timer, watchdog, interrupt controller, PWM, configuration registers, and status registers.
These blocks usually do not require high throughput. They need simple reads and writes to control registers, status registers, interrupt enables, baud rate registers, configuration fields, and data registers.
APB is not selected because it is the fastest protocol; it is selected because it is simple, low power, and sufficient for register-level peripheral access.

3. Why is APB considered low power and simple to use?

APB is considered low power because it minimizes switching activity. It is non-pipelined, has fewer control signals, does not support bursts, and has only one active transfer at a time. Since there are no independent address, data, and response channels toggling in parallel, the dynamic power is lower compared to protocols such as AHB or AXI.

Only the selected peripheral sees an active transfer through PSEL. Non-selected peripherals can keep their internal logic idle because their select signal is not asserted. In many designs, APB peripherals also use PSEL and PENABLE as local enable conditions, so internal register decode, write enable generation, and read mux activity happen only during an actual access.

APB is simple because every transfer follows a clear SETUP and ACCESS phase. There are no outstanding transactions, no transaction IDs, no out-of-order responses, no burst address generation, and no separate read/write data channels. This keeps the protocol easy to design, integrate, and verify.

In verification, this simplicity means the checks are straightforward but still important. Most APB bugs happen around SETUP/ACCESS sequencing, wait-state handling with PREADY, signal stability, and incorrect PSLVERR timing.

4. What are the phases of an APB transfer?

An APB transfer has two main phases: SETUP and ACCESS. In the SETUP phase, PSEL is asserted and transfer information such as PADDR, PWRITE, and PWDATA for writes is driven. PENABLE remains LOW in this phase.

In the ACCESS phase, PENABLE is asserted HIGH along with PSEL. The transfer completes when PREADY is HIGH during the ACCESS phase. If PREADY is LOW, the ACCESS phase is extended.

In this two-phase structure, PENABLE is not asserted in the same cycle as the SETUP phase. It is asserted in the next cycle for the ACCESS phase.

5. When exactly does an APB transfer complete?

An APB transfer completes in the ACCESS phase when PSEL, PENABLE, and PREADY are all HIGH on a rising clock edge. PSEL shows that the peripheral is selected, PENABLE shows that the transfer is in ACCESS phase, and PREADY shows that the peripheral is ready to complete the transfer.

For a write transfer, PADDR, PWRITE, and PWDATA must represent the write operation until completion. For a read transfer, PRDATA should be sampled only in the completion cycle. PSLVERR is also meaningful only in the completion cycle.

This distinction is important because PENABLE alone does not complete a transfer. If PREADY is LOW, the ACCESS phase continues and address/control/data must remain stable until the peripheral finally asserts PREADY

6. What is the difference between PSEL and PENABLE?

PSEL selects the APB peripheral. It is asserted during both SETUP and ACCESS phases for the selected peripheral.

PENABLE indicates the ACCESS phase. It is LOW during SETUP and HIGH during ACCESS. The transfer can complete only in the ACCESS phase when PSEL, PENABLE, and PREADY are HIGH.

The key point is that PSEL starts the transfer, while PENABLE advances it to the ACCESS phase. Asserting both incorrectly in the first cycle violates the normal APB transfer sequence.

Intermediate level questions

1. Explain an APB write transfer.

In an APB write transfer, the requester first enters the SETUP phase by asserting PSEL, driving PADDR, setting PWRITE HIGH, and placing write data on PWDATA. During this phase, PENABLE is LOW.

In the next cycle, the requester asserts PENABLE to enter the ACCESS phase. If PREADY is HIGH, the write completes in that cycle. If PREADY is LOW, the ACCESS phase continues until PREADY becomes HIGH.

In verification, the monitor should consider the write complete only when PSEL, PENABLE, and PREADY are HIGH. Sampling the write in the SETUP phase can cause false updates in the scoreboard when wait states or errors occur.

2. Explain an APB read transfer.

In an APB read transfer, the requester asserts PSEL, drives PADDR, and sets PWRITE LOW during the SETUP phase. PENABLE remains LOW during this phase.

In the ACCESS phase, PENABLE is asserted. The subordinate drives PRDATA, and the read transfer completes when PREADY is HIGH. If PREADY is LOW, the subordinate is not required to complete the read yet, and the ACCESS phase continues.

PRDATA should be sampled when the transfer completes, meaning when PSEL, PENABLE, and PREADY are all HIGH. Sampling before completion can capture stale or invalid data.

3. How are wait states inserted in APB?

APB wait states are inserted by keeping PREADY LOW during the ACCESS phase. The requester keeps PSEL and PENABLE asserted, and the transfer remains active until PREADY becomes HIGH.

While PREADY is LOW, the peripheral is telling the requester that it needs more time. This may happen because the peripheral is accessing an internal register file, crossing a clock boundary, waiting for an internal operation, or handling a slower block.

From a verification point of view, APB wait states are simple but important. Assertions should check that address/control/data remain stable during the waited ACCESS phase, and the monitor should create a completed transaction only when PREADY is HIGH.

4. What should remain stable during APB wait states?

During APB wait states, key transfer signals must remain stable. These include PADDR, PWRITE, PSEL, PENABLE, PWDATA for write transfers, PSTRB, and PPROT if used.

The reason is that the subordinate may complete the transfer in any later ACCESS cycle when PREADY becomes HIGH. If address, direction, or data changes while PREADY is LOW, the subordinate may complete a different transfer than the requester intended.

This is a common assertion question. A practical SVA check is to detect an ACCESS phase with PREADY LOW and then require the transfer information to remain unchanged until PREADY becomes HIGH.

5. What is the role of PREADY?

PREADY tells whether the selected APB subordinate is ready to complete the transfer. If PREADY is HIGH during the ACCESS phase, the transfer completes. If it is LOW, the ACCESS phase is extended.

For a simple zero-wait-state peripheral, PREADY can be tied HIGH. In that case, every APB transfer completes in one ACCESS cycle after the SETUP phase.

APB completion is not controlled by PENABLE alone. PENABLE indicates ACCESS phase, but PREADY decides whether that ACCESS phase completes or continues.

6. When is PSLVERR valid?

PSLVERR is valid only in the final cycle of an APB transfer, when PSEL, PENABLE, and PREADY are HIGH. It indicates whether the completed transfer has an error response.

If PREADY is LOW, the transfer is still waiting, so PSLVERR should not be treated as a final response. A design may drive some value on PSLVERR during wait cycles, but the requester and monitor should sample it only on transfer completion.

Many monitors incorrectly sample PSLVERR whenever PENABLE is HIGH. The correct sampling point is the completed ACCESS phase.

7. What is the use of PSTRB in APB?

PSTRB indicates which byte lanes are valid during a write transfer. It is used when the data bus has multiple byte lanes and the requester wants to update only selected bytes.

For example, on a 32-bit APB data bus, PSTRB can indicate whether byte 0, byte 1, byte 2, byte 3, or a combination of them should be written. This supports byte and halfword updates without overwriting the full word.

In verification, PSTRB affects the expected register model update. The scoreboard should update only the selected byte lanes for writes. For reads, PSTRB is not meaningful because it is a write strobe.

8. How do back-to-back APB transfers work?

Back-to-back APB transfers happen when one transfer completes and another starts immediately after it. After the first transfer completes, the bus moves to the SETUP phase of the next transfer.

If the next transfer is to the same peripheral, PSEL may remain asserted while PENABLE is deasserted for the next SETUP phase. If the next transfer is to a different peripheral, the previous PSEL is deasserted and the new peripheral’s PSEL is asserted.

Every APB transfer still needs a SETUP phase followed by an ACCESS phase. Even in back-to-back traffic, PENABLE must drop for the SETUP phase of the next transfer.

9. What is the role of an APB bridge?

An APB bridge converts transactions from a higher-performance bus such as AHB or AXI into APB transfers. It acts as a requester on the APB side and controls PSEL, PENABLE, address, write data, and read data return.

The bridge is needed because APB peripherals are simple and do not understand AHB or AXI transaction formats. The bridge absorbs the complexity of the high-speed bus and presents a simple APB transfer to the peripheral.

The bridge must correctly handle waits, errors, read data return, write strobes, and back-to-back transfers. It may also need to hold the upstream bus transaction incomplete while the APB transfer is still waiting.

Difficult level questions

1. Can PENABLE be asserted in the same cycle as PSEL?

For a normal APB transfer, PENABLE should not be asserted in the same first cycle as PSEL. The first cycle is the SETUP phase, where PSEL is asserted and PENABLE is LOW.

PENABLE is asserted in the next cycle to indicate the ACCESS phase. The transfer completes in the ACCESS phase only when PREADY is HIGH. This sequence keeps APB timing simple and gives the peripheral one cycle to decode address and control.

PSEL and PENABLE do not start the transfer together in the first cycle. PSEL starts SETUP; PENABLE marks ACCESS.

2. What happens if PREADY remains LOW for multiple cycles?

If PREADY remains LOW, the APB transfer remains in the ACCESS phase for multiple cycles. PSEL and PENABLE remain HIGH, and the requester must keep the transfer information stable.

The transfer does not complete until PREADY becomes HIGH. This allows a slow peripheral to add as many wait states as needed, subject to any system-level timeout policy.

In verification, this should be tested with zero wait, one wait, and multiple wait cycles. The scoreboard should update only once, at final completion, not once per ACCESS wait cycle.

3. Can PSLVERR be sampled when PREADY is LOW?

No. PSLVERR should be sampled only when the APB transfer completes, which is when PSEL, PENABLE, and PREADY are HIGH.

When PREADY is LOW, the transfer is still in progress. Any value seen on PSLVERR during those wait cycles should not be treated as the final response. The final error status is meaningful only in the completion cycle.

This is important for monitor design. A monitor should create a response object only on completion and should attach the sampled PSLVERR value from that cycle. Sampling early can create false error reports.

4. If an APB write returns PSLVERR, should the register update happen?

The APB protocol indicates that the transfer completed with an error, but whether the internal register was updated can be design-specific. Some peripherals may reject the write completely, while others may report an error after a partial or side-effecting operation.
For verification, the expected behavior must come from the peripheral specification or register model policy. If the design says an error write must not update the register, the scoreboard should check that. If the design allows side effects, the scoreboard must model them.
This separates protocol behavior from design behavior. The protocol tells how the error is signaled; the block specification tells what the internal state should do after that error.

5. What APB assertions are commonly written?

Common APB assertions check phase sequencing, transfer stability, completion timing, and response sampling. For example, after SETUP with PSEL HIGH and PENABLE LOW, the next ACCESS phase should assert PENABLE unless reset or transfer cancellation rules apply.

Another common assertion checks that address/control/write data remain stable while PSEL and PENABLE are HIGH and PREADY is LOW. A third common check is that PSLVERR is sampled only in a completed ACCESS phase.

The purpose of the assertion is more important than only naming signals. The purpose is to ensure legal APB phase movement, prevent transfer information from changing during waits, and avoid false transaction completion.

6. How should unaligned or narrow APB accesses be handled?

APB itself carries address, write data, and optional byte strobe information. For narrow writes, PSTRB can identify which byte lanes should be updated. The handling of unaligned addresses depends on the system and peripheral design rules.

Some designs may support byte-addressable registers with strobes. Other designs may require aligned word accesses and return an error or ignore unsupported byte lanes. This behavior should be clearly defined in the register or peripheral specification.

A verification answer should mention that the scoreboard cannot assume all writes update the full data bus. It must consider PADDR, data width, PSTRB, and the peripheral’s alignment rules.

7. How would you debug an APB read data mismatch?

First check whether the monitor sampled PRDATA in the correct cycle. The correct sampling point is when PSEL, PENABLE, and PREADY are HIGH. If wait states are present, sampling earlier can capture stale data.

Next check the address decode and register model. Make sure the expected register value corresponds to the selected peripheral and address. Also check whether the read has side effects, such as clear-on-read status bits.

Finally, check PSLVERR. If the transfer completed with an error, the read data may not be valid for normal comparison. The scoreboard should treat error responses separately from successful reads.

Interview Questions