We are thrilled to share the details of our recent project, where we successfully integrated Tile Link UH (Ultra High) into the Caravan framework. Tile Link UH, an extended protocol of Tile Link UL, brought new capabilities and improved performance to the framework by introducing atomic and hint operations, along with support for burst messages. In this blog, we will provide a more detailed account of our journey, from understanding Tile Link UH to addressing integration challenges and conducting thorough testing and verification.
What is Caravan?
Caravan aims to provide a unified framework for all Chisel based bus protocols that are supported to work on the FPGAs as well as on the ASIC flow.
Caravan makes it easier to
- re-use pre-made bus implementations instead of creating your own
- generate any major (AMBA, Wishbone, TileLink) bus implementation of your choice
- an abstract unified interface to integrate any bus protocol with your design
Fig 1 Architecture for Caravan
As can be seen in fig1, Caravan is implemented as an Adapter architecture. Where we have a host adapter and a device adapter. In between the two adapters lie the bus protocol. On either side we have general IOs which are not bus specific.
How to use Caravan?
Instruction memory and Data memory are connected to the host via TilelinkAdapters. Inorder to create TilelinkAdapter Interface, we have to use the TileLinkAdapter module to connect Host and Device interfaces. TilelinkAdapter has bundles specific to Host and Slave devices(generic interface for all bus protocols).
The code snippet below, shows how we can connect the host and slave devices across the adapter interface.
Note: In order to use Caravan framework, users should ensure that the generic interface of caravan is mapped to the IOs of Host and Save devices being used by the user.
Understanding Tile Link UH:
TileLink is a standard interconnect for chips that enables multiple masters to have coherent memory-mapped access to memory and other slave devices at a chip level.
TileLink Uncached Lightweight (TL-UL) is the basic level of compliance in the TileLink standard. It is specifically designed for low-performance peripherals to reduce chip area. TL-UL supports two types of memory access operations: Get and Put.
The Get operation allows agents to read a certain amount of data from the underlying memory. On the other hand, the Put operation enables agents to write a specific amount of data to the underlying memory. Additionally, the Put operation allows for partial writes with a byte-level write mask, providing flexibility in specifying which bytes are modified during the write operation.
Tile Link UH extends the capabilities of Tile Link UL, a widely used bus protocol in the field of computer architecture. The primary motivation behind integrating Tile Link UH into the Caravan framework was to leverage its advanced features and enhance the overall functionality of the framework. Tile Link UH introduces two new types of operations: atomic and hint operations.
Atomic Operation
In atomic operation we have two data values, First is the data value which is carried by message. Second is the extant data value which is at target address. These two values are required to perform either ARITHMETIC or LOGICAL operation. After the operation the new value is written at the same address while simultaneously returning the old data value to the requestor.
Atomic operation has two sub class operations
- Arithmetic operations.
- Logical operations
There are 5 types of arithmetic operation which are as follows
- MIN: Write a signed minimum of two operands and return the old value.
- MAX: Write a signed maximum of two operands and return the old value.
- MINU: Write an unsigned minimum of two operands and return the old value.
- MAXU: Write an unsigned maximum of two operands and return the old value.
- ADD: Write the sum of two operands and return the old value.
There are 4 types of logical operation which are as follows
- XOR: Bitwise logical xor the two operands, write the result, and return the old value.
- OR: Bitwise logical or the two operands, write the result, and return the old value.
- AND: Bitwise logical and the two operands, write the result, and return the old value.
- SWAP: Swap the two operands and return the old value.
Hint Operation
In hint operations, first the INTENT message is transferred by the master and then HINTACK message is responded by the slave.
The intent message, initiated by the requester, indicates the requester’s future intentions for a specific block of data. For instance, when a requester sends an intent message of PreFetchWrite for a data block on a particular clock cycle, it signifies that the requester plans to send a PUT message (either PUT PARTIAL DATA or PUT FULL DATA) for the same data block in a subsequent clock cycle. Similarly, the same logic applies to PreFetchRead, where the requester intends to send a GET message for the data block on a future clock cycle.
Implementing Atomic Operation:
Atomic operations are essential for performing read-modify-write operations atomically on a specific memory block. In our implementation, we focused on two sub-class operations: arithmetic and logical. Leveraging the signals on the A channel, we successfully implemented arithmetic operations such as minimum, maximum, addition, and more. Similarly, logical operations like XOR, OR, AND, and SWAP were implemented to manipulate data and return the previous values.
A state machine is introduced in the Tilelink Device Adapter. The state machine consists of three states namely, idle, uh & waitResponse.
Fig 2 State Machine Logic
| STATE | FUNCTIONALITY |
|---|---|
| idle | Address sent to memory to perform READ |
| uh | The read data is MODIFIED and WRITTEN back to same memory location |
| waitResponse | In this state the old data value is responded to the host |
We should not ignore the fact that this state machine would be active only in case of atomic operations, in any other case the TL-UL methodology is followed.
Hint Operation and Intent Messages:
Hint operations in Tile Link UH allow us to send intent messages, indicating future intentions for a specific data block. This feature is particularly useful for optimising memory accesses and improving performance. We implemented various intent messages, including PreFetchRead and PreFetchWrite, to signal future operations such as GET or PUT. By utilising the specified signals on the A channel, we effectively conveyed these intentions to the receiving components.
Stabilising TL-UL in the Existing Framework:
Integrating Tile Link UH into an existing framework like Caravan comes with its challenges. We encountered issues related to address handling, data response, ready-valid signals, abstract classes, and dummy memory. These issues needed careful analysis and resolution to ensure the smooth integration of Tile Link UH into the Caravan framework. Through collaborative problem-solving and diligent debugging, we were able to stabilise the Tile Link UH protocol within the existing framework, ensuring its compatibility and proper functionality.
Difference between TL-UL and TL-UH:
The major difference between TL-UL and TL-UH is that TL-UL supports only Get and Put operations while TL-UH supports Atomic and Hint operations in addition to Get and Put supported by TL-UL.
Also, there is support for Burst messages in TL-UH. Burst messages in TileLink refer to multi-beat messages where the data payload is spread out across multiple clock cycles. Depending on the size of the message and data bus, the data payload may be transmitted in consecutive beats.
Addressing Integration Challenges:
While integrating Tile Link UH, we faced specific challenges unique to this protocol. One of the major challenges was determining whether a received message corresponded to an atomic or hint operation, as well as identifying burst messages. To overcome this challenge, we introduced new pins and conditional logic to map the received inputs to the appropriate operations. This involved careful analysis of the protocol specifications and architectural considerations, ensuring that the integration met the required functionality.
Fig 3 Issue in Host Adapter
Fig2 shows the major issue faced, where we fell short of generic pins to map a_opcode and a_param. Hence, we came up with 5 conditional pins to resolve the above issue. The pins are isArithmetic, isLogical, isIntent, param, size. The functions of these pins are depictive as per their names.
Fig 4 Updated Host Adapter
Fig3 shows new IOs added in order to map a_opcode and a_param. It should be noted that these IOs are considered only when uh(Uncached Heavyweight) is 1.
Testing and Verification:
To ensure the reliability and correctness of our integration, we conducted rigorous testing and verification processes. We designed comprehensive regression tests that covered various scenarios, including burst operations involving PUT, atomic operations, and GET. Finally, we conducted compliance tests on NucleusRV core to validate the integrated protocol.
Conclusion:
Integrating Tile Link UH into the Caravan framework was a challenging yet rewarding journey that expanded the capabilities of the framework. By successfully implementing atomic and hint operations, addressing integration challenges, and conducting thorough testing and verification, we achieved enhanced functionality and improved performance. The integration of Tile Link UH opens up new possibilities for leveraging its advanced features within the Caravan framework and paves the way for future advancements. We are proud of our team’s efforts and the collaborative spirit that drove this project to success.
We hope this detailed account of our project provides valuable insights into the process of integrating Tile Link UH into the Caravan framework. If you have any further questions or would like to learn more about our project, please feel free to reach out. Stay tuned for more exciting updates as we continue our journey of innovation and integration.