Table of Contents

Table of Contents

Introduction

TileLink Architecture

Agents

Channels

Transaction Flows

Concurrency

Channel Signal Descriptions

Acquire

Probe

Release

Grant

Finish

Parameters

Introduction

TileLink is a protocol designed to be a substrate for cache coherence transactions implementing a particular cache coherence policy within an on-chip memory hierarchy. Its purpose is to orthogonalize the design of the on-chip network and the implementation of the cache controllers from the design of the coherence protocol itself. Any cache coherence protocol that conforms to TileLink’s transaction structure can be used interchangeably with the physical networks and cache controllers we provide.

TileLink is roughly analogous to the data link layer in the IP network protocol stack, but exposes some details of the physical link necessary for efficient controller implementation. It also codifies some transaction types that are common to all protocols, particularly the transactions servicing memory accesses made by agents that do not themselves have caches with coherence policy metadata.

TileLink Architecture

Agents

TileLink assumes a Client/Manager architecture where agents participating in the coherence protocol are either:

• clients requesting access to cache blocks, or
• managers overseeing the propagation of cache block permissions and data

A client may be a cache, a DMA engine, or any other component that would like to participate in the coherent memory domain, regardless of whether or not it actually keeps a copy of the data locally. A manager may be an outer-level cache controller, a directory, or a broadcast medium such as a bus. In a multi-level memory hierarchy, a particular cache controller can function as both a client (wrt. caches further out in the hierarchy) and a manager (wrt. caches closer to the processors).

Channels

TileLink defines five independent transaction channels. These channels may be multiplexed over the same physical link, but to avoid deadlock TileLink specifies a priority amongst the channels that must be strictly enforced. Channels may contain both metadata and data components. The channels are:

• Acquire. Initiates a transaction to acquire access to a cache block with proper permissions. Also used to write data without caching it.
• Probe. Queries a client to determine whether it has a cache block or revoke its permissions on that cache block.
• Release. Acknowledgement of probe receipt, releasing permissions on the line along with any dirty data. Also used to voluntarily write back data.
• Grant. Provides data or permissions to the original requestor granting, access to the cache block. Also used to acknowledge voluntary Releases.
• Finish. Final acknowledgement of transaction completion from requestor, used for transaction ordering.

At present time, all channels are routed from clients to managers or from managers to clients. (In the future, client-to-client Grants may be added.)

The prioritization of channels is Finish >> Grant >> Release >> Probe >> Acquire. Preventing messages of a lower priority from blocking messages of a higher priority from being sent or received is necessary to avoid deadlock.

Transaction Flows

There are two types of transaction that can occur on a cache block managed by TileLink. The first type enables clients to acquire a cache block:

• A client sends an Acquire to a manager
• The manager sends any necessary Probes to clients
• The manager waits to receive a Release for every Probe that was sent
• The manager communicates with backing memory if required
• Having obtained the required data or permissions, the manager responds to the original requestor with a Grant
• Upon receiving a Grant, the original client responds to the manager with a Finish to complete the transaction

The second type of transaction is supports clients voluntarily releasing a cache block:

• A client sends a Release to a manager, specifying that it is voluntary
• The manager communicates with backing memory if required
• The manager acknowledges completion of the transaction using a Grant

Concurrency

TileLink does not make any assumptions about the ordering of messages sent point-to-point over particular channels. Therefore, concurrency must be managed by agents at several points in the system.

• A manager should not accept a request for a transaction on a block that is already in-flight for a different client (unless it knows how to merge the two transactions as discussed below). Specifically, the manager must wait until it has received a Finish from the original client in order to ensure proper ordering of any future Grants.
• If client has an outstanding voluntary writeback transaction, it cannot respond to an incoming Probe request on that block with Releases until it receives a Grant from the manager acknowledging completion of the writeback.

Transactions can be merged in certain situations. One specific situation that must be handled by all manager agents is receiving a voluntary Release for a block which another client is currently attempting to Acquire. The manager must accept the voluntary Release as well as any Releases resulting from Probe messages, and provide Grant messages to both clients before the transaction can be considered complete.

When running on networks that provide guaranteed ordering of messages between any client/manager pair, the Finish acknowledgment of a Grant (and the Grant acknowledgement of a voluntary Release) can be omitted.

Channel Signal Descriptions

This section details the specific signals contained in each channel of the TileLink protocol.

Every channel is wrapped in the Chisel.DecoupledIO interface, meaning that each contains ready and valid signals as well as the following signals. Channels with data may send the data over multiple beats; the width of the underlying network is exposed to improve the efficiency of refilling data into caches whose data array rows are of a matching size.

Acquire

Initiates a transaction to acquire access to a cache block with proper permissions. Also used to write data without caching it (acquiring permissions for the write as it does so).

There are seven built-in types of Acquire that are available to all clients that want to participate in the coherence protocol, even if they themselves will not keep cached copies of the data. Because these transactions do not create a new private copy of the targeted cache block, they are termed “uncached” transactions. The available uncached transactions are as follows:

• Get: Fetches a single beat of data from a cache block and returns only that beat
• GetBlock: Fetches an entire cache block and serves it back to the requestor.
• GetPrefetch:  Prefetches a cache block into the next-outermost level of the memory hierarchy with read permissions
• Put: Writes up to a beat’s worth of data to backing memory. Uses a write mask to determine which bytes contain valid write data
• PutBlock: Writes out an entire cache block to backing memory
• PutPrefetch:  Prefetches a cache block into the next-outermost level of the memory hierarchy with write permissions
• PutAtomic: Performs an atomic memory op in the next-outermost level of the memory hierarchy. The maximum available operand size is 64b (sizes and opcodes per RISC-V atomic instructions).

The PutBlock message is unique in that may contains multiple beats of data (if the cache block size is larger than TLDataBits). The client controller that generates this message is responsible for generating multiple sequential PutBlock messages and incrementing the addr_beat field as it does so.

Probe

Queries an agent to determine whether it has a cache block or revoke its permissions on that cache block.

Release

Acknowledgement of probe receipt, releasing permissions on the line along with any dirty data. Also used to voluntarily write back data or cede permissions on the block.

Release messages may contains multiple beats of data (if the cache block size is larger than TLDataBits). The client controller that generates this message is responsible for generating multiple sequential Release messages and incrementing the addr_beat field as it does so.

Grant

Provides data or permissions to the original requester granting, access to the cache block. Also used to acknowledge voluntary Releases.

There are five built-in types of Grant that are available to all managers that want to participate in the coherence protocol. Because “uncached” transactions do not create a new private copy of the targeted cache block, we use these Grant types mostly as acknowledgements. The available types are as follows:

• GetDataBlock: Full cache block in response to Acquire.GetBlock
• GetDataBeat: Single beat of data in response to Acquire.Get or Acquire.PutAtmoic
• PutAck: Acknowledgement of Acquire.{Put, PutBlock}
• PrefetchAck: Acknowledgment of Acquire.{GetPrefetch, PutPrefetch}
• VoluntaryAck: Acknowledgement of any voluntary Release

The GetDataBlock message may contains multiple beats of data (if the cache block size is larger than TLDataBits). The manager controller that generates this message is responsible for generating multiple sequential GetDataBlockmessages and incrementing the addr_beat field as it does so.

Finish

Final acknowledgement of transaction completion from requestor, used for transaction ordering.

Agent-Specific Views of TileLink

For the convenience of designers implementing Client and Manager agents, we provide TileLinkNetworkPort modules which abstract away the details of the on-chip network implementation. These network ports automatically generate networking headers, perform SerDes for narrower physical network channels, and generate appropriate control flow logic. The ports then expose simplified subsets of the TileLink channels to the agent modules.

ClientTileLinkIO consists of standard Acquire, Probe, Release, and Grant message channels. It does not include the Finish channel as generating those acknowledgements is handled by the ClientTileLinkNetworkPort. ManagerTileLinkIO consists of Acquire, Probe, Release, and Grant message channels that have additional data appended about the source or destination of messages, expressed in terms of the Client’s id. It does include a Finish channel so that the manager knows when to register the transaction as complete.

Parameters

This section defines the parameters that are exposed by the TileLink to the top-level design. All agents that implement TileLink should either work for all values of these parameters within the specified ranges, or should add Chisel.Constraints to the design to define functional limits on hem.