1. CHI协议到底有什么用---片上互联0

1. CHI协议到底有什么用—片上互联0

1.1Architecture layer

看了协议的众所周知，chi有三层layer： Protocol，Network 以及Link。文中介绍如下：

读完这里的解释，我曾经想过放弃，曾经想过自己是不是不太合适学这个。幸运的是，贫穷让我为了不丢掉饭碗，不就是看不懂吗，硬看。

然后个人理解如下：
以一个最简单的例子为例子：

1.1.1Protocol

Protocol是最top的协议层，那它是如何当top的呢。假设上图中CPU要从DDR Controller读一个数据。那就是CPU先要发一个读请求的操作，那么CHI协议定义了，你可以发一个Readonce，也可以发一个Readshared等等的读请求，同时，你DDR Controller要通过一个叫做CompData的操作回复给CPU。
这就是Protocol主要干的事情了
1）定义了一些“transaction”的操作，比如读有ReadOnce，ReadShared，写有WriteClean，WriteNoSnpPtl等等好多的transaction。为什么要定义这些transaction呢，可往后面看。大致原因跟目录里面讲的实现各个组件保证cache一致性的基本读写，增强功能，提高性能。

2）再定义这些“transacton”的流程，比如说下面这张图，假设RN-F是CPU，ICN是L1 cahce，SN是DDR Controller。cpu要读一个数据，要发一个Snoopable Read的transaction给L1 cache，L1要发一个ReadNoSnp的transaction给DDRC，DDRC可以直接回一个CompData的transaction给CPU。你CPU读一个数据，整个系统一定要遵循这些流程来跑，这就是Protocol层要干的事情。（下面这张图看不懂的，可以看原协议，里面有讲怎么看）

其实Protocol层是看懂chi协议最重要的东西了，只要看到上面这种图，那就是在将Protocol层的内容。它主要是定义了一些东西，跟怎么实现是没有关系的。比如说你发一个ReadNoSnp操作怎么发给DDRC，里面要包含哪些内容，Protocol是不管的。比如还是上面这张图，它只管你读数据你可以发一个Read的req transaction，收完数据了你必须回一个CompAck transaction。
希望罗里吧嗦能讲清楚我知道的东西。

1.1.2 Link Layer

接着我们先讲Link Layer，如果说Protocol是top层纯软的定义协议的东西，那么Link Layer层就是纯纯硬的硬件层。多硬呢，就是你在eda仿真，把各个模块之间连接的接口的信号拉到verdi来看，看到的就是link层的信号。
Link层定义的信号，那都是实现到RTL里面实实在在的信号。这也是为啥先讲Link的原因

如下图，我们还是要CPU从DDRC读一个数据回来，假设我们要发一个ReadOnce的一个读操作，怎么搞呢。

一个CHI硬件接口（RN）应该包含图上的这些，叫做“channel”，一共有这6个，一共包含4种channels：REQ，RSP，DAT，SNP。这些channels对CPU或者DDRC来说，可以看做是6个不同的reg或者是6组不同的reg。这些Reg上面存的数据呢，是由好多信息拼成的，比如说对于TXREQ。
包含这么一组reg

最重要的就是reqflit这个“reg”了，这里面有啥呢，这个reg又包含了很多信息，简单说一下几个平时看的比较多的。
在chi组成soc系统中，会给每个组件根据地址分配一个nodeid，在上面的例子，我们就给CPU分配一个0x11，给DDRC分配一个0x22（这就是架构师干的活吗，哈哈哈哈h）。
所以回到我们要CPU读一个数据，CPU要在REQ通道，发出一个Readonce的transaction到DDRC。
我们就知道TgtID就是目标ID，就是DDRC的ID，也就是0x22.(下图中的第二列说TgtID的width是7-11，所以架构师应该也要给Tgtid订个位宽，我们就订8吧hhh)
然后SrcID就是CPU自己，也就是0x11
TxnID是当前这个操作的编号，我们从0x000开始，这个呢，意思就是说假设CPU同时要读10个数据，要发10个不同请求出去，这个ID就是请求的ID，等到这个请求全部结束之后，这个ID才能释放给下个请求用。
然后Opcode，这个玩意也是很重要的，这个决定了你发的是Readonce呢，还是Readshared，具体查表，看下面一张图，那我们要发ReadOnce，所以Opcode就是0x03
Addr和Size就不多说了，你访问个数据不得告诉人家地址嘛。


至于其他的东西，包括其他的channel就不一一赘述了，都差不多。把CPU读数据的流程讲完。
CPU的TXREQ里面的东西都填完了（就是那些id啊，opcode啥）就可以把这个REQ发给DDRC，然后根据Protocol我们知道，DDRC要回复一个“CompData”的transaction，DDRC就会在DAT channels把数据回给CPU了，紧接着，CPU还得在RSP通道返回一个“CompAck“的transaction。啊，这下CPU这个读操作就算是完成了。可不容易。
值得注意的是，这些SrcID，TgtID,TxnID,Opcode，不是只在REQ通道里面才有，在这些DAT通道，RSP通道，都有这些域段信息。在CHI中，这中间每一笔的Transaction都是独立的。

夜色已晚，明天再更Network 层
1.1.3 Network Layer
上面说了Protocol以及link，接着说不软不硬的中间层Network layer。原协议解释，Network是用来打包信息的，中间传输的单位叫做“packet”，协议中对这个packet解释是：

哎呀，看完了这个解释，懂得自然懂。不懂呢，看完了也不懂。还举了一个例子，一个Data response可以由1-4个packet组成，每个packet包含source id，destination id等等。那么这个跟我link layer里面的东西有什么不同，一个data response里面可以有4个source id和4个destination id吗？？？有理解这段的朋友们，可以找我聊聊呀。

通读整个协议之后，我的理解是这样子的，什么叫做不软不硬呢。cpu要读一个数据，chi规定你要发一些transaction，这是top的纯软。link层相当于硬件的cpu跟DDRC的接口，那接口里面的这些srcid，destid，opcode等东西从哪里来呢？诶！！这些东西从Network层来的！那Network怎么生成这些东西，这里会有地址映射，是指地址到tgtid的映射，比如地址0x000~0x100 =》tgtid：0x00，0x100~0x200 =》tgtid：0x11。那你要访问一个0x101的地址tgtid，自然就是0x11了。
比如说在下面的Data的Packets，chi定义了你需要生成以下这些信息（部分），然后这些packets就可以送到link层的DAT通道去。

1.1.4 Architecture Layer总结
还是一样，假设CPU要从DDRC读一个数据
Protocol层呢：定义了很多transaction，你可以根据需要选。同时呢，每种transaction的流程也已经定义好了。
Network层呢：你已经选好了transaction的种类，知道了要访问的地址是什么，就会生成packet，包括srcid，tgtid等等的信息，把它交给link layer
Link层呢：更像是一个接口，从Network拿到需要的数据，从channels里面发出去，以及收一些信息。