归档文章从一个 GTP 示例工程追踪参考时钟、COMMON、CHANNEL 和用户时钟模块。它的价值在于示范如何阅读生成层次，而不是给所有板卡提供一套相同频率。本文整理追踪方法，尚未测量 PLL 锁定、时钟频率或复位时序。
给每个时钟写三项说明
先记录时钟来自哪里、被谁使用、什么时候可以认为有效。参考时钟用于高速收发器的时钟基础；初始化或管理逻辑的时钟用于相应控制过程；用户时钟连接并行数据接口。核对时以生成 wrapper 和器件手册为准，名字相近不代表它们可以互换。
图把TX、RX用户时钟画成独立分支，并示意各自回接CHANNEL的用户时钟端口。数据通路未绘出；这不是完整接线图，所有频率关系与缓冲器仍须核对生成设计。它不表示可以把器件内部PLL输出直接当作任意逻辑时钟。
从实例连接追踪，而不是从名字猜测
检查原理图的参考时钟入口，再检查输入缓冲与 COMMON 的连接，接着分别追踪TXOUTCLK、RXOUTCLK、生成的用户时钟模块以及TXUSRCLK/TXUSRCLK2、RXUSRCLK/RXUSRCLK2回接端口。用户逻辑采用哪个时钟以实际接口配置为准。TX和RX分别画一张连接表，记录频率推导与实际配置之间的对应关系。
对于 7系列 GTP，阅读入口是 AMD UG482。原文同时对比了 GTX；后续设计应使用所选器件的资料，不能沿用另一族的PLL名称和参考路由。
先确认控制时钟，再审查复位过程
原文对特定示例列出了上电延迟计数，也提到尝试过不一致的系统时钟配置。这样的观察不能作为新工程中任意修改控制时钟的依据。若复位计数依赖声明的频率，应检查实际频率、参数和计时假设是否一致，并按当前IP文档与生成设计核查。
PLL锁定、用户时钟稳定、TX/RX复位完成和协议准备就绪是不同检查点。调试日志应分开记录这些状态，以便判断问题发生在哪个阶段。
待验证清单
- 建立每个时钟端口的来源、频率、用途和有效条件表。
- 检查时钟约束、生成时钟和工具报告，再审查业务逻辑的跨域路径。
- 如果TX与RX用户接口频率或相位关系不确定，明确业务数据如何跨域传递。
- 按器件允许的流程测试参考时钟变化、复位与恢复，记录状态和数据有效边界。
下一步需要实际板卡原理图和生成工程，才能把这份追踪清单落实成频率表；本文未填入推测的实测数值。
阅读来源
- 原始阅读材料：沧小海：《GTP学习：第三章 时钟结构》。
- 整理日期为2026-10-03；原文发表日期待核实。配图为本笔记原创概念示意，未复制原文截图。
适用范围：本文讨论AMD/Xilinx 7系列器件；不直接套用于UltraScale或Versal。