---

3.6 Data Integrity Mechansisms

3.6.1 Introduction

事务层向数据链路层提供TLP边界信息。这允许数据链路层将TLP Sequence Number和LCRC应用于TLP的错误检测。接收数据链路层通过检查TLP Sequence Number,LCRC和来自接收物理层的任何错误指示来验证接收到的TLP。如果这些错误中的任何一个在TLP中，则使用数据链路层重试进行恢复。

Figure 3-14显示了添加了TLP Sequence Number和LCRC的TLP格式。

在支持协议复用的端口上，在 Symbol+0中包含非零值的数据包，bit 7:4是PMUX数据包。对于TLP，这些位必须为0000b。有关详细信息，请参见Appendix G。

在不支持协议多路复用的端口上，Symbol+0 的bit 7:4被保留。

Figure 3-14 TLP with LCRC and TLP Sequence Number Applied

3.6.2 LCRC, Sequence Number, and Retry Management (TLP Transmitter)

数据链路层通过添加TLP Sequence Number和LCRC来确保每个TLP传输的完整性。TLP存储在一个重试缓冲区中，除非从其他组件收到了肯定的接收确认，否则数据链路层会尝试重传。如果重复尝试发送TLP失败，则发送器认为链路不能正确运行，于是指示物理层重新训练链路。如果链路重新训练失败，则物理层将指示链路不再可用，从而导致DLCMSM转移到 DLnactive 状态。

概念上的 "counters"和“'flags"来描述TLP LCRC和TLP Sequence Number 以及支持数据链路层重试的机制。此描述不暗示也不要求特定的实现，仅用于阐明要求。

3.6.2.1 LCRC and Sequence Number Rules (TLP Transmitter)

以下计数器和计时器用于解释本节中的其余规则：

• 使用了两个12-bit的计数器：
  • NEXT_TRANSMIT_SEQ-存储用于TLP的Sequence Number。该计数器为每个将发送的新的TLP分配序列号，每个新TLP其值加1，计数到4095时重新返回0。
    • 在DL_Inactive 状态设置为0。
  • ACKD_SEQ-存储最近收到的Ack或Nak DLLP中的序列号（即AckNak_Seq_Num字段的值，NEXT_TRANSMIT_SEQ
    与此值的差值的模表示有多少TLP未被响应）。
    • 在DL_Inactive状态设置为FFFh。
• 使用了一个2-bit的计数器：
  • REPLAY_NUM-计算重试缓冲区已重新发送该TLP的次数。当REPLAY_NUM从2’b11翻转到2’b00时会触发一次物理层的链路重新训练，在重新训练之后，再次尝试重发该TLP。无论何时收到ACK，此计数器也会复位为2’b00。
    • 在DL_Inactive 状态设置为0。
• 使用了下述计时器：
  • REPLAY_TIMER-根据以下规则计算需要重试的时间。或者理解为用来度量从发出TLP到收到对应的ACK或NAK DLLP的时间。
    • 从任何TLP传输或重传的最后一个符号开始。
    • 对于每个重试，在发送要重传的第一个TLP的最后一个符号时，重置并重新启动REPLAY_TIMER。
    • 在还有更多未确认的TLP要发送时，当且仅当接收到的Ack DLLP确认重试缓冲区中的某些TLP时，对于收到的每个Ack DLLP重置并重新启动 REPLAY_TIMER。
      • 注意：这样可确保仅在TLP正在传递过程时重置REPLAY_TIMER。
    • 当收到Nak、或当REPLAY_TIMER到期，需要重置REPLAY_TIMER直到重发条件满足。
    • 链路重新训练期间REPLAY_TIMER值不增加（即当LTSSM处于 Recovery或Configuration状态时保持其值）。请参阅Section 4.2.5.3和Section 4.2.5.4。
    • 如果支持协议多路复用，则可以选择在接收PMUX数据包期间不增加REPLAY_TIMER的值（PMUX请参阅Appendix G)。
    • 如果以Nak响应的TLP都解决了，则REPLAY_TIMER重置并保持。

以下规则描述了TLP在传递到物理层之前如何准备进行传输：

• 事务层在传输TLP时会向数据链路层指示TLP的开始和结束。
  - 数据链路层将TLP视为“黑盒”，并且不处理或修改TLP的内容。
• 当数据链路层从事务层的发送端接受每个TLP时，会为其分配一个12位序列号。
  • 在从事务层接受TLP时，通过以下方式将数据包序列号应用于TLP：
    • 把12-bit的NEXT_TRANSMIT_SEQ添加到TLP的头部。
    • 在序列号之前添加4bit保留位（请参见Figure 3-15）。
    • 如果(NEXT_TRANSMIT_SEQ – ACKD_SEQ) mod 4096 >= 2048为真，发送器必须停止从事务层接受TLP，直到等式不再成立为止。这还会报告一个致命的、无法修正的数据链路层协议错误。
    • 在将NEXT_TRANSMIT_SEQ应用于从事务层的发送方接受的TLP之后，NEXT_TRANSMIT_SEQ递增（除非TLP为空）：NEXT_TRANSMITSEQ:=(NEXTTRANSMITSEQ+1)mod4096

Figure 3-15 TLP Following Application of TLP Sequence Number and Reserved Bits

• 数据链路层使用32-bit LCRC保护TLP数据完整性。

• 使用以下机制计算LCRC值（see Figure 3-16)：

  • 多项式系数为04C11DB7h。

  • seed值为 FFFFFFFh

  • 序列号和TLP用于计算LCRC(see Figure 3-15）。

  • LCRC计算从byte 0的bit 0(TLP序列号的bit 8）开始，并从每个连续字节的bit0到bit7进行。

    • 请注意，LCRC计算使用TLP的所有位，而与字段类型无关，包括保留字段。

  • 补全LCRC计算的其余部分，并将补全后的结果位映射到32位LCRC字段中，如Table 3-6所示。

Table 3-6 Mapping of Bits into LCRC Field

◆ -从事务层收到这些字节之后，将32位LCRC字段附加到TLP（请参见Figure 3-16）。

为了支持TLP的直通路由，允许发送器修改发送的TLP，以指示接收器必须忽略该TLP（“作废”TLP）。

• 允许发送器作废正在发送的TLP；为了防止误解或损坏TLP，发送器必须执行以下操作：

  • 当物理层使用128b/130b编码时，发送TLP的所有DW（请参阅Section 4.2.2.3.1）。

  • 使用计算出的LCRC值的其余部分并且不进行反转（正常使用时LCRC值会逻辑反转）。

  • 向物理层指示该TLP无效。

• 完成此操作后，发送器不会递增NEXT_TRANSMIT_SEQ。

以下规则描述了数据链路层重试缓冲区的操作，必要时将从中重新发送TLP：

• 传输的TLP副本必须存储在数据链路层重试缓冲区中，但无效的TLP除外。

当由于接收到Nak或由于REPLAY_TIMER到期而触发重发时，以下规则描述了必须遵循的操作顺序：

• 如果已确认所有传输的TLP(Retry Buffer为空），请终止重发，否则继续。

• REPLAY_NUM递增。当通过接收确认重试缓冲区中某些TLP的Nak触发重发时，将重置REPLAY_NUM。然后允许（但不是必需）递增。

  • 如果REPLAY_NUM从11b翻转到00b，发送器将向物理层发送信号以重新训练链路，并在重新进行重发之前等待重新训练的完成。这会报告与端口相关的错误（请参见Section6.2）。

    Note：除非物理层报告 Physical LinkUp=0b（导致数据链路控制和管理状态机转换到DL_Inactive状态），否则此操作不会重置数据链路层状态（包括重试缓冲区的内容）。

  • 如果REPLAY_NUM不能从11b翻转到00b，请继续重发。

• 阻止从事务层接受新的TLP。

• 完成当前正在传输的任何TLP的传输。

• 重传响应了Nak的TLP，从最早响应Nak的TLP开始，以最初传输顺序发送。

  • 发送第一个要重传的TLP的最后一个符号时，重置并重新启动REPLAY_TIMER。

  • 一旦所有响应Nak的TLP被重新发送，请返回正常操作。

  • 如果在重发期间收到任何Ack或Nak DLLP，则允许发送器完成重发而无需考虑Ack或Nak DLLP，或者跳过任何新确认的TLP。

    • 发送器一旦开始重新发送TLP，则在所有情况下都必须完成该TLP的发送。

  • 重发期间收到的Ack和Nak DLLP必须进行处理，并且可能会折叠。

    • 如果收到多个Ack，则仅应考虑指定最新序列号值的Ack-指定较早序列号值的Ack实际上会“折叠”到该Ack 中。

    • 在重发期间，会收到Nak，接着是一个Ack，该Ack指定了后面的序列号-Ack取代了Nak，而Nak被忽略。

    注意：由于发送器的流控制选通逻辑已在接收器中为重试缓冲区中的所有条目分配了空间，因此无需进一步进行流控制同步。

• 事务层重新启用TLP的接收。

重发可以通过REPLAY_TIMER到期或接收到Nak来启动。以下规则涵盖REPLAY_TIMER的有效期：

TLP传输过程中有一个重传（Replay）机制，当经过“一段时间＂后，发送端仍然没有收到接收端返回的Ack或者Nak信息，就会触发重新发送TLP。这里的＂一段时间＂有个专业名字叫做＂REPLAY_TIMER＂。在PCle 3.0 Spec中，对于REPLAY_TIMER的定义，不偏不倚，2.5GT/s,5GT/s,8GT/s三个传输速率均有专属的定义，参【PCIE3.0】Table 3-4、Table 3-5和 Table 3-6。

到了PCle 4.0,PCI-SIG协会自己都不想再为16GT/s单独增加另外一个REPLAY_TIMER Table。于是，提出了更加简便的REPLAY_TIMER Limits。这下，对于所有的速率就都只有两个选择了，如下Extended Synch 字段所描述。Extended Synch字段在Link Control Register 中设置。

对于这个简化的REPLAY_TIMER，当PCle链路运行在2.5GT/5.0GT/8.0GT时，实现时可以选择无视，依然选择原本的定义方式。但是，当PCle链路运行在16GT/s或以上时，就必须实现 Simplified REPLAY_TIMER Limit。

• 如果发送重试缓冲区包含未收到Ack或Nak DLLP的TLP，并且（如REPLAY_TIMER所示）在超过REPLAY_TIMER限制的时间内未收到Ack或Nak DLLP，则发送器将启动Replay。
  • Simplified REPLAY_TIMER Limit 为：
    • 当Extended Synch字段清0时，为24000到31000个Symbol Time。
    • 当Extended Synch字段置1时，为80000到100000个Symbol Time。
    • 如果Extended Synch字段在未确认的TLP处于outstanding时改变状态，则允许实现在Extended Synch字段改变状态时或下次复位REPLAY_TIMER时调整其REPLAY_TIMER Limit。
  • 支持16.0GT/s或更高数据速率的实现必须使用Simplified REPLAY_TIMER Limit，以便在所有数据速率下进行操作。
  • 强烈建议仅支持低于16.0 GT/s的数据速率的实现在所有数据速率下使用Simplified REPLAY_TIMER Limit，但依然允许它们使用［PCle-3.1］中描述的REPLAY_TIMER Limit。

这是一个重发计时器超时错误，是与端口相关的报告错误（请参见Section 6.2）。

IMPLEMENTATION NOTE

Determining REPLAY_TIMER Limit Values Replay 主要由 Nak DLLP 启动，而REPLAY_TIMER作为辅助机制。由于它是辅助机制，因此REPLAY_TIMER Limit 对跨链路传输 TLP 所需的平均时间影响相对较小。本规范又定义了Simplified REPLAY _TIMER Limit ，因此与本规范的先前版本一样，无需对ASPM LOs ， Retimer 或其他项进行调整。

TLP发送器和一致性测试必须根据在TLP发送器端口上测量的重发时序。该时序以发送的TLP的最后一个符号或接收到的Ack DLLP 的最后一个符号开始，主要看哪个是最早响应Nak的TLP。该时序以TLP重传的第一个符号结尾。

在测量重发时序到TLP重发开始的时间点时，一致性测试必须允许在该方向上已经在进行任何其他TLP或DLLP传输（从而防止TLP重发）。

IMPLEMENTATION NOTE

Recommended Priority of Scheduled Transmissions

如果计划传输多个相同类型的DLLP但尚未传输，则在多数情况下有可能将它们“折叠”为单个DLLP。例如，如果已调度的Ack DLLP 传输停顿以等待另一次传输完成，并且在此期间已调度另-Ack进行传输，则仅需要传输第二个Ack，因为它提供的信息将取代第一个Ack中的信息。

除了来自事务层（或重试缓冲区，如果正在进行重发）的任何TLP之外，还可以同时调度多个不同类型的DLLP进行传输，此时必须对这些DLLP区分优先级进行传输。以下列表显示了选择传输信息的首选优先级顺序。请注意，未列出特定于供应商的DLLP 的优先级，因为这完全是特定于实现的，因此没有建议的优先级。请注意，此优先级顺序是一个准则，并且在所有情况下都强烈建议采用一种公平机制，以确保任何类型的业务流不会导致任何其他类型的业务流长时间或无限期地被阻塞。请注意，Ack Latency 值和 REPLAY_TIMER限制指定了在组件的端口上测量的要求，并且组件的内部仲裁策略必须确保满足这些外部测量的要求

1. 当前正在进行的任何传输（TLP 或DLLP ）的完成包（最高优先级）。 2. Nak DLLP。 3. 由于以下原因，需要尽快安排Ack DLLP 传输：收到一个副本TLP （重传过来的TLP ）或Ack 延迟计时器到期（see Section 3 . 6 . 3 . 1 ）。 4. 满足 Section 2.6 要求的FC DLLP 传输。 5. 重试缓冲区重传。 6. 来自事务层的TLP 。 7. 不满足Section 2.6 要求的FC DLLP 传输。 8. 所有其他DLLP 的传输（最低优先级）。

3.6.2.2 Handling of Received DLLPs

由于Ack/Nak和Flow Control DLLP影响对端发送过来的TLP，因此数据链路层中的TLP传输机制还负责处理从链路上其他组件接收的Ack/Nak和Flow Control DLLP。这些DLLP是根据以下规则处理的（请参阅Figure 3-17)：

• 如果物理层指示接收器错误，则丢弃当前正在接收的任何DLLP并释放为该DLLP分配的任何存储。请注意，将此类错误报告给软件是由物理层完成的（因此，数据链路层不会报告）。
• 对所有收到的DLLP执行以下CRC检查过程：
  • 对接收的DLLP应用于发送相同的DLLP的算法，不包括接收的DLLP的16-bit CRC字段。
  • 比较该计算值与DLLP中携带的16-bit CRC的值。
    • 如果不相等，则DLLP被损坏。
  • 接收到损坏了的DLLP将被丢弃，并且是与端口相关的报告错误（请参见Section 6.2）。
• 接收到的未损坏但使用不受支持的DLLP Type编码的DLLP会被丢弃，而无需采取进一步措施。这不被视为错误。
• 保留字段中的非零值将被忽略。
• 接收者必须按照接收到的速率处理所有接收到的DLLP。

Figure 3-17 Received DLLP Error Check Flowchart

• 把接收到的FCDLLP传递到事务层。

• 把接收到的PM DLLP传递到组件的电源管理控制逻辑。

• 对于Ack和Nak DLLP，请遵循以下处理步骤（请参阅Figure 3-18)：

  • 如果由AckNak_Seq_Num指示的Sequence Number不与任何响应Nak的TLP对应，或不与ACKD_SEQ值对应，则DLLP 将被丢弃。
    • 这是一个数据链路协议错误，是一个与端口相关的报告错误（参见Section 6.2）。

  Note：只要指示的Sequence Number与ACKD_SEQ值匹配，当TLP（包括复位和第一次TLP传输之间的时间）全部被确认，接收Ack DLLP并不是错误。

  • 如果AckNak_Seq_Num没有指示为一个最近响应Ack的TLP的Sequence Number，则用Ack
    DLLP响应重试缓冲区中的某些TLP：

    • 从重试缓冲区中清除所有TLP，从最早的到对应于AckNak_Seq_Num的TLP。

    • 使用AckNak_Seq_Num字段中的值加载ACKD_SEQ。

    • 重置REPLAY_NUM和 REPLAY_TIMER。

    • 如果DLLP是Nak，则触发 Replay过程（请参见上文）。

Note：收到Nak不报告错误。

Figure 3-18 Ack/Nak DLLP Processing Flowchart

以下规则描述了数据链路层重试缓冲区的操作，必要时将从中重新发送TLP：

• 发送的TLP副本必须存储在数据链路层重试缓冲区中。

3.6.3 LCRC and Sequence Number (TLP Receiver)

数据链路层的TLP Receiver负责检查LCRC和TLP Sequence Number，并决定是否传递给事务层、或者请求重发。

概念上的 "counters"和 flags"来描述TLP LCRC和 TLP Sequence Number 以及支持数据链路层重试的机制。此描述不暗示也不要求特定的实现，仅用于阐明要求。

3.6.3.1 LCRC and Sequence Number Rules (TLP Receiver)

• 使用了一个12-bit的计数器：

  • NEXT_RCV_SEQ-存储下一个TLP的期望 Sequence Number值。
    • 在DL_Inactive状态重置为 0∘

• 使用了下述flag：

  • NAK_SCHEDULED
    • 在DL_Inactive 状态重置为0b。

• 使用了下述计时器：

  • AckNak_LATENCY_TIMER-根据以下规则对Ack DLLP何时调度传输的时间进行计数：
    • 在DL_Inactive 状态重置为0。
    • 每次调度发送Ack或Nak DLLP时该值都从0重新开始；用Ack DLLP确认收到的所有TLP时重置为0。
    • 如果最初没有未确认的TLP，然后接收到TLP，则只有当TLP已转发到接收事务层时，AckNak_LATENCY_TIMER才开始计数。

依次应用以下规则来描述如何处理接收到的TLP，以及哪些事件触发了Ack和Nak DLLP的传输（请参见 Figure3-19)：

• 如果物理层报告一个Receiver Error，则丢弃当前正在接收的任何TLP，并释放为该TLP分配的任何存储。请注意，将此类错误报告给软件是由物理层完成的（因此，数据链路层不会报告）。

  • 如果物理层在报告Receiver Error时正在接收TLP，并且NAK_SCHEDULED标志清为0，
    • 立即调度一个Nak DLLP发送出去。
    • 把NAK_SCHEDULED是为1。

• 如果物理层报告接收到的TLP为空，并且LCRC为计算值的逻辑非，则丢弃TLP并释放为TLP分配的任何存储。这不被视为错误。

• 如果TLP无效，但LCRC与计算值的逻辑非匹配，则TLP损坏-丢弃TLP并释放为TLP分配的任何存储。

  • 如果NAK_SCHEDULED标志清为0，

    • 立即调度一个Nak DLLP发送出去。

    • 把NAK_SCHEDULED是为1。

  这是Bad TLP错误，是报告的与端口相关的错误（请参见Section 6.2）。

• 按以下方式检查LCRC：

  • 对接收到的TLP应用与上述计算相同的算法，不包括接收到的TLP的32位LCRC字段。

  • 把计算的值与数据链路层TLP携带的LCRC比较：

    • 如果不相等，则TLP损坏-丢弃TLP并释放为TLP分配的任何存储。

      • 如果NAK_SCHEDULED标志清为0，

        • 立即调度一个Nak DLLP发送出去。

        • 把NAK_SCHEDULED是为1。

  这是Bad TLP错误，是报告的与端口相关的错误（请参见Section 6.2）。

• 如果TLP Sequence Number 不等于期望值，则存储在NEXT_RCV_SEQ中：

  • 丢弃TLP并释放为TLP分配的任何存储。

  • 如果TLP Sequence Number 满足以下方程式：

  (NEXT_RCV_SEQ - TLP Sequence Number) mod 4096 <= 2048

  则TLP是对方重发过来的，需要为此传输Ack DLLP（根据传输优先级规则）。

  • 否则，TLP顺序不正确（指示一个或多个丢失的TLP)：

    • 如果NAK_SCHEDULED标志清为0，

      • 立即调度一个Nak DLLP发送出去。

      • 把NAK_SCHEDULED是为1。

  这是Bad TLP错误，是报告的与端口相关的错误（请参见Section 6.2）。

无论NAK_SCHEDULED的状态如何，都可以将其报告为与端口相关的错误（请参见Section 6.2节），并且这种允许的行为如Figure 3-17所示。但是，为了防止错误污染，建议仅当NAK_SCHEDULED 标志清零时，端口才报告此类错误。

• 如果TLP Sequence Number等于存储在NEXTCVEQ中的期望值：

  • 删除4-bit的保留位、TLP Sequence Number和LCRC（见Figure 3-12)，并发送到事务处理层。

    • 数据链路层在传输TLP时向事务层指示TLP的开始和结束。
      • 数据链路层将TLP视为“黑盒”，并且不处理或修改TLP的内容。
    • 请注意，在将TLP转发到事务层之前，接收方流控制机制不会考虑任何接收到的TLP。

  • NEXTCVEQ递增。

  • 如果NAK_SCHEDULED为1，则清为0∘

Figure 3-19 Receive Data Link Layer Handling of TLPS

• TLP接收器必须调度一个Ack DLLP，以便在满足以下所有条件的情况下进行传输：

  • 数据链路控制和管理状态机处于DL_Active状态。

  • TLP已转发到接收事务层，但尚未通过发送Ack DLLP进行确认。

  • AckNak_LATENCY_TIMER达到或超过Table 3-7（对于2.5 GT/s操作模式）,Table 3-8（对于5.0 GT/s操作模式）和Table 3-9（对于8.0GT/s以上操作模式）指定的值。

  • 用于Ack DLLP传输的链路已处于LO状中或已转换到LO状态。

  • Note：如果链路尚未在LO中，则链路必须转换为LO才能传输Ack DLLP。

  • 当前没有在用于Ack DLLP传输的链路上传输另一个TLP或DLLP。

  • NAK_SCHEDULED清为0。

  • Note：每次调度发送Ack或Nak DLLP时，都必须从0重新启动AckNak_LATENCY_TIMER。

• 数据链路层Ack DLLP的调度时间可能比所需的时间更频繁。

• 为数据链路层Ack和Nak DLLP的AckNak_Seq_Num字段指定（NEXT_RCV_SEQ-1）值。

Table 3-7,Table 3-8和Table 3-9定义了 AckNak_LATENCY_TIMER的阈值，在任何特定情况下，该阈值都称为Ack Latency Limit。

TLP接收器和一致性测试必须根据在TLP Receiver的端口上测量的Ack Latency时序为基础，从接收到TLP的最后一个符号开始到Ack<DLLP第一个符号发送出去结束。

在发送Ack DLLP之前进行测量时，一致性测试必须允许已经有TLP或其他DLLP在该方向上传输（从而保证了Ack DLLP传输）。如果LOs使能，则一致性测试必须允许Ack DLLP传输方向上链路的LOs退出延迟。如果Link Control寄存器的Extended Synch字段被设置，则一致性测试还必须考虑其对LOs退出延迟的影响。

不需要TLP接收器根据LOs退出延迟或Extended Synch的值来调整其Ack DLLP的调度。

Table 3-7 Maximum Ack Latency Limits for 2.5 GT/s (Symbol Times)

IMPLEMENTATION NOTE

Retry Buffer Sizing

Retry Buffer 应足够大，以确保在正常操作条件下不会因为重试缓冲区满而导致传输被限制。在确定最佳缓冲区大小时，必须考虑Ack Latency值、由接收器已经发送另-TLP引起的Ack延迟、由物理链路互连引起的延迟以及处理接收到的Ack DLLP所需的时间。

给定两个组件A和B，在调整A的发送重试缓冲区的大小时，应考虑A的Receiver要求的LOs退出延迟，如下例所示：

• A在其到B的传输路径上退出LOs，然后开始向B发送长突发的写请求。
• B会在其通往A的传输路径上发起LOs退出，但是A的接收方所需的LOs退出时间很长。
• 同时，B无法将Ack DLLP发送给A，并且A由于缺少重试缓冲区空间而停止。
• 从B到A的传输路径返回到LO,B向A传输Ack DLLP，并且停顿得到解决。

通过使组件的发送器重试缓冲区的大小与组件的接收器所需的LOs退出延迟匹配，或者从相反角度考虑，通过使接收器LOs的退出延迟与所需的重试缓冲区大小匹配，可以避免这种停顿。

选择AckFactor值是为了允许实现良好的性能，而不需要高成本的大重试缓冲区。为了在具有不同实现和应用程序的通用互连中实现一致的性能，有必要对所有组件设置相同的要求，而不考虑任何特定组件的应用程序空间。如果组件不需要链路的全部传输带宽，则可以将其重试缓冲区的大小减小到指定的Ack Latency值保持可用的重试缓冲区空间所需的最小大小以下。

请注意，指定的Ack Latency值可确保允许的outstanding TLP序列号的范围永远不会成为导致传输停顿的限制因素。