[参考译文] TMS320F28388D：FSITX 寄存器 TX_FRAME_CTRL.START 的操作

您好、Pierre、

我已经从设计团队那里听到、现在可以提供更完整的答案。 很抱歉耽误你的时间。

清除 TX_FRAME_CTRL.START 的硬件事件是什么？

当发送器内核的仲裁块接受传输请求并且串行器开始驱动帧时、START 位由硬件清零。 具体而言、一旦发送器内核状态机接受传输（对应于线路上前导码序列的开始）、就会清除 START 位。

时钟域关系和同步会受到什么影响？

这是解释您所询问的非确定性的关键点。 FSI 发送器有两个不同的时钟域：

CPU 寄存器接口、该接口依靠 SYSCLK 运行
发送器内核依靠 TXCLKIN（通过预分频器从 PLLRAWCLK 获得）运行
这两个域是彼此异步的。 当从 CPU 写入 start=1 时、该写入发生在 SYSCLK 域中。 在 TXCLKIN 域中运行的发送器内核必须先同步该请求、然后才能对其执行操作。 这种时钟域交叉会引入同步延迟、该延迟受 SYSCLK 和 TXCLKIN 之间关系的限制。

生成 TXCLKIN 的预分频器将 PLLRAWCLK 除以一个可配置值 (TX_CLK_CTRL 中的 PRESCALE_VALUE)、然后在 FSI 模式下将 TXCLK（实际输出时钟）作为 TXCLK/2。 记录的约束条件是 TXCLK 不得超过 SYSCLK/2。

鉴于此、从开始写入到发送器内核识别请求的最坏情况下的同步延迟约为 2 个 TXCLKIN 周期、这是从更快域过渡到更慢域的两级同步器的典型情况。 在配置的 TXCLK 频率下、可以计算相应的挂钟时间。

同步后会发生什么情况—前导码何时开始？

一旦发送器内核识别到启动请求、帧结构如下所示：

4 个前导码时钟边沿在帧起始 (SOF) 模式之前驱动
后跟 SOF 模式 (1001)、帧类型、用户数据、数据字、CRC 和 EOF
随后会产生 4 个帧后时钟边沿
当发送器内核开始该序列（即在前导码开始时）时、START 位被清除。 因此、从 CPU 写入到行上出现的第一个前导码时钟边沿的总延迟为：

同步延迟（≈2 个 TXCLKIN 周期）+到下一个 TXCLKIN 边沿的任何剩余时间

这意味着延迟是有界的但不是固定的、范围大约为 1 到 3 个 TXCLKIN 周期、具体取决于 SYSCLK 域写入在 TXCLKIN 周期中的位置。

直接回答您的三个原始问题：

• 在固定数量的时钟周期后、START 位不会清零。 它由 TXCLKIN 域中的状态机事件清除 — 特别是在发送器内核开始驱动前导码时。 该时序在写入后 1–3 个 TXCLKIN 周期的窗口内是确定性的。
• 是的、如果在同步窗口内轮询、则读回从 1 开始完全正常。 在正常运行时、这种观察结果没有病态。
• 是 — 读回 1 表示请求已在 SYSCLK 域中注册、但尚未同步到 TXCLKIN 域状态机并由其处理。

实际影响：

由于延迟很小、但不为零并受 TXCLKIN 周期的限制、因此不要依赖轮询开始作为传输开始的指示器。 继续使用 TX_EVT_STS.FRAME_DONE（或其中断）来确认完整帧发送。 如果您需要确认传输实际上已经在行上开始、而不是刚刚完成、则前导码结构意味着在任何数据位出现之前、您至少有 4 个 TXCLK 前导码周期 — 这为时间敏感型操作提供了很小但实际的裕度。

我希望这能为您提供所需的详细信息。 如果您有任何其他问题、敬请告知。

此致、

Zackary Fleenor