How bhavesh270106/ahb_to_apb-bridge-design works
1. Repository purpose
- This repo implements a synthesizable AHB-to-APB bridge in Verilog.
- The goal is to translate a single AHB read/write transaction into the two-cycle APB protocol, while keeping address, control, and data aligned across the bridge.
2. Top-level structure
- bridge_top.v is the integration point for the design.
- The project is organized around one real hardware block, the bridge, plus surrounding stimulus modules used to exercise it in simulation and validation.
3. Core bridge boundary
- The only synthesizable subsystem is the bridge itself.
- The other Verilog files serve as protocol-side endpoints for testing:
- AHB_Master.v generates AHB master transactions.
- AHB_Slave_Interface.v models the AHB-side slave-facing behavior.
- APB_Interface.v models the APB peripheral-side behavior.
- This means the repo is primarily a bus-interface RTL design with testbench wrappers, not a full SoC.
4. Functional decomposition
- APB_Controller.v appears to be the control/state-machine block.
- It is responsible for sequencing the APB transfer phases and generating bridge control outputs such as select and enable timing.
- AHB_Slave_Interface.v likely handles the AHB-side handshake and captures the incoming address/control phase from the master side.
- APB_Interface.v likely drives the APB-side outputs and returns read data to the AHB side.
5. Main data flow
- On an AHB write:
- The master presents address, write control, and write data.
- The bridge latches the address/control, decodes the target peripheral, and drives APB address, select, enable, and write data.
- On an AHB read:
- The bridge captures the AHB request, issues the APB read, then returns APB read data back onto the AHB read path.
- The bridge therefore acts as a protocol converter and timing adapter between the two buses.
6. Control and timing flow
- AHB is treated as the initiating, higher-performance side with master-driven address/control phases.
- APB is treated as the lower-complexity destination side that always uses a setup phase followed by an enable phase.
- The bridge inserts this APB timing by generating PSELx and PENABLE, while holding the APB address stable for the full transfer.
7. Address decode and peripheral selection
- The readme states the bridge decodes the address to generate PSELx.
- Only one APB select is active per transfer, so the bridge likely contains combinational address-decoding logic plus a registered control path to preserve stability during the APB transaction.
8. Handshake and response behavior
- The AHB side uses HREADY and HRESP to indicate completion and status.
- The APB side relies on PSELx, PENABLE, and the read/write direction signal rather than multi-response handshaking.
- The bridge’s job is to convert the AHB transaction into the APB timing model and return completion at the appropriate point.
9. Simulation/test setup
- The repo is validated with a single read and single write sequence.
- AHB_Master.v and APB_Interface.v are used to generate and observe bus activity, while the bridge under test converts the transaction between protocols.
- The README explicitly notes that burst support and arbitration are not implemented yet.
10. Tooling and implementation context
- The design is written in Verilog.
- It was simulated in ModelSim and synthesized in Quartus Prime for a Cyclone V FPGA target.
- Those tools matter architecturally because the bridge is intended to be both simulation-valid and synthesis-ready, unlike the surrounding test modules.
11. System-level architectural role
- In AMBA terms, this repository implements the classic boundary between a fast system bus and a simpler peripheral bus.
- The bridge is the only subsystem that must understand both protocols and enforce their timing differences; all other modules exist to stimulate or observe that conversion.
12. Current scope and limitations
- Supported: single AHB read, single AHB write, APB address decode, APB select generation, and APB enable sequencing.
- Not supported yet: bursts, arbitration, or broader multi-master behavior.
- For an architecture diagram, the key boundary is a single master-side AHB interface feeding a bridge FSM, which outputs APB-side control/data to a peripheral interface.
Main entry points: APB_Interface.v APB Side · APB_Controller.v APB FSM · bridge_top.v Top · AHB_Slave_Interface.v AHB Side
Components 6
Bridge RTL
Synthesizable AHB-to-APB bridge logic and top-level integration.
- Top · Top-level integration point that wires the bridge and its bus-side endpoints.
bridge_top.v - AHB Side · Captures AHB address/control, handshake, and completion behavior on the slave-facing side of the bridge.
AHB_Slave_Interface.v - APB FSM · Sequencer/state machine that generates APB setup and enable timing and coordinates transfer progress.
APB_Controller.v - APB Side · Drives APB address, select, enable, write data, and read-data return behavior.
APB_Interface.v
Validation
Simulation-side masters and peripheral-side models used to exercise the bridge.
- AHB Master · Testbench master that issues single read and write transactions into the bridge.
AHB_Master.v - APB Model · Peripheral-side endpoint used to observe APB activity and complete simulated transfers.
APB_Interface.v
Connections 8
- AHB Master → Top: AHB requests · Generates read/write transactions into the bridge top-level.
- Top → AHB Side: capture · Routes incoming AHB address, control, and handshake signals into the AHB-side interface.
- AHB Side → APB FSM: txn state · Transfers the latched transaction context into the APB control path.
- APB FSM → APB Side: phase control · Drives APB setup/enable sequencing and transfer timing.
- APB FSM → Top: HREADY/HRESP · Returns completion and response status to the AHB side.
- APB Side → APB Model: APB bus · Presents APB address, select, enable, and write data to the peripheral-side model.
- APB Model → APB Side: read data · Supplies APB read-back data for return to the bridge.
- APB Side → AHB Side: rdata path · Feeds APB read data back toward the AHB-side response path.