FPGA高速设计（六）

  之前我在学习的过程中，在找资料的过程中花费了大量时间，但也找到一些大佬的优质文章，为了减少各位粉丝查找优质资源的时间，在这里开创一个转载个人认为内容比较优质的文章，学习一下大佬阅读、分析手册的思路，提升对FPGA底层、应用的知识。

  如果觉得对你有帮助，可以订阅该专栏，后续会一直转载优质内容。

  以下为大佬文章正文，如有侵权，请通知删除：

---

  我没有想到有这么多人对FPGA的高速设计感兴趣，除了同行、在校生，更有跨行业的朋友也一起沟通。很多时候并不能面面俱到，因为很少有人在大的领域内都能精通（这种大佬应该也没有时间在网上写帖子），所以我一直以来抱着互相学习的心态写东西，把我认为的重要的点说明白，同时也接受大家的指正，确实有同学在留言中给了我很多建议和思考，也感谢你们！

  最近更新没那么频繁了，因为不仅工作忙，同时要抽空处理留言以及私信，同时期间我把项目的东西更改了一下，希望能有利于大家理解。今天根据简单的例子说一下大家都熟悉的扇出，我们直接开谝。

  这个例子是完全和高扇出相关的。如果学过数字集成电路，你就会非常明白，为什么扇出大对于数字电路影响这么严重，我在这里只简单提一下，有兴趣可以查资料往深里看。对下图来说，虽然都是反相器，但是对其他门电路、LUT甚至功能模块来说都是通用的，比如我们在A点输入方波激励，但是由于输出端B点有等效电容，这个电容大部分包括它所驱动的逻辑的输入电容（自身寄生电容和走线寄生电容等先不考虑），驱动的逻辑越多，它的等效电容越大，等效电容越大，在B点观察到的波形就越失真，至于为什么电容越大越失真这里不赘述，查看数集RC章节。

  所谓失真指更加偏离输入方波的形状，比如下图中蓝色线表示扇出小，输出等效电容较小，波形更加笔直；而扇出大的红线明显达到同样电压幅度需要的时间更长。那么如果时钟clk进行采样，就很大概率不能采到正确的值，这也导致接收端的建立时间不满足。

  说到这里，我们就大概知道扇出太大不利于同步电路时序收敛，而FPGA设计中，往往我们代码较为复杂，如果事前不考虑扇出，就会导致一连串恶性事件发生。当工具认为路径因为扇出大造成布线不通，就会强行替换其他逻辑的位置使其满足时序要求，但是这样又会造成其他更多路径出现问题……因此多数情况下，处理掉扇出问题，时序起码可以好一半。

  为了给布局布线减轻压力，推荐在综合完成后检查扇出和逻辑层级，对于非常高扇出的路径，往往比逻辑层级杀伤力还要大。下面我们看一下项目中的例子，可作为参考。

  查看方法很简单，打开工程的综合网表，查看扇出使用report_high_fanout_nets命令，具体如下，表示罗列出扇出大于200的100条路径：

             report_high_fanout_nets -fanout_greater_than 200 -max_nets 100

  然后显示满足条件的节点，如果时钟使用BUFG等强驱动的缓冲器，则可以暂时忽略时钟的高扇出，因为时钟的扇出本身就很大，而且有专用时钟走线；但是逻辑信号就完全不同了，比如下图扇出列表中的LUT扇出居然超过了1000，此时对于工具的走线分析压力非常大。要知道寄存器的驱动能力是大于LUT驱动能力的，这依然是数字集成电路的内容。本例着重解决WinProcChn0中的LUT3的问题，此时扇出为1038。

  打开综合网表，在网表中找到对应路径的LUT。输入命令：

       select_objects [get_nets WinProcChn0/front.u_FrontProc/u_FrontScaler/rWinVideoMask_reg[0][0]]

  找到这个net后使用原理图打开，发现这个节点是由一个LUT3驱动，前级为rSrcVs_reg和rSrcStable_reg驱动，由于综合后的网表名称可能与代码中不同，不能完全依靠名字一一对应，我们在u_FrontScaler模块中根本找不到rWinVideoMask_reg这个信号在代码中找到相关逻辑。（这个例子也是想告诉大家，综合网表很多cell或者net名字都是工具命名的，不能完全与你的代码对应，你得有根据其前后级做出判断的能力）。

  由于网表名称和代码名称不同，我们通过将查找到的net双击，查看其后续电路，发现驱动的后续电路都是u_FrontWriteDDR模块中的寄存器，扇出确实非常大，通过查看u_FrontWriteDDR中的代码，最终锁定下图中的代码逻辑，真正高扇出的节点是if中的判断逻辑"((rSrcVs[1:0] == 2’b01) || (!rSrcStable[0])) "，这个逻辑驱动着下面非常多的信号，重要的是，这些被驱动的信号并不是1bit，有些达到32bit甚至64bit，这就意味着这个逻辑的扇出比能看到的信号名字多的多。

  对于当前逻辑，明显是由于if中的判断逻辑没有进行寄存器打拍，从LUT输出后直接驱动了多个寄存器的CE端，导致扇出太大。本来LUT的驱动能力就比寄存器差很多，此时还有1000以上的扇出，仅此一个节点就足以对整体布局布线产生很大影响。解决方法也比较通俗，只需要将if中的条件逻辑进行打拍，使用寄存器输出驱动后续逻辑；但当前对于寄存器而言，1000以上的逻辑仍然有些大，因此还需要进行寄存器复制，每个寄存器输出只驱动少数逻辑。另一种方法就是使用最大扇出约束，使用max_fanout约束寄存器，好处是不用改变代码。

  寄存器复制比较简单，但是代码修改量比较大；最大扇出约束即使用max_fanout属性，综合时工具会自动进行寄存器复制，省去很多麻烦。下面针对这两种方法分别进行试验。

（1） 寄存器复制

  使用 (* EQUIVALENT_REGISTER_REMOVAL=“NO” *)，表示等效寄存器不被优化，或者也可以使用DONT_TOUCH语句，也表示防止被工具优化。下图分别是修改的代码和修改后的扇出列表，可以看到扇出已经被分散了。

（2） Max_fanout约束

  使用（* max_fanout = “N”*）来约束扇出高的寄存器，N表示最大的扇出值，下图中约束当前寄存器最大扇出为300，多于300后工具会自动进行寄存器复制。修改完重新综合后，发现工具已经进行了寄存器自动复制，同时每个复制的寄存器扇出被固定到260，同时看到工具自动给复制后的寄存器进行命名，虽然这些名字看起来非常不人性化。

  到这里就是最基本的处理扇出的方法，如果你想往深里再挖一挖，欢迎一起探讨，毕竟这些东西只有做了实际项目后才会体会更加明显。本来到这里本章应该结束了，不过后面要分析时序了，考虑到有童靴可能不懂得怎么查看时序报告，我这里简单提一下扫个盲，后面说的时候就不过多解释了。

  这里只管分析时序报告，至于查看异步路径约束资源利用功耗管脚之类一律先不管，后面有时间再说。

1）经过综合、布局、布线后，我们可以在软件下面看到粗略的时序报告。

  最显眼的几个名词包括WNS、TNS、WHS、THS、TPWS。打眼一看很蒙，如果你修过数集，你会知道set_up和hold time；如果你用过ISE，你会知道什么是slack；那其实完全是一个东西，WNS表示最差负时序裕量（worst Negative Slack），WTS表示总的负时序裕量 (Total Negative Slack)，WHS表示最差保持时序裕量 (Worst Hold Slack)，TNS表示总的保持时序裕量 (Total Hold Slack)，而TPWS则表示总体脉冲宽度时序裕量。至于slack（时序余量）是什么我在下面说。

  通常假如有时序告警，上面说的几个指标的值就会为负，同时变成红色，你只需要打开implement design，然后查看时序报告就能看到爆红的违例路径，然后找到一个，双击，就看到详细的时序报告。

  这个报告分为几部分，首先是summary和source clock path，summary中关注slack就行了。source clock path中Incr表示增加的延迟，Path…表示总延迟，比如下图中开始经过IBUF后增加的延迟是1.54ns，增加后总延迟就是1.54ns；然后经过net线延迟后增加了1.081ns，这个时候总延迟就是1.54+1.081，后面不多说了。

  然后就是Data Path和Destination Clock Path。数据路径和源时钟路径分析一样不多说。对于目的端时钟路径，需要注意两个，一个是clock pessimism，表示工具进行的时钟悲观预算；另一个时候clock uncertainty，这个是所有时钟不确定性的总和，其中就包括jitter抖动，但是它不止是抖动。我们知道，目的端时钟到来的时候，如果数据还没来（或者说数据来晚了）就表示不满足setup建立时间，工具会将这种概率尽可能放大，所以看到uncertainty都是负值。

  对于最后一项，表示会寄存器固有建立时间0.065ns，也就是器件本身规定时钟到来前至少0.065ns，数据必须到达，大家可以想一下为什么这个值在这里是正值。

  最后，slack就是目的端寄存器时钟到达时间 - 目的端数据达到时间，也就是满足setup或者hold的规则前提下，还有多少余量，所以当slack为负则表示时序有违例，对于hold大家可以自行分析。

  思考：下图Destination Clock Path项中，为什么时钟延迟从2.689ns开始？