PCIe学习笔记(21)

读请求的数据返回(Data Return for Read Requests)

•针对内存读取请求的单个完成可能提供少于请求的全部数据量,只要对于给定请求的所有完成在组合起来时返回了读取请求中请求的数据量。

不同请求的完成不能合并。

◦I/O和Configuration read必须在一个Completion内完成。

◦Completion的Completion Status只对应于与该Completion返回的数据相关的状态

▪Completion的状态不是success Completion将终止单个Read Request的Completions

▪在这种情况下,Length字段中的值是未定义的,必须被Receiver忽略

Completion不能包含超过Max_Payload_Size允许的数据

◦接收方必须检查是否违反此规则。

注:这只是适用于所有带数据有效负载的tlp的规则的一个特例

•内存读取请求可以通过一个或在某些情况下多个完成来完成

读取完成边界(Read Completion Boundary,RCB)决定了完成者被允许将单个读取请求的响应分成多个完成的自然对齐地址边界。

◦对于根复合体,RCB为64字节或128字节。

注意:SW和EP可以实现相应的命令位,该命令位可以由系统软件设置,以指示根复合体的RCB值,允许网桥或端点在根复合体的RCB为128字节时优化其行为。

对于所有其他系统元素,RCB是128字节

•对于没有以RCB字节的整数倍跨越自然对齐的地址边界的请求,Completion必须包含请求中指定的所有数据。

•在RCB字节的整数倍的地址边界上的请求允许使用多个Completion完成,但遵循以下规则:

◦第一个Completion必须从请求中指定的地址开始,如果成功,必须在以下其中一个结束:

•满足整个请求的地址。

•请求开始和结束之间的地址边界,位于RCB字节的整数倍

◦如果最后的完成是成功的,它必须在满足整个请求的地址结束

◦在第一个和最后一个Completion之间的所有Completion (但不包括第一个和最后一个Completion),其长度必须是RCB字节长度的整数倍

•接收方可以选择检查是否违反RCB。如果实现此检查的Receiver确定Completion违反了此规则,则必须将Completion作为Malformed TLP处理。

◦这是一个与接收端口相关的报告错误(见6.2节)。

单个读请求的多个内存读完成必须按递增的地址顺序返回数据

•如果单个读请求的所有内存读完成状态都是成功完成状态,则它们的有效负载之和必须等于请求的大小

•对于每个内存读完成,字节计数字段必须指示完成请求所需的剩余字节数,包括完成时返回的字节数,除非设置了BCM位(PCI-x)。

◦完成一次Memory Read Request需要的总字节数计算如表2-38所示。

  ◦如果内存读请求使用多个Completions完成,每个连续的Completion的字节计数值是由前一个Completion指示的值减去前一个Completion返回的字节数

•完成数据区域从请求指定的DW地址开始。在第一个或唯一一个Completion的第一个或唯一一个Data DW中,只有在Request中的first BE字段中配置为有效的字节包含有效数据。在Request的First BE字段中配置为无效的字节将返回未定义的内容。

•在最后一次成功完成的Last Data DW中,只有在Request的last BE字段中配置为有效的字节包含有效数据。在请求的Last BE字段中配置为无效的字节将返回未定义的内容。

•所有完成数据字节,包括那些内容未定义的字节,在所有的CRC(循环冗余校验)计算中都会被包含。

•举例如图2-44所示。该示例假设返回一个Completion TLP。

BCM位永远不会在读取完成的后续数据包中设置,因此这些后续数据包中的字节计数字段将始终指示每个实例中剩余的字节计数。因此,请求者可以使用这些数据包中的字节计数字段来确定是否缺少读取完成的其他数据包。

PCI Express Completer永远不会设置BCM位。

通过Length和Byte Enable字段计算字节计数

对于所有的Memory Read Completion, Lower Address字段必须表示与Completion一起返回的使能的首字节数据的字节地址的低位

◦对于第一个(或唯一的)Completion, Completer可以从Request地址的最低有效的5位与2位字节级地址连接产生该字段,如表2-39所示。

◦对于任何后续的Completions, Lower Address字段将始终为零,除了由具有64字节RCB(读取完成边界)值的根复合体生成的Completions。在这种情况下,Lower Address字段的最低有效位将始终为零,而Lower Address字段的最高有效位将根据64字节数据负载的对齐方式进行切换。

当生成的状态不是成功完成的读取完成时

◦没有数据包含在完成

▪Cpl(或CplLk)编码被使用,而不是CplD(或CplDLk)

◦此完成是请求的最终完成

    ▪Completer不得为此请求传输额外的完成

    ▪示例:完成者将请求分成四个部分进行;第二个Completion的Completion状态为“Completion中止Completion状态”; Completer终止了对该请求的服务,并且没有传输剩余的两次Completion。

◦字节计数字段必须表明完成请求需要的剩余的字节数 (如果完成状态是成功完成)

◦低地址字段必须指示如果完成状态是成功完成,将与完成一起返回的使能的首字节数据的字节地址的低位。

Completion Handling Rules

当设备接收到与该设备发出的任何未完成请求的事务ID不匹配的完成时,该完成称为“意外完成”(Unexpected Completion,UC)

•如果接收到的完成与未完成请求的事务ID匹配,但在某些其他方面与相应的请求不匹配(例如,属性,流量类,字节计数,低地址等问题),强烈建议接收方将完成作为畸形TLP处理。

◦完成者不能检查完成中的IDO属性(属性位2),因为请求者不需要将请求中的IDO值复制到完成中,如2.2.6.4和2.2.9节所述。

◦然而,如果Completion以其他方式正确形成,则允许Receiver将Completion处理为Unexpected Completion。

当交换机的入口端口接收到无法转发的完成时,该入口端口必须将该完成作为意外完成处理(UC)。这包括对以下目标的完成:

◦与上游端口关联的设备中不存在的功能,

◦与上游端口关联的总线上不存在的设备,

◦Switch内部结构中不存在的设备或功能,或

◦上游端口的总线号范围内但未被任何下游端口声称的总线号。

接收一个意外完成是一个错误,必须根据以下规则处理:

◦接收意外完成的组件必须丢弃完成。

◦意外完成是与接收端口相关联的报告错误 (见6.2节)。

完成状态不是成功完成或配置请求重试状态(仅响应配置请求)的完成必须导致请求者:

◦释放与请求相关的完成缓冲区空间和其他资源。

◦通过request -specific机制处理错误(参见6.2.3.2.5节)。

如果在FLR启动和目标函数完成FLR之间到达完成,则允许将完成作为意外完成处理或被静默丢弃(在流控制积分更新之后),而不将其记录或标记为错误。一旦FLR完成,收到的与在FLR之前发出的请求相对应的Completion必须作为UC处理,除非该函数已重新启用以发出请求。

•RC完成的处理与配置请求重试状态的配置请求是具体实现的,除了系统重置后的时期(见章节6.6)。对于支持CRS软件可见性的RC,适用以下规则:

◦如果CRS软件可见性未启用,RC必须重新发出配置请求作为一个新的请求。

◦如果CRS软件可见性是启用:

   ▪对于包含设备功能配置空间头的Vendor ID字段的两个字节的配置读取请求,RC必须通过返回Vendor ID字段的读取数据值0001h和请求中包含的任何其他字节的所有' 1 '来完成对主机的请求。这个读数据值是专门为PCI-SIG保留的,不对应于任何分配的Vendor ID。

▪对于配置写请求或任何其他配置读请求,RC必须重新发出配置请求作为一个新的请求。

RC的实现可以选择限制配置请求/ CRS完成状态循环的数量,然后再确定请求的目标有问题并采取适当的行动,例如,将发送给主机的请求作为失败的事务完成。

CRS软件可见性可以通过根控制寄存器中的CRS软件可见性启用位(见章节7.5.3.12)来在单个根端口的基础上控制根复核行为。或者,根复合行为可以通过根复合寄存器块(RCRB)控制寄存器中的CRS软件可见性使能位进行管理,如章节7.9.7.4所述,允许一个或多个根端口或rciep的行为由单个使能位控制。对于这种替代情况,每个根端口或RCiEP通过根复合链路声明能力(见章节7.9.8)中的RCRB头关联声明其与特定Enable位的关联。每个根端口或RCiEP最多允许被一个Enable位控制。因此,例如,禁止根端口的根控制寄存器包含Enable位来声明与RCRB头关联的RCRB头在其RCRB头能力中也包含Enable位。根端口或RCRB报头能力中的Enable位的存在由相应的CRS软件可见性位

•对于非配置请求的请求,使用配置请求重试状态的完成是非法的。接收方可以选择将这些违规行为报告为畸形tlp。

◦这是一个与接收端口相关的报告错误(见6.2节)。

•具有保留完成状态值的完成被视为完成状态为不支持的请求(UR)。

•完成状态为Unsupported Request或Completer Abort的完成使用传统的PCI报告机制进行报告(参见章节7.5.1.1.4)。

◦请注意,触发生成这样一个完成的错误条件是Completer报告如6.2节所述。

•当接收到的读取完成或原子操作完成的状态不是成功完成时:

◦没有数据包含在完成

▪Cpl(或CplLk)编码被使用,而不是CplD (CplDLk)

◦此完成是请求的最终完成

▪请求者必须考虑请求终止,而不是期望额外的完成

▪先前收到的部分完成的处理是特定于实现的

示例:请求方收到了一个128字节的Read Request的32字节的Read数据,然后它收到一个Completion,并带有Completer Abort Completion Status。然后,请求者必须释放为该特定读请求分配的内部资源。

  • 26
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
PCIE-DMA是一种基于PCIe接口的直接内存访问技术,能够实现高速数据传输。在我的学习笔记中,我详细记录了与PCIE-DMA相关的知识和学习心得。 首先,我了解到PCIE-DMA技术的基本原理和作用。PCIE-DMA可以通过PCIe总线直接访问系统内存中的数据,而不需要过多的CPU干预,提高数据传输的速度和效率。这种技术在需要大量数据传输的场景下非常有效,比如高性能计算、数据采集等。 其次,我深入学习PCIE-DMA的工作原理。PCIE-DMA的核心是DMA控制器,它负责管理和控制数据传输的流程。当设备需要读写内存中的数据时,它通过DMA控制器发送请求,然后DMA控制器生成一个事务,将数据直接传输到或从内存中。这样就大大减少了CPU的参与,提高了数据传输的效率。 另外,我还学习PCIE-DMA的配置和编程方法。PCIE-DMA的配置主要包括硬件配置和软件配置两个部分。硬件配置通常涉及到DMA控制器和PCIe接口的初始化和配置,软件配置则需要编写驱动程序来驱动DMA控制器和处理数据传输过程中的事件和异常。这部分内容对于我来说还比较新颖,需要更多的实践和实践。 最后,我总结了PCIE-DMA的应用场景和发展前景。PCIE-DMA在高性能计算、数据采集等领域具有广阔的应用前景。随着数据量的不断增加和传输速度的要求越来越高,PCIE-DMA技术的需求也将越来越大。因此,对于我来说,学习掌握PCIE-DMA技术非常有价值。 通过学习和记录PCIE-DMA的相关知识和经验,我对这项技术有了更深入的理解和掌握。希望将来能通过应用PCIE-DMA技术解决实际问题,为科研和工程项目的顺利进行做出贡献。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值