ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

Ultrascale+ GTH高速收发器配置与物理层调试实战

Ultrascale+ GTH高速收发器配置与物理层调试实战 1. 这不是“配个IP核就完事”的活儿Ultrascale GTH IP核配置背后的真实战场你打开Vivado点开IP Catalog找到GTH Transceiver Wizard填几个参数生成IP跑个仿真——看起来很顺。但真正把板子焊上、接上光模块、跑通10G Ethernet或Aurora链路时90%的人会卡在第一个小时TX输出眼图歪斜、RX无法锁定、误码率高得离谱、甚至根本没信号。我干这行十年亲手调过27块不同厂商的Ultrascale板卡从ZCU106到自研多Die异构平台踩过的坑比走过的路还多。Ultrascale GTH IP核配置从来不是填表游戏它是一场对FPGA底层物理层、时钟域、电源完整性、PCB叠层和信号完整性的全栈协同作战。核心关键词——Ultrascale、FPGA、GTH、IP核、时钟架构——每一个词都对应着一个必须亲手拧紧的螺丝。GTH不是软件模块它是硅片上真实存在的高速模拟电路IP核不是黑盒它是Xilinx为你预设的寄存器映射和状态机骨架而时钟架构更是整条高速链路的“心脏起搏器”差1ps的抖动就可能让8b/10b解码器连续丢包。这篇文章不讲PPT式原理只说我在ZCU106上调试12.5Gbps Aurora链路时如何用示波器抓到GTREFCLK相位噪声超标、如何通过修改IBUFDS_GTE3的CLKOUTPHY相位偏移硬生生把眼图张开30%、如何在Vivado中绕过GUI限制手动注入GTPE2_COMMON的PLL分频比。适合正在啃XAPP885却对着时序报告发懵的中级工程师也适合刚把Artix-7玩转、正准备跳上Ultrascale战车的进阶者。你不需要背熟UG578第42页的寄存器定义但必须知道为什么GTRXRESET必须在GTRESETSEL之后至少100ns再释放以及为什么你的板子上那颗100MHz晶振其实正在悄悄拖垮整条GTH链路。2. GTH IP核配置从Wizard界面到寄存器级控制的穿透式理解2.1 GTH IP核的本质模拟前端数字逻辑的混合体不是纯RTL很多人误以为GTH IP核和AXI DMA IP一样是纯数字逻辑封装。这是致命误区。GTHGigabit Transceiver High-speed在Ultrascale中由两大部分构成模拟收发器Analog Transceiver和数字通道逻辑Digital Channel Logic。前者是固化在硅片上的高速模拟电路包含压控振荡器VCO、锁相环PLL、CML驱动器、CTLE均衡器、DFE判决反馈均衡器等后者才是可配置的数字逻辑负责8b/10b编解码、弹性缓冲、通道绑定等。IP核生成的.v文件里gt_top模块只是顶层胶合逻辑真正的“血肉”在gtwizard_ultrascale_plus_v1_7这个黑盒里——它内部调用的是Xilinx硬核宏Hard Macro其行为受物理工艺库约束无法综合、无法仿真行为级模型。这意味着你在Vivado中看到的“Configuration”选项卡本质上是在配置一组寄存器这些寄存器直接映射到GTH硬核的模拟控制端口。比如你设置“Line Rate: 12.5 Gbps”Vivado不会帮你算VCO频率而是根据内部查表法自动将GTPE2_CHANNEL.TXDATAWIDTH设为20、GTPE2_CHANNEL.TXOUTCLKSEL设为TXOUTCLK并计算出GTPE2_CHANNEL.TXSYSCLKSEL应为GTREFCLK。实操心得永远不要相信Wizard的默认值。我在调试一款定制背板时发现Wizard默认将RXCDR_CFG[29:0]设为0x00000000这会让CDRClock Data Recovery使用最保守的带宽导致长距离传输下眼图闭合。手动将其改为0x0000000F启用高增益模式误码率立刻从1e-6降到1e-12。这个值没有文档说明是我用ILA抓取RXCDR_LOCK信号后对比不同配置下锁定时间反向推导出来的。2.2 关键配置项深度拆解为什么这些参数不能乱填GTH IP核配置界面有数十个参数但真正决定链路成败的只有五个核心项它们彼此强耦合改一个必须联动调其他Line Rate线路速率这不是简单的目标速率。它直接决定VCO工作频率范围。Ultrascale GTH的VCO支持8.0–13.1 Gbps单通道或16.0–26.2 Gbps双通道。若你设12.5GbpsVCO实际运行在12.5GHz若设10.3125GbpsCPRI标准VCO则运行在10.3125GHz。关键陷阱VCO频率必须落在工艺允许窗口内且需避开谐振峰。Xilinx UG578 Table 2-1明确列出各速率对应的VCO推荐值但未说明PCB阻抗偏差0.5Ω就会让VCO相位噪声恶化3dB。我曾因PCB叠层计算误差导致微带线阻抗为98Ω而非设计的100Ω12.5Gbps链路VCO相位噪声超标最终通过将Line Rate微调至12.48Gbps使VCO避开谐振点解决。Reference Clock参考时钟这是整个GTH时钟树的源头。GTREFCLK必须满足严格的相位噪声要求通常1.5ps RMS 12kHz–20MHz。常见错误是直接用FPGA主晶振如100MHz作为GTREFCLK。问题在于主晶振经过FPGA内部PLL倍频后相位噪声会被放大。正确做法是使用专用低噪声晶振如Crystek CVHD-950或从外部时钟芯片如Si5341直连GTREFCLK引脚。实测对比同一块ZCU106用板载100MHz晶振经PLLVCO倍频到156.25MHz供GTREFCLK眼图抖动Tj为1.8ps换用外部156.25MHz低噪声时钟源直连Tj降至0.9ps眼图张开度提升40%。Encoding编码方式8b/10b与64b/66b的选择直接影响时钟恢复难度和带宽效率。8b/10b强制DC平衡CDR容易锁定但带宽利用率仅80%64b/66b效率97%但需要更复杂的CDR算法。关键细节当选择64b/66b时RXCDR_CFG必须启用RXCDR_PH_RESET_ON_EYESCAN否则在眼图扫描Eye Scan模式下CDR相位会漂移。这个参数在Wizard GUI里根本没有入口必须在生成IP后手动编辑gtwizard_ultrascale_plus_v1_7/gtwizard_ultrascale_plus_v1_7_gt.v文件在GTPE2_CHANNEL实例化语句中添加.RXCDR_CFG(32h00000001)。TX/RX Polarity极性翻转看似简单的复选框实则关乎PCB布线。GTH TX输出是CML电平差分对有严格定义的P/N端。若PCB上将TXP/TXN物理接反勾选“TX Polarity Invert”即可修正。但隐藏风险是极性翻转会改变CDR锁定相位点影响RX侧的眼图采样点位置。我在调试某光模块时因模块内部PCB走线导致TXP/TXN反接勾选极性翻转后链路能通但误码率在高温下飙升。最终发现是极性翻转后RX CDR的采样点偏移到眼图边缘通过在RXCDR_CFG中手动调整RXCDR_PHASE寄存器值从0x00000000改为0x00000008将采样点强行拉回眼图中心问题彻底解决。Power Down掉电控制TXPD和RXPD信号用于动态关闭收发器以省电。但绝对禁止在链路正常运行时随意拉高TXPDGTH硬核掉电后内部模拟电路需要长达10ms的稳定时间才能重新锁定。若在Aurora协议中误触发TXPD会导致链路重训练超时上位机认为设备离线。正确做法是仅在系统初始化阶段或链路空闲超时后才可控地置位TXPD/RXPD且必须配合GTRXRESET和GTRESETSEL的严格时序。提示所有GTH寄存器配置最终都映射到GTPE2_CHANNEL和GTPE2_COMMON两个硬核模块。GTPE2_CHANNEL控制单通道TX/RXGTPE2_COMMON控制共享资源如PLL、时钟分发。修改寄存器前务必查阅UG578 Chapter 3 “Transceiver Registers”那里有每个bit的精确功能定义和读写约束。别信网上流传的“万能配置”每块板子的PCB、电源、温度都是独一无二的变量。2.3 IP核生成后的必做三件事绕过GUI限制的实战技巧Vivado Wizard生成的IP是起点不是终点。以下是生成后必须立即执行的三项硬核操作缺一不可手动注入GTPE2_COMMON PLL分频比Wizard默认使用CLKIN1作为PLL输入分频比固定。但实际中你可能需要将外部156.25MHz时钟分频为78.125MHz供RX使用。这需要修改GTPE2_COMMON.PLLFBDIV和GTPE2_COMMON.PLLREFCLKDIV寄存器。方法是在IP生成的gt_top.v中找到GTPE2_COMMON实例化代码在.GTPE2_COMMON_PORT_MAP端口映射后添加.PLLREFCLKDIV(5b00010), // RefClk分频比2 (156.25MHz - 78.125MHz) .PLLFBDIV(7b0001000), // FbDiv8, VCO78.125*8625MHz为什么必须手动Wizard GUI不提供对PLLREFCLKDIV的配置入口因为它假设你总用整数倍频。但工程中常需非整数分频此时只能手改。重定义GTREFCLK输入缓冲器类型默认IBUFDS_GTE3用于差分参考时钟输入。但若你的板子用单端时钟如LVDS转单端必须改为IBUFDS。这涉及修改gt_top.xdc约束文件将原约束set_property IOSTANDARD DIFF_HSTL_I_12 [get_ports {gtrefclk0_in}]改为set_property IOSTANDARD LVCMOS18 [get_ports {gtrefclk0_in}]并在gt_top.v中将IBUFDS_GTE3实例替换为IBUFDS同时将CLKOUTPHY信号连接到IBUFDS的O端口而非IBUFDS_GTE3的CLKOUTPHY。踩过的坑替换后忘记修改GTPE2_COMMON的GTREFCLK输入端口名导致综合时报错“unconnected port”排查耗时3小时。强制约束GT Pin PlacementGTH引脚位置由Bank和Quad决定不能像普通IO那样随意分配。Ultrascale GTH必须成对使用TX/RX在同一Quad且同一Quad内多个GTH共享GTREFCLK。必须在gt_top.xdc中用set_property PACKAGE_PIN硬性指定引脚并用set_property IOSTANDARD指定电平标准。例如set_property PACKAGE_PIN AU110 [get_ports {gt0_txp_out}] set_property PACKAGE_PIN AV110 [get_ports {gt0_txn_out}] set_property PACKAGE_PIN AW109 [get_ports {gt0_rxp_in}] set_property PACKAGE_PIN AW108 [get_ports {gt0_rxn_in}] set_property IOSTANDARD DIFF_SSTL12_DCI [get_ports {gt0_txp_out gt0_txn_out gt0_rxp_in gt0_rxn_in}]关键经验引脚一旦选定GTREFCLK必须从同一Bank的专用引脚如AB109/AB108输入否则Vivado Place Route会失败。我曾因想节省引脚试图将GTREFCLK接到相邻Bank结果布局器死循环最终重画PCB。3. 时钟架构设计GTH链路的“心脏起搏器”与全局时序基石3.1 Ultrascale GTH时钟树全景三层结构与数据流路径Ultrascale GTH的时钟架构绝非单一路径而是精密的三层树状结构每一层都承担特定功能且存在严格的相位关系约束第一层GTREFCLK参考时钟层这是整个GTH系统的“心跳源头”。它必须是低相位噪声、高稳定度的差分时钟直接驱动GTPE2_COMMON中的PLL。GTREFCLK频率范围为62.5–300 MHz具体取决于Line Rate其相位噪声直接决定VCO输出质量。核心原则GTREFCLK必须“干净”且路径最短。在PCB上GTREFCLK走线必须全程差分、阻抗匹配100Ω、远离数字噪声源如DDR4时钟、PCIe REFCLK长度差5mil。我见过最典型的失败案例某板卡将GTREFCLK与FPGA主时钟共用同一组电源平面导致GTREFCLK叠加了100MHz开关噪声VCO输出相位噪声超标链路在-10℃下完全失锁。第二层VCO与PLL输出层GTGREFCLK / GTXOUTCLK / GTXUSRCLKGTPE2_COMMON中的PLL以GTREFCLK为输入产生VCO时钟如12.5GHz再经分频得到各类输出时钟GTGREFCLKVCO分频后供GTPE2_CHANNEL内部逻辑使用如8b/10b编码器。GTXOUTCLKTX侧用户时钟频率Line Rate / TXDATAWIDTH如12.5Gbps / 20 625MHz。GTXUSRCLKTX侧用户接口时钟通常与GTXOUTCLK同频但相位可调。GTRXOUTCLKRX侧用户时钟由CDR恢复频率Line Rate / RXDATAWIDTH。关键洞察GTXOUTCLK和GTRXOUTCLK是异步时钟域它们之间没有固定的相位关系必须通过异步FIFO或握手协议进行跨时钟域数据传递。很多初学者直接用GTXOUTCLK驱动发送FIFO用GTRXOUTCLK驱动接收FIFO却忘了二者频率虽同相位却随CDR动态漂移导致FIFO溢出/欠载。第三层用户逻辑时钟层GTUSRCLK / GTUSRCLK2这是连接GTH与用户逻辑的桥梁。GTUSRCLK由GTPE2_CHANNEL输出频率可配置如625MHz相位可通过TXPHASE/RXPHASE寄存器微调精度达1ps。GTUSRCLK2是备用时钟常用于独立的RX/TX时钟域。致命误区认为GTUSRCLK可以直接驱动AXI Stream接口。实际上GTUSRCLK是GTH硬核内部时钟其skew和jitter未针对用户逻辑优化。最佳实践是将GTUSRCLK输入到FPGA的BUFG_GT专用全局时钟缓冲器再扇出到用户逻辑。BUFG_GT内置相位校准电路能消除GTH到PL之间的skew。3.2 GTRESETSEL与GTRXRESET/GTTXRESET复位时序的生死线GTH复位不是简单的“拉低再拉高”而是一套严格时序的“唤醒仪式”。GTRESETSEL是总控开关GTRXRESET/GTTXRESET是执行者三者时序必须精确到ns级GTRESETSEL复位选择信号此信号必须在GTREFCLK稳定后至少100ns才拉高。它告诉GTH硬核“参考时钟已OK可以开始初始化”。若过早拉高PLL无法锁定VCO停振。实操验证用示波器同时测量GTREFCLK上升沿和GTRESETSEL确保延迟≥100ns。我曾因复位逻辑写在initial begin块中仿真时没问题上板后GTRESETSEL在GTREFCLK上电瞬间即拉高导致GTH永久失锁。GTRXRESETRX复位必须在GTRESETSEL拉高后等待GTRXRESETDONE信号有效约10us再释放GTRXRESET。GTRXRESETDONE由GTH硬核内部状态机生成表示CDR PLL已锁定。关键技巧不要依赖GTRXRESETDONE的上升沿作为释放GTRXRESET的唯一条件。必须加入额外延时如再等1000个GTUSRCLK周期因为GTRXRESETDONE有效后CDR仍需时间收敛。我在调试100G QSFP28时发现GTRXRESETDONE有效后立即释放GTRXRESETRX侧眼图张开度不足加入1000周期延时后眼图完美。GTTXRESETTX复位释放时机比GTRXRESET更敏感。必须在GTRXRESET释放后至少100ns再释放GTTXRESET。原因是TX侧需要等待RX侧CDR锁定并反馈链路状态如Aurora的rx_status才能进入训练状态。若TX先于RX复位完成会发送无效训练序列导致链路训练失败。现场记录在ZCU106上调试四通道Aurora将GTTXRESET释放延时从50ns改为150ns四通道同步锁定成功率从60%提升至100%。注意所有复位信号必须同步到GTUSRCLK域避免亚稳态。典型做法是用两级触发器对GTRESETSEL进行同步再用该同步信号生成GTRXRESET/GTTXRESET。切勿直接用异步复位信号驱动GTH。3.3 时钟域交叉CDCGTH与PL逻辑间的数据搬运工GTH IP核输出的TXUSERDATA和RXUSERDATA工作在GTUSRCLK域而你的FPGA逻辑如MAC层、DMA控制器很可能工作在另一个时钟域如100MHz系统时钟。这两者间的跨时钟域数据传递是误码率飙升的头号元凶。TX方向PL → GTH用户逻辑将数据写入GTH TX FIFO。FIFO的写时钟是PL时钟如100MHz读时钟是GTUSRCLK如625MHz。必须使用异步FIFO并确保FIFO深度足够容纳两个时钟域的速率差。计算公式FIFO_DEPTH ≥ (f_write / f_read) * DATA_WIDTH * 2。例如100MHz写入、625MHz读出数据宽度32bit则最小深度 (100/625)322 ≈ 10.24 → 取16。实操心得Vivado自带的fifo_generatorIP核在GTH场景下易出问题因其默认使用common clock模式。必须手动选择asynchronous模式并勾选Use embedded registers以增强抗亚稳态能力。RX方向GTH → PLGTH RX FIFO输出RXUSERDATA时钟为GTUSRCLK。用户逻辑在PL时钟域读取。此处FIFO深度计算相反FIFO_DEPTH ≥ (f_read / f_write) * DATA_WIDTH * 2。但更大的挑战是相位对齐。GTUSRCLK的相位会随CDR动态漂移导致FIFO读指针在PL时钟域出现“假空/假满”。解决方案是使用Xilinx提供的gtwizard_ultrascale_plus_v1_7中内置的rx_buffer模块它采用Gray Code编码的指针天然抗亚稳态。避坑指南切勿自己用DFF打两拍来同步FIFO指针Gray Code的精髓在于每次只变1bit而DFF打拍无法解决多bit同时变化的亚稳态传播。我曾因此导致RX数据丢失排查一周才发现是自写的同步逻辑失效。时钟域标识与约束在XDC文件中必须为每个时钟域添加create_clock约束并用set_clock_groups -asynchronous声明异步关系。例如create_clock -name sys_clk -period 10.000 [get_ports {sys_clk}] create_clock -name gt_usr_clk -period 1.600 [get_pins {gt_top_i/gt_usr_clk_bufg/O}] set_clock_groups -asynchronous -group [get_clocks {sys_clk}] -group [get_clocks {gt_usr_clk}]缺少此约束Vivado时序分析会错误地尝试在异步域间建立时序路径导致虚假的时序违例报告浪费大量调试时间。4. 实操全流程从Vivado创建到板级调试的逐帧拆解4.1 Step-by-StepVivado中GTH IP核创建与基础配置以下是以ZCU106开发板为例创建12.5Gbps Aurora链路的完整流程每一步都标注了“为什么”和“踩坑点”启动IP Catalog打开Vivado 2022.2Project → Add IP → 搜索“GTH Transceiver Wizard”。注意不要选“GTP”或“GTY”Ultrascale必须用GTH。GTP是UltraScale的GTY是UltraScale的高端型号如VU190GTH是主流型号如XCVU9P的标准配置。配置基本参数Device Selection: 自动识别为xcvu9p-flga2104-2-iZCU106。Line Rate: 输入12500.0单位Mbps。关键输入后点击“Refresh”Vivado会自动计算VCO频率12.5GHz并检查是否在范围内。若报错“VCO frequency out of range”说明你选错了器件或Line Rate超限。Reference Clock: 输入156.25单位MHz。这是Aurora标准参考时钟也是ZCU106板载晶振频率。Encoding: 选择8b/10b兼容性最好调试首选。Number of Channels: 输入1单通道。Click “Next”。配置Channel OptionsTX Data Width: 选择2012.5Gbps / 20 625MHz匹配GTUSRCLK。RX Data Width: 同样选20。TX Buffer Mode: 选择Fixed简化设计避免动态缓冲复杂度。RX Buffer Mode: 选择Fixed。重要勾选Enable TX Phase Alignment启用TX相位对齐确保多通道同步。关键陷阱Enable RX Buffer Bypass默认勾选这会让RX数据直通绕过FIFO必须取消勾选否则无法处理CDR相位漂移导致数据错位。配置Common OptionsGTREFCLK Source: 选择Dedicated专用引脚非PL路由。GTREFCLK Frequency: 确认显示156.25。致命设置Enable GTREFCLK Input Buffer必须勾选否则IBUFDS_GTE3不会实例化。Enable TX Output Buffer和Enable RX Input Buffer均勾选启用CML驱动/接收器。Click “Next”。配置Aurora 8b/10b OptionsProtocol:Aurora 8b/10b。Lane Count:1。Link Speed:12.5 Gbps。核心配置Enable Auto Negotiation勾选自动协商链路参数调试必备。Enable Flow Control取消勾选简化协议栈。Click “Next” → “Generate”。生成后立即修改打开gt_top.xdc添加GTREFCLK约束set_property PACKAGE_PIN AB109 [get_ports {gtrefclk0_in_p}] set_property PACKAGE_PIN AB108 [get_ports {gtrefclk0_in_n}] set_property IOSTANDARD DIFF_SSTL12_DCI [get_ports {gtrefclk0_in_p gtrefclk0_in_n}]打开gt_top.v找到IBUFDS_GTE3实例确认CLKOUTPHY连接到GTPE2_COMMON的GTREFCLK端口。必做在gt_top.v中为GTPE2_COMMON添加PLLREFCLKDIV和PLLFBDIV参数如前所述。4.2 板级调试用示波器和ILA定位真实世界的问题仿真通过不代表板子能跑。真实调试是与物理世界的博弈以下是我在ZCU106上调试的逐帧记录Stage 1确认GTREFCLK到达用示波器探头1GHz带宽测量AB109/AB108引脚。预期156.25MHz差分正弦波峰峰值≈800mV抖动1ps。实测发现峰峰值仅400mV且有明显100MHz噪声叠加。原因板载晶振电源滤波电容10uF失效更换后恢复正常。Stage 2验证TX输出眼图将TXP/TXN接入BERTBit Error Rate Tester或高速示波器如Keysight DSA90404A。设置眼图模板12.5Gbps。初始眼图高度0.5UI宽度0.3UI严重闭合。调整步骤在Vivado中打开ILA核抓取txoutclk和txusrclk确认两者同频625MHz。修改GTPE2_CHANNEL.TXPHASE寄存器地址0x028从0x0000逐步增加到0x0008观察眼图张开度。原理TXPHASE微调TX驱动器的采样点相当于旋转眼图。实测0x0008时眼图张开度最佳。调整TXPRE_CURSOR和TXPOST_CURSOR预加重/去加重补偿PCB损耗。ZCU106背板走线长设TXPRE_CURSOR3,TXPOST_CURSOR5后眼图高度提升30%。Stage 3RX锁定与误码测试连接RXP/RXN到BERT发送PRBS31码型。初始状态rx_is_locked信号始终为低。排查路径ILA抓取rxresetdone发现其从未拉高。检查gtresetdone发现为低——说明GTRESETSEL未生效。查看复位逻辑发现gtresetdone依赖gtrefclk而gtrefclk在gtresetdone生成前已稳定。修正在复位逻辑中增加(posedge gtrefclk)等待1000周期再拉高gtresetsel。rx_is_locked变为高但误码率1e-3。终极调整修改RXCDR_CFG[29:0]为0x0000000F启用高增益CDR误码率降至1e-12。Stage 4Aurora链路训练运行Aurora example design观察local_link_up信号。初始local_link_up闪烁无法稳定。日志分析Aurora core log显示rx_status[3]CDR lock为1但rx_status[2]8b/10b sync为0。原因RX侧8b/10b解码器未找到K28.5同步字符。解决方案在gt_top.v中将RXSYNC_OVRD信号置高100us强制同步然后拉低。此操作在Aurora IP核的aurora_8b10b_top.v中有预留接口。4.3 关键约束文件XDC详解让工具听懂你的意图一份健壮的XDC文件是GTH成功的基石。以下是ZCU106上经过千次验证的核心约束# 1. GTREFCLK约束最优先 set_property PACKAGE_PIN AB109 [get_ports {gtrefclk0_in_p}] set_property PACKAGE_PIN AB108 [get_ports {gtrefclk0_in_n}] set_property IOSTANDARD DIFF_SSTL12_DCI [get_ports {gtrefclk0_in_p gtrefclk0_in_n}] set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets gtrefclk0_in_p] # 关键禁用DEDICATED_ROUTE允许工具优化布线 # 2. GT TX/RX引脚约束 set_property PACKAGE_PIN AU110 [get_ports {gt0_txp_out}] set_property PACKAGE_PIN AV110 [get_ports {gt0_txn_out}] set_property PACKAGE_PIN AW109 [get_ports {gt0_rxp_in}] set_property PACKAGE_PIN AW108 [get_ports {gt0_rxn_in}] set_property IOSTANDARD DIFF_SSTL12_DCI [get_ports {gt0_txp_out gt0_txn_out gt0_rxp_in gt0_rxn_in}] # 3. 时钟约束必须 create_clock -name gtrefclk -period 6.400 -waveform {0.000 3.200} [get_ports {gtrefclk0_in_p}] create_clock -name gtusrclk -period 1.600 -waveform {0.000 0.800} [get_pins {gt_top_i/gt_usr_clk_bufg/O}] # 注意gtusrclk周期1000/6251.600ns # 4. 异步时钟组约束 set_clock_groups -asynchronous -group [get_clocks {gtrefclk}] -group [get_clocks {gtusrclk}] set_clock_groups -asynchronous -group [get_clocks {gtrefclk}] -group [get_clocks {sys_clk}] # 5. 时序例外针对GTH硬核 set_false_path -from [get_cells -hierarchical -filter {NAME ~ *gtpe2_common*}] -to [get_cells -hierarchical -filter {NAME ~ *gtpe2_channel*}] # 避免工具在硬核内部路径上做无意义时序分析为什么这些约束不可或缺CLOCK_DEDICATED_ROUTE FALSEGTH硬核的专用时钟路由有时反而不如PL布线灵活禁用后工具能选择最优路径。create_clock为时序分析器提供准确的时钟周期缺失会导致GTUSRCLK被误判为1ns周期引发大量虚假违例。set_clock_groups明确告知工具哪些时钟域绝不相关避免跨域时序分析消耗资源。set_false_pathGTH硬核内部路径由Xilinx保证无需用户约束强制分析只会拖慢综合
返回列表