My journey of Google Summer of Code 2023.

I recently had the incredible opportunity to participate in Google Summer of Code (GSoC) program, collaborating with MERL (Micro Electronic Research Laboratories) on a fascinating project called azadi-soc. The main objective of this project was to upgrade from TileLink Uncached Light-Weight (TL-UL) to TileLink Uncached Heavy-Weight (TL-UH), which introduces three additional operations: burst, intent, and atomic. In this blog post, I will summarize my work throughout the GSoC program and share my experiences and learnings.

SoC Architecture

System-on-Chip (SoC) architecture refers to the design approach where all the necessary components of a computer system are integrated onto a single chip. This includes the processor, memory, input/output interfaces, and other peripherals. SoC architecture aims to optimize performance, power consumption, and cost by consolidating these components into a single chip.

In the SoC architecture, the TileLink bus is typically implemented as an interconnect fabric that connects various components within the chip. It serves as a high-bandwidth communication channel for transferring data between different modules such as the CPU, memory controllers, accelerators, and peripherals.

Bus protocols

A bus in computer architecture refers to a communication pathway that allows multiple devices or components within a computer system to exchange data and control signals. It acts as a shared medium through which information can be transferred between different modules.

Some famous bus protocols used in various computer systems include: — Advanced High-performance Bus (AHB): AHB is a widely used bus protocol developed by ARM Holdings. It provides a high-performance interface between different modules in an SoC design. — Wishbone: Wishbone is an open-source bus protocol commonly used in FPGA-based designs. It offers flexibility and simplicity for connecting IP cores within an FPGA. — Advanced eXtensible Interface 4 (AXI4): AXI4 is another popular bus protocol developed by ARM Holdings. It provides high-performance interconnects for on-chip communication in complex SoC designs. — ACE (AXI Coherency Extensions): ACE is an extension of the AXI4 protocol that adds cache coherency support. It allows multiple processors or cores to share a common cache and maintain data consistency. — Cache coherent interconnect for accelerators (CHI): CHI is a high-performance, cache-coherent bus protocol developed by ARM Holdings. It is designed to enable efficient communication between multiple processors and accelerators in complex SoC designs. — TileLink: An open-source scalable cache-coherent fabric protocol designed specifically for SoC architectures. It provides efficient interconnectivity between IP blocks while supporting various levels of caching.

Features of TileLink Bus Protocol over other protocols

Understanding TileLink protocol

Before diving into the project, it was crucial to gain a comprehensive understanding of the TileLink protocol. I researched its architecture, explored its various components, and familiarized myself with its existing features and limitations. This foundational knowledge served as a solid base of my subsequent work.

What is TileLink?

TileLink is a chip-scale interconnect standard providing multiple masters with coherent memory-mapped access to memory and other slave devices. TileLink is designed for use in a System-on-Chip (SoC) to connect general-purpose multiprocessors, co-processors, accelerators, DMA engines, and simple or complex devices, using a fast scalable interconnect providing both low-latency and high-throughput transfers.

TileLink conformance levels

The TileLink specification includes three conformance levels for attached agents, which indicates which subset of the protocol they must support as shown in the table below.

TileLink conformance level

TileLink Uncached Light-Weight (TL-UL)

This is the simplest conformance level of the TileLink protocol. TL-UL agents can perform two kinds of operations. They are both related to accessing memory:

Get operation: Read some data from the memory.

Put operation: Write some data to the memory and the write can have a partial byte mask.

The following table shows the request and response messages available in this protocol. There are 3 request message types (Get, PutFullData, PutPartialData) and 2 response message types (AccessAckData, AccessAck).

TL-UL messages

TileLink Uncached Heavy-Weight (TL-UH)

TL-UH is intended for use beyond the outermost cache layer, where no permission transfer operations are required. It builds on TL-UL by providing additional operations:

Atomic operation. Atomically read and return the extant data value while simultaneously writing a new value that is the result of some logical or arithmetic operation.

Hint operation. Provide an optional hint related to some performance optimization.

Burst messages. Allow messages with data larger than the width of the physical data bus to be transmitted as bursts occurring over multiple cycles. Applies to various data-containing messages within the Get, Put and Atomic operations.

So, there are three request messages and one response message added by TL-UH to the messages defined for TL-UL

TL-UH messages

Designing the upgrade strategy

Burst operation

• Used when the message contains data larger than the width of the physical data bus.
• Allows operations to target larger address range.
• Any message that carries data payload can be a burst message.
• The beats of the burst message are serialized, and they are sent in order.
• The message is identified to be burst or not by the size parameter contained in the message.
• For example, if the size parameter is only 2 bits. So, the max value it can take is 3 and this size is in the form of log2(data width), therefore the max data width is 2³ = 8 bytes. And if the data bus width is 4 bytes, then this means that the max number of beats in a burst message is 8 / 4 = 2 beats.

Atomic operation

• This operation allows the agent to do 3 operations in an atomic way: Get: to read the data from the memory, Calculate the result: according to the desired requested operation, put: to write the result in the memory.
• Request and response messages are as follows:

• Arithmetic operations:

• Logical operations:

• The operation requires two operands: one is the data carried with the atomic message, and the other is the existing data value at the target address. Upon completion, this operation provides a copy of the original data to the requester.
• To execute this operation, I created two units: an arithmetic unit and a logical unit. Both units are integrated into a top module called ALU. Additionally, there is an input signal that determines which unit to activate based on the request.
• The message flow to perform an atomic memory access operation is as follows:

Intent operation

• These operations allow the agent to send some hints about the data.
• It is used mainly to increase the performance. As the hint instruction could tell the cache that data being fetched will be used only once, so put this data at the front of the eviction list. Once the data is used by the host, the data will get evicted from the cache and the location will become available. But actually, TL-UH responsibility is no more than transferring this message from the master to the slave and then transferring the acknowledgment signal back to the master from the slave.
• Request and response messages are as follows:

• The types of intent operation:

• The message flow to perform the intent operations is shown in the figure below.

TL_UH Components

Current implementation contains the following communication blocks.

TL-Host Adapter module

• This module is connected with the host’s external interface and manages and converts host signals to TLUH protocol.
• To upgrade this module from light-weight version to heavy-weight version, we have to let it support burst, atomic and intent operations.
• For the burst operations, we have to consider 3 cases: Burst responses, burst requests and burst requests & responses.
• Burst Responses: When sending a GET request message, it is important to note that it does not carry a data payload. As a result, the request will always be a single beat, regardless of the size of the requested data. To determine whether the response will be burst or not, we need to check the size of the data that the host wants to retrieve. If it can fit on a single beat, then it will be a non-burst response. However, if it exceeds the capacity of a single beat, it will be a burst response. After sending the initial single beat request, we must wait indefinitely for the response message beats.
• Burst Requests: On the other hand, when dealing with PUT messages, they do carry a data payload and can be burst. However, the response to these requests is just a single acknowledge beat to ensure that the data is written correctly in the target device. To determine how many beats are required for writing data, we need to check the size parameter associated with it. After sending the first beat of data in a burst request, we should be prepared to receive an acknowledgment message as a response in any subsequent clock cycle. It is crucial for our implementation to accept concurrent AccessAck messages even before completing sending all Put messages. We may choose to buffer these AccessAck messages until completion.
• Burst Requests & Responses: When dealing with atomic operations that consists of a request message and a response message that both carry data, it is important to consider the size of the data payload. If a request is burst, the corresponding response will also be burst. To determine the number of beats to send as a response, we need to examine the size of the data on which the operation is applied. It is crucial to note that response beats may experience arbitrary delays. In most cases, these delays will be at least as long as it takes to accept the corresponding beats of the request message. Furthermore, there can be instances where there is either a significant delay between request and response messages or overlapping beats for both.
• To handle the above 3 scenarios effectively, we can implement two counters: one to track sending beats and another to track receiving beats. Additionally, when a request comes from the host, we need to determine whether it is a new request or a beat of an existing one.
• For atomic and intent operations, this module’s role is limited to sending the request and operation information. The target device will then take appropriate action based on this information.
• The code for this module (in sub/tluh/src folder): Link.

TL-SRAM Adapter module

• This module is connected with SRAM/memory devices. It manages read/write requests for SRAMs and converts SRAM signals to TLUH protocol. It optionally converts the host byte mask to a bit mask for SRAM having bit-masked access. It is done by the byte mask parameter.
• It has response FIFO to hold the responses which carry data payload in case the host is not ready to receive it yet. It also has requests FIFOs to hold the requests until it served successfully. The depth of the request FIFO is equal to the value assigned to the parameter outstanding. And for the response FIFO, its depth is equal to the outstanding multiplied by the max number of beats in a burst response which is in our case equal 2.
• In order to upgrade this module, we have to implement the 3 features added in the heavyweight version of the TileLink.
• Burst: Check both the size and type of the request in order to determine the number of beats required for a response.
• Atomic: Add an ALU (Arithmetic Logic Unit) unit to perform the arithmetic and logical operations requested by the sender.
• Intent: Simply send the type of intended operation and the block size of the data on which the intention is applied to the SRAM.
• The code for this module (in sub/tluh/src folder): Link.

TL-Reg Adapter module

• This module is connected with Register based devices like GPIO, UART, etc. Just like a host adapter it manages and converts device signals to TLUH protocol.
• Like the TL-SRAM Adapter, this module should support burst, atomic and intent operations.
• Burst: Check both the size and type of the request in order to determine the number of beats required for a response.
• Atomic: Add an ALU (Arithmetic Logic Unit) unit to perform the arithmetic and logical operations requested by the sender.
• Intent: Simply send the type of intended operation and the block size of the data on which the intention is applied to the target register.
• The code for this module (in sub/tluh/src folder): Link.

TL-error module

• This module is connected to both the TL-Reg Adapter and the TL-SRAM Adapter modules to check for the validity of the coming requests. In other words, it is used to check the validity of the A channel.
• It checks the following: — opcode. — ‘A’ channel configuration. — Operation parameter.
• opcode check: it should be one of the following: — PutFullData — PutPartialData — Get — ArithmeticData — LogicalData — Intent
• A channel configuration check: — address and size alignment check — inactive lane a_mask check — PutFullData should have size match to mask
• Operation parameter check: — PutFullData: 0 — PutPartialData: 0 — Get: 0 — ArithmeticData: MIN, MAX, MINU, MAXU, ADD — LogicalData: XOR, OR, AND, SWAP — Intent: PrefetchRead, PrefetchWrite
• The code for this module (in sub/tluh/src folder): Link.

Hint: In burst requests, the address remains fixed for all the request message beats. Therefore, it is the target device’s responsibility to increment it.

Hint: I made a separate testbench for each of the three basic modules to check their behavior and ensure they work as expected.

The block diagrams

The following are links for the block diagrams.

• tluh_host_adapter
• tluh_adapter_reg
• tluh_sram_adapter

The documentation

Here you can find a documentation for the project illustrating some important signals in each module: Link.

Tools

I used ModelSim to compile and simulate my code.

The code

You can find the code for project through this link: Link.

Future work

• Make this bus protocol parametrizable so that we can switch to either TLUL or TLUH whenever we want by simply changing the parameters in the RTL.
• Upgrade TLUH to TL-C. — A cache unit will be added so that the design will be more efficient and faster. — Instead of using only 2 channels A & D, 3 additional channels will be used which are B, C and F. — 3 new transfer operations will be added which are acquire, release and probe.

References

• https://static.dev.sifive.com/docs/tilelink/tilelink-spec-1.7-draft.pdf
• Integrating Tile Link UH in the Caravan Framework: A Journey of Enhanced Functionality — RISC-V International (riscv.org)