归档文章用请求和确认介绍多位数据的跨域传输，并给出自己的RTL与波形。本笔记重新按一笔事务的生命周期整理：发送方何时锁住数据、接收方何时捕获、双方何时允许下一笔。没有运行或复制原文完整代码。
同步控制，保持数据
对需要整体一致的总线，各位独立同步可能得到不同事务的混合字。握手方案通常让发送方在事务期间保持数据，通过跨域同步后的请求告诉接收方何时捕获，再将确认同步返回。
图画的是协议顺序。数据总线需要单独保持，不能理解为数据依次经过每个控制框；请求与确认分别经过各自目的域同步链。
确认收到不等于马上可以再发
对于四阶段电平握手，收到ack有效后先撤销req；目的端看到req撤销后再撤销ack，源端确认返回空闲，才启动下一笔。这避免上一笔控制状态被误认为下一笔的请求。
AMD XPM_CDC_HANDSHAKE（UG974 2023.2） 要求下一次传输前完成确认及握手信号复位，并区分内部确认与外部确认模式。消费时机需要与所选模式一致，不能把内部自动确认当作下游无限接收能力。
数据保持必须写成接口条件
原文强调输入数据稳定，我会进一步把它写进接口约定：数据何时被锁存、保持到哪个返回条件、忙时的新输入怎么办。一次握手可以传递一个数据字，却不能自动保存忙期间到来的多个字。
数据路径的传播和建立时间仍需约束与实现检查。控制同步形成的等待时间有用，但不能只在RTL图上画几拍就认定所有布局条件成立。需要连续高吞吐时，异步FIFO通常比单笔往返握手更适合，仍须检查容量和回压。
读原文时保留的问题
原文在适用数据变化频率及快慢方向的说明中有容易混淆的表述。本文不以方向限制握手，而以完整协议、稳定窗口与吞吐需求判断；也不据原作者波形声称本项目已验证。
- 检查长时间目的端不消费时，源数据是否仍保持且busy不丢失。
- 对比发起、接受、完成三种计数，避免把被拒绝输入也算作成功事务。
- 复位打断事务后，明确丢弃还是重发；两端须有一致的恢复约定。
- 检查连续两笔不同数据能否被分别识别，并核查相关CDC路径。
阅读来源
原始阅读材料：FPGA逻辑设计回顾（7）多比特信号的CDC处理方式之握手同步-腾讯云开发者社区-腾讯云。
本文为原创阅读整理；引用的宏文档有明确器件族与版本，实际实现须核对目标平台。整理日期不是原文发表日期。配图为原创概念示意，未复用原文截图。