Open source TileLink to AHB bridges with dedicated Cocotb extensions
Topics: Open ASICs, Open source tools
Antmicro uses open source to introduce pragmatic innovation into areas which have traditionally been heavily reliant on proprietary technologies such as ASIC and FPGA. Due to high complexity and long design cycles, testing and verification are of critical importance especially in ASIC development. To bridge between the established methodologies and the emerging workflows, in collaboration with its customers Antmicro is improving SystemVerilog support in open source tools and working towards adding open source UVM capabilities to Verilator. At the same time, reflecting the company’s software-driven approach, it is popularizing modern frameworks such as Cocotb, an open source Python-based verification framework, and showing how it can be used for RISC-V cores and entire SoCs written in any HDL, including SystemVerilog.
FPGA and ASIC designs are comprised of building blocks often called IP cores, which typically communicate via shared buses. Reflecting different origins and design goals of various such blocks, there are many different protocols that may need bridging so that the blocks can be connected together. In this blog note, we will describe the SystemVerilog implementation of two bridges that allow communication between the TileLink and AHB interfaces, as well as AHB and TileLink Bus Functional Models (BFMs) in the form of Cocotb extensions that were used for testing and verification of the cores. Both the TL-AHB and the AHB-TL bridges are available on Antmicro’s GitHub.
TileLink and AHB overview
TileLink is a free and open interconnect standard originally developed by SiFive, with an RTL implementation hosted by CHIPS Alliance as part of the Rocket project. It was created to cater for tightly coupled, low-latency SoC buses, providing multiple master interfaces with coherent memory-mapped access to memory and other slave devices. It was designed for RISC-V, but supports other ISAs as well, and is used by many open source projects beyond the SiFive RISC-V portfolio such as OpenTitan. TileLink offers many useful features, including:
- packet based interconnect,
- acyclic connection graph,
- proven deadlock freedom,
- multiple levels of compatibility: starting from simple data transfers scaling up to cache aware coherent interconnect.
There are three versions of TileLink:
- TL-C (TileLink Cached),
- TL-UH (TileLink Uncached Heavyweight),
- TL-UL (TileLink Uncached Lightweight) - used in the bridge implementations described in this note.
ARM’s AMBA 5 AHB (Advanced High-performance Bus) is a bus interface suitable for high-performance synthesizable designs, widely adopted in the semiconductor industry. It defines the interface between components such as managers, interconnects, and subordinates. It provides multiple features important for high-performance, high frequency systems, including:
- pipeline design for high bandwidth interconnects,
- byte addressing capability,
- cache aware design with coherency,
- burst capability,
- address and data phases strongly connected with each other,
- clearly defined structure: managers, interconnect, subordinates.
The specification can be found on ARM’s website.
Bridging between TileLink and AMBA 5 AHB is useful in scenarios where new, RISC-V based IP (often using the former standard) needs to be added to state-of-the-art systems which are based on the latter. This, again, reflects Antmicro’s approach: introducing practical innovations based on open source IP, standards and workflows into existing, industrial systems.
The bridges described in this note enabling communication between TL and AHB were written in SystemVerilog and tested in simulation with Verilator and Cocotb. In order to thoroughly test the transactions, Cocotb needed to be extended with Bus Functional Models (drivers and monitors) for both types of buses.
Bridging TileLink and AHB
AHB and TileLink are fundamentally different - AHB is tightly coupled, while TL is packet based.
From the manager point of view, the AHB interface always has 2 transactions pending, one in the address phase and the other in the data phase. When the bus ready signal is high, transactions go from address to data, data to done, and a new transaction must be placed in the address phase. On the other hand, TileLink Uncached Light transactions are split into A and D packets. A packets are sent from the master, which contains: memory address, command, data and source id. The D response is sent from a device and includes: data, response opcode and error flag. This is a bit of a challenge, as we aren’t simply repackaging packets from one standard to another - we have to completely change how control signals and data are presented.
The TL to AHB bridge was implemented as a 4 stage pipeline core. In the first stage, A packets are received and acknowledged. In the second stage, the address and command are sent to AHB. In the next to last stage, data and the error flag are retrieved from AHB. In the last stage, a D packet is sent to the master. This is possible because TL is packet based, so a delay between A and D is not an issue. Multiple requests can be processed to AHB, as A packets are independent of each other.
The AHB to TL implementation, however, is a different story. As AHB is tightly coupled, the whole transaction has to be processed in 1 AHB bus cycle. This was done using a finite state machine to control communication with TL and AHB. First, the bridge receives what has to be done. Reads can be processed right away, while writes have to wait 1 extra cycle for data to be valid on AHB. When the command is ready, the bridge sends an A packet over TileLink and awaits the D packet. Once the D packet is received, data is put in AHB, and the end of transaction and/or error flag is signaled to the interconnect.
TileLink and AHB BFMs for Cocotb
A Bus Functional Model (BFM) is a non-synthesizable software model of a component having one or more external buses. BFMs apply stimuli to the design under verification and are capable of monitoring the transactions and inspecting the data flowing through the bus.
The open source Cocotb co-simulation framework has been graining adoption in the industry alongside more traditional approaches, and has been used by Antmicro in many projects throughout the years, e.g. for IP core testing or developing FPGA-accelerated AI processing platforms - and testing the newly created bridges felt like exactly the kind of task where Cocotb would be a good match.
Cocotb allows creating custom bus extensions in the form of Python modules, which include, most commonly, an abstraction of the bus itself, a bus driver, and a bus monitor. Antmicro developed such extensions for the AHB and TL BFMs respectively - both cocotb-AHB and cocotb-TileLink are available on GitHub.
A short snippet for TileLink slave testing using the TileLink Cocotb BFM is shown below:
# Create simulated master for TileLink
TLm = SimSimpleMasterUL(bus_width).register_clock(dut.clk).register_reset(dut.rstn, True)
# Create interface to tested TileLink slave
TLs = DutMultiMasterSlaveUL(dut)
# Register slave in master
# Register master in slave
# Start main loops of master and slave
# Issue read stimuli to DUT using simulated master
# Get slave response to given stimuli
before = TLm.get_rsp(0)()
# Issue write stimuli
TLm.write(0x2000, 4, 0xff00ff00, 0xa)
# Issue read stimuli once again
# Get slave response
after = await TLm.get_rsp(0)
# Request master finish and wait for finish
As part of developing the BFMs, Antmicro also created load generators and simple endpoints for the TileLink and AHB buses, as well as tests checking the model behavior against TileLink Uncached Lightweight and AHB specification respectively.
Currently, the open source bridges and BFMs support TileLink Uncached Lightweight, however Antmicro’s future efforts may include adding support for the remaining TileLink versions (TL-UH and TL-C) as well, as we continue to help customers innovate by adopting open source IP and tools in their ASIC design work.
Antmicro offers comprehensive services and expertise spanning the entire ASIC lifecycle, including software-driven prototyping, verification and custom open source tools. If you’re interested in learning more about how Antmicro can help in your next ASIC project, reach out to us at firstname.lastname@example.org.