时序约束增量编译
⑴ FPGA时序约束的几种方法（待续）
从最近一段时间工作和学习的成果中，我总结了如下几种进行时序约束的方法。按照从易到难的顺序排列如下： 0. 核心频率约束 这是最基本的，所以标号为0。 1. 核心频率约束+时序例外约束 这还不是最完整的时序约束。设计者的思路还局限在FPGA芯片内部。 2. 核心频率约束+时序例外约束+I/O约束（包括位置、外部走线延时、上下拉电阻、驱动电流强度等等） 这才是最完整的时序约束。FPGA作为PCB上的一个器件，是整个PCB系统时序收敛的一部分。FPGA作为PCB设计的一部分，是需要PCB设计工程师像对待所有COTS器件一样，阅读并分析其I/O Timing Diagram的。FPGA不同于COTS器件之处在于，其I/O Timing是可以在设计后期在一定范围内调整的；虽然如此，最好还是在PCB设计前期给与充分的考虑并归入设计文档。 正因为FPGA的I/O Timing会在设计期间发生变化，所以准确地对其进行约束是保证设计稳定可控的重要因素。许多FPGA外部器件在FPGA重新编译后出现不稳定的问题都有可能是由此引起的。 3. 核心频率约束+时序例外约束+I/O约束+LogicLock LogicLock是FPGA器件内部的布局约束。从一次成功的时序收敛结果开始，把特定的一组逻辑在FPGA上实现的布局位置和范围固定下来。相应地，其布线结果和时序收敛结果也就得到了间接的保证。需要注意的是，LogicLock不同于DesignPartition中的Post-fit Netlist。LogicLock的约束是粗粒度的，并且其精度范围是可调整的；而引入Post-fit Netlist是精确到门级的细粒度约束。 4. 核心频率约束+时序例外约束+I/O约束+FloorPlan+LogicLock FloorPlan也是FPGA器件内部的布局约束，是LogicLock的一种特例。成功的FloorPlan需要设计者对可能的时序收敛目标作出预计，并可以参考上一次时序成功收敛的结果。FloorPlan给了设计者对布局位置和范围更多的控制，不能也不可能照搬上一次时序收敛后零散的布局结果，所以对设计者的要求比简单的LogicLock要高。由于获得了更多的自主的控制权，时序收敛结果的可重现性也就越高。 5. 核心频率约束+时序例外约束+I/O约束+寄存器布局约束 寄存器布局约束是精确到寄存器或LE一级的布局约束。设计者通过对设计施加更精准的控制来获得更可靠的时序收敛过程。
⑵ fpga时序约束输入和输出两个约束就够用了吗
从系统上来看，同步时序约束可以分为系统同步与源同步两大类。简单点来说，系统同步是指FPGA与外部器件共用外部时钟:源同步(SDR, DDR) 即时钟与数据一起从上游器件发送过来的情况。在设计当中，我们遇到的绝大部分都是针对源同步的时序约束问题。所以下文讲述的主要是针对源同步的时序约束。
根据网络上收集的资料以及结合自己的使用习惯，我比较趋向于下面的约束流程方式:时序约束一共包含以下几个步骤:
1.首先约束时钟。输入时钟，输出时钟。从种类来看不外乎以下几种:单端输入时钟、差分输入时钟、GT或恢复时钟(例如LVDS信号恢复出来的时钟)、PLL产生的时钟以及自己产生的门控时钟。
2. I0约束。只有等待内部时钟完全通过后，再配置input delay和output delays， 告知FPGA外部端口的数据时序关系。
3.时序例外。在约束完时钟以及I0后，还是有时序违例的时候，注意检查一下是否有 时序例外的情况。
⑶ Quartus II中的完全编译包括几个环节每个环节分别完成什么功能
直接全编译(Ctrl + L)就知道有哪些环节了
分析和综合:这里主要是检查每个源文件的语法错误,生成门级代码,模块之间的错误可能检查不出来;
布局和布线:针对不同的器件进行优化,布局布线,这是关键步骤
汇编:产生编程文件,简单的fpga工程就完了
完整的步骤还有时序约束,约束完再编译,查看时序分析是否满足条件,再修改,这是一个反复的过程,如果要用第三方的工具进行仿真还需要单独生成对应的时序网表,包括一下仿真模型,延时输出文件等
⑷ fpga中添加时序约束问题
去这里把官方文档下下来：https://www.altera.com/en_US/pdfs/literature/manual/mnl_sdctmq.pdf
第167页的解释如图：
看懂了没？
就是如果说加了-expand，那么derive_clocks等等这一类执行源时钟关联操作的宏指令将会在被写入SDC文件之前就已经得以预编译展开，而如果不勾选，则只是写入SDC文件，不预先执行预编译展开操作。
⑸ FPGA时序约束
https://my.oschina.net/u/4583591/blog/4455472
时序分析本质上就是一种时序检查，目的是检查设计中所有的D触发器是否能够正常工作，也就是检查D触发器的同步端口（数据输入端口）的变化是否满足建立时间要求（Setup）和保持时间要求（Hold）；检查D触发器的异步端口（异步复位端口）的变化是否满足恢复时间要求（Recovery）和移除时间要求（Removal）。
时序分析包括静态时序分析（STA）和动态时序分析。
静态时序分析使用的工具：
动态时序分析使用的工具：
撰写基本的时序约束文件，告知时序引擎一些必要的信息（比如时钟，输入输出延时等）。若没有正确的时序约束，那么时序分析的结果是没有意义的。
第一种，从FPGA的输入端口到目的寄存器的数据输入端口 。
第二种，从源寄存器的时钟端口到目的寄存器的数据输入端口。
第三种，从源寄存器的时钟端口到FPGA的输出端口。
第四种，从FPGA的输入端口到FPGA的输出端口。
Data Arrival time = lauch_edge + Tclka + Tco + Tdata(Tlogic+Tnet)
Data Require Time = capture edge + Tclkb - Tsu
Setup Slack= Data Require Time - Data Arrival Time
Setup Slack = （Capture edge – Launch edge）+ （destination clk delay – source clk delay）- Setup time - clk uncertainty – datapath delay
Setup Slack = Setup Requirement（一定大于0） + clk skew – Tsu – Tclk uncertainty – Tlogic – Tnet - Tco
① Setup Requirement 与实际情况不符
建立时间需求过小，这种情况通常会在同步跨时钟域路径中出现，在同步跨时钟域路径中的源时钟频率与目的时钟频率的相位关系虽然是已知的，但是时序引擎默认选择的捕获沿通常都是错误的，需要用户通过多周期路径约束的方式手动修正建立时间需求。比如下图中，两个同频不同相的同步时钟，时序引擎默认选择的捕获沿是目的时钟第二个上升沿，导致建立时间需求非常小，最终肯定会导致时序违例。
② clk skew为负值，且很大
通常情况下，同一个时钟下的时钟歪斜不应该超过300ps，同步跨时钟域路径的时钟歪斜不应该超过500ps，异步跨时钟域路径的时钟歪斜一般比较大，因为它们的时钟源不同。当出现时钟歪斜大的情况时:
③Tsu/Tco大
当设计中使用Block（DSP/Block RAM等）时，应该要注意以下问题。对于以这些Block为时序路径的起点或终点的时序路径，这些Block的Tsu/Th/Tco都比普通的寄存器大，而且这些Block的布线延时和时钟歪斜比较大。所以当使用这些Block作为时序路径的终点时，它的起点一定要是触发器，比如说一个Block RAM的写数据信号，输入进Block前最好打一拍。当使用这些Block作为时序路径的起点时，应该使用Block 内部的输出寄存器，比如使用由Block RAM组成的FIFO时，尽量不要使用首字置出的，而使用打一拍后输出的，使用后者可以显着降低Tco。当时序路径为从一个Block到另一个Block时，中间需要进行打拍操作。当使用这些Block的控制端口时，应该保证这些控制信号的低扇出，如使用由Block RAM组成的FIFO时，应该尽量降低读/写能信/地址信号的扇出。
④Tlogic大
一般情况下，逻辑延时与时序路径的逻辑层级数息息相关，逻辑层级是指时序路径的起点和终点之间组合逻辑单元（LUT）的个数，而逻辑层级多一级意味着多1个LUT的延时加1条连接LUT的网线延时。通常一级逻辑层级的延时标准是1个LUT加1根网线的总延迟为0.5ns，如果某条路径的逻辑级数大于时钟周期/0.5ns，那么这条路径就被称为长路径。
常用的处理长路径的方案有两种：
⑤Tnet大
一般情况下，布线延迟与设计整体或局部模块的资源利用率以及拥塞程度息息相关。在正常情况下，一条网线的延时小于1ns，在发生拥塞的区域，网线的延时可能达到若干ns，导致布线延时显着增加。为了解决布线延迟大，需要从降低资源利用率和降低拥塞程度下手，比如某个模块使用了大量的寄存器堆，占用了大量的资源，此时应该考虑使用Block RAM代替这些寄存器堆；某个模块使用了大量的数据选择器，此时应该考虑如何优化这些数据选择器；某个模块的控制信号扇出比较大，与其他模块的互联很重，此时应该考虑如何降低这些信号的扇出；某条时序路径的起点或终点是Block，由于Block的位置比较固定，所以Block的布线延迟会大一些。最后需要强调的是，一定要额外关注高扇出的网线也会对布线延时产生影响。🔺TimeQuest时序分析（Setup）[图片上传失败...(image-23b6a0-1596829289696)]
①确定保持时间要求（确定发起时钟沿和捕获时钟沿）
保持时间要求是以建立时间要求为基础的，保持时间要求有两种：
根据所有的建立时间需求找到所有的保持时间需求，并从保持时间需求（可正可负）中找到最大的保持时间需求。
②计算数据的需求时间
③计算数据的到达时间
④计算Hold up的裕量（slack）
Data Arrival time（new data） = lauch edge + Tclka + Tco + Tdata(Tlogic+Tnet)
Data Require time = capture edge + Tclkb + Th
Hold up slack = Data Arrival time - Data Require time
Holp Slack = （lauch edge - capture edge） + （Tclka – Tclkb） + Tco + Tdata(Tlogic+Tnet) -Th
Holp Slack = Tco + Tdata(Tlogic+Tnet) -Th - Holp Requirement - clk skew
Hold up Slack为负的情况比较少见，当Setup Slack有较大裕量时，通常工具会自动插入延时来增加Hold up Slack。
①保持时间需求大于0（通常由时序引擎选择错误的捕获沿导致）
②时钟歪斜大于300ps（通常由时钟路径上的组合逻辑导致）
③Th过大（通常由时序路径终点为Block导致）
时序引擎能够正确分析4种时序路径的前提是，用户已经进行了正确的时序约束。时序约束本质上就是告知时序引擎一些进行时序分析所必要的信息，这些信息只能由用户主动告知，时序引擎对有些信息可以自动推断，但是推断得到的信息不一定正确。
首先用户必须要正确的约束时钟，时序引擎才能根据时钟信息进行各种时序检查。
用户约束时钟时，一般有两种类型的时钟需要约束。
①主时钟（Primary Clock）约束
使用Create_clock进行时序约束
全局时钟输入引脚是ClkIn，时钟周期10ns，占空比25%，相移90度。
②生成时钟（Generated Clock）约束
用Create_generated_clock进行时序约束 每个生成时钟都会对应一个时钟源（Master_clk），这个时钟源可以是Primary Clock或者另一个Generated Clock。在约束生成时钟时，用户不需要描述生成时钟的周期和波形，只需要描述由Master_clk经过了怎样的变化而产生的生成时钟即可。比如经过分频（-devide_by），倍频(-multiply_by)，反相（-invert），相移（-edge_shift）等等操作。
当生成时钟需要进行相移时，使用-edge_shift选项。-edge_shift不能与-divide_by/-multipl_by/-invert同时使用 。
时序引擎默认情况下会分析所有时钟之间的时序路径，用户可以通过时钟分组（ set_clock_group）命令或伪路径（set_false_path）命来关闭一部分路径的时序分析。
①同步时钟（synchronous clock）
两个时钟之间的相对相位关系是固定的（两个时钟来源于同一个Primary clock），并且这两个时钟的频率的最小公共周期是个整数。比如一个生成时钟（200M）和该生成时钟的Master_clk（100M）之间就属于同步时钟关系，因为这两个时钟的相位关系肯定是确定的，并且可以找到两个时钟的最小公共周期。通常情况下，一个Primary Clock和它产生的生成时钟之间都属于同步时钟关系，除非找不到最小公共周期。 **属于同步时钟关系的两个时钟之间的路径是可以进行时序分析的。
②异步时钟（ asynchronous clock ）
两个时钟之间的相对相位关系不确定。比如FPGA上两个晶振分别产生两个Primary clock（相对相位关系不固定），这两个Primary clock分别从FPGA的两个全局时钟引脚输入给两个MMCM，由两个MMCM分别产生的生成时钟之间属于异步时钟。一般情况下，不同的Primary clock之间都属于异步时钟，这些Primary clock分别产生的生成时钟之间也属于异步时钟关系。 **属于异步时钟关系的两个时钟之间的路径无法进行正确的时序分析。
一般情况下，如果用户不通过时钟分组对时钟之间的关系进行约束，时序引擎会默认所有的时钟之间都属于同步时钟关系。
③不可扩宽的时钟（unexpandable clock）
对于这类时钟，时序引擎无法在1000个时钟周期内找到两个时钟的公共周期，时序引擎就会从这1000个时钟周期中找到建立时间需求最差的情况，并进行时序分析，然而它不一定FPGA实际允许过程中建立时间需求最差的情况，因为在1000个时钟周期外可能还会有建立时间需求更差的情况，这样一来，时序引擎的分析结果就无法保证该路径一定不会出现问题，所以时序引擎的分析结果也就变的无意义。比如说由同一个Primary Clock驱动的两个MMCM的生成时钟分别是clk0（5.125ns）和clk1（6.666ns），虽然它们的相对相位关系是固定的，但是时序引擎无法保证对两个时钟之间路径的分析属于最差情况，这种情况和异步时钟之间的时序分析类似，时序分析的结果都看起来正常，但是这个结果确是不可信的。所以对这种时钟的处理方式与处理异步时钟是相同的，用户都需要进行跨时钟域的操作。
总结：异步时钟和不可扩展的时钟之间的路径都无法进行正确的时序分析，所以在时序分析之前，需要使用set_clock_group对时钟进行分组，从而将这些无法进行正确时序分析的路径忽略掉。
Input delay概念
Input delay计算
Max Input Delay = Tco(Max) + Tpcb(Max) - Clk skew(Min)
Min Input Delay = Tco(Min) + Tpcb(Min) - Clk skew(Max)
Input delay约束
Output delay概念
Output delay计算
Max Output Delay = Tpcb(Max) + Tsu - Clk skew(Min)
Min Output Delay = Tpcb(Min) - Th - Clk skew(Max)
Output delay约束
时序引擎默认情况下会在建立时间需求/保持时间需求最差的情况下进行时序分析，而时序引擎选择的这种需求不一定是用户真正希望的，而且时序引擎默认选择的这种需求是非常严苛的，甚至是根本无法满足的。此时就需要用户进行Multicycle约束，手动修改建立时间需求/保持时间需求。用户希望放松某些路径的约束力度，就可以通过Multicycle约束调整建立时间需求/保持时间需求。
使用set_multicycle_path命令进行约束
注：使用set_multicycle_path命令
①在源时钟和目的时钟相同的情况下进行Multicycle约束
②在源时钟和目的时钟频率相同且有正向偏移的情况下（正向偏移0.3ns）
⑹ fpga时序约束问题,重金感谢呀。。。求大侠帮帮忙。。
这个光看这个也看不到具体信息啊 那你的那个整体报告里面去点timing constrain ，然后找那些打了叉子或者显示某个时钟或者别的什么的时钟约束没过有个NO，如果你做的是相对高速的东西，尽量把那些高速时钟换成低速的，还有一些不好的编程习惯都有可能造成这样的结果。
你可以查看一下ISE的帮助里面有关于全部时钟约束的类似datasheet的东西，刻意去学暂时没必要，有什么查什么吧。希望对你有帮助
⑺ 关于quartus时序约束方法
占空比约束没问题 不写也可以 缺省就是50%
虽然都是用于pin的约束 tsu/th和offset不是一回事（offset是io的数据和时钟的延迟 tsu/th是芯片里的dff的数据和时钟的延迟关系 不考虑clock skew的话 应该满足offset+tsu+delay <= T） 如果是registered-in/registered-out的设计 没必要加tsu/th约束了
原则上讲hold time不需要设的 这就是工艺的一个参数 选择了器件以及环境条件以后 工具自然获取了该参数
不管哪个厂家的fpga 肯定hold violation都少于setup violation的
如果出现这种情况 一般都是时钟有问题 查一下clk是否使用了全局时钟资源 再查一下TimeQuest选项Common Clock Path Pessimism Removal是否使能
⑻ 求助，下图中的时序约束在dc中如何实现
从最近一段时间工作和学习的成果中，我总结了如下。按照从易到难的顺序排列如下：0. 核心频率约束这是最基本的，所以标号为0。1. 核心频率约束+时序例外约束时序例外约束包括FalsePath、MulticyclePath、MaxDelay、MinDelay。但这还不是最完整的...
⑼ 几种进行时序约束的方法
从最近一段时间工作和学习的成果中，我总结了如下。按照从易到难的顺序排列如下： 0. 核心频率约束 这是最基本的，所以标号为0。 1. 核心频率约束+时序例外约束 时序例外约束包括FalsePath、MulticyclePath、MaxDelay、MinDelay。但这还不是最完整的时序约束。如果仅有这些约束的话，说明设计者的思路还局限在FPGA芯片内部。 2. 核心频率约束+时序例外约束+I/O约束 I/O约束包括引脚分配位置、空闲引脚驱动方式、外部走线延时（InputDelay、OutputDelay）、上下拉电阻、驱动电流强度等。加入I/O约束后的时序约束，才是完整的时序约束。FPGA作为PCB上的一个器件，是整个PCB系统时序收敛的一部分。FPGA作为PCB设计的一部分，是需要PCB设计工程师像对待所有COTS器件一样，阅读并分析其I/O Timing Diagram的。FPGA不同于COTS器件之处在于，其I/O Timing是可以在设计后期在一定范围内调整的；虽然如此，最好还是在PCB设计前期给与充分的考虑并归入设计文档。 正因为FPGA的I/O Timing会在设计期间发生变化，所以准确地对其进行约束是保证设计稳定可控的重要因素。许多在FPGA重新编译后，FPGA对外部器件的操作出现不稳定的问题都有可能是由此引起的。 3. 核心频率约束+时序例外约束+I/O约束+Post-fit Netlist 引入Post-fit Netlist的过程是从一次成功的时序收敛结果开始，把特定的一组逻辑（Design Partition）在FPGA上实现的布局位置和布线结果（Netlist）固定下来，保证这一布局布线结果可以在新的编译中重现，相应地，这一组逻辑的时序收敛结果也就得到了保证。这个部分保留上一次编译结果的过程就是Incremental Compilation，保留的网表类型和保留的程度都可以设置，而不仅仅局限于Post-fit Netlist，从而获得相应的保留力度和优化效果。由于有了EDA工具的有力支持，虽然是精确到门级的细粒度约束，设计者只须进行一系列设置操作即可，不需要关心布局和布线的具体信息。由于精确到门级的约束内容过于繁多，在qsf文件中保存不下，得到保留的网表可以以Partial Netlist的形式输出到一个单独的文件qxp中，配和qsf文件中的粗略配置信息一起完成增量编译。 4. 核心频率约束+时序例外约束+I/O约束+LogicLock LogicLock是在FPGA器件底层进行的布局约束。LogicLock的约束是粗粒度的，只规定设计顶层模块或子模块可以调整的布局位置和大小（LogicLock Regions）。成功的LogicLock需要设计者对可能的时序收敛目标作出预计，考虑特定逻辑资源（引脚、存储器、DSP）与LogicLock Region的位置关系对时序的影响，并可以参考上一次时序成功收敛的结果。这一权衡和规划FPGA底层物理布局的过程就是FloorPlanning。LogicLock给了设计者对布局位置和范围更多的控制权，可以有效地向EDA工具传递设计者的设计意图，避免EDA工具由于缺乏布局优先级信息而盲目优化非关键路径。由于模块在每一次编译中的布局位置变化被限定在了最优的固定范围内，时序收敛结果的可重现性也就更高。由于其粗粒度特性，LogicLock的约束信息并不很多，可以在qsf文件中得到保留。 需要注意的是，方法3和4经常可以混合使用，即针对FloorPlanning指定的LogicLock Region，把它作为一个Design Partition进行Incremental Compilation。这是造成上述两种方法容易混淆的原因。5. 核心频率约束+时序例外约束+I/O约束+寄存器布局约束 寄存器布局约束是精确到寄存器或LE一级的细粒度布局约束。设计者通过对设计施加精准的控制来获得可靠的时序收敛结果。对设计中的每一个寄存器手工进行布局位置约束并保证时序收敛是一项浩大的工程，这标志着设计者能够完全控制设计的物理实现。这是一个理想目标，是不可能在有限的时间内完成的。通常的做法是设计者对设计的局部进行寄存器布局约束并通过实际运行布局布线工具来获得时序收敛的信息，通过数次迭代逼近预期的时序目标。 不久前我看到过一个这样的设计：一个子模块的每一个寄存器都得到了具体的布局位置约束。该模块的时序收敛也就相应地在每一次重新编译的过程中得到了保证。经过分析，这一子模块的设计和约束最初是在原理图中进行的，在达到时序收敛目标后该设计被转换为HDL语言描述，相应的约束也保存到了配置文件中 6. 核心频率约束+时序例外约束+I/O约束+特定路径延时约束 好的时序约束应该是“引导型”的，而不应该是“强制型”的。通过给出设计中关键路径的时序延迟范围，把具体而微的工作留给EDA工具在该约束的限定范围内自由实现。这也是一个理想目标，需要设计者对每一条时序路径都做到心中有数，需要设计者分清哪些路径是可以通过核心频率和简单的时序例外约束就可以收敛的，哪些路径是必须制定MaxDelay和MinDelay的，一条也不能遗漏，并且还需要EDA工具“善解人意”的有力支持。设定路径延时约束就是间接地设定布局布线约束，但是比上述3、4、5的方法更灵活，而且不失其准确性。通过时序约束而不是显式的布局和网表约束来达到时序收敛才是时序约束的真谛。 记得有网友说过“好的时序是设计出来的，不是约束出来的”，我一直把这句话作为自己进行逻辑设计和时序约束的指导。好的约束必须以好的设计为前提。没有好的设计，在约束上下再大的功夫也是没有意义的。不过，通过正确的约束也可以检查设计的优劣，通过时序分析报告可以检查出设计上时序考虑不周的地方，从而加以修改。通过几次“分析—修改—分析”的迭代也可以达到完善设计的目标。应该说，设计是约束的根本，约束是设计的保证，二者是相辅相成的关系。