Serial RapidIO Gen2Endpoint v4.1 (PG007):Chapter 2:Product Specification

SRIO Gen2 端点以三个子核的形式呈现（通过 srio_gen2_<core_version>_unifiedtop 封装模块提供），并通过 <component_name> 模块组合成一个完整的解决方案。该封装模块为大多数应用场景提供了高层级且易于维护的接口，同时在必要时允许对子组件进行控制。

本章对每个子核及接口进行了基本的功能性概述，包括信号列表和寄存器定义。以下各节列出的信号并非全部都会引出到 <component_name> 端口。

2.1、Standards Compliance

Serial RapidIO Gen2 物理层（PHY）、Serial RapidIO Gen2 逻辑层（LOG）和 Serial RapidIO Gen2 缓冲器（BUF）均依据《RapidIO 互连规范修订版 2.2》（RapidIO 规范） $参考文献 13$ 进行设计。虽然使用 SRIO Gen2 端点并不要求事先掌握 RapidIO 规范，但若涉及本指南范围之外的细节，可能仍需查阅该规范。本指南将在必要时引用 RapidIO 规范中的相关内容。

以下所列《RapidIO 互连规范修订版 2.2》的各章节与 SRIO Gen2 端点直接相关：

• Part 1: Input/Output System Logical -- 规定了 Serial RapidIO Gen2 逻辑（I/O）层与传输层的功能。

• Part 2: Message Passing Logical -- 规定了在使能门铃（Doorbell）和消息（Message）解析功能时，Serial RapidIO Gen2 逻辑（I/O）层与传输层的功能。

• Part 3: Common Transport -- 规定了 Serial RapidIO Gen2 逻辑（I/O）层与传输层的功能。

• Part 6: Serial Physical Layer -- 规定了 Serial RapidIO Gen2 物理层及 Serial RapidIO Gen2 缓冲器的功能。

2.2、Performance

表 2-1 列出了每种所支持器件对应的建议速度等级。

注：

不建议使用其他速度等级，否则可能需要投入大量设计工作才能满足时序收敛。
对于 Zynq-7000 器件，同时支持 GTX 和 GTP。表 2-1 仅列出了 Zynq 的 GTX 速度等级。Zynq 的 GTP 速度等级与 Artix-7 的速度等级相近。
Artix-7 和 Kintex-7 低电压器件（artix7l、kintex7l）不支持超过 3.125 Gbps 的线速率。
UltraScale+ 的速度等级详细信息与 UltraScale 完全相同。

2.3、Serial Transceiver Support

表 2-2 列出了所支持的器件系列及串行收发器（GT）类型。对于使用 7 系列器件的设计，仅支持生产级封装模块。

2.4、Top-Level Wrapper

<component_name>_block 模块将 SRIO Gen2 端点的各个组件（包括参考设计）集成在一起，提供了一个可用于开展设计的封装解决方案。图 2-1 给出了各组件如何组合到 <component_name>_block 模块中的基本框图，以及 <component_name>_block 设计内部各组件之间数据交互的总体视图。

2.5、Port Descriptions

本节详细说明 SRIO Gen2 端点中三个子核各自的接口，以及参考设计中各模块的接口。

2.5.1、Logical Layer Interfaces

逻辑层（LOG）划分为多个模块，用于控制发送数据包的组包与接收数据包的解析。LOG 具有三个接口：
• 用户接口（User Interface）
• 传输接口（Transport Interface）
• 配置结构接口（Configuration Fabric Interface）

图 2-2 展示了与 LOG 各个接口相关联的端口。在图 2-2 中，实心箭头表示 AXI4-Stream 端口，空心箭头表示 AXI4-Lite 端口。

注：端口名称与描述均从 LOG 的角度给出。

用户接口（user interface）包含用于发出或接收数据包的端口。在生成核时，可以配置端口的数量以及每个端口所关联的事务类型。通过这些端口，还可以对位于本 SRIO Gen2 端点设备内部或远端设备中的配置寄存器发起配置读写访问。这些接口经由 Serial RapidIO 封装模块引出，用于数据包的生成与接收。

传输接口（Transport Interface）包含接收和发送两个端口，设计用于与符合 RapidIO 标准的物理层或缓冲应用进行连接。该接口在封装模块外部不可见。

配置结构接口（Configuration Fabric Interface）包含两个端口：

• 配置主端口（Configuration Master port），通过配置结构对本地配置空间发起读写操作。

• LOG 配置寄存器端口（LOG Configuration Register port），该端口为从接口，用于对定义为逻辑层或传输层组成部分的所有配置寄存器进行读写访问。

配置结构对来自配置总线主端口的读写地址进行解码，并将其传递给 LOG、PHY 和 BUF 的配置寄存器端口。这一交互过程完全在 <component_name>_block 模块内部进行。

2.5.1.1、Clock and Reset Interface

表 2-3 列出了 <component_name>_block 中与 LOG 层的时钟和复位相关的信号。（srio_gen2_v4_1_15_unifiedtop.v）

Table 2-3: LOG Clock and Reset Interface Signal List

|-----------------|-----------|-------------------------------------------------------------------------------------------------------------------------------|
| Signal | Direction | Description |
| log_lcl_log_clk | Output | LOG 的时钟。在示例设计中，log_clk 取决于线速率和链路宽度（从 Nx 降级训练至 1x 的核仍使用 Nx 时钟速率）。更多信息请参见第 3 章中的时钟部分。注：该信号与 log_clk 相同，log_clk 是本文件其他部分所使用的名称。 |
| log_rst | Input | LOG 的复位。必须与 log_clk 同步释放。请参见第 3 章中的复位部分。 |
| log_lcl_cfg_clk | Input | 配置寄存器接口时钟。如果使用了 AXI4-Lite 维护端口和配置结构参考设计，则该时钟必须与 log_clk 相同。否则，该时钟独立于 log_clk。注：该信号与 cfg_clk 相同，cfg_clk 是本文件其他部分所使用的名称。 |
| log_lcl_cfg_rst | Input | 配置寄存器接口复位。将 LOG 寄存器复位为默认值。必须与 cfg_clk 同步释放。注：该信号与 cfg_rst 相同，cfg_rst 是本文件其他部分所使用的名称。 |

2.5.1.2、User Interfaces

用户接口包含一组 I/O 端口以及以下可选端口：

• 消息端口（Messaging Port）

• 维护端口（Maintenance Port）

• 用户自定义端口（User-Defined Port）

这些接口可在 <component_name>_block 层级使用。每种事务类型都被分配到特定的端口。通常，任何受支持的 I/O 事务（如 NWRITE、NWRITE_R、SWRITE、NREAD 和 RESPONSE，不包括 MAINTENANCE 响应）都通过 I/O 端口进行发送或接收。MESSAGE 事务（若支持）可被分配到消息端口或 I/O 端口。无论是否存在消息端口，DOORBELL 事务均使用 I/O 端口。若维护端口已使能，则所有 Maintenance 报文都应在维护端口上传输。如果事务是用户自定义的、属于不支持的类型、或没有分配对应的端口，则使用用户自定义端口（当用户自定义端口未使能时，接收到的与其他端口不匹配的报文将被丢弃）。

2.5.1.2.1、I/O Port

I/O 端口可配置为两种样式之一：精简 I/O（Condensed I/O）或发起方/目标方（Initiator/Target）。可用的信号取决于在核生成过程中所选的样式。

I/O 端口基于 AXI4-Stream 通道构建。支持两种数据包格式：

• HELLO

• SRIO Stream

重要提示：I/O 端口中的所有通道必须使用相同的数据包格式，该格式在核生成时选定。有关端口使用的更多信息，请参见第 3 章"Designing with the Core for more information on port usage"。

2.5.1.2.1、Condensed I/O

精简 I/O 端口样式减少了用于发送和接收 I/O 数据包的通道数量。该样式使用一个 AXI4-Stream 通道来发送与 I/O 端口关联的所有类型数据包（iotx）。同样地，使用一个通道来接收所有 I/O 端口的接收数据包（iorx）。图 2-3 展示了精简 I/O 端口。

注：端口名称与描述均从 LOG 的角度给出。

表 2-4 列出了与精简 I/O 端口相关的信号。s_axis_iotx* 信号与 <component_name> 层级的 CONDENSED_IO_TX 接口相关联，m_axis_iorx* 信号则与 CONDENSED_IO_RX 接口相关联。

Table 2-4: Condensed I/O Port Signal List

|---------------------------|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Signal | Direction | Description |
| s_axis_iotx_tvalid | Input | 表示通道上的信息有效。 |
| s_axis_iotx_tready | Output | 握手信号。表示来自源端的数据已被接受（若有效）。 |
| s_axis_iotx_tdata $63:0$ | Input | 数据包头和数据。 |
| s_axis_iotx_tkeep $7:0$ | Input | 字节限定符，用于指示数据对应字节的内容是否有效。若端口配置为使用 HELLO 格式，则该信号必须固定为 8'hFF。对于配置为使用 SRIO Stream 格式的端口，除 tlast 置位的情况外，该输入应设置为 8'hFF。位 7 对应数据的最高有效字节（tdata $63:56$ ），位 0 对应数据的最低有效字节（tdata $7:0$ ）。 |
| s_axis_iotx_tlast | Input | 指示数据包的最后一个节拍。 |
| s_axis_iotx_tuser $31:0$ | Input | HELLO 格式：该信号在数据包的第一个节拍有效，由数据包的源 ID（位 31:16）和目的 ID（位 15:0）组成。若使用 8 位器件 ID，则每个 ID 的最高有效字节应填充 0。信号中的源 ID 部分与 deviceid 信号相连。 SRIO Stream 格式：在此格式下，tuser 仅为 8 位宽。位 1 用于设置数据包的临界请求流（CRF）标志，若未使能 CRF 支持，则应将该位固定为 0。所有其他位均保留。在数据包内的后续节拍中，该字段为保留字段。 |
| m_axis_iorx_tvalid | Output | 表示通道上的信息有效。 |
| m_axis_iorx_tready | Input | 握手信号。表示来自源端的数据已被接受（若有效）。 |
| m_axis_iorx_tdata $63:0$ | Output | 数据包头部和数据。 |
| m_axis_iorx_tkeep $7:0$ | Output | 字节限定符，用于指示数据对应字节的内容是否有效。若端口配置为使用 HELLO 格式，则该信号固定为 8'hFF。对于配置为使用 SRIO Stream 格式的端口，除 tlast 置位的情况外，该输出设置为 8'hFF。位 7 对应数据的最高有效字节（tdata $63:56$ ），位 0 对应数据的最低有效字节（tdata $7:0$ ）。 |
| m_axis_iorx_tlast | Output | 指示数据包的最后一个节拍。 |
| m_axis_iorx_tuser $31:0$ | Output | HELLO 格式：该信号在数据包的第一个节拍有效，由数据包的源 ID（位 31:16）和目的 ID（位 15:0）组成。若使用 8 位器件 ID，则每个 ID 的最高有效字节填充 0。 SRIO Stream 格式：在此格式下，tuser 仅为 8 位宽。若数据包的临界请求流（CRF）标志已设置，则位 1 置位。所有其他位均保留。在数据包内的后续节拍中，该字段为保留字段。 |

2.5.1.2.2、Initiator/Target

发起方/目标方端口样式可以将发往远端设备的事务（置于发起方端口）与发往本地端点的事务（置于目标方端口）分离开来。

如图 2-4 所示，使用发起方/目标方端口样式时，I/O 事务共有四个 AXI4-Stream 通道。在图 2-4 中，请求通道以黑色表示，响应通道以灰色表示。

注：端口名称与描述均从 LOG 的角度给出。

由本地端点生成的请求被放置在发起方请求（ireq）通道上，以便在链路上进行传输。从远端设备接收到的响应则通过发起方响应（iresp）通道呈现给用户设计。

来自远端设备并由核接收到的请求，通过目标方请求（treq）通道呈现给用户设计。用户设计对这些请求生成的响应，则被放置在目标方响应（tresp）通道上。

表 2-5 列出了与发起方/目标方端口相关的信号。在 <component_name> 层级，以下信号与这些接口相关联：

• s_axis_ireq* 与 INITIATOR_IREQ 接口相关联。

• m_axis_iresp* 与 INITIATOR_IRESP 接口相关联。

• m_axis_treq* 与 TARGET_TREQ 接口相关联。

• s_axis_tresp* 与 TARGET_TRESP 接口相关联。

Table 2-5: Initiator/Target Port Signal List

|----------------------------|-----------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Signal | Direction | Description |
| s_axis_ireq_tvalid | Input | 表示接口上的信息有效。 |
| s_axis_ireq_tready | Output | 握手信号。表示来自源端的数据已被接受（若有效）。 |
| s_axis_ireq_tdata $63:0$ | Input | 数据包头部和数据。 |
| s_axis_ireq_tkeep $7:0$ | Input | 字节限定符，用于指示数据对应字节的内容是否有效。若端口配置为使用 HELLO 格式，则该信号必须固定为 8'hFF。对于配置为使用 SRIO Stream 格式的端口，除 tlast 置位的情况外，该输入应设置为 8'hFF。位 7 对应数据的最高有效字节（tdata $63:56$ ），位 0 对应数据的最低有效字节（tdata $7:0$ ）。 |
| s_axis_ireq_tlast | Input | 指示数据包的最后一个节拍。 |
| s_axis_ireq_tuser $31:0$ | Input | HELLO 格式：该信号在数据包的第一个节拍有效，由数据包的源 ID（位 31:16）和目的 ID（位 15:0）组成。若使用 8 位器件 ID，则每个 ID 的最高有效字节应填充 0。在默认示例设计中，器件 ID 连接到源 ID。但采用定制设计的用户应进行必要的连接。 SRIO Stream 格式：在此格式下，tuser 仅为 8 位宽。位 1 用于设置数据包的临界请求流（CRF）标志，若未使能 CRF 支持，则应将该位固定为 0。所有其他位均保留。在数据包内的后续节拍中，该字段为保留字段。 |
| m_axis_iresp_tvalid | Output | 表示接口上的信息有效。 |
| m_axis_iresp_tready | Input | 握手信号。表示来自源端的数据已被接受（若有效）。 |
| m_axis_iresp_tdata $63:0$ | Output | 数据包头部和数据。 |
| m_axis_iresp_tkeep $7:0$ | Output | 字节限定符，用于指示数据对应字节的内容是否有效。若端口配置为使用 HELLO 格式，则该信号固定为 8'hFF。对于配置为使用 SRIO Stream 格式的端口，除 tlast 置位的情况外，该输出设置为 8'hFF。位 7 对应数据的最高有效字节（tdata $63:56$ ），位 0 对应数据的最低有效字节（tdata $7:0$ ）。 |
| m_axis_iresp_tlast | Output | 指示数据包的最后一个节拍。 |
| m_axis_iresp_tuser $31:0$ | Output | HELLO 格式：该信号在数据包的第一个节拍有效，由数据包的源 ID（位 31:16）和目的 ID（位 15:0）组成。若使用 8 位器件 ID，则每个 ID 的最高有效字节应填充 0。 SRIO Stream 格式：在此格式下，tuser 仅为 8 位宽。若数据包的临界请求流（CRF）标志已设置，则位 1 置位。所有其他位均保留。在数据包内的后续节拍中，该字段为保留字段。 |
| m_axis_treq_tvalid | Output | 表示接口上的信息有效。 |
| m_axis_treq_tready | Input | 握手信号。表示来自源端的数据已被接受（若有效）。 |
| m_axis_treq_tdata $63:0$ | Output | 数据包头部和数据。 |
| m_axis_treq_tkeep $7:0$ | Output | 字节限定符，用于指示数据对应字节的内容是否有效。若端口配置为使用 HELLO 格式，则该信号固定为 8'hFF。对于配置为使用 SRIO Stream 格式的端口，除 tlast 置位的情况外，该输出设置为 8'hFF。位 7 对应数据的最高有效字节（tdata $63:56$ ），位 0 对应数据的最低有效字节（tdata $7:0$ ）。 |
| m_axis_treq_tlast | Output | 指示数据包的最后一个节拍。 |
| m_axis_treq_tuser $31:0$ | Output | HELLO 格式：该信号在数据包的第一个节拍有效，由数据包的源 ID（位 31:16）和目的 ID（位 15:0）组成。若使用 8 位器件 ID，则每个 ID 的最高有效字节应填充 0。 SRIO Stream 格式：在此格式下，tuser 仅为 8 位宽。若数据包的临界请求流（CRF）标志已设置，则位 1 置位。所有其他位均保留。在数据包内的后续节拍中，该字段为保留字段。 |
| s_axis_tresp_tvalid | Input | 表示接口上的信息有效。 |
| s_axis_tresp_tready | Output | 握手信号。表示来自源端的数据已被接受（若有效）。 |
| s_axis_tresp_tdata $63:0$ | Input | 数据包头部和数据。 |
| s_axis_tresp_tkeep $7:0$ | Input | 字节限定符，用于指示数据对应字节的内容是否有效。若端口配置为使用 HELLO 格式，则该信号必须固定为 8'hFF。对于配置为使用 SRIO Stream 格式的端口，除 tlast 置位的情况外，该输入应设置为 8'hFF。位 7 对应数据的最高有效字节（tdata $63:56$ ），位 0 对应数据的最低有效字节（tdata $7:0$ ）。 |
| s_axis_tresp_tlast | Input | 指示数据包的最后一个节拍。 |
| s_axis_tresp_tuser $31:0$ | Input | HELLO 格式：该信号在数据包的第一个节拍有效，由数据包的源 ID（位 31:16）和目的 ID（位 15:0）组成。若使用 8 位器件 ID，则每个 ID 的最高有效字节应填充 0。在默认示例设计中，器件 ID 连接到源 ID。但采用定制设计的用户应进行必要的连接。 SRIO Stream 格式：在此格式下，tuser 仅为 8 位宽。位 1 用于设置数据包的临界请求流（CRF）标志，若未使能 CRF 支持，则应将该位固定为 0。所有其他位均保留。在数据包内的后续节拍中，该字段为保留字段。 |

2.5.1.2.2、Messaging Port

消息端口是一个可选接口（消息也可以合并到 I/O 端口上，并通过 Vivado 集成设计环境（IDE）的设置作为写事务处理）。独立的消息端口采用发起方/目标方样式。

发起方/目标方端口样式可以将发往远端设备的事务与发往本地端点的事务分离开来。图 2-5 详细展示了消息端口。

注：端口名称与描述均从 LOG 的角度给出。

由本地端点生成的请求被放置在消息发起方请求（msgireq）端口上，以便在链路上进行传输。从远端设备接收到的响应则通过消息发起方响应（msgiresp）端口呈现。

来自远端设备并由 Serial RapidIO 核接收到的请求，通过消息目标方请求（msgtreq）端口呈现。用户设计对这些请求生成的响应，则被放置在消息目标方响应（msgtresp）端口上。

表 2-6 列出了与消息端口相关的信号。在 <component_name> 层级，以下信号与这些接口相关联：

• s_axis_msgireq* 与 MSGIREQ 接口相关联。

• m_axis_msgiresp* 与 MSGIRESP 接口相关联。

• m_axis_msgtreq* 与 MSGTREQ 接口相关联。

• s_axis_msgtresp* 与 MSGTRESP 接口相关联。

Table 2-6: Messaging Port Signal List

|-------------------------------|---------------|-----------------------------------------------------------------------------------------------------------------|
| Signal | Direction | Description |
| s_axis_msgireq_tvalid | Input | 表示接口上的信息有效。 |
| s_axis_msgireq_tready | Output | 握手信号。表示来自源端的数据已被接受（若有效）。 |
| s_axis_msgireq_tdata $63:0$ | Input | 数据包头部和数据。 |
| s_axis_msgireq_tkeep $7:0$ | Input | 字节限定符，用于指示关联数据字节的内容是否有效。对于HELLO端口，此值必须绑定为8'hFF。 |
| s_axis_msgireq_tlast | Input | 指示数据包的最后一个节拍。 |
| s_axis_msgireq_tuser $31:0$ | Input | 在数据包的第一个节拍，该信号包含数据包的源 ID（位 31:16）和目标 ID（位 15:0）。若使用 8 位设备 ID，则每个 ID 的最高有效字节应填充 0。在数据包内的后续节拍中，该字段为保留字段。 |
| m_axis_msgiresp_tvalid | Output | 表示接口上的信息有效。 |
| m_axis_msgiresp_tready | Input | 握手信号。表示来自源端的数据已被接受（如果有效）。 |
| m_axis_msgiresp_tdata $63:0$ | Output | 数据包头部和数据。 |
| m_axis_msgiresp_tkeep $7:0$ | Output | 字节限定符，用于指示关联数据字节的内容是否有效。对于 HELLO 端口，该信号必须固定为 8'hFF。 |
| m_axis_msgiresp_tlast | Output | 指示数据包的最后一个节拍。 |
| m_axis_msgiresp_tuser $31:0$ | Output | 在数据包的第一个节拍，该信号包含数据包的源 ID（位 $31:16$ ）和目标 ID（位 $15:0$ ）。若使用 8 位设备 ID，则每个 ID 的最高有效字节应填充 0。在数据包内的后续节拍中，该字段为保留字段。 |
| m_axis_msgtreq_tvalid | Output | 表示接口上的信息有效。 |
| m_axis_msgtreq_tready | Input | 握手信号。表示来自源端的数据已被接收（在有效的情况下）。 |
| m_axis_msgtreq_tdata $63:0$ | Output | 数据包头部及数据。 |
| m_axis_msgtreq_tkeep $7:0$ | Output | 字节限定符，用于指示关联数据字节的内容是否有效。对于 HELLO 端口，该信号必须固定为 8'hFF。 |
| m_axis_msgtreq_tlast | Output | 指示数据包的最后一个节拍。 |
| m_axis_msgtreq_tuser $31:0$ | Output | 在数据包的第一个节拍，该信号包含数据包的源 ID（位 $31:16$ ）和目标 ID（位 $15:0$ ）。若使用 8 位设备 ID，则每个 ID 的最高有效字节应填充 0。在数据包内的后续节拍中，该字段为保留字段。 |
| s_axis_msgtresp_tvalid | Input | 表示接口上的信息有效。 |
| s_axis_msgtresp_tready | Output | 握手信号。表示来自源端的数据已被接收（在有效的情况下）。 |
| s_axis_msgtresp_tdata $63:0$ | Input | 数据包头部及数据。 |
| s_axis_msgtresp_tkeep $7:0$ | Input | 字节限定符，用于指示关联数据字节的内容是否有效。对于 HELLO 端口，此信号必须固定为 8'hFF。 |
| s_axis_msgtresp_tlast | Input | 指示数据包的最后一个节拍。 |
| s_axis_msgtresp_tuser $31:0$ | Input | 在数据包的第一个节拍，该信号包含数据包的源 ID（位 $31:16$ ）和目标 ID（位 $15:0$ ）。若使用 8 位设备 ID，则每个 ID 的最高有效字节应填充 0。在数据包内的后续节拍中，该字段为保留字段。 |

2.5.1.2.3、User-Defined Port

用户自定义端口是一个可选端口，包含两个 AXI4-Stream 通道，其中一个通道用于发送方向，另一个通道用于接收方向。用户自定义端口仅使用 SRIO Stream 格式。图 2-6 展示了用户自定义端口。

注意：端口名称及描述均从 LOG 角度给出。

表 2-7 列出了与用户自定义端口相关的信号。s_axis_usrtx* 信号与 USER_IO_TX 接口相关联，而 m_axis_usrrx* 信号与 <component_name> 层的 USER_IO_RX 接口相关联。

Table 2-7: User-Defined Port Signal List

|----------------------------|-----------|-------------------------------------------------------------------------------------------------------------------------------------|
| Signal | Direction | Description |
| s_axis_usrtx_tvalid | Input | 指示通道上的信息有效。 |
| s_axis_usrtx_tready | Output | 握手信号。表示来自源端的数据已被接收（在有效的情况下）。 |
| s_axis_usrtx_tdata $63:0$ | Input | 数据包头部和数据。 |
| s_axis_usrtx_tkeep $7:0$ | Input | 字节限定符，用于指示关联数据字节的内容是否有效。对于 SRIO Stream 格式，该输入应设置为 8'hFF，但在 tlast 断言时除外。位 7 对应数据的最高有效字节（tdata $63:56$ ），位 0 对应最低有效字节（tdata $7:0$ ）。 |
| s_axis_usrtx_tlast | Input | 指示数据包的最后一个节拍。 |
| s_axis_usrtx_tuser $7:0$ | Input | 在 SRIO Stream 格式中，tuser 仅宽 8 位。位 1 用于设置数据包的临界请求流（CRF）标志，若 CRF 支持被禁用，则应将其绑定为 0。所有其他位均为保留位。在数据包内的后续节拍中，该字段为保留字段。 |
| m_axis_usrrx_tvalid | Output | 指示通道上的信息有效。 |
| m_axis_usrrx_tready | Input | 握手信号。表示来自源端的数据已被接收（在有效的情况下）。 |
| m_axis_usrrx_tdata $63:0$ | Output | 数据包头部和数据。 |
| m_axis_usrrx_tkeep $7:0$ | Output | 字节限定符，用于指示关联数据字节的内容是否有效。对于 SRIO Stream 格式，该输出设置为 8'hFF，但在 tlast 断言时除外。位 7 对应数据的最高有效字节（tdata $63:56$ ），位 0 对应最低有效字节（tdata $7:0$ ）。 |
| m_axis_usrrx_tlast | Output | 指示数据包的最后一个节拍。 |
| m_axis_usrrx_tuser $7:0$ | Output | 在 SRIO Stream 格式中，tuser 仅宽 8 位。若数据包的临界请求流（CRF）标志被设置，则位 1 被置位。所有其他位均为保留位。在数据包内的后续节拍中，该字段为保留字段。 |

2.5.1.2.4、Maintenance Port

若维护端口启用，则使用 AXI4-Lite 接口。该 AXI4-Lite 接口允许用户应用访问本地或远程配置空间。

2.5.1.2.4.1、AXI4-Lite Maintenance Port

图 2-7 展示了与 AXI4-Lite 维护端口相关联的 AXI4-Lite 通道。请求通过黑色通道（从右向左）进行传输，而 AXI4-Lite 响应则通过灰色通道（从左向右）返回。

注意：端口名称及描述均从 LOG 角度给出。

每个通道都有独立的 ready/valid 握手。维护端口的信号列表如表 2-8 所示。s_axi_maintr* 信号与 <component_name> 层的 MAINT_IF 接口相关联。

Table 2-8: Maintenance Port Signal List

|-----------------------------|-----------|----------------------------------------------------------------|
| Signal | Direction | Description |
| s_axi_maintr_rst | Input | maintr 接口的复位。用于清除未完成的数据包。旨在用于链路超时场景。 |
| s_axi_maintr_awvalid | Input | 表示写地址有效。 |
| s_axi_maintr_awready | Output | 握手信号。表示写地址已被接收（在有效的情况下）。 |
| s_axi_maintr_awaddr $31:0$ | Input | 写地址。 • $31:24$ - 跳计数 + 1（本地写操作为 8'h00） • $23:0$ - 写的配置偏移地址 |
| s_axi_maintr_wvalid | Input | 表示写数据有效。 |
| s_axi_maintr_wready | Output | 握手信号。表示写数据已被接收（在有效的情况下）。 |
| s_axi_maintr_wdata $31:0$ | Input | 写数据。 |
| s_axi_maintr_bvalid | Output | 表示写响应有效。 |
| s_axi_maintr_bready | Input | 握手信号。表示写响应已被接收（在有效的情况下）。 |
| s_axi_maintr_bresp $1:0$ | Output | 写响应。 • 2'b00 - 成功 • 2'b10 - 错误 • 2'bx1 - 保留 |
| s_axi_maintr_arvalid | Input | 表示读地址有效。 |
| s_axi_maintr_arready | Output | 握手信号。表示读地址已被接收（在有效的情况下）。 |
| s_axi_maintr_araddr $31:0$ | Input | 读地址。 • $31:24$ - 跳计数 + 1（本地读操作为 8'h00） • $23:0$ - 读的配置偏移地址 |
| s_axi_maintr_rvalid | Output | 表示读响应有效。 |
| s_axi_maintr_rready | Input | 握手信号。表示读响应已被接收（在有效的情况下）。 |
| s_axi_maintr_rresp $1:0$ | Output | 读响应。 • 2'b00 - 成功 • 2'b10 - 错误 • 2'bx1 - 保留 |
| s_axi_maintr_rdata $31:0$ | Output | 读取的数据。 |

2.5.1.2.5、Status

表 2-9 列出了提供状态信息的信号。

Table 2-9: Status Signal List

|-------------------|---------------|------------------------------------------------------------------------------------|
| Signal | Direction | Description |
| deviceid $15:0$ | Output | 当前存储在 Base DeviceID CSR（偏移地址 0x60）中的值。 |
| port_decode_error | Output | 表示接收到不支持的事务，且由于用户自定义端口未启用而被丢弃。当任一用户接口上出现下一个支持的数据包类型时，该信号将置为无效。该信号在 log_clk 时钟域下同步。 |

2.5.1.3、Configuration Fabric Interface

配置结构接口包含两个端口：

• Configuration Master port,用于通过配置结构对本地配置空间（针对 LOG、BUF 和 PHY）发起读写操作。

• LOG Configuration Register port,这是一个从接口，用于对定义为逻辑层或传输层一部分的寄存器进行读写操作。

表 2-10 列出了与配置主端口和 LOG 配置寄存器端口相关联的信号。

Table 2-10: LOG Configuration Fabric Interface Signal List

|---------------------------|---------------|--------------------------|
| Signal | Direction | Description |
| s_axi_cfgl_awvalid | Input | 表示写地址有效。 |
| s_axi_cfgl_awready | Output | 握手信号。表示写地址已被接收（在有效的情况下）。 |
| s_axi_cfgl_awaddr $23:0$ | Input | 写地址。 |
| s_axi_cfgl_wvalid | Input | 表示写数据有效。 |
| s_axi_cfgl_wready | Output | 握手信号。表示写数据已被接收（在有效的情况下）。 |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |

2.5.1.4、Transport Interface

传输接口包含一个发送端口和一个接收端口，并连接至缓冲层或直接连接至符合 RapidIO 规范的物理层。表 2-11 从 LOG 角度列出了与传输接口相关联的信号。

Table 2-11: LOG Transport Interface Signal List

|---------------------------|-----------|------------------------------|
| Signal | Direction | Description |
| m_axis_buft_tvalid | Output | 指示通道上的信息有效。 |
| m_axis_buft_tready | Input | 握手信号。表示来自源端的数据已被接收（在有效的情况下）。 |
| m_axis_buft_tdata $63:0$ | Output | 数据包头部和数据。输出数据包格式如图 3-5 所示。 |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |

2.5.2、Buffer Design Interfaces

与 PHY 一同生成的缓冲设计（BUF）用于实现发送和接收数据包的缓冲。BUF 对于保证数据包可靠传输和流控操作是必需的。Xilinx 提供了一种可配置的缓冲方案，允许在系统性能和资源需求之间进行权衡。

发送缓冲用于对输出事务进行排队，并管理这些数据包通过链路接口进入 PHY 的流程。TX 和 RX 缓冲大小可通过 Vivado IDE 配置为 8、16 或 32 个数据包的深度。TX 缓冲是一种存储转发缓冲，旨在实现低数据包间延迟，从而最大化流吞吐量。发送缓冲必须保留每个数据包，直至其被链路对端设备成功接收，此时该数据包才会被释放，为后续数据包腾出空间。当多个未发送数据包在缓冲中累积时（通常在流控发生时），BUF 会根据数据包类型和优先级进行重排序，优先发出响应包，再发出请求包。有关流控和数据包重排序的更多信息，请参阅第 3 章"Designing with the Core"。

此外，BUF 在必要时会处理时钟跨域。生成内核时，可以选择添加或移除跨时钟域逻辑。

建议：对于所有多通道内核，建议使用跨时钟域逻辑，因为 PHY 时钟在启动时以及链路训练降级场景下是动态变化的。这可以使用户逻辑以一致且已知的速率运行。

接收缓冲作为一个 FIFO，用于存储数据并将其转发到 LOG 的接收路径。接收缓冲还包含时跨钟域逻辑，允许逻辑层/用户设计与 PHY 以不同的时钟速率运行。与发送缓冲设计类似，建议在多通道内核中使用该逻辑。

BUF 的所有接口均在内部连接到 <component_name>_block 模块，并从封装层外部不可见。

注意：端口名称及描述均从 BUF 角度给出。

如图 2-8 所示，在 BUF 的 LOG 侧和 PHY 侧，每个方向上都各有两个 AXI4-Stream 通道。此外，还有一个连接到配置结构的 AXI4-Lite 接口，用于访问 BUF 配置空间。

2.5.2.1、Clock and Reset Interface

表 2-12 列出了 BUF 层的时钟和复位接口的相关信号。

Table 2-12: BUF Clock and Reset Interface Signal List

|-----------------|---------------|-------------------------------------------------------------------------------------------------------------------------|
| Signal | Direction | Description |
| buf_lcl_log_clk | Input | LOG 的时钟。注意：该信号与 log_clk 相同，log_clk 是本文件其他部分使用的名称。 |
| buf_lcl_phy_clk | Input | PHY 的时钟。注意：该信号与 phy_clk 相同，phy_clk 是本文件其他部分使用的名称。 |
| buf_rst | Input | BUF 的复位。异步输入。更多信息请参见第 3 章中的"复位"一节。 |
| buf_lcl_cfg_clk | Input | 配置寄存器接口时钟。若 AXI4-Lite 维护端口和配置结构参考设计正在使用，则该时钟必须与 log_clk 相同。否则，该时钟独立于 log_clk。注意：该信号与 cfg_clk 相同，cfg_clk 是本文件其他部分使用的名称。 |
| buf_lcl_cfg_rst | Input | 配置寄存器接口复位。将 BUF 寄存器复位为默认值。必须与 cfg_clk 同步解除复位。注意：该信号与 cfg_rst 相同，cfg_rst 是本文件其他部分使用的名称。 |

2.5.2.2、Transport Interface

表 2-13 列出了与 BUF 传输接口相关联的信号。

Table 2-13: BUF Transport Interface Signal List

|---------------------------|-----------|------------------------------|
| Signal | Direction | Description |
| s_axis_buft_tvalid | Input | 指示通道上的信息有效。 |
| s_axis_buft_tready | Output | 握手信号。表示来自源端的数据已被接收（在有效的情况下）。 |
| s_axis_buft_tdata $63:0$ | Input | 数据包头部和数据。 |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |

2.5.2.3、Link Interface

表 2-14 列出了与 BUF 链路接口相关联的信号。

Table 2-14: BUF Link Interface Signal List

|---------------------------|-----------|------------------------------|
| Signal | Direction | Description |
| m_axis_phyt_tvalid | Output | 指示通道上的信息有效。 |
| m_axis_phyt_tready | Input | 握手信号。表示来自源端的数据已被接收（在有效的情况下）。 |
| m_axis_phyt_tdata $63:0$ | Output | 数据包头部和数据。 |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |

2.5.2.4、BUF Configuration Fabric Interface

表 2-15 列出了与配置结构接口相关联的信号。

注意：表 2-15 中的所有信号名称均从 BUF 角度给出。

Table 2-15: BUF Configuration Fabric Interface Signal List

|---------------------------|---------------|--------------------------|
| Signal | Direction | Description |
| s_axi_cfgb_awvalid | Input | 表示写地址有效。 |
| s_axi_cfgb_awready | Output | 握手信号。表示写地址已被接收（在有效的情况下）。 |
| s_axi_cfgb_awaddr $23:0$ | Input | 写地址。 |
| s_axi_cfgb_wvalid | Input | 表示写数据有效。 |
| s_axi_cfgb_wready | Output | 握手信号。表示写数据已被接收（在有效的情况下）。 |
| s_axi_cfgb_wdata $31:0$ | Input | 写数据。 |
| s_axi_cfgb_wstrb $3:0$ | Input | 字节限定符，用于指示关联数据字节的内容是否有效。 |
| s_axi_cfgb_bvalid | Output | 表示写响应有效。 |
| s_axi_cfgb_bready | Input | 握手信号。表示写响应已被接收（在有效的情况下）。 |
| s_axi_cfgb_arvalid | Input | 表示读地址有效。 |
| | | |
| | | |
| | | |
| | | |

2.5.3、Physical Layer Interfaces

物理层（PHY）负责链路训练、初始化和协议处理。其工作包括向输出数据包中插入 CRC 和确认标识符。PHY 还与串行收发器进行接口。

这些收发器作为外部实例化提供给内核，以简化客户的使用模型。然而，PHY 到串行收发器的连接通过两个封装模块（PHY 封装和 <component_name>_block）进行了抽象。因此，收发器接口以及 BUF 接口均从 <component_name>_block 外部隐藏。

注意：端口名称及描述均从 PHY 角度给出。

如图2-9所示，在PHY的BUF侧，每个方向各有一个AXI4-Stream通道。此外，还有一个连接配置结构的AXI4-Lite接口，用于访问PHY的配置空间。在PHY的收发器侧，还有一个串行接口。

2.5.3.1、Clock and Reset Interface

表2-16列出了PHY层的时钟和复位接口的相关信号。

Table 2-16: PHY Clock and Reset Interface Signal List

|-----------------|---------------|----------------------------------------------------------------------------------------------------------------------------------|
| Signal | Direction | Description |
| phy_lcl_phy_clk | Input | 频率取决于串行传输频率和初始化链路宽度。如果核心训练到1x模式，phy_clk必须更改为1x速率。有关更多信息，请参阅第3章中的时钟。注意：此信号与phy_clk相同，phy_clk是本文档其他部分使用的名称。 |
| phy_rst | Input | PHY复位。必须与phy_clk同步取消激活。有关更多信息，请参阅第3章中的复位。 |
| gt_pcs_clk | Input | 串行接口的时钟信号。必须与phy_clk相位对齐。时钟速率基于核心的传输频率，是gt_clk的一半： •1.25 G-31.25 MHz •2.5G-62.5MHz •3.125 G-78.13 MHz •5G-125MHz •6.25 G-156MHz |
| gt_pcs_rst | Input | 串行接口复位。必须与gt_pcs_clk同步取消激活。有关更多信息，请参阅第3章中的复位。 |
| phy_lcl_cfg_clk | Input | 配置寄存器接口时钟。如果使用AXI4 Lite维护端口和配置结构参考设计，则必须与log_clk等效。否则，此时钟与log_clk无关。注意：此信号与cfg_clk相同，后者是本文档其他部分使用的名称。 |
| phy_lcl_cfg_rst | Input | 配置寄存器接口复位。将PHY寄存器清除为默认值。必须与cfg_clk同步取消激活。注意：此信号与cfg_rst相同，后者是本文档其他部分使用的名称。 |

2.5.3.2、GT Common Clock Interface

表2-17列出了GT通用时钟接口的相关信号。

Table 2-17: GT Common Clock Interface Signal List

|---------------------|---------------|-------------------------------------|
| Signal | Direction | Description |
| gt0_pll0_clk | Input | 仅适用于Artix7系列。指示GT公用PLL0的时钟 |
| gt0_pll0_refclk | Input | 仅适用于Artix7系列。表示GT Common PLL0的参考时钟 |
| gt0_pll1_clk | Input | 仅适用于Artix7系列。指示GT公共PLL1的时钟 |
| gt0_pll1_refclk | Input | 仅适用于Artix7系列。指示GT公共PLL1的参考时钟 |
| gt0_pll0_lock | Input | 仅适用于Artix7系列。表示GT Common的PLL0已锁定 |
| gt0_pll0_reset_out | Output | 仅适用于Artix7系列。复位GT Common的输入 |
| gt0_qpll_clk | Input | 仅适用于非Artix7系列。指示GT公共PLL的时钟 |
| gt0_qpll_out_refclk | Input | 仅适用于非Artix7系列。指示GT公共PLL的参考输出时钟 |
| gt0_qpll_lock | Input | 仅适用于非Artix7系列。表示GT公共PLL的时钟锁定 |

2.5.3.3、Link Interface

表2-18列出了与PHY链路接口相关的信号。

Table 2-18: PHY Link Interface Signal List

|---------------------------|---------------|----------------------------------------------------------------------------------------------------------------------|
| Signal | Direction | Description |
| s_axis_phyt_tvalid | Input | 表示通道上的信息有效。 |
| s_axis_phyt_tready | Output | 握手信号。表示（当有效时）来自源端的数据已被接收。** |
| s_axis_phyt_tdata $63:0$ | Input | 数据包头部和数据 |
| s_axis_phyt_tkeep $7:0$ | Input | 字节限定符，用于指示相关数据字节的内容是否有效。该输入应设置为 8'hFF，除非在断言 tlast 时。位 7 对应数据的最高有效字节（tdata $63:56$ ），位 0 对应数据的最低有效字节（tdata $7:0$ ）。 |
| s_axis_phyt_tlast | Input | 表示数据包的最后一个节拍。 |
| s_axis_phyt_tuser $7:0$ | Input | 在数据包的第一个节拍，若支持关键请求流（CRF）功能，则位 1 反映该数据包的 CRF 标志值。所有其他位均保留。在数据包的最后一个节拍，位 0 用作源端断传标志。若在 tlast 传输时位 0 为高电平，则该数据包应被丢弃。 |
| m_axis_phyr_tvalid | Output | 指示通道上的信息有效。 |
| m_axis_phyr_tready | Input | 握手信号。表示源端的数据已被接收（若有效）。 |
| m_axis_phyr_tdata $63:0$ | Output | 数据包头部及数据。 |
| | | |
| | | |

2.5.3.4、Serial Interface

表2-19列出了与串行接口相关的信号。

注意：LW = 链路宽度。

Table 2-19: PHY Serial Interface Signal List

|-------------------------------|---------------|-------------------------------------------------------------------|
| Signal | Direction | Description |
| gttx_data $32\*LW-1:0$ | Output | 向串行收发器发送数据。 |
| gttx_charisk $4\*LW-1:0$ | Output | 面向串行收发器的逐字节K字符指示信号。若位0置位，则gttx_data $7:0$ 为K字符，以此类推。 |
| gttx_inhibit $LW-1:0$ | Output | 面向串行收发器的逐通道抑制信号。若位0置位，则通道0的发送器被禁用，以此类推。 |
| gtrx_data $32\*LW-1:0$ | Input | 从串行收发器接收数据。 |
| gtrx_charisk $4\*LW-1:0$ | Input | 来自串行收发器的逐字节K字符指示信号。若位0置位，则gtrx_data $7:0$ 为K字符，以此类推。 |
| gtrx_chariscomma $4\*LW-1:0$ | Input | 来自串行收发器的逐字节逗号指示信号。若位0置位，则gtrx_data $7:0$ 为逗号字符，以此类推。 |
| gtrx_disperr $4\*LW-1:0$ | Input | 来自串行收发器的逐字节极性偏差错误指示信号。若位0置位，则表示gtrx_data $7:0$ 出现极性偏差错误，以此类推。 |
| gtrx_notintable $4\*LW-1:0$ | Input | 来自串行收发器的逐字节无效码表错误指示信号。若位0置位，则表示gtrx_data $7:0$ 出现8b/10b解码错误，以此类推。 |
| gtrx_chanbondseq $LW-1:0$ | Input | 来自串行收发器的逐通道通道绑定序列指示信号。若位0置位，则表示通道0接收到通道绑定序列，以此类推。 |
| gtrx_chanisaligned $LW-1:0$ | Input | 来自串行收发器的逐通道对齐指示信号。若位0置位，则表示通道0已与通道绑定主通道对齐，以此类推。 |
| gtrx_chanbonden | Output | 启用串行收发器中的通道绑定功能。 |
| gtrx_reset_req | Input | 串行收发器需要复位，例如由于弹性缓冲器下溢或上溢所致。 |
| gtrx_reset | Output | 串行收发器的复位信号。 |
| gtrx_reset_done $LW-1:0$ | Input | 逐通道指示信号，表示串行收发器的复位序列已完成。若位0置位，则表示通道0已完成复位过程，以此类推。 |

注释：

SRIO（Serial RapidIO）接口中的通道绑定（Lane Bonding），简单来说，就是把多个物理上的高速串行通道（Lane）"捆绑"在一起，形成一个逻辑上的单一、更高带宽的链路。

这项技术主要位于SRIO的物理层，其核心目的就是为了提升数据传输的总吞吐量。

为什么要通道绑定？

SRIO的每个通道（Lane）都有其固定的最大传输速率。在一些高带宽需求的场景下，单个通道的带宽可能成为瓶颈。通道绑定技术应运而生，它通过并行传输来成倍地扩展带宽。

例如，SRIO Gen2支持1x、2x和4x的通道绑定模式。这意味着你可以将最多4个通道绑定在一起。

单通道速率：最高可达6.25 Gbaud。
绑定后总带宽：如果绑定4个通道（4x模式），理论上的总带宽将提升至单通道的4倍。实际有效带宽会因编码开销（如8b/10b编码效率为80%）而略低，例如：6.25 Gbps × 4 × 0.8 = 20 Gbps的有效吞吐量。

通道绑定是如何工作的？

通道绑定的实现并非简单的"合并"，而是一个精密的协同过程，涉及到发送端和接收端的紧密配合。

发送端：将准备发送的数据流按照一定的规则（如轮询）拆分，并同时通过多个绑定的通道并行发送出去。这就像把一整块大蛋糕切成几份，同时通过几条传送带运送。
接收端：这是技术的关键所在。由于物理走线长度差异、温度变化等因素，不同通道上的信号到达接收端的时间会存在微小的差异，这种现象称为通道偏移（Skew） 。

为了正确重组数据，接收端必须执行通道对齐（Lane Alignment） 。它会利用SRIO协议中定义的特定同步码元 （如/K/、/R/等控制字符）来校准各个通道，消除通道间的偏移，确保从不同通道到达的数据能被正确地拼回原始顺序。

此外，接收端的弹性缓冲器还会补偿发送和接收两端时钟的微小差异，通过动态增删空闲码元来保证数据流的稳定，通道绑定逻辑需要能正确处理这些操作，避免对齐错误。

实际应用与设计考量

在FPGA中实现SRIO的通道绑定时，有几点需要特别注意：

硬件支持 ：通道绑定功能由FPGA内部的高速串行收发器（如Xilinx的GTP/GTX/GTH） 硬核逻辑直接支持。你只需要在配置SRIO IP核时，在GUI界面中选择所需的通道宽度（如x1, x2, x4）即可。IP核会自动生成相应的控制逻辑。
时钟架构 ：当绑定多个通道时，这些通道通常共用一个GT Quad中的QPLL（Quad Phase-Locked Loop） 作为时钟源，以保证同步性。这也会影响到整个系统的时钟设计，例如，物理层接口时钟（phy_clk）的频率就需要根据绑定的通道宽度来计算。
链路初始化 ：绑定后的链路作为一个整体进行初始化和训练。只有当所有绑定的通道都成功完成链路训练后，整个链路才会被标记为可用（link_initialized信号拉高），之后才能进行正常的数据传输。
性能与成本权衡：更宽的通道绑定（如x4）能带来更高的总带宽，但同时也需要占用更多的FPGA引脚、PCB布线空间和逻辑资源。在实际设计时，需要根据系统的带宽需求和硬件资源进行权衡。

2.5.3.5、Control and Status Interface

表2-20列出了与PHY控制/状态接口相关的信号。

|---------------------|---------------|----------------------------------------------------------------------------------|
| Signal | Direction | Description |
| sim_train_en | Input | 该信号用于缩短初始化定时器。在仿真时，srio_sim.v 中将该信号固定为 1。其他情况下，该信号在核内被赋值为 0。硬件实现时，应将其保持悬空或固定为 0。 |
| phy_mce | Input | 这是一个单周期输入信号，用于指示PHY发送MCE控制信号。 |
| phy_link_reset | Input | 只要该信号有效，PHY就会持续发送链路复位控制符。 |
| force_reinit | Input | 该信号强制PHY重新初始化链路。 |
| link_initialized | Output | 指示链路已完成初始化。具体而言，已发送至少15个状态控制符，并接收到8个无错误的状态控制符。 |
| phy_rcvd_mce | Output | 指示PHY已从链路对端接收到MCE控制符。 |
| phy_rcvd_link_reset | Output | 指示PHY已连续接收到至少四个无错误的链路复位控制符。注意：状态控制符和空闲符允许穿插在这些链路复位控制符之间。 |
| port_error | Output | 指示端口已收到不可恢复的错误并处于错误状态。该信号反映物理层配置中"端口n错误与状态CSR"寄存器的端口错误位值。 |
| port_initialized | Output | 指示端口已完成初始化。该信号反映物理层配置中"端口n错误与状态CSR"寄存器的端口未初始化位值。 |
| | | |
| | | |
| | | |

2.5.3.6、Configuration Fabric Interface

表2-21列出了与配置结构接口相关的信号。

Table 2-21: PHY Configuration Fabric Interface Signal List

|---------------------------|---------------|--------------------------|
| Signal | Direction | Description |
| s_axi_cfgp_awvalid | Input | 指示写地址有效。 |
| s_axi_cfgp_awready | Output | 握手信号。表示写地址已被接收（若有效）。 |
| s_axi_cfgp_awaddr $23:0$ | Input | 写地址。 |
| s_axi_cfgp_wvalid | Input | 指示写数据有效。 |
| s_axi_cfgp_wready | Output | 握手信号。表示写数据已被接收（若有效）。 |
| s_axi_cfgp_wdata $31:0$ | Input | 写数据。 |
| s_axi_cfgp_wstrb $3:0$ | Input | 字节限定符，用于指示相关数据字节的内容是否有效。 |
| | | |
| | | |
| | | |
| | | |

2.5.3.7、Serial Transceivers Interfaces

表2-22列出了与phy_wrapper中串行收发器模块接口相关的信号。

注意：端口名称和描述均从串行收发器的角度给出。LW = 链路宽度

Table 2-22: Serial Transceivers Interface Signal List

|------------|---------------|-------------------------------------------------------------------------------------------------------------------------------|
| Signal | Direction | Description |
| Clocks and Reset |||
| refclk | Input | 收发器的参考时钟，其频率取决于线路速率。有关支持的参考时钟频率的更多信息，请参见第3章中的时钟部分。 |
| gt_clk | Input | 收发器接口的时钟信号。必须与 phy_clk 相位对齐。时钟频率基于内核的传输频率： 1.25G - 62.5 MHz 2.5G - 125 MHz 3.125G - 156.25 MHz 5G - 250 MHz 6.25G - 312.5 MHz |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |

2.5.4、Configuration Fabric Reference Design Interfaces

配置结构参考设计用于管理对各子核配置空间的访问。每个子核中的配置模块作为配置总线（AXI-Lite接口）上的从设备，而配置结构模块则作为总线主设备。无论是本地发起还是来自链路对端的维护事务所产生的读写操作，都会通过LOG中的配置主端口呈现给配置结构。表2-23列出了与配置结构参考设计相关的信号。

Table 2-23: Configuration Fabric Reference Design Signal List

|---------------------| | Signal | cfg_clk | cfg_rst | LOG Master Port | cfgr_awvalid | cfgr_awready | cfgr_awaddr | Direction | Description |
| Input | 配置寄存器接口时钟。若使用AXI4-Lite维护端口和配置结构参考设计，则该时钟必须与log_clk保持一致。 |
| Input | 配置寄存器接口复位。必须与 cfg_clk 同步解除断言。 |
|||
| Input | 指示写地址有效。 |
| Output | 握手信号。指示写地址已被接受（若有效）。 |
class="md-editor-katex-inline">23:0 | Input | 写地址 |
class="md-editor-katex-inline">2:0 | Input | 接低电平 / 接地为 0。 |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |

2.5.4.1、Debug Interfaces

在 <component_name> 层级定义了三个接口（CORE_DEBUG、TRANCEIVER_DEBUG 和 SIDE_BAND_SIGNALS），用于对内核和 GTX/GTP 控制/状态信号进行分组。这些端口在调试 SRIO 内核和收发器时使用。表 2-24 列出了与这些总线接口相关的信号。

重要提示：收发器控制与状态接口中的端口必须按照相应的 GT 用户指南进行驱动。使用表 2-24 中所列的输入信号可能会导致 IP 核的行为不可预测。

Table 2-24: Debug Interfaces

|---------------|---------------------|---------------|------------------------------|---------------------------------------------------------------------------|
| Interface | Signal | Direction | Clock Domain Description | Description |
| CORE_DEBUG | phy_debug | Output | phy_clk | 位定义请参见表 C-3。 |
| CORE_DEBUG | gtrx_disperr_or | Output | gt_pcs_clk | 来自串行收发器的每字节极性错误指示。若 bit 0 置为有效，则表示 gtrx_data $7:0$ 存在极性错误，以此类推。 |
| CORE_DEBUG | gtrx_notinitable_or | Output | gt_pcs_clk | 来自串行收发器的每字节非表中错误指示。若 bit 0 置为有效，则表示 gtrx_data $7:0$ 存在 8b/10b 解码错误，以此类推。 |
| CORE_DEBUG | phy_rcvd_mce | Output | phy_clk | 表示 PHY 已从链路对端接收到 MCE 控制符号。 |
| CORE_DEBUG | phy_rcvd_link_reset | Output | phy_clk | 表示 PHY 已接收到至少四个连续且无错误的链路复位控制符号。 |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |

2.5.5、Register Space

寄存器空间的定义分布于 RapidIO 规范各处。表 2-25 展示了寄存器空间的结构，以及 SRIO Gen2 Endpoint 子核中各部分地址空间的归属。

Table 2-25: Register Space

|---------------------------------|--------------------------------------|--------------------|
| Configuration Space Byte Offset | RapidIO Specification Register Space | SRIO Gen2 Endpoint |
| 0x00 - 0x3C | 能力寄存器空间 | LOG(1) |
| 0x040 - 0xFC | 命令与状态寄存器空间 | LOG |
| 0x0100 - 0xFFFC | 扩展特性空间 | PHY |
| 0x010000 - 0xFFFFFC | 实现定义空间 | BUF, LOG(2) |

注：

LOG 中实现的处理元件特性 CAR 包含 RapidIO 规范第 6 部分"LP-串行物理层规范"中定义的位。
维护请求信息寄存器仅在使用 AXI4-Lite 维护端口时存在，位于 LOG 中。该寄存器存在于用户维护接口之后，无法被其他 AXI4 主设备访问（只能通过维护请求事务或从链路对端接收的请求进行访问）。

2.5.5.1、Capability Register Space

能力寄存器空间中的寄存器主要定义于 RapidIO 规范的第 1 至第 3 部分（不过处理元件特性 CAR 中包含定义于第 6 部分"RapidIO 规范 LP-串行物理层规范"中的位）。这些寄存器为只读，并与 LOG 中的命令与状态寄存器一同实现。

Table 2-26: Capability Register Map

|-------------------------------------|-------------------|
| Configuration Space Byte Offset | Register Name |
| 0x00 | 设备标识 CAR |
| 0x04 | 设备信息 CAR |
| 0x08 | 组件标识 CAR |
| 0x0C | 组件信息 CAR |
| 0x10 | 处理元件特性 CAR |
| 0x14 | 交换端口信息 CAR |
| 0x18 | 源操作 CAR |
| 0x1C | 目的操作 CAR |
| 0x20 - 0x3C | 保留 |

2.5.5.1.1、Device Identity CAR

该 CAR 定义了设备 ID 和设备厂商 ID。此 CAR 对用户不可访问且无法更改。读取该寄存器时，返回的值取决于目标设备。

Table 2-27: Device Identity CAR (Offset 0x0)

|-----------|-----------|------------------------|------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Bits | Field | Value | Access | Description |
| $31:16$ | Device ID | See Description Column | R | Device ID Zynq-7000: 16'h0480 Artix-7: 16'h0170 Virtex-7: 16'h0370 Kintex-7: 16'h0270 Kintex UltraScale: 16'h0285 Virtex UltraScale: 16'h0385 Zynq UltraScale+: 16'h485 Kintex UltraScale+: 16'h585 Virtex UltraScale+: 16'h685 |
| $15:0$ | 设备厂商 ID | 16'h000E | R | RIO 联盟分配给 Xilinx 的厂商 ID |

2.5.5.1.2、Device Information CAR

该 CAR 定义了关于设备的附加信息，例如设备版本标签、主版本号、次版本号和补丁版本。所有其他位均保留。

Table 2-28: Device Information CAR (Offset 0x4)

|-----------|-----------|-----------|------------|-------------------------------------------------------|
| Bits | Field | Value | Access | Description |
| $31:20$ | Reserved | 12'b0 | R | |
| $19:16$ | 设备版本标签 | 4'h2 | R | 设备版本标签。4'h2。表示该核依据 RapidIO 互连规范 2.2 版 $参考文献 13$ 设计。 |
| $15:12$ | Reserved | 4'h0 | R | |
| $11:8$ | 主版本号 | 4'h4 | R | 随每个主版本发布而更新 |
| $7:4$ | 次版本号 | 4'h0 | R | 随每个官方内核版本发布而更新 |
| $3:0$ | 补丁版本 | 4'h0 | R | 仅当修复缺陷时更新 |