【CHI】（三）网络层

网络层负责确定目标节点的NodeID。本章包含以下部分：

• 系统地址映射，SAM
• 节点ID
• 目标ID确定
• 网络层flow示例

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，即ID唯一。 CHI协议支持的NodeID位宽为7~11bits，由具体实现决定，但是一个系统中所有组件的NodeID位宽必须一致，至于每个组件的NodeID值也是由具体实现决定的。

3. Target ID determination

本节描述对于不同的message types，如何决定target ID。包含以下部分：

• Request messages的Target ID的确定
• Response messages的Target ID的确定
• Snoop request messages的Target ID的确定

3.1 Request messages的Target ID的确定

        为了对RN的request的TgtID进行映射，CHI协议要求SAM逻辑应该在RN或ICN中实现。如果在ICN中，ICN可能会对RN发送的Request packet的TgtID进行重新映射。

Request message的TgtID使用SAM由以下行为决定：

1.非PCrdRetrun：

• 如果请求没有使用预分配的信用证credit,，那么TgtID的决定方式是：

——DVMOp操作用单独方式决定；

——除了DVM操作的其它request是由address来决定。但是PrefetchTgt相对于其它请求有不同的地址映射方式，对于RN发出同地址的两笔请求，PrefetchTgt总是指向SN，其它request总是指向HN；

• 如果请求使用预分配的信用证credit，那么请求的TgtID是由RetryAck的SrcID决定的，即原始请求的TgtID。

2.对于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，比如软件编程错误。在这种情况下，HN-I仍需要对符合协议的行为返回响应，但这样会导致一致性无法保证。

        HN上也可能使用SAM逻辑来对每一笔request进行映射决定发往哪个SN。

3.2 Response messages的Target ID的确定

     组件在收到message后需要回Response packets，Response packets的TgtID是由收到message的SrcID、HomeNID、ReturnNID、FwdNID中的一个决定的。下表为对于Response message中每个Response packet的TgtID和接收到的message的决定TgtID的域之间的关系：

3.3 Snoop Request messages的Target ID的确定

     Snoop request没有包含TgtID，协议没有定义snoop request的TgtID，是由实现具体实现确定。

4. Network layer flow examples

本小结举几个简单的网络层传输transaction flow例子。包含以下内容：

• Simple flow
• Flow with interconnect based SAM
• Flow with interconnect based SAM and Retry request

4.1 Simple flow

图3-1为一个简单的transaction flow，描述了requests和responses的TgtID是如何决定的。

在图3-1中，不需要重新映射的TgtID分配的步骤是：

1. RN0使用内部SAM向HN0发送一个TgtID的RN0请求。——ICN不会重新映射节点ID。
2. HN0查找内部SAM以确定目标SN节点。
3. SN0接收该请求并发送一个数据响应。——数据响应包具有来自请求ReturnNID的TgtID。
4. RN0接收来自SN0的数据响应。
5. 如果需要，RN0发送一个CompAck响应，其TgtID来自数据响应包中的HomeNID，以完成事务。

4.2 Flow with interconnect based SAM

        图3-2为在ICN上发生对请求的TgtID进行重映射的传输场景，重映射只发生在请求的TgtID上，transaction flow的其它packet的TgtID和simple flow类似，不需要remap：

在图3-2中，使用重映射逻辑进行TgtID分配的步骤如下：

1. RN0使用内部SAM向RN0发送TgtID为HN0的RN0的请求。
2. ICN会将请求TgtID从HN0重新映射到HN1。SrcID仍然设置为原始请求程序RN0。
3. HN1查找内部SAM以确定目标SN节点。ReturnNID被设置为匹配原始请求程序RN0。
4. SN0接收该请求并发送一个数据响应。——数据响应包具有来自请求ReturnNID的TgtID，并将HomeNID设置为匹配重新映射的主节点。
5. RN0接收来自SN0的数据响应。
6. 如有必要，RN0发送来自数据响应包中HN1的HomeNID，以完成事务。

4.3 Flow with interconnect based SAM and Retry request

图3-3为请求被retry的情况：

上图中重新映射TgtID且请求被retry步骤如下：

1. 互连将RN0提供的TgtID重新映射到HN1。
2. 请求接收RetryAck响应。——RetryAck和PCrdGrant响应从接收到的请求中的SrcID中获取TgtID信息。
3. 一旦同时收到RetryAck和PCrdGrant响应，RN0将重新发送该请求。——retry请求中的TgtID与接收到的重新尝试请求中的SrcID或原始请求中的TgtID相同。TgtID必须再次通过重映射逻辑（？）。
4. 事务流的其余部分中的数据包以基于互连的SAM的流类似的方式获得TgtID。