CHI网络层

网络层的主要功能是决定各个目的地节点的node ID,主要按照下面四个小结来描述。

1. System address map

系统中每个Requester(包括RN和HN)必须有一个System Address Map(SAM)来决定一个request的target ID。SAM的范围可能只是简单的为所有发送的requests提供一个固定的node ID。SAM具体的结构和格式是由具体实现决定的。
SAM必须可以对全地址空间进行解码,CHI协议建议所有没有对应物理组件的地址都应该分配个一个agent,该agent可以对这些无用地址的访问提供恰当的error响应。

2. Node ID

每一个连接到总线Port的组件都会被分配一个node ID,用于标识ICN上packets路由的源节点和目的节点。一个Port可以有多个node IDs,但是一个node ID只能分配给一个Port,CHI协议支持的NodeID域宽在7~11bits之间可变,由具体实现决定,且一个系统中所有组件的NodeID域宽必须一样,至于每个组件的NodeID值也是由具体实现决定的。

3. Target ID determination

本节描述对于不同的message types,如何决定target ID。可以从request messages、response messages和snoop request messages三个方面来阐述。
Request messages的Target ID的确定:
为了对RN的request的TgtID进行映射,CHI协议要求SAM逻辑应该在RN或ICN中实现。如果在ICN中,ICN可能会对RN发送的Request packet的TgtID进行remap(重映射)。使用SAM,除了PCrdRetrun,Request message的TgtID由以下行为决定:

  • 如果request没有使用pre-allocated credit,那么TgtID的决定方式是:a. DVMOp操作用单独方式决定;b. 除了DVM操作的其它request是由address来决定。但是PrefetchTgt相对于其它requests有不同的地址映射方式,对于RN发出同地址的两笔请求,PrefetchTgt总是指向SN,其它request总是指向HN;
  • 如果request使用pre-allocated credit,那么request的TgtID是由RetryAck的SrcID决定的,即原始request的TgtID。

对于PCrdRetrun:

  • RN发送该命令的TgtID必须等于PCrdGrant中提供的SrcID。

从RN发送的transactions,除了PrefetchTgt是发往SN-F,CHI协议期望Snoopable transaction发往HN-F,Non-snoopable transaction发往HN-I或HN-F。当然Snoopable transaction也可以发往HN-I,但这样可能会导致error,比如software programming error。在这种情况下,HN-I仍需要对符合协议的行为返回响应,但这样会导致一致性无法保证。
HN上也可能使用SAM逻辑来对每一笔request进行映射决定发往哪个SN NodeID。
Response messages的Target ID的确定:
组件在收到message后需要回Response packets,Response packets的TgtID是由收到message的SrcID、HomeNID、ReturnNID、FwdNID中的一个决定的。表1为对于Response message中每个Response packet的TgtID和接收到的message的决定TgtID的域之间的关系:
表1 Source of response packet TgtID
在这里插入图片描述
Snoop Request messages的Target ID的确定:
Snoop request没有包含TgtID,协议没有定义snoop request的TgtID,是由实现具体实现的机制。

4. Network layer flow examples

本小结举几个简单的网络层传输transaction flow例子。

4.1 Simple flow

图1为一个简单的transaction flow,描述了requests和responses的TgtID是如何决定的。
在这里插入图片描述
图1 TgtID assignment without remapping

4.2 Flow with interconnect based SAM

图2为在ICN上发生对request的TgtID进行remap的传输场景,remap只发生在request的TgtID上,transaction flow的其它packet的TgtID和simple flow类似,不需要remap:
在这里插入图片描述
图2 TgtID assignment with remapping logic

4.3 Flow with interconnect based SAM and Retry request

图3为ICN发送人map,且RN收到retry响应的transaction flow,除了retry响应,其它transaction flow和flow with interconnect based SAM一致。
在这里插入图片描述
图3 Remapping of TgtID and retried request

在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

谷公子的藏经阁

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值