AHB stands for Advanced High-performance Bus. It is an AMBA bus protocol used for high-performance on-chip communication between managers, interconnects, memories, and high-bandwidth peripherals.

AHB is used when the system needs better performance than a simple peripheral bus. It supports pipelined transfers, burst transactions, single clock-edge operation, wait-state insertion, and configurable address/data widths. Because of this, AHB is commonly used for processor-to-memory paths, DMA access, and subsystem-level interconnects.

AHB improves bus throughput by overlapping address and data phases while still keeping the protocol simpler than AXI. From a verification point of view, the most important areas are transfer sequencing, HREADY behavior, burst address generation, and error response handling.

2. Where is AHB normally used in an SoC?

AHB is normally used in the performance-sensitive part of an SoC. Typical AHB-connected blocks include processors, DMA controllers, memory controllers, SRAM interfaces, high-speed peripheral subsystems, and bridges to lower-speed buses.
In many SoC architectures, AHB sits above APB. The high-speed side communicates using AHB, and low-speed register-based peripherals are connected through an AHB-to-APB bridge. This allows the main system to use a higher-performance bus while keeping simple peripherals on a low-power interface.
AHB is not always used everywhere because different buses are optimized for different needs. APB is cheaper and simpler for low-bandwidth control registers, while AXI is better for very high-performance, multiple-outstanding, independent read/write traffic. AHB fits the middle ground: efficient, pipelined, and simpler than AXI.

3. What is the difference between AHB and APB?

AHB is a high-performance pipelined bus, while APB is a simple, low-power, non-pipelined peripheral bus. AHB supports overlapping address and data phases, burst transfers, and wait-state insertion through HREADY. APB uses a simple two-phase transfer made of SETUP and ACCESS phases.

AHB is suitable for memory and high-bandwidth peripheral access. APB is suitable for register access in peripherals such as UART, SPI, timer, GPIO, interrupt controller, and watchdog. APB has fewer control signals and lower complexity, which makes it easier to design and verify.

The difference is not only that AHB is faster and APB is slower. The real difference is architecture: AHB is pipelined and supports bursts; APB is non-pipelined and optimized for simple register reads and writes.

4. What are the address phase and data phase in AHB?

Every AHB transfer has an address phase and a data phase. During the address phase, the manager drives address and control information such as HADDR, HWRITE, HSIZE, HBURST, and HTRANS. During the data phase, the actual data transfer happens using HWDATA for writes or HRDATA for reads.

The important point is that AHB is pipelined. The address phase of the next transfer can occur at the same time as the data phase of the current transfer. For example, while the data for address A is being transferred, the address and control for address B can already be present on the bus.

This pipeline behavior improves throughput, but it is also a common source of bugs. A verification engineer must sample data only when the transfer actually completes, not simply when address/control signals appear. Wait states and error responses can stretch or cancel parts of the pipeline.

5. How do you identify a valid AHB transfer?

An AHB transfer is valid when the subordinate is selected and the transfer type indicates a real transfer. Practically, this means HSELx is asserted and HTRANS is either NONSEQ or SEQ.

IDLE and BUSY are not real data transfers from the subordinate’s point of view. The subordinate should ignore them and return an OKAY response. For NONSEQ and SEQ, the subordinate uses address and control signals such as HADDR, HWRITE, HSIZE, and HBURST to understand the requested operation.

The transfer is considered complete only when HREADY is HIGH. Therefore, a monitor should detect a valid transfer from HSELx and HTRANS, but it should create the completed transaction only after the corresponding data phase completes with HREADY HIGH and the final HRESP value.

6. What are the possible values of HTRANS?

HTRANS indicates the type of AHB transfer. It has four values: IDLE, BUSY, NONSEQ, and SEQ.

IDLE means no data transfer is required. BUSY means the manager is in the middle of a burst but is not ready to continue with the next beat. NONSEQ is used for a single transfer or the first beat of a burst. SEQ is used for the remaining beats of a burst.

Many protocol bugs happen around incorrect HTRANS sequencing. A burst should start with NONSEQ and continue with SEQ beats, except when BUSY is inserted. A subordinate should ignore IDLE and BUSY transfers and respond with OKAY.

Intermediate level questions

1. Why is AHB called a pipelined protocol?

AHB is called pipelined because the address phase of one transfer overlaps with the data phase of the previous transfer. This allows the bus to prepare the next transfer while the current transfer is completing.
For example, in cycle N the manager may drive address A. In cycle N+1, the data phase for address A happens, and at the same time the manager can drive address B. If no wait states are added, AHB can complete one transfer per clock after the pipeline is filled.
Pipelining increases performance but makes timing less obvious. Address and data seen in the same clock cycle may belong to different transfers. A monitor, scoreboard, or assertion must track the address phase and associate it with the correct later data phase.

2. How does an AHB read transfer work?

In an AHB read transfer, the manager drives the address and control information in the address phase with HWRITE LOW. The selected subordinate returns the read data on HRDATA during the data phase.

The read data is considered valid only when the transfer completes. Completion happens when HREADY is HIGH and the response is OKAY. If the subordinate needs more time, it drives HREADYOUT LOW, which extends the data phase. During those wait cycles, the monitor should not sample HRDATA as final valid data.

The pipeline effect is important in a read transfer. The address for the next transfer may already be on the bus while the read data for the previous transfer is being returned. Therefore, verification logic must maintain a queue or sampled copy of pending address/control information.

3. How does an AHB write transfer work?

In an AHB write transfer, the manager drives address and control information in the address phase with HWRITE HIGH. The actual write data appears on HWDATA in the following data phase.

Because of pipelining, the address/control and write data for the same transfer are not driven in the same phase. The address phase identifies what will be written and where, while the next data phase carries the write payload. The transfer completes only when HREADY is HIGH.

From a verification point of view, the driver and monitor must align write data with the correct previous address phase. A common bug is sampling HWDATA in the same cycle as HADDR; that can associate data with the wrong address when back-to-back or waited transfers occur.

4. What is the difference between HREADY and HREADYOUT?

HREADYOUT is driven by a subordinate to indicate whether it has completed the current transfer. If the subordinate needs more time, it drives HREADYOUT LOW to insert wait states.

HREADY is the global ready signal generated by the interconnect. It is seen by the manager and subordinates and indicates whether the current transfer has completed from the system point of view. In a system with multiple subordinates, the interconnect selects the appropriate subordinate’s HREADYOUT and response to generate global HREADY.

These two signals are sometimes confused because they can look similar in a simple single-subordinate environment. In a real interconnect they have different roles. HREADYOUT is local to the selected subordinate; HREADY is the bus-level completion signal.

5. How are wait states inserted in AHB?

Wait states are inserted when the selected subordinate drives HREADYOUT LOW. This causes the bus-level HREADY to remain LOW, which extends the current data phase.

During wait states, the transfer has not completed. The manager must keep the required address/control information stable for the waited transfer, and for write transfers it must keep HWDATA stable during the extended data phase. The subordinate uses this extra time to complete the operation.

A monitor should not create a completed transaction until HREADY is HIGH. Assertions should check stability during wait states, and scoreboards should avoid comparing read data before the final completion cycle.

6. What should remain stable when HREADY is LOW?

When HREADY is LOW, the current transfer is being extended. The manager must keep address and control signals stable until HREADY becomes HIGH. This includes signals such as HADDR, HWRITE, HSIZE, HBURST, HTRANS, and other relevant control information for the active transfer.

For write transfers, HWDATA must also remain stable during the extended data phase. For read transfers, the subordinate is required to provide valid HRDATA only when the transfer completes successfully, not necessarily during every wait cycle.

This is a very common assertion question. A typical check is: if HREADY is LOW during a valid transfer, address/control should not change until the transfer completes. Another check is that write data remains stable while the write data phase is waited.

7. What is the difference between NONSEQ and SEQ transfer?

NONSEQ is used for a single transfer or the first beat of a burst. It tells the subordinate that the address/control information is not related to the previous transfer.

SEQ is used for the remaining beats of a burst. In a sequential transfer, the address is related to the previous beat and usually increments by the transfer size. For wrapping bursts, the address wraps at the defined wrap boundary.

The important point is that burst sequencing starts with NONSEQ and continues with SEQ. If a manager drives SEQ without a valid previous burst context, or generates the wrong address progression, that is a protocol error.

8. What are AHB burst transfers?

An AHB burst is a group of related transfers. Bursts improve efficiency because the manager can access consecutive or wrapping addresses without treating every beat as an unrelated transaction.

HBURST defines the burst type. Common burst types include single transfer, incrementing bursts, and wrapping bursts. The first beat of a burst uses NONSEQ, and the following beats use SEQ, unless BUSY cycles are inserted by the manager.

From a verification perspective, burst checking includes beat count, address increment, wrap behavior, transfer size, and boundary rules. The next address is calculated using transfer size from HSIZE and burst behavior from HBURST.

9. What is the role of HSIZE in AHB?

HSIZE defines the size of each transfer in the burst or single transaction. It tells how many bytes are transferred in one beat. For example, a byte, halfword, word, or wider transfer can be represented depending on the supported bus width.

HSIZE affects address incrementing. For an incrementing burst, the next address normally increases by the number of bytes indicated by HSIZE. If HSIZE indicates a 4-byte transfer, consecutive beats normally move by 4 bytes.

This matters in verification because burst address generation cannot be checked using a fixed increment. The checker must derive the increment from HSIZE. It should also check that transfers are aligned as required by the protocol and by the subordinate design.

10. What is HRESP used for?

HRESP is the AHB response signal. It tells whether the transfer completed normally or whether an error occurred. In common AHB-Lite usage, the main responses are OKAY and ERROR.

An OKAY response means the transfer completed successfully. An ERROR response means the subordinate detected a problem, such as an invalid address, unsupported access, protection violation, or another subordinate-specific error condition.

HRESP must be interpreted with HREADY. A response is meaningful when the data phase completes. If HREADY is LOW, the transfer is still being extended and the final completion has not happened yet.

Difficult level questions

1. Why does an AHB ERROR response take two cycles?

In AHB, an ERROR response is normally given as a two-cycle response so the manager gets time to react to the error. During the first cycle of the error response, HRESP indicates ERROR while HREADY is LOW. During the second cycle, HRESP remains ERROR and HREADY becomes HIGH to complete the error response.

The reason is related to pipelining. Since AHB overlaps address and data phases, the manager may already have driven the next address phase when the current transfer reports an error. The extra cycle allows the manager to cancel or adjust the following transfer by driving an appropriate HTRANS, often IDLE.

The two-cycle ERROR response is needed because of both response timing and pipeline behavior. It gives the manager a clean opportunity to handle the already-pipelined next transfer.

2. How should a manager behave after an AHB ERROR response?

After an ERROR response, the manager must treat the current transfer as failed. If the manager had already started a following address phase because of pipelining, it may need to cancel that following transfer by driving HTRANS as IDLE or by restarting the transaction sequence as required by the design.

If the error occurs in the middle of a burst, the manager usually terminates or restarts the burst rather than continuing as if all previous beats succeeded. The exact system-level action depends on the manager design, but the protocol expectation is that the manager must not ignore the error response.

In verification, this becomes both a protocol and scoreboard question. The monitor should record the failed transfer as an error completion. The scoreboard should not update expected memory state for a failed write unless the design specification says the write can have side effects before error reporting.

3. What is the AHB 1KB boundary rule?

AHB bursts must not cross a 1KB address boundary. This means all beats of a burst should remain inside the same 1KB region.
The purpose of this rule is to simplify subordinate selection and address decoding. If a burst crossed a 1KB boundary, it could move from one subordinate region to another in the middle of the burst, which would complicate interconnect behavior and response handling.
For example, if a burst starts near the end of a 1KB region, the manager must choose a burst length and transfer size such that the final beat still stays within that region. Verification should include directed and random tests for bursts near boundary addresses.

4. What is a BUSY transfer and why is it used?

BUSY is used by a manager during a burst when it is not ready to continue with the next meaningful beat but still wants to indicate that the burst is ongoing. It is different from IDLE, which means no transfer is required.

A subordinate must ignore a BUSY transfer and respond with OKAY. No data transfer should occur for a BUSY beat. The next valid beat of the burst can continue after the BUSY cycle, usually with SEQ.

BUSY is easy to misunderstand because it is not a wait state inserted by the subordinate. Wait states are controlled by HREADY. BUSY is inserted by the manager through HTRANS.

5. What is a locked transfer in AHB?

A locked transfer is used when a manager needs exclusive access to the bus for a sequence of transfers. The signal commonly associated with this behavior is HMASTLOCK.

The purpose is to prevent another manager from interrupting a critical sequence. For example, a read-modify-write operation may need to be performed atomically. The interconnect or arbiter uses the lock information to preserve bus ownership for the locking manager.

The system-level need is atomic access, not just the presence of a lock signal. In verification, locked transfers require checks that arbitration does not switch ownership in the middle of the locked sequence and that the lock eventually releases.

6. What is the role of arbitration in AHB?

In a multi-manager AHB system, arbitration decides which manager gets access to the bus. Only one manager can drive the shared address and control bus at a time, so an arbiter grants ownership based on priority, fairness, lock status, or system-specific rules.
The granted manager drives address/control information, while the interconnect routes the transfer to the selected subordinate based on address decoding. The response from the selected subordinate is routed back to the active manager.
AHB is a bus architecture, not only a signal list. From a verification perspective, arbitration tests include simultaneous requests, locked sequences, priority behavior, starvation checks, and correct routing of responses.

7. What should be verified in an AHB-to-APB bridge?

An AHB-to-APB bridge converts high-performance AHB transfers into simple APB register transfers. It accepts AHB address/control/data information and generates APB PSEL, PENABLE, PWRITE, PADDR, PWDATA, and related signals.

The bridge must handle protocol timing differences. AHB is pipelined, while APB is non-pipelined and has SETUP and ACCESS phases. The bridge may need to insert AHB wait states while the APB transfer is in progress.

Important verification checks include correct read/write conversion, correct address and data mapping, APB wait-state handling, AHB HREADY generation, APB PSLVERR mapping to AHB error response, and back-to-back transfer behavior.

8. What are common AHB protocol assertions?

Common AHB assertions check transfer stability, legal HTRANS sequencing, burst address progression, response timing, and boundary rules. For example, address and control should remain stable when HREADY is LOW for an active transfer.

Other useful assertions check that a burst starts with NONSEQ, continues with legal SEQ beats, does not cross the 1KB boundary, and generates the correct address increments based on HSIZE. For write transfers, HWDATA should remain stable during waited data phases.

Protocol rules should be connected to practical SVA checks and functional coverage. A few meaningful checks with clear intent are more useful than a long list of signal names.

9. How would you debug an AHB data mismatch?

First identify whether the mismatch is on a read or write transfer. Then check the transfer completion cycle using HREADY and HRESP. A common mistake is sampling data before the transfer has completed, especially when wait states are present.

For a write mismatch, verify that the scoreboard associated HWDATA with the correct previous address phase. Because AHB is pipelined, write data belongs to the earlier address phase, not necessarily the address visible in the same cycle. Also check byte lanes, HSIZE, and address alignment.

For a read mismatch, verify that the subordinate returned valid HRDATA only at completion and that the monitor sampled it in the correct cycle. Also check whether an ERROR response occurred, because an error transfer should not be compared as a normal successful data transfer.

Interview Questions