PCIE-TLP中的域及其涉及的小知识点

1.Fmt和Type有哪些组合?

---------------------------------------------------------------------------------------------------------------------------------

2.TC

参考virtual channel机制

---------------------------------------------------------------------------------------------------------------------------------

3.Attr

参考ordering机制和snoop相关内容

bit0:0表示当前TLP所传送的数据再通过FSB的时候需要和cache保持一致,由FSB通过总线监听自动完成而不需要软件干预;1表示FSB并不会将TLP中的数据与cache进行一致,这种情况下进行数据传输的时候需要软件保证cache一致性。在一些明确知道不会cache命中的操作,可以将该位置为1以减少FSB在进行总线监听带来的带宽损失。(当置为 1 时,Requester 的意思是这个 TLP 不会存在 host cache 一致性的问题(host cache coherency issues),因此系统硬件可以通过跳过普通处理器对这个请求的 cache 窥探,以此来节省时间。而当这一位被置为 0 时,需要进行 PCI-type cache 窥探保护)

---------------------------------------------------------------------------------------------------------------------------------

4.TH

待补充

---------------------------------------------------------------------------------------------------------------------------------

5.TD

表示TLP中是否含有ECEC,PCIE中的校验机制有哪些?

 (1)ECRC/LCRC  (为什么需要ECRC?) 

(3)PCRC(Plaintext CRC,纯文本 CRC):是 IDE TLP 中的概念,在大多数方面,PCRC的计算方法与ECRC相同,并且CRC多项式是相同的。IDE TLP上不允许使用ECRC,因此任何TLP都不能同时拥有PCRC和ECRC。

(4)FEC(Forward error correction,向前纠错):基于字典将要传输的内容重新编码,接收者再根据接收内容、字典、hamming distace接收这部分内容。

LCRClink CRC

ECRC(End-toEnd CRC)

长度

32bit-TLP/16bit-DLLP

源/目的

用于检测两个连接的设备之间的链路上的错误,这些错误一般是由于物理层的信号质量问题引起的

用于检测Requester和completer之间的路径是否有损坏,ECRC是requester/initiaor的TL层生成的。

通过switch

在入口被DLL层校验LCRC,在出口重新计算生产

Switch不会修改内容

Switch收到错误报文时

要求对端重发

记录错误,继续转发

completer收到错误报文后

发送NAK报文给发送端,要求对端重发,重传过程不需要软件参与

发出一个不可修正的错误信息通知系统处理,没有重传机制,系统处理需要软件参与

是否可修正

可修正

不可修正

ECRC 

多项式系数:04C11DB7(h)

Seed value(初始值):FFFFFFFF(h)

所有header field、End-End TLP Prefixes/OHC (如果有的话) 、data payload(如果有的话)都需要包含在ECRC计算中;

所有变化的域,在ECRC计算过程中都需要被认定为1:

(1)TLP header中type field中的bit 0;

(2)EP位 

关于ECRC使用过程中的一些准则:

(1)一些基本准则;(2)针对switch的一些准则;

在NFM中,32位的ECRC值被放置在TLP的末尾的TLP Digest field字段中。在FM中,32位的ECRC值被放置在TLP Trailer中。

支持end-to-end data integrity检查的receiver收到包含ECRC的TLP该如何检查?

注意,计算出来的ECRC和32位TLP ECRC字段中对应的位置并不直接对应,存在一个对应关系:

---------------------------------------------------------------------------------------------------------------------------------

6.EP

data posioned,参考链接

---------------------------------------------------------------------------------------------------------------------------------

7.AT域是用来做什么的?

AT域是存储器读请求、AtomicOp及ATS地址转换请求的专属域,在其他事务中该域为Reserved预留。

AT=00Untranslated:表示Translation Agent (TA) 可以将地址视为虚拟地址或物理地址;

AT=01Translation RequestTA将返回转化的地址(包含requestAddress字段)作为read completion, 此值仅对显式Translation Request有意义。 如果 TA Memory Read以外的Memory Request中收到 AT01b TLP,则 TA 将发出Unsupported Request (UR) 信号;

AT=10Translated:事务中的地址已由 ATC 转换。 如果允许与 SourceID 关联的Function向系统内存提供物理地址,则 TA 可能不会转换该地址。 如果Function不允许展现物理地址,则 TA 可以将其视为 UR

AT=11Reserved:如果 TA 收到一个Memory Request TLP,其中 AT 字段设置为 11b,则 TA 将发出Unsupported Request (UR) 信号。

---------------------------------------------------------------------------------------------------------------------------------

8.zero length表示什么?

关于zero-length

Length长度为1,实现读刷新,为了确保之前使用posted方式所传输的数据最终达到目的地,与zero-length读对应的读完成报文中是不含有负载的,从而提高PCIE链路利用效率。另外,标准的存储器读同样可以完成刷新操作,但是这种读请求完成报文需要数据负载,链路利用效率可能不如zero-length

应用:解决MSI报文使用的TC与数据传递使用的TC不一致导致的数据完整性问题(MSI报文的序问题)。

进行数据传递的TLP使用TC0,而MSI报文使用TC1,这两种TC使用的VC可能并不相同,不同的VC间的数据传递的时候并没有序的要求,虽然发送的时候是把传送数据的存储器写的TLP发送完以后在发送MSI报文,但是RC可能任然是优先收到MSI报文,此时如果立刻在中断处理服务程序中使用该PCIE设备写入的数据可能就会出现数据完整性的问题。

解决:PCIE完成DMA写操作的时候,再向目标地址发送一个zero-length存储器读的请求报文,当PCIE设备收到与这个存储器读请求对应的完成报文以后在发送MSI报文。因为存储器读请求TLP不能超越存储器写报文。

---------------------------------------------------------------------------------------------------------------------------------

9.PCIE中的BDF是什么?为什么cfg中还有个bus num?PCIE中的hirechary ID是什么?completer ID是什么?AIR机制是什么?

---------------------------------------------------------------------------------------------------------------------------------

10.PCIE中的tag机制是什么?

---------------------------------------------------------------------------------------------------------------------------------

11.byte enable机制是什么样的?

---------------------------------------------------------------------------------------------------------------------------------

12. 哪些操作是通过地址进行路由的,那些操作是通过ID进行路由的?

---------------------------------------------------------------------------------------------------------------------------------

13.PH是什么?

待补充

---------------------------------------------------------------------------------------------------------------------------------

14.cpl中的status有哪些?UR,CA等待源头有哪些?

---------------------------------------------------------------------------------------------------------------------------------

15.BCM及byte count是什么?

---------------------------------------------------------------------------------------------------------------------------------

16.lower address是什么?

---------------------------------------------------------------------------------------------------------------------------------

17.各种包的格式是什么样的?

 

---------------------------------------------------------------------------------------------------------------------------------

18 message中的route字段表示什么意思,和type字段有什么关系? 

fmt+type[4:3]决定了这个TLP是message类型,fmt=001+type[4:3]=10 -> msg;fmt=011+type[4:3]=10-> msgd;

而type的剩余字段表示route,代表隐式路由,具体方式如下:

<think>好的,用户想了解PCIe TLP中的ECS(End Credit Syntax)。首先,我需要确认ECS的正确全称。根据已有的知识,ECS可能是指“End-to-End CRC”或者与流量控制相关的字段。不过,根据引用[3]提到的“ecrc”,即End-to-End CRC,这可能与用户的问题相关。但用户提到的“End Credit Syntax”似乎与流量控制中的信用机制有关。需要进一步核实。 在PCIe规范中,流量控制机制使用信用系统来管理数据流,确保发送方不会溢出接收方的缓冲区。流量控制信用(Flow Control Credit)分为不同类别,如Posted、Non-Posted和Completion。每个TLP在发送前需要检查是否有足够的信用,这可能涉及到信用信息的更新和传递,但通常这些信息是在数据链路层处理的,而不是在TLP本身的结构中。 另外,引用[3]提到TLP的结构包括头、有效载荷和ECRC(End-to-End CRC)。ECRC是可选的,用于检测数据传输中的错误。因此,用户可能将ECRC误称为ECS,或者存在其他术语混淆。需要检查是否存在“End Credit Syntax”这一术语,或者是否是用户对流量控制信用的某种表述错误。 查阅资料发现,PCIe TLP中并没有名为ECS(End Credit Syntax)的字段。可能的误解来自于流量控制中的信用结束标记,或者ECRC的拼写错误。因此,在回答中需要澄清这一点,并解释相关的流量控制机制和ECRC字段,以覆盖用户可能的意图。</think>关于PCIe TLP消息中的"ECS"(End Credit Syntax),需注意以下关键点: 1. **术语澄清** PCIe规范中不存在"End Credit Syntax"(ECS)的标准术语。根据上下文推测,可能涉及以下两种概念混淆: - **ECRC(End-to-End CRC)**:TLP中的可选校验字段 - **流量控制信用机制**:与数据链路层相关的信用管理系统 2. **ECRC详解** 在TLP格式中,ECRC是位于数据包末端的32位循环冗余校验码(参见引用[3]): $$ \text{TLP结构} = \text{Header} + \text{Data Payload} + \text{ECRC} $$ - 作用:检测TLP在传输过程中是否发生位翻转等错误 - 特点: * 可选项,由TLP头部的ECRC使能位控制 * 覆盖整个TLP(头+数据) * 接收端发现错误时通过Ack/Nak机制触发重传 3. **流量控制信用机制** 这是PCIe流量控制的核心机制(引用[3]提到流量控制): ```plaintext +-------------------+-------------------+ | 发送端 | 接收端 | | 维护信用计数器 | 提供信用更新包 | | 每发送TLP消耗信用 | 通过DLLP返回新信用 | +-------------------+-------------------+ ``` - 信用类型分为三类: 1. Posted(P)信用:用于无需响应的请求 2. Non-Posted(NP)信用:需要响应的请求 3. Completion(Cpl)信用:响应包 4. **关键差异对比表** | 特性 | ECRC | 流量控制信用 | |---------------|-------------------------------|---------------------------| | 位置 | TLP末端 | 数据链路层(DLLP) | | 作用范围 | 单TLP完整性校验 | 全局流量控制 | | 实现层级 | 事务层 | 数据链路层 | | 协议交互 | 错误检测后触发重传 | 信用更新驱动发送权限 |
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值