SiFive TileLink Specification v1.8.1: A Comprehensive Overview

需积分: 5 23 浏览量更新于2024-07-09 收藏 6.67MB PDF 举报

"TileLink是RISC-V架构中常用的一种片上互连协议，用于处理器、内存和其他系统组件之间的通信。这份文档详细介绍了TileLink规范的1.8.1版本，涵盖其架构、信号描述、序列化、死锁自由、操作和消息等方面，旨在为RISC-V系统的开发提供指导。" 在RISC-V架构中，TileLink是一种灵活且高效的通信协议，它定义了不同硬件组件如何高效地共享和传输数据。这份文档首先介绍了协议的符合性级别，这决定了一个设计必须遵循的协议部分，以及文档的大致内容概述。在“Architecture”部分，文档详细阐述了网络拓扑，解释了如何构建和连接不同的通道以形成通信网络。此外，还讨论了通道优先级，确保关键操作的优先处理。地址空间属性这部分描述了如何分配和访问系统中的地址空间。 “Signal Descriptions”章节详细解析了各种信号的命名规范，时钟、复位和电源管理。时钟部分讲述了如何同步网络中的组件，而复位和电源跨越则讨论了在不同电源域或时钟域之间交互时的处理策略。文档深入到具体通道（Channel A, B, C, D, E）的描述，这些通道有不同的功能，其中Channel A和D是强制性的，B, C, E是TL-Confined通道，用于特定的高级功能。 “Serialization”章节讨论了流控制规则，确保请求和响应的正确顺序。例如，对于突发（burst）响应和请求，有特定的排序规则，防止数据包的混淆。同时，该部分还涉及到与传统总线的接口，以及错误处理机制，以及如何处理字节 lane。 “Deadlock Freedom”部分解释了如何避免系统中的死锁问题，定义了相关术语，并通过实例展示了如何保证代理的合规性，构建代理图，并给出了向前推进的证明概要。 “Operations and Messages”章节详细列出了操作分类和消息分类，如地址映射、源和目标标识符，以及操作的顺序规则。这有助于理解不同操作的执行流程。最后，“TileLink Uncached Lightweight (TL-UL)”部分专用于轻量级的无缓存模式，解释了在这种模式下的流量和波形，以及TL-UL消息，如Get和PutF等操作，这些操作构成了基本的数据传输。这份文档提供了关于TileLink协议的详尽指南，对于理解和实现RISC-V系统中的数据交换至关重要。

Table 6. Channel A signals

Signal Type Width Description

a_code C 3

Operation code. Identies the type of message carried by the channel.

(

Table 12)

a_param C 3

Parameter code. Meaning depends on

a_opcode; species a transfer of

caching permissions or a sub-opcode. (

Section 7.2, Section 8.2, Section

9.3)

a_size C

Logarithm of the operation size: 2

bytes (Section 4.5)

a_source C

Per-link master source identier. (Section 6.4)

a_address C

Target byte address of the operation. Must be aligned to a_size.

(

Section 4.5)

a_mask D

Byte lane select for messages with data. (Section 4.5)

a_data D

Data payload for messages with data. (Section 4.5)

a_corrupt D 1 The data in this beat is corrupt. (Section 4.4)

a_valid V 1 The sender is offering progress on an operation. (Section 4.1)

a_ready R 1 The receiver accepted the offered progress. (Section 4.1)

3.4. Channel B (TL-C only)

Channel B flows from slave interface to master interface, carrying request messages sent to a

particular cached data block held by a particular master. This channel is used by the TL-C

conformance level and is optional in lower levels.

Table 7. Channel B signals

Signal Type Width Description

b_opcode C 3

Operation code. Identies the type of message carried by the channel.

(

Table 12)

b_param C 3

Parameter code. Meaning depends on ; species a transfer of caching

permissions or a sub-opcode. (

Section 9.3)

b_size C

Logarithm of the operation size: 2

bytes. (Section 4.5)

b_source C

Per-link master source identier. (Section 6.4)

b_address C

Target byte address of the operation. Must be aligned to b_size.

(

Section 4.5)

b_mask D

Byte lane select for messages with data. (Section 4.5)

b_data D

Data payload for messages with data. (Section 4.5)

b_corrupt D 1 Corruption was detected in data payload. (Section 4.4)

b_valid V 1 The sender is offering progress on an operation. (Section 4.1)

b_ready R 1 The receiver accepted the offered progress. (Section 4.1)

3.5. Channel C (TL-C only)

Channel C flows from master interface to slave interface. It can carry response messages to Channel B
requests sent to a particular cached data block. It is also used to voluntarily write back dirtied cached
data. This channel is used at the TL-C conformance level and is optional in lower levels.
Table 8. Channel C signals
Signal Type Width Description
c_opcode C 3
Operation code. Identies the type of message carried by the channel.
(
Table 12)
c_param C 3
Parameter code.  Meaning  depends  on  ;  species  a  transfer  of  caching
permissions. (
Section 9.3)
c_size C
z
Logarithm of the operation size: 2
n
 bytes. (Section 4.5)
c_source C
o
Per-link master source identier. (Section 6.4)
c_address C
a
Target  byte  address  of  the  operation.  Must  be  aligned  to  c_size.
(
Section 4.5)
c_data D
8w
Data payload for messages with data. (Section 4.5)
c_corrupt D 1 Corruption was detected in data payload. (Section 4.4)
c_valid V 1 The sender is offering progress on an operation. (Section 4.1)
c_ready R 1 The receiver accepted the offered progress. (Section 4.1)
3.6. Channel D (Mandatory)
Channel D flows from slave interface to master interface. It carries response messages for Channel A
requests  sent  to  a  particular  address.  It  also  carries  acknowledgements  for  Channel  C  voluntary
writebacks. This channel is used by all TileLink conformance levels and is non-optional.
Table 9. Channel D signals
Signal Type Width Description
d_opcode C 3
Operation code. Identies the type of message carried by the channel.
(
Table 12)
d_param C 2
Parameter code. Meaning depends on 
d_opcode; species permissions
to transfer or a sub-opcode. (
Section 7.2,Section 8.2,Section 9.3)
d_size C
z
Logarithm of the operation size: 2
n
 bytes. (Section 4.5)
d_source C
o
Per-link master source identier. (Section 6.4)
d_sink C
i
Per-link slave sink identier. (Section 6.4)
d_denied C 1 The slave was unable to service the request. (Section 4.4)
d_data D
8w
Data payload for messages with data. (Section 4.5)
d_corrupt D 1 Corruption was detected in the data payload. (Section 4.4)
d_valid V 1 The sender is offering progress on an operation. (Section 4.1)
d_ready R 1 The receiver accepted the offered progress. (Section 4.1)
3.7. Channel E (TL-C only)
16

4. Serialization

The ve channels in TileLink are implemented as ve physically distinct unidirectional parallel buses.

Each channel has a sender and a receiver. For the A, C, and E channels, the agent with the master

interface is the sender and the agent with the slave interface is the receiver. For the B and D channels,

the agent with the slave interface is the sender and the agent with the master interface is the receiver.

Many TileLink messages contain a data payload, which, depending on the size of the message and

data bus, may need to be spread out across multiple clock cycles (or

beats

). A multi-beat message is

often called a

burst

. TileLink messages without a data payload are always exchanged in a single beat.

It is forbidden in TileLink to interleave the beats of different messages on a channel. Once a burst has

begun, the sender must not send beats for any other message until the last beat of the burst has been

accepted by the receiver. The duration of a burst is determined by the channel’s

size eld.

Progress on an operation is regulated by the exchange of beats between sending and receiving agents

on a particular channel. The sender of a beat raises the channel

valid signal to offer the availability

of a beat on the channel. Receivers raise the

ready channel signal to indicate their ability to accept a

beat. The receiver lowers the

ready signal to indicate that they are busy and are not accepting a beat.

Only when both

ready and valid are raised concurrently is the content of the beat considered

exchanged.

The rest of this chapter lays out the flow control rules that govern when

ready and valid may be

toggled to exchange a beat of a message, and also denes rules for how request/response message

pairs can be ordered. We nally discuss interfacing with legacy bus standards, error handling, and how

bursted data is mapped onto a physical data bus of a particular width.

4.1. Flow Control Rules

In order to implement correct ready-valid handshaking, these rules must be followed:

If ready is LOW, the receiver must not process the beat and the sender must not consider the

beat processed.

If valid is LOW, the receiver must not expect the control or data signals to be a syntactically

correct TileLink beat.

valid must never depend on ready. If a sender wishes to send a beat, it must assert valid

independently of whether the receiver signals that it is

ready.

As a consequence, there must be no combinational path from ready to valid or any of the

control and data signals.

A low priority valid may not combinationally depend on a high priority valid. In other words,

the decision to send a request may not be based on receiving a response in the same cycle.

A high priority ready may not combinationally depend on a low priority ready. In other words,

acceptance of a response may not be made contingent upon a request being accepted the same

cycle.

Anything not forbidden is allowed. In particular:

It is acceptable for a receiver to drive ready in response to valid or any of the control and data

signals. For example, an arbiter may lower

ready if a valid request is made for an address

which is busy. However, whenever possible, it is recommended that

ready be driven

independently so as to reduce the handshaking circuit depth.

A channel may change valid and all control and data signals based on the value of ready in the

prior cycle. For example, after a request has been accepted (

ready HIGH), a new request may

be presented. Only a same-cycle dependency of

valid on ready is forbidden.

A device may legally drive valid for a response based on valid of a request in the same cycle.

For example, a combinational ROM which answers immediately. In this case, presumably

ready

for the request will likewise be driven by

ready for the response. The converse relationship is

forbidden.

Note that a sender may raise

valid and then lower it on the following cycle, even if the message was

not

accepted on the previous cycle. For example, the sender might have some other higher priority

task to perform on the following cycle, instead of trying to send the rejected message again.

Furthermore, the sender may change the contents of the control and data signals when a message

was not accepted.

On TileLink channels which can carry bursts, there are additional restrictions. A burst is said to be

progress

after the rst beat has been accepted and until the last beat has been accepted. When a

burst is in progress, if

valid is HIGH, the sender must additionally present:

Only a beat from the same message burst.

Control signals identical to those of the rst beat.

Data signals corresponding to the previous beat’s address plus the data bus width in bytes.

If the rst beat of data in a burst is rejected, the sender may choose to attempt a different message on

the following cycle (including initiating a different burst). If a beat of data of a burst that is already in

progress is rejected, the sender may choose to change the values of the data the next time the beat is

presented. However, whatever value of data is presented on the next valid beat will continue to

correspond to the same address, until some offered beat is accepted by the receiver. Only accepted

beats cause the burst to make progress through the address range associated with the beats of the

data payload. Control signals for a burst that is in progress must remain constant for all valid beats

until the burst is complete.

clock

a_ready

a_valid

a_opcode 0 0 0 0 0 0 4 0

a_size

5 5 5 0 6 2 4 1

F beat 0 F-1 F-1 F-2 F-3 G-0 H-0 I-0 J-0 K-0

剩余92页未读，继续阅读

吾心安处GZYYYYY

粉丝: 18
资源: 6

SiFive TileLink Specification v1.8.1: A Comprehensive Overview

LanguagePack TortoiseSVN_1.8.1 win64位 简体中文语言包

tilelink-spec-1.7.1-draft.zh.pdf

tilelink-spec-1.7-draft.pdf

labelimg windows_v1.8.1.zip

sentinel-dashboard-1.8.1.jar

shapely-1.8.1.post1-cp37-cp37m-win_amd64.whl is not a supported wheel on thi

如何下载jquert.min.1.8.1.js

generic-pc-1.8.1.iso下载

jquert.min.1.8.1.js

java: 读取D:\Maven2_repository\org\jvnet\staxex\stax-ex\1.8.1\stax-ex-1.8.1.jar时出错; error in opening zip file

最新资源

LanguagePack TortoiseSVN_1.8.1 win64位简体中文语言包