高级FPGA开发之PCIe IP Core(三)
一、PCIe IP核简介
通过阅读PCIe spec文档，可以看到UltraScale+器件Integrated Block For PCI Express解决方案IP核是具备高带宽、高可缩放性和高可靠串行互联的解决方案，适用于UltraScale+器件。赛灵思在 UltraScale+ 架构内提供了 2 个 PCIe 集成块：PCIE4 集
成块和 PCIE4C 集成块。
功能特性：
-
PCI Express端点、传统端点或根端口模式；
-
针对PCIe 4和PCIe 4c块支持x1、x2、x4、x8或x16链路带宽以及Gen1、Gen2和Gen3链路速度；
-
针对PCIe4C块支持x1、x2、x4和x8链路带宽以及Gen4的链路带宽；
-
AXI4-Stream接口，可连接到客户逻辑；
-
高级错误报告（AER）和端到端CRC；
-
用于传输事务缓冲的块RAM；
-
1个PCI Express虚拟通道和8个流量类；
-
最多支持4个PF和252个VF；
-
完全可配置的3x64位或6x32位基地址寄存器（bar）；
-
支持所有中断类型：
INTx
32多矢量MSI功能
含最多2048个矢量的MSI-X功能，具有可选内置MSI-X矢量表；
-
内置发起方读取请求/完成标签管理器
支持最多256项未完成的发起方读取请求传输事务
二、PCIe IP核端口描述 — CQ
2.1 Completer Request Interface
CQ端口将链路层收到的所有请求交付给user logic。
DW表示已经配置的数据总线宽度（64、128或者256）。
| port | IO | Width | description |
|---|---|---|---|
| m_axis_cq_tdata | O | DW | 从CQ接口输出的数据 |
| m_axis_cq_tuser | O | 88 | CQ用户数据（这组数据包含所传输事务层（tlp）的边带信息。） |
| m_axis_cq_tlast | O | 1 | CQ数据的tlast指示 |
| m_axis_cq_tkeep | O | DW/32 | CQ数据的tkeep指示。 |
| m_axis_cq_tvalid | O | 1 | CQ数据有效。 |
| m_axis_cq_tready | I | 1 | CQ数据就绪。 |
| pcie_cq_np_req | I | 2 | 输入可控制内部信用值，进行选择性反压(00-无更改，01-增加1，10/11-保留) |
| pcie_cq_np_req_count | O | 6 | 输出的信用值，当信用值为非0时，才能通过完成器请求接口交付非转发请求，该信用值饱和上限为32。 |
其中m_axis_cq_tuser中的边带信号描述：
| 索引 | 名称 | Width | description |
|---|---|---|---|
| 3:0 | first_be[3:0] | 4 | 有效载荷的首个 Dword 的字节使能。 |
| 7:4 | last_be[3:0] | 4 | 有效载荷的最后一个 Dword 的字节使能。 |
| 39:8 | tyte_en[31:0] | 32 | 用户逻辑可以选择使用这些字节使能位来判定所传输的包的有效载荷中的有效字节。 |
| 40:40 | sop | 1 | 包起始。 |
| 41:41 | discontinue | 1 | 如果核在从其内部 FIFO 存储器读取 TLP 有效载荷时检测到不可纠正的错误，那么它会在 TLP 的最后一个节拍中断言此信号有效。当核发出此类错误信号时，用户应用必须丢弃整个 TLP。 |
| 42:42 | tph_present | 1 | 此位表示在通过接口交付的请求 TLP 中存在“Transaction Processing Hint (TPH)”（传输事务处理提示）。 |
| 44:43 | tph_type[1:0] | 2 | 当请求TLP中存在TPH时，这2个位可提供与提示关联的PH[1:0]字段的值 |
| 52:45 | tph_st_tag[7:0] | 8 | 当请求TLP中存在tph时，输出可提供与提示关联的8位导向标签 |
| 84：53 | parity | 32 | 位 i 可提供针对 m_axis_cq_tdata 的字节 i 计算所得奇校验。 |
| 87：85 | reserved | 3 | 保留 |
注： 当axis_tready和axis_tvalid均处于高位时，节拍采用总线传输。
2.2 Completer Request Interface Formats
描述符长度始终为16字节，并在请求包的前16字节内发送。
当所传输的请求TLP为存储器读取/写入请求、IO读取/写入请求或者原子操作（atomic operation）请求时，格式如下：
供应商定义的报文完成器请求描述符：
对应于ATS报文的完成器请求描述符：
对应于所有其它报文的完成器请求描述符格式：
2.3 CQ字段说明
| 位索引 | 字段索引 | 描述 |
|---|---|---|
| 1:0 | AT 地址类型 | 仅适用于存储器传输事务和原子操作。00-地址未转换 01-传输事务为转换请求 10-请求的地址已转换的地址 11：保留 |
| 63:2 | “address” 地址 | 该字段用于存储器、IO和原子请求，必须使用m_axis_cq_tuser的first_be位判定字节级别的地址 |
| 74:64 | “dword count”(dword计数) | 指示读取或者写入的块大小，对于报文有效范围0-256，对于IO访问，dword计数始终为1 |
| 78：75 | “request type”（请求类型） | 用于识别传输事务类型 |
| 95：80 | “request ID”（请求器ID） | 请求器ID，[95:88]-bus number,[87:83]-device, [82:80]-function number，如果是non-posted请求，那么用户必须存储该字段，并将完成数据一起重新发给集成块 |
| 103：96 | “tag”（标签） | 与请求关联的PCIe标签，如果是non-posted事务，用户必须存储该字段，然后一起重新返回block |
| 111：104 | “target function”（目标功能） | PF/VF映射 |
| 114：112 | “BAR ID” | 仅适用于存储器、IO和原子操作，可为请求中的地址提供匹配的bar编号 |
| 120：115 | “BAR aperture” | 仅适用于存储器、IO和原子操作，提供与请求匹配的bar的间隙设置 |
| 123：121 | “traffic class” | 请求关联的PCIe传输事务（TC），如果是non-posted，必须存储该字段，并将其与完成的数据一起返回集成块 |
| 15：0 | “snoop latency”（嗅探时延） | 该字段定义仅适用于 LTR 报文。它可提供报文的 TLP 报头中的 16 位“Snoop Latency”（嗅探时延）字段的值。 |
| 111：104 | “message code”（报文代码） | 该字段定义适用于所有报文。 |
| 114：112 | “message routing”（报文路由） | 该字段定义适用于所有报文。这些位可提供来自 TLP 报头的 3 位路由(Routing) 字段 r[2:0]。 |
| 15:0 | “destination ID”(目的ID) | 该字段仅适用于供应商定义的报文。 |
2.4 传输事务类型
| request type | description |
|---|---|
| 0000 | 内存读请求 |
| 0001 | 内存写请求 |
| 0010 | IO读请求 |
| 0011 | IO写请求 |
三、PCIe IP核端口描述 — CC
用户应用生成的完成包通过完成器完成（CC）接口端口来相应发射的完成器请求。可以将所有non-posted传输事务作为独立拆分的传输事务来处理。
3.1 Completer Completion Interface
CC接口可持续接受请求器接口上的新请求，同时针对请求发送完成（completion）包。
completer completion interface(CC接口)上，将每个TLP均作为1个axi-stream数据包交付。
| 接口 | IO | 宽度 | 描述 |
|---|---|---|---|
| s_axis_cc_tdata | 输入 | DW | 完成器完成数据总线 |
| s_axis_cc_tuser | 输入 | 33 | 完成器完成用户数据，TLP传输包含的边带信息 |
| s_axis_cc_tlast | 输入 | 1 | 对应完成器完成数据的tlast信号 |
| s_axis_cc_tkeep | 输入 | DW/32 | 对应完成器完成数据的tkeep信号 |
| s_axis_cc_tvalid | 输入 | 1 | 完成器完成数据有效。 |
| s_axis_cc_tready | 输出 | 1 | 完成器完成数据就绪。 |
其中m_axis_cq_tuser中的边带信号描述：
| 位索引 | 名称 | 宽度 | 描述 |
|---|---|---|---|
| 0 | discontinue | 1 | 如果传输期间用户应用在所传输的数据中检测到错误，并且需要中止该数据包，即可断言此信号有效。 |
| 32：1 | parity | 32 | 256位数据奇偶校验位 |
3.2 Completer Completion Interface Formats
user logic将完成器请求的完成数据作为axi4-stream包发送至集成块cc接口。
每个数据包均以1个描述符开头，在描述符后可包含有效载荷数据。描述符长度始终为12个字节，并且在完成包的前12字节内发送。
当用户应用将请求的完成数据拆分为多个完成包（split completion）包后，它必须将每个拆分完成包作为独立axi4-stream包随描述符一起发送。
| 位索引 | 名称 | 描述 |
|---|---|---|
| 6：0 | “lower address”（低位地址） | 对于memory read complete包，该字段必须设置所传输的存储器的起始字节地址的7个最低有效位 |
| 9：8 | “address type”（地址类型） | 该字段定义仅适用于存储器传输事务和原子操作的完成包。user logic必须将AT位从对应的请求描述符复制到该字段中。 |
| 28：16 | “byte count”（字节计数） | 这13个位可包含范围在0 - 4096个字节内的值。如果存储器读取请求已通过使用单一完成包完成，那么byte count值将以字节为单位表示“payload length”。IO读取/写完成包，必须设置为4。对于每个“Memory Read Completion”（存储器读取完成），“Byte Count”字段必须表明完成请求所需的剩余字节数，包括随完成包返回的字节数。 |
| 29：29 | “locked read completion”（锁定读取完成） | 当“locked read”（锁定读取）请求的相应中包含完成包时，必须设置该位，其他为0 |
| 42：32 | ”dword count“（dword计数） | 这11位表示当前包的有效载荷大小（以dword数为单位） |
| 45：43 | “completion status”（完成状态） | 基于所完成包（completion）包的类型来设置。000-完成，001-请求不支持（UR）002-完成器异常（CA） |
| 46：46 | “completion status”（完成状态） | 此位可用于对所发送的tlp进行毒化。针对所有完成包，必须设置为0 |
| 63：48 | “requester ID”（请求器ID） | 与请求关联的PCI请求器ID（从请求复制所得） |
| 71：64 | “tag”（标签） | 与请求关联的PCIe标签（从请求复制所得） |
| 79：72 | “target/device number” | 完成器功能的器件和/或功能编号 |
| 87：80 | “completer bus number”（完成器总线编号） | 与完成器功能关联的总线编号 |
| 88 | “completer ID enable”（完成器ID使能） | 端点模式设置为0 |
| 91：89 | “transaction class”TC（传输事务类） | 与请求关联的PCIe传输事务类（TC），user logic从关联的请求描述符TC复制 |
| 94：92 | 属性 | 与请求关联的PCIe属性（从请求复制所得），92-“no snoop”, 93-“relaxed oerdering”, 94-“ID-based ording” |
| 95 | “force ECRC”（复制ECRC） | 强制执行ECRC插入 |
四、未完待续
下章将继续介绍PCIe Hard IP rc和rq接口。
欢迎关注知乎：北京不北，+vbeijing_bubei
欢迎关注douyin：near.X （北京不北）
欢迎+V：beijing_bubei
获得免费答疑，长期技术交流。
五、参考文献
https://docs.xilinx.com/r/en-US/pg213-pcie4-ultrascale-plus
https://docs.xilinx.com/r/zh-CN/pg213-pcie4-ultrascale-plus
