This blog post is the second in our two-part summer internship series. Following Beshr’s great work on porting Enabling Position-Independent Code and Dynamic Memory Management in ZeroRISC OS, Yeabsira tackled porting OpenTitan’s interconnect from TL-UL to AXI.

Introduction

Yeabsira is a rising senior at MIT studying Electrical Engineering & Computer Science, with a passion for the hardware stack - from digital systems and chip design to all things low-level. When not engineering, he can be found kickboxing, laying down jazz grooves on his bass guitar, or tinkering with audio circuits.

Extending OpenTitan to AXI

My project focused on porting OpenTitan to AXI. OpenTitan’s interconnect is currently TL-UL (TileLink Uncached Light-Weight), which works well. However, many common IP blocks, debug probes, and FPGA tools use AXI. Generating AXI-compatible IP allows straightforward integration with AXI-enabled designs and leverages existing AXI-based DV collateral to enhance verification. My goal was to start an incremental conversion to AXI, beginning with AXI-based register interface transactions while preserving the TL-UL interconnect.

I developed two key RTL components.

The first is a TL-UL to AXI bridge, which repackages TL-UL host-to-device (H2D) requests into AXI and AXI’s device-to-host (D2H) responses back into TL-UL D2H responses.
The second is the AXI AdapterReg, replicating TL-UL AdapterReg functionality. This module translates TL-UL H2D requests into peripheral CSR read/write operations and returns results as TL-UL D2H responses, providing a clean communication path. The AXI AdapterReg maintains the CSR handshake while exposing an AXI D2H interface upstream, allowing AXI hosts to communicate directly with peripherals. By replacing TL-UL AdapterReg with the bridge + AXI AdapterReg, full DV regression can be rerun, supporting functional equivalence and incremental migration to AXI-native IP.

The simplified diagram below illustrates the implementation and how a fully AXI-enabled open silicon blocks could function in the future.

The Bridge

Understanding the bridge requires comparing TL-UL and AXI. TL-UL has two channels: A_Channel for requests and D_Channel for responses. Signals are shared between reads and writes, with A_Opcode indicating request type. OpenTitan-derived IP adds user bits for response integrity.

AXI uses five separate channels: AW (write addresses), W (write data), AR (read addresses), R (read responses), and B (write responses). Each has its own handshake, so signals are not shared between reads and writes.

I implemented flip-flop registers to capture TL-UL input signals during handshakes. Based on A_Opcode, requests are mapped to the appropriate AXI channels. AXI D2H responses are then routed back to TL-UL D2H outputs according to the registered request type.

A notable challenge involved handling AW and W handshakes, which can occur independently. The solution was a state machine tracking AW and W, waiting for the other handshake when only one occurs. Currently, the bridge supports a single inflight request at a time, ensuring clear and reliable state transitions. The diagram and accompanying state machine illustrate the timing and toggling of each signal.

AXI AdapterReg

The AXI AdapterReg sits in front of each peripheral, translating AXI transactions into CSR accesses and returning AXI responses. It can also be integrated into the current TL-UL-based system via the bridge.

Its scope is narrower than the bridge, converting AXI’s split channels into a single CSR-side handshake. The CSR interface asserts we_o for writes, re_o for reads, passes address, data, and byte enables, and expects rdata_i or error_i. Only one inflight request is supported, so responses are immediately matched, and AXI ready signals remain low until completion.

Error handling was a critical focus. Differences between TL-UL and AXI can introduce cycle delays or missed errors. The AdapterReg and bridge communicate via an error_i/error_o handshake to ensure detected errors propagate correctly and prevent unhandled system failures.

Testing

Approximately 30% of my effort went into RTL design, and 70% into testing and debugging. Iterative simulation is crucial, as FPGA iteration is slow. I validated the design first in Verilator, then on FPGA, and finally in the full-chip environment, resolving major issues beforehand.

Tests revealed response integrity mismatches, cycle delays in error propagation, address alignment issues, AXI handshake quirks, and the need for the AW/W state machine. Each failed test guided design improvements, producing a robust bridge and AdapterReg ready for full-chip integration.

Impact and Benefits

My bridge and AXI AdapterReg now pass top-level DV regression and are being prepared for PR to main. Enabling AXI support allows for easier integration into more commercial silicon. Future work includes an AXI Host AdapterReg, enabling common open source RISC-V cores like Ibex to communicate with an AXI interconnect.

Beyond technical skills, I gained experience designing a system from scratch, integrating it into a larger chip, debugging complex issues, and understanding UVM-driven verification workflows. Collaboration with full-time engineers accelerated learning and allowed project completion, highlighting the value of curiosity, persistence, and hands-on problem-solving in digital systems engineering.

My experience demonstrates how early involvement in substantial RTL projects at ZeroRISC provides exposure to real-world digital systems challenges, making it an ideal environment for aspiring engineers seeking meaningful and technically rich work.

Conclusion

Yeabsira’s time at ZeroRISC shows how internships offer meaningful, hands-on exposure to real-world digital systems challenges. From designing and testing complex RTL components to understanding verification flows and system-level integration, interns leave with practical skills and insights that are hard to gain elsewhere. Stay tuned for future updates on our AXI work, and an announcement of its full open source release.

We’re proud of our interns' contributions and grateful for the fresh ideas and energy they brought to ZeroRISC this past summer. Their work not only advances our projects but also demonstrates the kind of learning, growth, and impact our internship program offers.

If you’re interested in learning more about our internship program or exploring collaboration opportunities with ZeroRISC, please visit our Career page.

Bridging Hardware and Software: Summer Interns Making an Impact at ZeroRISC