EHCI控制器同步传输调度：siTD数据结构与分事务状态机详解

1. 项目概述：理解USB 2.0同步传输的调度挑战

在USB 2.0系统中，如果你想让一台高速（High-Speed， 480 Mbps）的电脑主机与一个全速（Full-Speed， 12 Mbps）的USB音频接口或者摄像头稳定通信，中间必须经过一个叫做“事务翻译器”（Transaction Translator， TT）的组件，通常它集成在USB 2.0集线器里。这个TT的核心任务，是把一个在“慢速世界”（全/低速总线）里需要连续时间完成的数据传输，拆解成一系列在“快速世界”（高速总线）的125微秒微帧（Microframe）里执行的“碎片化”操作，这就是“分事务”（Split Transaction）。

想象一下，你要用一辆高速卡车（高速总线）定期去一个慢速的手工作坊（全速设备）取货。卡车速度极快，但只能在固定的、很短的时间窗口（微帧）停靠装卸。而手工作坊生产一件产品需要的时间远超过一个窗口。解决方案就是：卡车在第一个窗口发出“开始生产”指令（起始分事务， Start-Split），然后在后续几个窗口依次来查看进度并取走部分成品（完成分事务， Complete-Split）。EHCI主机控制器的核心职责，就是为这辆卡车制定一份精确到微秒的行程表，并确保在任何交通拥堵（系统延迟）或计划变更（调度调整）时，都不会取错货、漏取货或者让手工作坊的生产线混乱。

本文要深入剖析的，正是EHCI控制器如何为同步（Isochronous）传输——这种对时序和带宽有严苛要求的传输类型——实现这套精密的分事务调度与状态管理机制。我们将聚焦于其核心数据结构siTD，解读S-mask、C-mask、SplitXState状态机等关键字段如何协同工作，并探讨在遇到“跨帧调度”等边界情况时，系统软件与硬件如何通过Back Pointer等机制保持一致性。理解这些底层细节，对于开发高性能、高可靠的USB音频、视频类设备驱动，或进行嵌入式USB主机控制器深度优化，至关重要。

2. 核心机制解析：siTD数据结构与调度原理

要管理好同步分事务，EHCI设计了一个专用的数据结构：siTD。你可以把它理解为描述“一次全速同步事务在高速总线上如何被拆分执行”的工单。这份工单必须包含所有关键信息：什么时候发指令、什么时候取货、货放在哪里、当前进行到哪一步了。

2.1 siTD的关键字段与职责

一个siTD包含了调度、缓冲区和状态跟踪三类信息。我们重点关注与调度直接相关的几个核心字段：

1. S-mask (Start-split Mask) 与 C-mask (Complete-split Mask)： 这是调度的“时刻表”。两者都是8位位图，每一位对应一个H-Frame（8个微帧组成的一个帧）内的一个微帧（位0对应微帧0， 位7对应微帧7）。

   • S-mask：标记在哪个微帧执行起始分事务。对于一个事务，通常只有一位被设置。
   • C-mask：标记在哪些微帧执行完成分事务。对于一个IN事务，可能会有多位被设置，表示需要多次“取货”。

   为什么需要两个Mask？因为起始和完成分事务在时间上是分离的。TT接收到起始指令后，需要时间在全速总线上执行事务并准备数据。主机必须等待足够多的微帧后，才能开始尝试取数据。C-mask定义了允许尝试取数据的“时间窗口”。

2. SplitXState (Split Transaction State)： 这是一个单比特状态位，指示当前siTD所代表的分事务处于哪个阶段：

   • Do Start Split：等待或正在执行起始分事务。
   • Do Complete Split：等待或正在执行完成分事务。 这是硬件状态机的核心。硬件在遍历到siTD时，首先检查Active位，若激活，则根据SplitXState决定当前微帧应该做什么（检查S-mask还是C-mask）。

3. Active 位： 这是siTD的“总开关”。为1时，主机控制器会处理此siTD；为0时，直接跳过。事务完成或出错时，硬件会将其清零。

4. Back Pointer (后向指针)： 这是处理跨H-Frame边界调度的关键。当一个IN事务的完成分事务需要跨越两个H-Frame时（即Case 2a），需要用两个siTD来描述。Back Pointer让第二个siTD能找到第一个siTD，以获取正确的缓冲区状态（如当前数据偏移、剩余字节数）来继续完成事务。

5. C-prog-mask (Complete Progress Mask)： 这是一个8位位图，由硬件维护。硬件每成功执行一个完成分事务，就会在对应微帧的位置置位。它的核心作用是检测微帧丢失。在准备执行当前微帧的完成分事务前，硬件会检查上一个按计划应执行的完成分事务（根据C-mask）是否已在C-prog-mask中标记。如果没有，说明中间有微帧被跳过了，数据可能已丢失，硬件会设置错误状态并停止该siTD。

6. TP (Transaction Position) 与 T-count (Transaction Count)： 这两个字段专用于同步OUT传输。因为一个大数据包的OUT传输可能需要多个起始分事务才能发完。TP用来标注当前发送的数据包是整个事务的哪一部分（BEGIN, MID, END, ALL）。T-count是一个递减计数器，表示还剩多少个起始分事务要执行。

注意：siTD的缓冲区指针（Current Offset,Page Select）和Total Bytes to Transfer字段与调度逻辑紧密耦合。硬件在每次传输后都会更新偏移和剩余字节数。软件必须确保初始化的缓冲区大小足以容纳整个事务的数据，否则会导致缓冲区溢出或数据截断，而硬件可能仅报告Babble错误。

2.2 分事务调度模型与边界条件

EHCI规范定义了三种基本的调度边界情况，理解它们对正确配置siTD至关重要。

• Case 1: 事务完全在一个H-Frame内这是最简单也是最理想的情况。起始分事务和所有完成分事务都安排在同一个H-Frame的微帧内。只需要一个siTD即可描述整个事务。调度简单，无需Back Pointer。

• Case 2a: 完成分事务跨越H-Frame边界这种情况发生在IN传输中，事务的完成阶段横跨了两个H-Frame。例如，起始分事务在Frame N的微帧4，而最后几个完成分事务被安排在了Frame N+1的微帧0和1。这时必须使用两个siTD：

  • siTD[N]: 状态为Do Start Split，负责执行起始分事务和Frame N内的完成分事务。
  • siTD[N+1]: 状态初始化为Do Complete Split，负责执行Frame N+1内的完成分事务。它通过Back Pointer指向siTD[N]，以访问统一的数据缓冲区。软件必须确保siTD[N+1]的Back Pointer有效且T-bit为0，否则硬件无法找到前一个siTD的状态，会导致事务失败。

• Case 2b: 超大数据包IN传输这是唯一允许起始分事务和完成分事务发生在同一个微帧的特殊情况。它只发生在全速同步IN端点最大数据包大于579字节时。此时，由于数据量巨大，TT可能在上一个微帧刚结束时就准备好了部分数据，使得当前微帧既需要执行上一个事务的最后一个完成分事务，又需要执行下一个事务的起始分事务。硬件处理此情况逻辑复杂，软件必须通过精心设计S-mask和C-mask来避免调度冲突，规范明确禁止在微帧1同时安排起始和完成分事务，以简化硬件设计。

实操心得：在驱动开发中，应尽量避免设计需要Case 2b调度的大数据包同步端点。如果无法避免，必须严格遵循规范计算和设置S-mask、C-mask，并充分测试边界情况。大部分音频设备（如48kHz, 16-bit立体声）的帧数据量远小��579字节，通常不会触发此情况。

3. 状态机详解：SplitXState的运转与事务生命周期

siTD的生命周期由一个清晰的硬件状态机驱动，围绕SplitXState位展开。理解这个状态机，就理解了硬件如何“自动”推进一个分事务。

3.1 状态机总体流程

状态机主要包含两个核心状态：Do Start Split和Do Complete Split。此外，Active位作为总使能，决定了siTD是否参与调度循环。

1. 初始与激活：系统软件（驱动）初始化一个siTD，设置好所有字段（S/C-mask, 缓冲区指针，数据长度等），并将SplitXState设为Do Start Split，Active位设为1。然后将其链接到周期调度列表的相应位置。
2. Do Start Split 状态：
   • 主机控制器在遍历周期列表时，遇到Active=1且SplitXState = Do Start Split的siTD。
   • 检查当前微帧编号（cMicroFrameBit，由FRINDEX[2:0]得出）是否在S-mask中被设置。
   • 如果匹配，则执行起始分事务。对于OUT，会发送令牌包和数据包；对于IN，只发送令牌包。
   • 执行完毕后，对于IN事务，状态无条件转换到Do Complete Split。对于OUT事务，则保持在Do Start Split状态，直到所有数据分片（由T-count控制）发送完毕，然后Active位清零，事务结束。
3. Do Complete Split 状态：
   • 主机控制器遇到处于此状态的siTD。
   • 首先进行Test A：检查当前微帧是否在C-mask中计划有完成分事务。
   • 接着进行Test B：使用CheckPreviousBit算法，检查上一个计划中的完成分事务是否已执行（通过C-prog-mask判断）。这是检测微帧丢失的关键。
   • 如果Test A和Test B都通过，则执行完成分事务。
   • 根据事务翻译器的响应（NYET, MDATA, DATAx, ERR等）更新缓冲区状态（偏移、剩余字节数）、C-prog-mask，并判断事务是否完成。完成后，将Active位清零。

3.2 关键操作：Test B与微帧丢失检测

CheckPreviousBit算法是确保数据流连续性的卫士。其逻辑简述如下：

1. 取得cMicroFrameBit，它代表当前微帧（例如，微帧3对应二进制0000 1000）。
2. 将其右旋一位（Rotate Right），得到previousBit。这代表了按时间顺序上的“上一个”微帧（微帧2对应0000 0100）。注意这里是环形右旋，微帧0的上一个是微帧7。
3. 检查previousBit这个位置在C-mask中是否被设置（即计划在上一个微帧执行完成分事务）。
4. 如果被设置，则进一步检查C-prog-mask中对应位是否被设置（即上一个微帧的完成分事务是否实际执行了）。
5. 如果C-mask计划执行但C-prog-mask未标记，说明上一个微帧被跳过了，Test B失败。

为什么微帧会被跳过？最常见的原因是“系统保持”（Host Hold-off）。当主机系统因为高优先级中断、内存访问拥堵等原因，导致EHCI控制器无法在规定的微帧时间内访问周期调度列表（位于系统内存中）时，就会发生保持。控制器错过了处理某个siTD的时机，对应的完成分事务就无法执行。

当Test B失败时，硬件认为数据流已经中断，继续执行当前完成分事务可能拿到的是错误或无效的数据。因此，硬件会采取保守策略：立即设置Missed Micro-Frame状态位，并清除Active位，终止本siTD代表的事务。这虽然导致当前帧的数据丢失，但防止了错误数据的传播，并释放了总线带宽给其他事务。

注意事项：C-prog-mask必须由软件在激活siTD前初始化为0。如果软件忘记清零，残留的位可能导致Test B误判，在事务开始时即报错终止。这是一个常见的软件初始化错误。

3.3 事务完成与状态更新

事务的完成取决于传输方向和TT的响应：

• 同步IN传输：

  • 正常完成：收到DATAxPID响应，表示TT已返回最终数据包。硬件更新缓冲区后，清除Active位。
  • 提前完成：在收到DATAx之前，Total Bytes to Transfer可能因收到MDATA而减为0。此时硬件不能停止！它必须继续执行后续计划中的完成分事务，因为TT可能还在等待返回CRC校验结果或错误状态。这是由TT的流水线规则决定的。
  • 错误完成：收到ERR或XactErr，硬件设置相应错误位并清除Active位。

• 同步OUT传输：

  • 没有完成分事务。硬件根据T-count和TP依次执行多个起始分事务，发送数据。
  • 当最后一个数据分片（TP为END或ALL）发送完毕，且Total Bytes to Transfer减为0时，硬件清除Active位。
  • 同样，如果发生微帧跳过导致TP序列不连续，TT会检测到协议错误并丢弃该数据包。

4. 高级话题：跨帧调度与Back Pointer机制

当同步IN传输的数据量或调度安排导致完成分事务需要跨越两个H-Frame时（Case 2a），就进入了最复杂的调度场景。单个siTD的描述范围被严格限制在一个H-Frame内，因此必须用两个siTD来描述一个连续的事务。Back Pointer是连接这两个siTD的桥梁。

4.1 跨帧调度的工作流程

假设一个IN事务，起始分事务在H-Frame N的微帧4，完成分事务分布在微帧6,7（Frame N）和微帧0,1（Frame N+1）。

1. 软件设置：

   • siTD[N]:SplitXState = Do Start Split,S-mask = 0x10(微帧4),C-mask = 0xC0(微帧6,7)。Active=1。
   • siTD[N+1]:SplitXState = Do Complete Split,S-mask = 0x00,C-mask = 0x03(微帧0,1)。关键：Back Pointer字段指向siTD[N]的内存地址，且其T位（Terminate，终止位）必须为0。Active=1。

2. 硬件执行（Frame N）：

   • 在微帧4，硬件处理siTD[N]，执行起始分事务，并将其状态改为Do Complete Split。
   • 在微帧6和7，硬件处理siTD[N]，执行完成分事务，更新C-prog-mask和缓冲区状态。

3. 硬件执行（Frame N+1， 关键步骤）：

   • 在微帧0，硬件遍历到siTD[N+1]。发现其SplitXState = Do Complete Split，且C-mask[0]=1。
   • 硬件检查到当前是微帧0（或1），且siTD[N+1]的Back Pointer有效（T-bit=0）。此时，硬件不会直接使用siTD[N+1]自身的缓冲区状态。
   • 硬件通过Back Pointer读取siTD[N]的内容到内部缓存。后续的完成分事务将基于siTD[N]的缓冲区状态（Current Offset,Total Bytes to Transfer等）来执行。
   • 执行微帧0的完成分事务，更新的是内部缓存的siTD[N]状态（主要是C-prog-mask和缓冲区指针）。
   • 在微帧0的事务完成后，硬件将更新后的状态写回siTD[N]的内存位置。
   • 对于微帧1，重复此过程。当所有完成分事务结束（例如收到DATAx），硬件会清除siTD[N]的Active位。siTD[N+1]的Active位可能在其所有计划的完成分事务执行完毕后，由硬件根据规则清除。

4.2 Back Pointer的使用规则与陷阱

硬件在以下两种情况下会使用Back Pointer：

1. 当前siTD处于Do Complete Split状态，且当前是微帧0（cMicroFrameBit = 0x01），并且Back Pointer的T-bit为0。
2. 当前siTD处于Do Complete Split状态，且当前是微帧1（cMicroFrameBit = 0x02），并且当前siTD的S-mask[0]为0（即微帧0没有安排起始分事务），同时Back Pointer有效。

第二条规则是为了处理Case 2b的极端情况，确保逻辑正确。

软件必须遵守的严苛规则：

• 数据缓冲区唯一性：整个全速同步事务（无论跨越多少个siTD）必须使用同一个数据缓冲区，即siTD[N]所指向的缓冲区。siTD[N+1]的缓冲区指针字段在跨帧调度中不被使用。软件必须确保siTD[N]的缓冲区足够大。
• 状态一致性：软件在初始化siTD[N+1]时，其SplitXState必须设为Do Complete Split，并且其C-prog-mask必须初始化为0。它的C-mask只应包含Frame N+1中计划执行的那些完成分事务对应的位。
• 禁止递归：Back Pointer链不能形成环或递归。一个siTD的Back Pointer只能指向一个在时间上更早的siTD，且硬件只跟随一次跳转。

踩坑记录：一个常见的驱动Bug是，在动态调整调度（如改变采样率）后，没有正确更新或清除相关siTD的Back Pointer。导致一个已被释放或重用的siTD被错误的Back Pointer引用，造成内存访问错误或数据混乱。在修改任何可能涉及跨帧调度的siTD前，务必先将其Active位清零，等待硬件停止访问后，再更新其内容或释放其内存。

5. 系统软件的角色：调度、平衡与错误处理

EHCI硬件提供了精密的自动状态机，但整个系统的正确运行高度依赖于系统软件（通常是USB主机控制器驱动和协议栈）的配合。

5.1 周期性调度列表的构建与带宽计算

软件在枚举设备、配置接口时，需要为每个同步端点计算带宽并创建调度。

1. 计算事务时间：根据端点描述符中的wMaxPacketSize，计算该端点在高速总线上完成一次分事务所需的时间（包括协议开销）。
2. 分配微帧：在125us的微帧内，为多个同步和中断端点分配时间片，确保总和不超过微帧的可用带宽（通常预留约80%-90%给周期性传输）。
3. 设置S-mask和C-mask：根据事务时间和TT的流水线延迟，确定起始分事务和各个完成分事务的最佳微帧位置，并设置到siTD中。对于IN传输，完成分事务通常起始于起始分事务后的第2或第3个微帧。
4. 处理边界条件：如果计算出的完成分事务跨越了H-Frame边界，软件必须创建两个siTD，并正确设置第一个siTD的C-mask和第二个siTD的Back Pointer及C-mask。

5.2 调度再平衡与Inactivate-on-next-Transaction (I) 位

系统运行中，可能需要动态调整调度（如新的同步设备加入或移除）。直接修改一个正在被硬件使用的siTD的S-mask或C-mask是危险的，会导致竞态条件。EHCI提供了I位来安全地暂停一个队列头（对于异步和中断传输）或siTD。

安全更新S/C-mask的流程：

1. 保存状态：软件首先保存siTD当前的传输状态（如Current Offset,Total Bytes to Transfer），以便在恢复后能知道进度。
2. 设置I位：软件将siTD的I位设为1。这是一个信号，告诉硬件：“我准备修改调度参数，请在完成当前进行中的分事务后暂停”。
3. 等待硬件响应：硬件会在下一次访问该siTD时，看到I位被设置。如果当前没有活跃的分事务（Active=0），硬件什么也不做。如果正在执行分事务，硬件会在完成当前微帧的操作后，将Active位清零。软件必须轮询等待硬件将Active位清零。
4. 更新参数：确认Active=0后，软件可以安全地修改S-mask和C-mask字段。
5. 重新激活：重新激活不能简单地只设置Active=1，因为硬件可能在检查I位和Active位之间访问该结构。规范给出了原子操作序列： a. 设置Halted位（阻止硬件推进队列）。 b. 清除I位。 c. 在同一次内存写入中，设置Active位并清除Halted位。

5.3 错误检测与恢复

软件需要定期检查siTD的状态字段，以处理错误：

• Missed Micro-Frame：表明发生了微帧跳过，数据丢失。对于音频，可能导致爆音；对于视频，可能导致卡顿。驱动应向上层报告这个错误，上层可能选择重同步或填充静默数据。
• XactErr (Transaction Error)：事务级错误，如超时、CRC错误等。通常意味着物理连接问题或设备故障。
• Babble Detected：设备发送的数据超过了wMaxPacketSize或缓冲区容量。这是严重的设备违规。
• Buffer Error：数据覆盖或指针错误，通常由软件bug（如缓冲区太小或指针计算错误）引起。

恢复策略：对于同步传输，通常不进行重试（因为会破坏实时性）。驱动应统计错误率，如果超过阈值，可能通知应用层设备连接不稳定。对于OUT传输，丢失的数据包就丢失了。对于IN传输，驱动可以用上一个有效数据包填充，或插入静默/空白数据，以维持数据流的连续性。

6. 性能优化与调试实践

理解了基本原理后，在实际系统中优化同步传输性能和进行问题调试，还需要一些工程经验。

6.1 优化调度以减少延迟和抖动

1. 紧凑安排完成分事务：对于IN传输，在TT流水线允许的前提下，尽量将完成分事务的C-mask设置得紧凑一些（例如连续几个微帧），而不是分散开。这可以减少数据在TT内部的缓冲时间，降低端到端延迟。
2. 避免微帧0和1的完成分事务：如果可能，尽量不要将完成分事务安排在微帧0和1，尤其是对于跨帧Case 2a的情况。因为微帧0和1涉及复杂的Back Pointer处理逻辑，且是系统中断和调度活动可能较密集的区域，更容易受到“系统保持”影响。
3. 权衡数据包大小与调度复杂度：使用接近wMaxPacketSize的大数据包可以提高总线利用率，但可能迫使调度跨越H-Frame边界（Case 2a），甚至触发复杂的Case 2b。对于低延迟要求的应用，有时使用较小的数据包，确保事务在一个H-Frame内完成（Case 1），反而能获得更稳定、可预测的延迟。

6.2 调试技巧与常见问题排查

当遇到音频断断续续、视频卡顿或同步传输失败时，可以按以下思路排查：

1. 检查siTD状态位：首先通过调试工具或驱动日志，查看出错siTD的Status字段。Missed Micro-Frame是最常见的错误，直接指向系统延迟问题。
2. 分析系统负载：Missed Micro-Frame通常由“系统保持”引起。检查同时是否有高带宽的批量传输在进行、是否有高优先级中断风暴、系统内存带宽是否饱和。可以使用性能分析工具监控系统中断和DMA活动。
3. 验证调度参数：
   • S/C-mask计算：确认软件计算的起始和完成分事务位置是否符合TT的流水线延迟要求。一个常见的错误是完成分事务安排得太早，TT还没有准备好数据。
   • 缓冲区对齐与大小：确保siTD的数据缓冲区指针是缓存行对齐的（通常32或64字节），以避免不必要的缓存同步开销。确认缓冲区大小至少为wMaxPacketSize。
   • Back Pointer有效性：对于跨帧调度，用调试器检查siTD[N+1]的Back Pointer是否确实指向siTD[N]，且T位为0。
4. 使用EHCI调试寄存器：大多数EHCI控制器都有USBSTS（USB状态）和FRINDEX（帧索引）等寄存器。USBSTS中的HCHalted、Reclamation等位可以指示控制器是否遇到严重错误或暂停。FRINDEX可以帮助你确认硬件当前正在处理哪个微帧。
5. 逻辑分析仪抓包：这是终极手段。使用USB协议分析仪同时捕获高速总线（上游）和全速总线（下游）的流量。你可以直观地看到：
   • 起始分事务（SSPLIT）是否在预期的微帧发���。
   • 完成分事务（CSPLIT）是否按计划执行，以及TT返回的是NYET、MDATA还是DATAx。
   • 微帧之间是否有不预期的长时间空闲，指示系统保持。
   • 全速设备实际的数据传输时机，与TT的调度是否匹配。

个人经验：在调试一个USB音频设备的间歇性爆音问题时，我们最初怀疑是驱动或硬件问题。最终通过逻辑分析仪发现，每当系统运行一个特定的后台磁盘备份任务时，就会出现长达多个微帧的“系统保持”，导致连续的Missed Micro-Frame。原因是该任务触发了大量的DMA操作，占用了内存控制器带宽。解决方案不是修改USB驱动，而是调整了该备份任务的I/O优先级，并限制了其磁盘缓存大小，问题得以解决。这提醒我们，USB同步传输的稳定性问题，根因往往在系统层面，而非USB子系统本身。