✨Virtual Channel (VC) Mechanism（虚拟通道机制）
虚拟通道（VC）机制在PCI Express 6.0中用于通过网络传输不同类型的流量。其基本概念是创建独立的缓冲区和控制逻辑，这样不同的虚拟通道之间可以进行独立的数据流控制。这种设计解决了在数据传输中，某一流量可能造成全系统瓶颈的问题。
随着链路速度的提高，为了支持不同VC的独立流量控制，所需的缓冲区空间也随之增加。然而，通过使用共享流量控制（Shared Flow Control），可以降低资源需求。在这种模式下，流量通过将特定的流量类别（TC标签）映射到相应的虚拟通道（VC）来管理。
虚拟通道的建立是将一个或多个TC与指定的物理VC资源（由虚拟通道标识符VC ID确定）关联。系统软件负责这个配置过程。一旦初始化完成，所有启用的VC都会分享到一个共享的流量控制池。这种共享机制使得在多通道环境中，资源使用更加高效。
引入虚拟通道的原因包括：
- 流量隔离：不同的流量类别可以在不互相干扰的情况下进行处理，从而提高整体性能。
- 资源优化：通过共享流量控制和按需分配资源，减少对独立缓冲的需求，降低硬件成本。
- 质量服务（QoS）：支持优先级队列处理，可以根据不同流量的要求提供不同的服务质量。
✨Virtual Channel Identification (VC ID)
- 虚拟通道的支持：每个PCI Express端口（Port）可以支持最多8个虚拟通道。每个端口可以独立配置，依据特定的使用模型来决定支持的虚拟通道数量。
- VC ID机制：虚拟通道通过VC ID机制进行唯一标识。尽管数据链接层协议包（DLLP）包含VC ID信息用于流控计算，但事务层包（TLP）没有。因此，TLP与VC ID的关联是通过每个端口的事务类（TC）到虚拟通道（VC）的映射来实现。
- 扩展能力结构：所有支持VC0以外虚拟通道的端口必须提供至少一个VC扩展能力结构。对于只支持默认TC0/VC0配置的端口，提供这些扩展结构是可选的。
- 配置要求：配置软件需要确保链路两端的端口配置匹配的虚拟通道数量。这通过扫描设备层次结构并使用相关的扩展能力寄存器来完成。
- VC ID的分配规则：
○ VC ID必须在每个端口内唯一，不能在同一端口内重复使用。
○ 两端口之间的VC ID分配必须一致（数量和ID匹配）。
○ 如果多功能设备（MFD）实现了MFVC扩展能力结构，其VC硬件资源与功能的VC扩展能力结构分开，并且每个方案的VC ID唯一性仍需遵守。
○ VC ID 0被分配并固定为默认虚拟通道。
✨TC 到 VC 映射
- 每个支持的流量类别必须映射到一个虚拟通道。TC0到VC0的映射是固定的。
- 除TC0之外的流量类别到虚拟通道的映射是由系统软件自行决定的，但必须遵循以下规则：
○ 一个或多个流量类别（TCs）可以映射到一个虚拟通道（VC）。
○ 一个流量类别不能在同一个端口或端点功能中映射到多个虚拟通道。
○ TC/VC的映射必须在链接的两端的端口之间保持一致。
✨ VC and TC Rules
支持要求：
○ 所有设备必须支持通用I/O流量类别（TC0），并实现默认的VC0。
独立流控：
○ 每个虚拟通道（VC）具有独立的流量控制（Flow Control）。
无序要求：
○ 不同的流量类别（TC）之间没有排列顺序要求。
○ 不同的虚拟通道（VC）之间也没有排列顺序要求。
对等能力：
○ Switch的对等能力适用于所有支持的虚拟通道。
○ 多功能设备（MFD）在不同功能之间的对等能力也适用于所有支持的虚拟通道。
无效事务处理：
○ 如果在入口端口有不映射到任何启用的VC的TC，接收设备将视其为无效事务（Malformed TLP）。
○ 对于Switch，如果目标出口端口的TC未映射到任何启用的VC，同样会被视为无效事务。
○ 根端口（Root Port）对未映射到目标RCRB启用VC的TC也将视为无效事务。
○ 对于具有MFVC扩展能力结构的多功能设备，未映射到启用VC的TC事务将被视为无效事务。
映射配置：
○ Switch必须支持每个端口的独立TC/VC映射配置。
○ 根复合体（Root Complex）必须支持每个RCRB、相关根端口和RCiEP的独立TC/VC映射配置。
✨排序和接收缓冲区流控制
🌟流量控制的目的：
○ 流量控制用于防止接收方缓冲区溢出，并确保遵循分层规则及数据传输的顺序。
○ 流量控制在链路（Link）上是点对点的，即只涉及请求方和响应方之间的通信，而不是端到端的控制。
🌟流量控制的独立性：
○ 流量控制与实现可靠信息交换的数据完整性机制是正交的。数据完整性机制确保在传输过程中丢失或损坏的事务级别报文（TLP）会通过重传进行修正。
🌟Non-Flit模式与Flit模式：
○ 在Non-Flit模式中，每个虚拟通道（VC）都有独立的流量控制信用池。
○ 在Flit模式中，使用共享流量控制（Shared FC）来减少虚拟通道的资源需求。在此模式下，每个VC都有两个资源集合：一个（通常很小的）专用资源池与每个 FC/VC 独立关联（通过允许发送器仅使用专用信用在该 VC/FC 中传输至少一个 TLP 来避免死锁）以及（通常较大的）共享资源池的一部分。对于支持 Flit 模式的端口，发送器必须支持共享 FC，接收器可以选择支持共享 FC。
Shared FC Buffer，该 Buffer Size 相对较大，是一种 VC 间共享的 Buffer，所有类型 TC 的 TLP 均可使用，或者说送到任意一个 Rx VC 的 TLP 都可以使用。
Dedicated FC Buffer，该 Buffer Size 相对较小，是一种该 VC 独享的 Buffer，只能当前由映射到当前 VC 的 TC TLP 使用，其他类型 TC 的 TLP 不能使用。该 Buffer 内至少能容纳一笔该 VC/FC 的该类型 TLP。
✨TX FC的门控逻辑
对于发送端而言，即使 Shared Credits 足够，也可以直接要求 Rx 使用 Dedicated Buffer。若想发送 Dedicated TLP，需要对该 TLP 添加 Flit Mode Local TLP Prefix，并将其中的 TLP Uses Dedicated Credits bit 置一。
✨FC的信用类型
PCIe 提供了多种事务类别（Traffic Class, TC） 及虚通道（Virtual Channel, VC）来对不同紧要程度的 TLP 提供有别的服务质量（Quality of Servide, QoS）。在常规流控（Normal Flow Control）机制中，每个 VC 均需 6 块 Rx FC Buffer 来独立进行流控：PH、PD、NPH、NPD、CPLH、CPLD。
✨FC 初始化及更新
若开启了 Shared Flow Control，在流控初始化过程中分别需要对 Dedicated Credit 及 Shared Credit 进行通报。具体而言，先按照 InitFC-P -> InitFC-NP -> InitFC-Cpl 的顺序通报 Dedicated Credit，然后按照该顺序通报 Shared Credit。Credit 更新时亦然。Credit 初始化及更新时，并没有一种专用于 Shared Flow Control 的新的 DLLP，而是采用原有 InitFC1、InitFC2 及 UpdateFC DLLP 中的 bit27 来指示当前为 Dedicated 还是 Shared，为 1 表示为 Dedicated Flow Control。支持 Shared Flow Control 的 UpdateFC DLLP 格式。
