网络层的主要功能是决定各个目的地节点的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