USB 2.0 TT 拆分事务技术解析：原理、计算与设计逻辑

事务转换器（TT，Transaction Translator）是 USB 2.0 高速（HS，120Mbps）总线兼容全速（FS，12Mbps）/低速（LS，1.5Mbps）设备的核心组件。其核心作用是解决高低速总线速率不匹配、时序不同步的问题——高速总线以 125μs 为一个微帧（microframe），而全速总线以 1ms 为一个帧（frame），TT 通过“拆分事务”（Split Transaction）将高速总线的事务拆解为适配全速/低速总线的时序，同时通过带宽预算、流水线管控确保传输可靠。本文将从技术本质出发，拆解 TT 核心机制的计算逻辑、设计初衷，而非单纯罗列协议规范。

一、全速带宽最优预算（Best Case Full-Speed Budget）

设计初衷：高速主机需要提前规划下游全速/低速事务的执行时间，避免多个事务抢占总线导致时序溢出或带宽浪费。由于全速/低速总线存在位填充（bit stuffing）机制（每6个连续相同比特插入1个反转比特），会增加实际传输耗时，因此需要一个“最优场景”预算作为基准——假设无位填充，简化计算并预留冗余，确保即使存在位填充，事务也能在预算时间内完成。

1. 核心指标的由来与计算

（1）单微帧全速最大原始字节数（187.5字节）
计算逻辑：高速微帧时长为 125μs，全速总线速率为 12Mbps（12×10⁶ 比特/秒），单个比特传输时间为 1/12μs。单微帧内全速总线可传输的最大比特数 = 125μs × 12×10⁶ 比特/秒 = 1500 比特。由于 1 字节 = 8 比特，因此最大原始字节数 = 1500 比特 ÷ 8 比特/字节 = 187.5 字节。
协议取 188 字节作为预算基准（向上取整），目的是预留微小冗余，避免因计算误差导致预算不足——实际传输中无位填充时，187.5字节是物理上限，188字节仅为预算参考，不代表实际可传输量。

（2）1ms 帧全速最大周期字节数（1157字节）
计算逻辑（协议公式拆解）：1157 = 12Mbps ÷ 1000ms ÷ 8 比特/字节 × 6数据比特/7位填充数据比特 × 90% 最大周期数据占比
逐部分解析：

• 12Mbps ÷ 1000ms：1ms 内全速总线理论可传输的总比特数 = 12×10⁶ bit/秒 × 0.001秒 = 12000 bit；
• ÷8 比特/字节：将比特转换为字节，得到理论无填充字节数 = 12000 ÷ 8 = 1500 字节；
• ×6/7：位填充折算系数——最坏情况下，每6个数据比特插入1个填充比特，实际有效数据比特占比为 6/7（避免因位填充导致实际传输字节数减少，需提前折算）；
• ×90%：协议规定，周期事务（同步、中断）最多占用总线 90% 带宽，剩余 10% 预留用于非周期事务（控制、批量），避免周期事务垄断总线。

实际预算分配：1ms 帧分为 8 个微帧，前 6 个微帧各分配 188 字节（6×188=1128 字节），最后 1 个微帧分配 29 字节（1157-1128=29 字节），对应物理时序上限为前 6 个微帧各 187.5 字节、最后 1 个微帧 32 字节（时序与预算的微小差异，用于兼容位填充带来的耗时波动）。

二、TT 微帧流水线（TT Microframe Pipeline）

设计初衷：高速微帧（125μs）远短于全速帧（1ms），若直接将高速事务下发到全速总线，会导致时序错乱（高速事务完成后，全速总线还未准备好下一个事务）。因此，TT 设计“流水线”机制，将高速拆分事务与全速事务错峰执行，实现高低速总线的时序解耦。

1. 流水线核心逻辑

拆分事务分为两类：启动拆分（Start-split）和完成拆分（Complete-split），其流水线调度的核心是“时间提前量”和“结果缓存”：

• 启动拆分：提前 1 个微帧调度，即全速事务预计在某个微帧启动，启动拆分需在该微帧的前一个微帧下发——目的是给 TT 预留足够的“思考时间”（TT think time），完成高速到全速的信号转换、事务解析，避免事务启动延迟。
• 完成拆分：在全速事务可能结束的微帧调度——由于全速事务受位填充、总线干扰影响，结束时间存在波动，因此完成拆分需覆盖多个微帧，确保能捕获事务结果。

2. 关键设计细节与原因

（1）按最大载荷预算：主机始终按全速/低速端点的最大数据载荷尺寸计算带宽，而非实际单次传输尺寸。原因是：端点的最大载荷是固定的，若按实际载荷动态预算，会导致带宽分配频繁变动，增加调度复杂度；按最大载荷预算，可确保无论实际传输数据多少，总线资源都能满足需求，避免因载荷突发导致时序溢出。
（2）TT 思考时间：TT 完成一次高速拆分事务到启动下一次全速事务的间隔，由集线器描述符的 wHubCharacteristics 字段第 5、6 位定义。原因是：TT 需完成高速信号解码、全速信号编码、事务状态缓存等操作，需要固定的处理时间，若没有该时间，会导致事务叠加，引发总线冲突。
（3）典型流水线示例：某全速事务预算在 Y0 微帧执行，启动拆分需在 Y-1 微帧下发（提前 1 微帧），完成拆分分配在 Y1、Y2、Y3 微帧——既给 TT 预留思考时间，又覆盖全速事务可能的结束时间范围，避免结果丢失。

三、全速帧生成：时序同步的核心的设计

设计初衷：全速设备依赖 1ms 帧时钟（SOF 信号）同步事务，而 TT 作为下游全速总线的“虚拟主机”，必须生成符合时序要求的 SOF 信号，同时与高速总线的微帧时钟同步，确保高低速事务的时序对齐。

1. 时钟同步机制

TT 拥有独立的帧时钟，但需同步于高速总线的微帧 SOF 信号——高速总线的第 0 号微帧 SOF（zeroth microframe SOF），对应 TT 下游全速总线的 SOF 信号，以此将全速 1ms 帧与高速 8 个微帧（8×125μs=1ms）精准对齐。
关键时序要求：全速 SOF 的生成时刻，需与高速 0 号微帧 SOF 偏差不超过 ±3 个全速比特时间（1 个全速比特时间 = 1/12μs ≈ 83.3ns）。原因是：若偏差过大，会导致全速设备的事务时序与高速拆分事务错位，引发数据传输错误。

2. 休眠同步机制

当高速总线进入休眠（空闲 250μs），TT 需在 250μs 内停止下发全速 SOF，确保下游全速/低速总线同步休眠。原因是：若全速总线继续运行，会导致设备功耗浪费，同时可能与高速总线的休眠状态冲突，引发链路异常。

四、主机拆分事务调度：规则背后的技术考量

拆分事务的调度由主机（软件层）负责，核心是避免流水线溢出、事务冲突，确保不同类型传输（同步、中断）的实时性和可靠性。以下是关键规则的技术解析及计算逻辑：

1. 基础限制规则

• 禁止在 Y6 微帧调度启动拆分：Y6 是 1ms 帧的第 7 个微帧（0~7 编号），后续仅剩余 Y7 微帧，若在 Y6 调度启动拆分，TT 无足够时间完成思考和事务启动，会导致时序溢出，因此协议未定义该场景下的 TT 响应。
• 单微帧启动拆分不超过 16 个：TT 的启动拆分缓存容量有限，同时全速总线单微帧最多可处理 16 个全速事务（后续会解析），若超过 16 个，会导致缓存溢出和总线过载。
• 传输错误立即重试完成拆分：高速总线传输错误（trans_err）属于偶发故障，立即重试可避免事务结果丢失，确保数据传输的可靠性。

2. 不同传输类型的调度逻辑（核心技术点）

（1）同步输出（Isochronous OUT）
调度逻辑：按事务预算微帧，拆分数据并调度启动拆分，采用“起始（beginning）/中间（middle）/末尾（end）/全部（all）”四种令牌编码。
设计原因：同步输出数据量大（最大 1023 字节），需拆分到多个微帧传输，编码用于标识分片位置，确保主机能正确拼接数据；禁止“末尾拆分携带零长度数据”，因为零长度数据无法标识分片结束，会导致主机解析异常，因此零载荷仅可使用“全部”编码。

（2）同步输入（Isochronous IN）与中断传输（Interrupt IN/OUT）
调度逻辑：仅需提前 1 个微帧调度 1 次启动拆分；中断事务需 2~3 个完成拆分，同步输入需根据事务占用微帧数增补完成拆分。
计算逻辑（完成拆分数量）：

• 中断事务：最大载荷小（全速中断最大 64 字节），即使跨微帧，最多仅需 2 个完成拆分即可捕获结果；若事务在 Y6 微帧启动，后续仅 Y7 微帧可用，因此仅需 2 个完成拆分。
• 同步输入：最大 1023 字节，按单微帧 188 字节预算，需 1023÷188≈5.44，即 6 个微帧，加上收尾冗余，最多需 8 个完成拆分（最坏情况：位填充导致单微帧实际传输量减少，需额外微帧）。

五、TT 事务响应：数据交互的可靠性设计

设计初衷：TT 作为高低速总线的“中转站”，需将全速/低速事务的执行结果（数据、状态）准确反馈给高速主机，同时处理传输过程中的异常（CRC 错误、数据未完成），确保数据完整性。

1. 响应逻辑与技术考量

• 正常响应（DATA0/DATA1）：当全速事务正常完成且 CRC16 校验合法时，用 DATA0/DATA1 标识结束——同步输入固定用 DATA0（无需区分帧序号），中断传输匹配下游设备的 PID（确保数据同步）。
• 异常响应（ERR/NYET/MDATA）：
  • ERR：CRC16 错误，丢弃数据并回复 ERR，避免主机接收错误数据；
  • MDATA：微帧边界数据未接收完成，且已接收超过 2 字节——剔除末尾 2 字节（可能是 CRC16，TT 未完成校验），返回已接收数据，告知主机继续下发完成拆分；
  • NYET：微帧边界已接收数据不足 3 字节，无法判断 CRC 状态，回复 NYET 告知主机继续等待。
• 无匹配响应：若 TT 未启动对应全速事务，回复 NYET——主机后续会重试，连续 3 次错误则暂停端点，避免无效重试浪费带宽。

六、TT 周期事务管控：避免流水线溢出的核心机制

设计初衷：TT 的流水线缓存（启动拆分缓存、完成拆分缓存）容量有限，若事务执行超时或并发过多，会导致缓存溢出、时序错乱，因此需要建立事务终止、缓存释放、并发限制机制。

1. 事务终止（Abort）：及时止损，避免时序溢出

触发条件：

• 全速帧结束（EOF）：无论事务是否完成，强制终止——避免事务跨帧运行，影响下一个帧的时序；
• 中断事务超时：启动拆分接收后延迟 4 个微帧仍未执行——防止中断事务长期占用总线，影响其他周期事务。

终止处理逻辑：输入事务停止下发握手、忽略残留数据；输出事务停止发包并制造位填充错误——目的是快速终止事务，释放总线资源，且不生成完成拆分记录（避免主机误判）。

2. 缓存释放：复用资源，避免溢出

释放规则：每个微帧起始时刻，清理 4 个微帧前的过期启动拆分、回收 2 个微帧前的完成拆分缓存。
设计原因：启动拆分的有效生命周期为 4 个微帧（超过则无法在预算时间内执行），完成拆分的结果反馈周期为 2 个微帧（超过则主机已重试或放弃），及时释放可确保缓存空间充足，避免新事务无法写入。

3. 并发限制：单微帧全速事务不超过 16 个

计算逻辑：TT 的完成拆分缓存最多可存储 16 个事务结果，同时全速总线单微帧（125μs）最多可处理 16 个全速事务（每个事务至少占用 7.8μs，16×7.8≈125μs），因此限制单微帧并发量为 16 个，避免总线过载和缓存溢出。

七、总结：TT 拆分事务的核心设计逻辑

TT 的所有机制都围绕一个核心目标：在高低速总线速率、时序不匹配的前提下，实现可靠、高效的跨速率通信。其设计逻辑可总结为三点：

1. 以“最优预算”为基础：通过无位填充假设、位填充折算、带宽占比限制，建立量化的带宽分配基准，避免时序溢出和带宽浪费；
2. 以“微帧流水线”为载体：通过启动拆分提前调度、完成拆分覆盖结果周期，实现高低速事务的时序解耦，提升总线利用率；
3. 以“异常管控”为保障：通过事务终止、缓存释放、并发限制、错误重试，应对位填充、传输错误等突发情况，确保传输可靠性。

理解 TT 的关键，在于明确“每个规则、每个指标都对应具体的技术痛点”——无论是 187.5 字节的微帧上限，还是 16 个事务的并发限制，本质都是平衡“传输效率”与“时序可靠性”，最终实现 USB 2.0 总线的高低速兼容。