tilelink

Introduction

TileLink是一种为SoC设计的互联总线,类似于AMBA总线。它能够保证cache的一致性,并且验证了不会出现死锁。支持MOESI等价协议。

协议包括三个子协议:TL-UL,TL-UH,TL-C。UL只支持单拍的读写操作;UH支持多拍读写操作,原子操作,Hint操作;C支持cache一致性。

Topology

最基本的拓扑结构是,一个master和一个slave,master给slave发请求,slave回响应给master。

也可以构造多个master和多个slave通过crossbar互联起来,crossbar负责转发。下图中,processor可以发送请求给crossbar,crossbar根据地址进行区分,该笔请求是发给cache的还是device的,从而分发出去;device或cache收到请求,回响应给crossbar,crossbar再转回给process;crossbar是根据source id来区分该笔响应是会给哪个processor的;这也就要求了发给cache或device的请求需要带有source id信息,而cache或device把请求中的source id填入响应中去。

Channel

TileLink接口有5组,分别是ABCDE。每组的方向如图所示。为了避免死锁,协议规定了每组channel的优先级,E>D>C>B>A。A通道的请求,D通道回;B通道的请求,C通道回;C通道的请求,D通道回;D通道的请求,E通道回。

Signal

clock reset

TileLink是同步总线协议,master和slave必须使用相同的时钟复位,当然不同的Links可以用不同的时钟复位。

时钟上升沿采样。复位高有效,也就是高的时候是复位的。复位拉高的时候是可以异步的,但是解复位,也就是拉低的时候,必须是时钟上升沿同步的。并且valid必须在复位期间拉低至少100个时钟。

Parameter

先看下几个参数,w代表总线数据位宽,单位是bytes。a代表地址数据位宽,单位是bits。z代表size位宽,单位是bits。o代表master的source位宽,标识是哪个master。i代表slave的sink位宽,标识是哪个slave。

Channel A

Channel B

Channel C

Channel D

Channel E

Notes

opcode和param就可以标识这是笔什么message,该消息想干什么。

size可以标识这笔消息会有多少数据,或者该消息想要多少数据。比如在put消息中,size就标识这笔数据会有多少拍;get消息中,size就标识希望拿多少数据。

source标识这笔消息的master是谁。所以在master往slave发的消息中,或者说ACE通道上,source就要master来填自己的id;而在slave往master发的消息中,也就是BD通道上,source就需要slave把收到的master来的request里的source填到respone里面去。

sink标识这笔消息的slave是谁。我们会发现ABC通道并没有sink,这三个通道应该是用address来区分要到哪个slave去。

valid和ready同时有效,才代表这拍数据有效。

不同message中的beat不能interleave,message和message可以interleave。也就是说,假如一个message有4拍数据,必须一次性发完这4拍,才能发另外一个message,不允许在前一个message还没发完的时候插入另外一个message的数据。这很好理解,因为在信号里,我们没有发现标识每个message id的信息。

只要request的第一拍被收到,就能够回response,即使这个request有多拍,也不用等所有数据都发完再回response。

Message

TL-UL

TL-UL是最轻量级的。它只有AD通道,只支持put和get消息,并且只支持单beat数据。master从A通道发送request,slave从D通道回应response。

putfull和putpartial的区别在与mask,putfull的mask必须连续,而putpartial的mask可以不连续。不过我感觉partial的需求好像比较少。需要看下RISCV ISA里面有没有操作部分数据的指令。

TL-UL因为不支持多beat,那就要求2^size必须小于等于数据位宽。

TL-UH

TL-UH在上面增加了Atomic、Hint和burst。同样还是只使用AD通道。