搞FPGA的兄弟，十有八九都被DDR接口的时序约束折磨过。尤其当你第一次在Vivado里写完代码，打开时序报告，发现一大片红色的setup/hold违例，几十条路径全挂在那个DDR读数据总线上，血压直接就上来了。

我陷入这个坑的时候，项目的DDR3读接口死活跑不上400MHz，问题不是出在PCB布线，也不是出在IDELAY调节，而是出在一开始就没把set_input_delay这个约束写对。你去看Xilinx官方文档UG903，它把语法说得明明白白，但真正到了DDR这种源同步接口上，min/max两个值怎么算、参考时钟选哪个沿、负延迟怎么理解，文档讲得云里雾里。这篇文章我就把自己踩过的坑、验证过的思路完整的讲一遍，把DDR接口下set_input_delay的前因后果、推导过程、实际写法和报告解读方式一次性说透，希望能帮你少走几周的弯路。

1. DDR接口时序的本质：为什么光看数据手册没用

1.1 源同步接口的时序模型

很多做FPGA的同学第一次接触DDR接口时，习惯性地用系统同步（System Synchronous）的思维去理解时序——主时钟由FPGA内部逻辑直接产生，数据由外部器件在某个固定时刻送出来，只要板子布线延迟稳定，一切妥妥当当。

但DDR接口完全是另一套玩法，它是典型的源同步（Source Synchronous）接口。所谓源同步，就是数据的伴随时钟（DQS）不是由系统时钟分出来的，而是由发送端（不管这个发送端是DDR颗粒还是FPGA）从自己的内部时钟域里派生出来，和发送的数据一起送到接收端。接收端用这个DQS来采集对应的数据线，而不是用自己本地的全局时钟。这也是为什么DDR读操作时，DQS是边沿对齐于数据的——DQS从0变1的那一下，数据总线上的信号正好处于稳定区间。

为什么DDR要这么设计？因为频率上来了以后，系统同步的时序预算根本撑不住。举个例子：一个400MHz的DDR3接口，UI（Unit Interval）才2.5ns，如果用系统时钟做采集，那PCB走线长度差1mm，引入的时延差就在6ps左右，看着不大，但几百mil的线长差加上片内时钟树偏差和器件内部的PLL抖动，预算一下子就爆了。而源同步接口的好处在于，DQS和数据走的是同一条物理路径，PVT（工艺、电压、温度）变化对两者的影响是共模的，接收端只需要关心DQS相对于数据自己的相位关系，这就把很多全局不确定性变成了局部的、可控的时序预算。

1.2 setup/hold在DDR里的真实含义

搞清楚了源同步模型，setup和hold的含义也就跟着变了。对FPGA内部的触发器来说，setup time是数据必须在时钟有效沿之前多长时间保持稳定，hold time是时钟有效沿之后数据还必须继续稳定多长时间——这两个参数由FPGA的硅片工艺决定，是固定的物理特性，比如7系列的FF在慢工艺角下setup可能是0.18ns左右，hold则可能是负值。

但接口约束里的setup/hold，指的其实是外部DDR颗粒或者控制器在DQS采样沿上对数据有效窗口的要求。你读DDR数据时，DQS的上升沿和下降沿都要去采数据，所以一个完整的DDR读数据窗口，定义在DQS上升沿前后和下降沿前后各有一段有效时间。外部颗粒手册会给一个tDS（DQS到数据有效的建立时间）和tDH（DQS到数据保持的时间）——你就把它理解成颗粒自己要求的交货条件：数据必须在DQS沿到来之前的tDS时间就位，并且一直保持到沿过后的tDH时刻。

所以这个时候，set_input_delay要干的事情，就是把外部这个“交货条件”翻译成FPGA内部时序引擎能看懂的输入延迟值。FPGA里布好了触发器和IOB，时序引擎并不直接知道DQS何时翻转，它只看得见FPGA的时钟网络和输入引脚。你必须告诉它，相对于哪个时钟的哪个沿，数据线上的信号在什么时候到达。

这里就有一个很多人绕不过去的弯——DDR的DQS双向信号、数据和DQS边沿对齐，到底该怎么用set_input_delay去描述？

答案在于，你约束的不是DQS本身，而是数据相对于内部参考时钟的到达时刻。而这个“内部参考时钟”，通常就是你在FPGA内部生成的一个和DQS同频同相（或者经过MMCM/PLL调整后满足采样关系）的时钟，它的名字会在对应的set_input_delay里通过-clock选项指定。

2. set_input_delay的数学拆解

2.1 min/max两个值到底怎么算

set_input_delay的标准语法大家都不陌生，给数据路径设置一个相对于时钟沿的延迟范围。命令长这样：

set_input_delay -clock [get_clocks ddr_dqs_clk] -max 1.2 [get_ports ddr_dq[*]] set_input_delay -clock [get_clocks ddr_dqs_clk] -min 0.8 [get_ports ddr_dq[*]]

但到了DDR接口上，难的不是语法，是这里的max和min到底取多少。

从数据手册读到的tDS和tDH，是DQS沿相对数据的时序要求。但FPGA时序引擎分析的是：内部时钟（就是你指定的那个时钟）到达内部触发器时，触发器输入引脚上的数据是否满足建立和保持时间。所以你要算的延迟，是数据相对于那个内部时钟的延迟，而不是相对于DQS的延迟。

我们来推一遍。假设DQS的上升沿在FPGA内部时钟的上升沿之后t_clk_q时刻到达输入引脚（这个值取决于你选择的相位关系，比如你是让内部时钟上升沿对齐DQS上升沿，那t_clk_q就是0；如果你是让内部时钟的下降沿对齐DQS上升沿，则为半个周期）。数据相对于DQS的建立、保持要求是tDS和tDH。那么数据相对于内部时钟上升沿的延迟范围是：

• max（最晚到达）=t_clk_q- tDS
• min（最早到达）=t_clk_q+ tDH

这个推导的逻辑就是你把自己放在FPGA内部触发器的位置上想问题——数据必须晚于DQS的建立要求时刻到达（对setup来说是“够早”，对hold来说是“够晚”）。实际上，对DDR读数据来说，数据是围绕着DQS沿对称分布的，所以max和min的取值通常就在DQS沿前后各一段，也就是数据有效窗口的边界。

以DDR3-1600为例（频率800MHz，UI=1.25ns），数据手册上tDS典型值可能在0.05ns到0.15ns，tDH类似。如果我们把内部采样时钟的上升沿对齐DQS在数据有效窗口的中央，那么数据相对于这个采样沿的建立余量等于半个UI减去tDS加tDH的（这里做了简化，实际计算还需加上DQS到采样时钟的相位关系）。

打个实际算例。假设你给DDR读数据生成的采样时钟，其上升沿与你期望的DQS锁存沿对齐，而这个DQS锁存沿正好在数据有效窗口中央，且外部颗粒手册给出tDS=0.1ns、tDH=0.1ns。那么数据相对于采样时钟上升沿的窗口中心有一个偏移，我们想让这个偏移落在max和min的中间，留出最大裕量。按上面的公式，max = 0 - 0.1 = -0.1ns，min = 0 + 0.1 = 0.1ns。

看到问题没有？max比min还小，这在数学上是不合理的，因为max代表最晚到达，min代表最早到达，不可能最晚时刻比最早时刻还早。

这里的实际原因是，DQS的锁存沿相对于数据有效窗口中心有相位偏置，而你指定的内部时钟沿未必就在窗口正中央。所以实际操作中，你要选择一个内部时钟相位，使得窗口中心对齐你的采样沿，然后max和min就会变成一正一负的对称值。比如我们将采样时钟沿向前调整半个采样窗口，使得数据窗口中央正好落在时钟沿上，则：

• 数据最早到达 = 窗口中心 - 半个窗口宽度 = 0 - 0.6 = -0.6ns
• 数据最晚到达 = 窗口中心 + 半个窗口宽度 = 0 + 0.6 = 0.6ns

负的min值，表示数据在时钟沿之前就到来了，这在物理上完全说得通——因为数据其实是“围绕”着DQS采样的，有一部分数据位在采样沿之前就已经有效了。这也是很多新手卡住的地方：set_input_delay的min为负完全正常，不要以为是写错了。

2.2 时钟沿的选择和-options的细节

DDR接口一个周期内有两个有效沿——上升沿和下降沿都要采样，所以对DDR读数据约束时，通常需要给同一个数据总线针对不同的时钟沿写两组约束。

怎么处理？两种常见做法：

第一种，建立两个主时钟，一个是DQS的上升沿采样时钟（create_clock -name dqs_rise -period 2.5 [get_ports ddr_dqs_p]，注意DDR3的DQS是差分对，时钟周期是比特周期的一倍，因为DDR在每个沿都传数据），另一个是下降沿采样时钟（create_clock -name dqs_fall -period 2.5 -waveform {1.25 3.75}）。然后分别对两组数据用不同的时钟来约束。

第二种做法，只创建一个时钟，利用set_input_delay的-clock_fall选项。它对数据指定相对于时钟下降沿的延迟，与不写-clock_fall（即默认上升沿）的那条约束配合，就能覆盖DDR的双沿采样场景。

set_input_delay -clock [get_clocks dqs_clk] -max 0.6 [get_ports ddr_dq[*]] set_input_delay -clock [get_clocks dqs_clk] -min -0.6 [get_ports ddr_dq[*]] set_input_delay -clock [get_clocks dqs_clk] -clock_fall -max 0.6 [get_ports ddr_dq[*]] set_input_delay -clock [get_clocks dqs_clk] -clock_fall -min -0.6 [get_ports ddr_dq[*]]

这里的dqs_clk是在FPGA内部生成的、用于捕获DDR数据的时钟信号。特别强调一下，这个时钟的实际位置可以直接定义在DQS引脚上，也可以定义在内部逻辑生成点。如果定义在DQS引脚上，那么输入路径的起点就是这个引脚，时序引擎会计算DQS从引脚到内部触发器的路径延迟；如果定义在内部生成点，建议在约束中加-source_latency来补上DQS从引脚到这个生成点的延迟，否则时序引擎会低估延迟，报告里的余量会失真。

-source_latency是个容易忽略的坑。我见过一个项目，功能仿真全对，上板之后偶发读数据错位，查到最后就是source latency没加，工具评估的保持余量比实际大了几百皮秒，导致IDELAY的tap值定在了一个临界位置。DDR跑高速时，几百ps的差异足够让你的眼图闭合。

2.3 System Sync和Source Sync的本质区别

为什么set_input_delay在DDR上这么容易写错？因为很多人下意识用系统同步的公式来算延迟，算出来总觉得哪里不对劲。

系统同步接口里，数据延迟 = 时钟从FPGA到外部器件的传播延迟 + 外部器件的时钟到输出延迟 + 数据线从外部器件到FPGA的传播延迟 - 内部时钟到达触发器的延迟。所有路径都以系统的同一个时钟为参考。

DDR的源同步接口不一样。FPGA和DDR颗粒共享的不是系统时钟，而是DQS这个局部时钟。读数据的时候，DQS本身和DQ一样，是外部器件发出的信号，二者的相对相位由颗粒内部的DLL/PLL保证（DDR3的DQS和数据是边沿对齐的，DDR4则数据位于DQS两侧，具体看芯片型号）。所以你在算输入延迟时，参考的不是板级系统时钟到DQS的绝对延迟，而是DQS到达FPGA引脚那一刻与内部采样时钟沿的相对位置。

换句话说，DDR接口set_input_delay里的-clock不是系统时钟，而是你在FPGA内部生成的DQS采样时钟。这也是很多教程里反复强调的一句话：DDR读数据的输入延迟不是相对于时钟周期的百分比，而是相对于DQS采样沿的有效窗口。

这个认知一转变，很多矛盾就迎刃而解了。比如你会看到别人的约束文件里，set_input_delay的max和min数值都很小，比如±0.6ns、±0.7ns，而不是像SPI接口那样写1.8ns、2.2ns。原因就是DQS和数据走在一起，数据窗口相对采样沿只有几百皮秒的余量——没有系统同步那种动辄一个周期的大预算。

3. Vivado里写DDR读接口约束的完整实操

3.1 一个具体的DDR3读接口示例

用一个实际例子来串联前面说的理论。假设FPGA外接一颗DDR3L，运行频率400MHz（即DDR3-800，UI=2.5ns/2=1.25ns）。DQS是差分信号，数据线8根。我们通过IDELAYEYE2原语把DQ和DQS都做延迟对齐，然后利用内部生成的dqs_clk做采集中间时钟，最后把数据同步到系统时钟域。

初始化阶段，我们需要创建时钟。DQS引脚在FPGA里通常先经过IBUFDS变成单端，再进IDELAYEYE2，然后进BUFR或BUFIO等时钟缓冲。这里我演示一种比较典型的做法——用BUFG把处理后的DQS转成全局时钟，最大化时钟树的覆盖范围（代价是延迟大一些，但对低速DDR3-800来说通常够用；如果跑DDR3-1600，推荐用BUFIO来减小时钟偏斜）。

假设约束文件里已经有：

create_clock -name dqs_clk -period 2.500 [get_ports ddr_dqs_p]

注意，DDR3的DQS时钟周期是数据速率的倒数乘以2，数据速率800MT/s，所以周期2.5ns，UI是1.25ns。

接下来写输入延迟。假设你通过示波器或仿真确认了，DQS上升沿到达FPGA引脚时，数据有效窗口的中心比这个沿早0.1ns（在个别实际工程中，因为你用了IDELAY，此时采样时钟已经做过相位补偿，所以相对位置可以做相应调节；方便起见，我们假设已经调好使时钟沿对准窗口中心）：

set_input_delay -clock dqs_clk -max 0.60 [get_ports {ddr_dq[*]}] set_input_delay -clock dqs_clk -min -0.60 [get_ports {ddr_dq[*]}] set_input_delay -clock dqs_clk -clock_fall -max 0.60 [get_ports {ddr_dq[*]}] set_input_delay -clock dqs_clk -clock_fall -min -0.60 [get_ports {ddr_dq[*]}]

这里ddr_dq[*]的写法在Tcl里会展开成ddr_dq[0]、ddr_dq[1]等。如果你的工程用Verilog定义了[7:0] ddr_dq，那么管脚名字一般就是ddr_dq[0]这种方括号带索引的形式，在XDC里最好用get_ports {ddr_dq[*]}加上花括号，避免Tcl把方括号解释成命令替换。

再补上DQS的-source_latency。假设从DQS引脚到内部时钟生成点，经过IBUFDS加IDELAYEYE2的总延迟大约是1.2ns（具体数值以布线后的时序报告为准，这里先给一个预估值；实际工程中这件事的做法是先跑一版不理想的约束，看路径报告里DQS的实际延迟，再回填）：

set_input_delay -clock dqs_clk -source_latency 1.2 [get_clocks dqs_clk]

3.2 参数计算的验证与回填

有些工程师会问，示例里的0.60ns怎么来的？是不是拍脑袋？不是的，它来自DDR3芯片手册的tDS/tDH和你的采样策略。

取一个具体的DDR3颗粒为例，手册上写着tDS（DQS to DQ setup）在某个slew rate下是0.05ns，tDH是0.08ns，数据有效窗口最窄处大约是UI减去这两个值。窗口中心到边界的距离，如果近似认为窗口是对称的，那么就是UI/2减去tDS和tDH的平均值，即1.25/2 - (0.05+0.08)/2 = 0.625 - 0.065 = 0.56ns。考虑到输入jitter和板上串扰，留20%的余量，就得到0.67ns左右。所以示例里的0.60ns是一个相对合理但略紧的初始值，正式项目里应该在实现后用report_timing_summary去检查实际裕量，再决定要不要把约束调整得更接近物理极限。

这个过程我强烈建议反复迭代。第一版你用一个“偏紧”的约束，时序报告如果通过了，说明实际裕量比约束预留的还大；如果setup/hold有违例，查看违例路径的报告，分析是约束给得太死板，还是数据窗口真没对齐。后者往往需要调节IDELAY的tap值，而不是继续改约束值。

在7系列FPGA上，IDEALEYEYE2的tap延迟每个约78ps（Vivado的实际值与原语配置有关），调节IDELAY前先确认你的约束和物理延迟匹配。很多人的经验是先通过调整采样时钟相位（例如MMCM的CLKOUT_PHASE或调整BUFR的分频脚）把窗口中心对准，再用IDELAY细调，两条腿走路。

3.3 容易写错的几个细节

把最容易翻车的几个细节列一下，都是我实际debug过的问题。

第一个，get_ports和get_pins搞混。set_input_delay约束的是FPGA的输入端口，必须用get_ports。如果你把内部信号线名放进去，Vivado会直接报warning，并且这条约束不生效。

第二个，差分信号的命名。DQS差分对的两个引脚在XDC里通常叫ddr_dqs_p和ddr_dqs_n，但create_clock只需要定义在P端。如果你把N端也定义了，工具会报时钟穿越差分缓冲的冲突。DDR3的DQS，P和N之间是互补关系，不需要两个独立的时钟。

第三个，用-add_delay的必要性。当同一个网表里有好几组不同的输入延迟约束时（比如既约束了DQS上升沿，又约束下降沿，同时还约束了地址/控制信号），中间要用-add_delay隔开。例如：

set_input_delay -clock dqs_clk -max 0.6 [get_ports {ddr_dq[*]}] set_input_delay -clock dqs_clk -min -0.6 [get_ports {ddr_dq[*]}] -add_delay

不加-add_delay，后面的set命令会覆盖前面同一条约束同group的设置。对DDR这种多沿接口，是很容易踩的坑。Vivado会报warning提醒你，但warning一闪而过经常被忽略。

第四个，约束的层级。set_input_delay写在XDC里时，如果被约束的网口在一个子模块里（非顶层），Vivado会判定约束作用域不对，不生效。所以DDR接口约束最好统一写在顶层XDC里，用顶层的端口名来指定。

4. 时序报告怎么读，怎么定位DDR的setup/hold违例

4.1 读懂report_timing_summary的关键行

写完约束，跑完综合和实现，打开Vivado的时序报告，很多人看到一堆红色就开始慌。别急，DDR接口的时序报告，关键在于过滤出有问题的路径来单独分析。

report_timing_summary会按时钟域组织报告，包含setup、hold和pulse width三类检查。对DDR读接口，最常看的是dqs_clk域里的input path。在Vivado的Timing Summary界面，右键选择“Report Timing”，指定-from [get_ports {ddr_dq[*]}]和-to [get_cells ...]，就能只报DDR数据线到内部寄存器的路径。

报告里有几个字段需要盯紧：

拿setup检查举例，Vivado验证的不等式是： 数据到达时间 ≤ 数据要求时间 - setup时间

数据到达时间 = 输入延迟（你写的set_input_delay）+ PCB延迟（port到buffer，通常为0）+ 内部逻辑延迟。数据要求时间 = 内部采样时钟沿 - 目的触发器的setup time。

这个不等式如果被打破，报告里会标出哪个环节超了。

4.2 从违例路径反推问题所在

我总结了一套快速定位DDR接口违例的流程。

第一步，看违例的路径是setup还是hold。纯setup违例，slack为负，路径上数据到达时间晚于要求时间，优先怀疑数据通道延迟太大。此时检查IDELAY的tap数是不是太大，或者组合逻辑里是否插了多余的LUT。通常的做法是在靠近IO的采样寄存器路径上不要放任何逻辑，直接由IBUF->IDELAY->寄存器。如果编译器插入了莫名其妙的逻辑，看看是不是代码里不小心给输入信号做了跨时钟域处理。

第二步，看hold违例。都符合DDR读数据应用，因为数据和DQS是源同步的，一般hold不会太难看。如果hold违例严重，优先怀疑采样时钟相位不对——DQS采样时钟没有对准数据有效窗口的后沿，导致数据在沿后太早发生变化。调IDELAY tap值让DQ整体往后移，或者让采样时钟往前走，都能缓解。

第三步，看是单根线违例还是整个总线违例。整组DQ线都违例，说明DQS时钟的整体相位不对；只有某几根违例，大概率是PCB布线等长没做好，或者这几位在IDELAY配置里没对齐。后者可以在代码里给每一根线一个独立的IDELAY tap配置值，通过ILA在线调试逐步调。

对于DDR这种高速接口，示波器和ILA是两大法宝。逻辑分析仪看采样后的数据翻转点，示波器看DQS和DQ物理波形。我调试时习惯抓读写DQS的相对位置，然后对照时序报告里的clock arrival time，判断是软件模型对还是物理测量对。

5. 常见问题与排查技巧实录

5.1 典型setup违例的处理思路

假设你第一次上板，时序报告里setup违例，slack大概是-0.3ns左右，数据路径延迟高出了要求。别急着调约束，先按下面顺序排查：

1. 检查IDELAYEYE2的配置。每个tap的延迟是固定的，多打一个tap就是多78ps（7系列典型值），如果你的tap数当时是根据仿真随便设的，很可能整体偏大或偏小。Vivado里可以直接在约束里用set_property IDELAY_VALUE来配置，也可以例化时在参数里指定。两者冲突时以后者为准。
2. 检查采样时钟域。如果内部采样时钟是由MMCM生成的，确认MMCM的输出相位是否准确。你应让DQS采样时钟沿和数据窗口中心对齐，而不是和数据窗口边缘对齐。换句话说，采样时钟沿需要有意识地向数据稳定的中间放。
3. 检查IOB寄存器的推断。Xilinx的IOB里有现成的寄存器资源，IDDR原语就是用IOB里的寄存器实现的。如果工具没有把读数据采样寄存器放入IOB，路径延迟会大很多，因为数据要先从IOB走通用布线资源到CLB的FF。查看综合后的schematic，确认是否例化了IDDR或IDELAYEYE2。没有的话，在代码里直接例化原语，避免综合器自由发挥。

我遇到过一次比较诡异的情况：setup违例只出现在特定温度和电压角下，常温下余量还有0.1ns，跑到高温就变负了。后来查出来，那是因为PCB上DQS走线比DQ走线长了接近500mil，导致高温下DQS延迟增大把数据窗口挤掉了。解决方式不是改约束，而是换了一版等长做得好一点的PCB。这种事情在验证板子上很常见，时序分析只能告诉你系统在当前的物理条件下能不能跑，不能替你把PCB的问题掩盖掉。

5.2 典型hold违例的处理思路

hold违例和setup违例经常成对出现，处理手段却经常是矛盾的。hold违例表示数据在采样沿之后失效得太早，即数据有效窗口在采样沿之前就关闭了。在DDR读接口里，最常见的原因有两个。

第一个是IDELAY的tap数给得太多，导致数据被整体向后延迟。数据后移后，hold检查的裕量会变小，因为hold关心的是采样沿之后数据还能稳定多久。如果你发现setup变好了但hold变差了，多半就是这个原因。

第二个是采样时钟与DQS之间的相位关系调得不干净。比如MMCM的CLKOUT0_PHASE设置不当时，采样时钟沿会落在数据窗口的边缘附近，一边裕量很大一边却很小。所以在调试过程中，方法就是先扫IDELAY的所有tap值，找到setup和hold都为正的中间区间，再在这个区间里选择居中的值。

调试我通常用Vivado的硬件管理器，通过VIO核来在线改变IDELAY的tap值。具体做法是：在代码里例化一个VIO输出，把若干位连到IDELAYEYE2的CNTVALUEIN端口，通过VIO界面动态调整，然后回读眼图监视模块的结果。这种方法不需要反复重新编译，一次综合就能在板子上扫描完整个延迟链。

如果扫描完整个IDELAY范围都找不到一个同时满足setup和hold的tap值，那就说明问题不在IDELAY，而是DQS的相位本身就不对，或者说设计里的采样时钟相位需要跨一个较大的调整范围。此时去看看MMCM的相位设置，或者检查DDR控制器的读DQS训练逻辑是否正常工作。

5.3 问题速查表

5.4 关于双向总线约束的额外提醒

DDR的DQ是双向总线，读和写走的是同一条物理线。上面讲的都是读方向的输入延迟约束。写方向则是FPGA作为发送端，约束是set_output_delay，由DDR颗粒的tDS和tDH倒推。两者必须同时做对，才能保证整个DDR接口的闭环。

实战中常见一个错误：只做了读方向的输入约束，写方向放养了，结果跑读写综合测试时，写操作偶发错误。Vivado对未约束的路径会默认使用相对宽松的默认值，所以报告里大概率不报错，但这种默认约束无法保证与DDR颗粒真正的时序需求匹配。个人经验是，读写两个方向都要用ILA抓一遍实际波形，不要看报告没红就觉得万无一失。

6. 一点实战提示：IDELAY、眼图与约束的联调

这部分想分享的是约束文件之外的功夫。很多人以为时序约束写对了，问题就解决了，实际上约束只是让工具“知道”物理世界的规则，真正的DDR接口成功率，取决于你的训练/校准逻辑是否能把数据和DQS对齐到窗口正中心。

在DDR3接口里，读数据训练的基本思路是：不断调整IDELAY的tap值，找到setup/hold都满足的区间，然后取中间值。有些控制器IP自带训练逻辑，比如Xilinx MIG会自己完成读DQS的训练。如果你是自己写DDR控制器，没有现成的训练模块，可以用状态机配合ILA来扫，方法虽笨但可靠。

扫描窗口的过程中，建议你好好利用report_timing_summary里的hold和setup报告，在每个tap值下记录对应的slack。以tap值为横轴、slack为纵轴，会看到setup裕量和hold裕量两条线交错的形状，一上一下，中间会有一段两者都为正的重叠区。你要选的值就是这段重叠区的中间点。如果重叠区非常窄，说明DQS和DQ的相位关系本身就不理想，可能需要在PCB层面改善走线等长，或者在FPGA内对DQS单独加一段延迟。

这种扫描工作，在第4步里提到的VIO方案下，通常一个上午就能完成。扫完后把最终tap值固化到代码里作为默认参数，就再也不用手动调整了。我个人的体会是，这个功夫值得下足——比你在约束文件里反复试数字要高效得多，也能真正帮你理解接口的物理特性。DDR接口这种东西，纸上谈兵永远比不过亲手调一次IDELAY链。

另外加一句，UltraScale和UltraScale+系列的IDELAYEYE3控制方式和7系列略有不同，tap延迟值也差一些，但整体思路完全一致。换到高云、安路这些国产FPGA上，原语名称和配置方式不同，不过源同步接口的分析方法和set_input_delay的推导思路是通用的。掌握了方法，换平台只是换命令单词的问题。