FPGA编译加速实战：从13小时到5小时的优化全攻略

FPGA开发里的编译等待绝对是能磨掉人性格的一件事。我之前带一个视频采集处理项目逻辑规模不算夸张但时序收敛要求比较狠每次跑完完整实现流程少则十一二个小时多则直接十三四个小时。白天改完代码晚上睡觉前点下Run Implementation第二天早上到工位第一件事就是看有没有跑挂、时序有没有红。最难受的是如果早上发现布线不收敛改一行代码再来一轮又要等到第二天下班前才能看到结果一天最多迭代一次整个项目进度被编译时间硬生生拖住。后来我专门花了几周时间从硬件环境、工具参数、工程结构、流程编排四个方向做了一轮系统性的编译加速优化把一次完整编译从13小时左右压到了5小时上下最顺的时候甚至能到4小时出头。这个改善带来的不只是时间缩短而是整个开发和调试节奏都变了——白天改完代码下午能出结果晚上继续调一天能迭代两到三轮。这篇文章就把我实际验证过的加速手段、参数设置、以及过程中的坑都整理出来。1. 先搞明白FPGA编译到底慢在哪里1.1 一个完整编译流程里时间都消耗在哪个环节很多人一说编译加速第一反应就是换更好的电脑、加更多核心。但实际效果往往没那么理想原因是不清楚FPGA编译的时间到底消耗在哪个阶段。以Vivado为例一条完整的编译流水线大致分成综合、实现、生成比特流三大段而实现阶段内部又继续拆分为布局、布线、时序优化等多个子步骤。我手头这个项目用Vivado 2021.2逻辑规模大约是26万个LUT、38万个FF、将近500个DSP、400多块BRAM时钟约束有12个其中两个跨时钟域约束比较麻烦。实测下来完整跑一遍的时间分布大概是这样综合占10%到15%布局占15%到20%布线占50%以上最后的比特流生成和时序报告约占5%到10%。布线为什么这么慢因为它本质上是一个搜索过程。布局阶段把逻辑单元放到FPGA内部的具体位置后布线引擎要在巨大的可编程互联资源网络里找出满足时序要求的路径。换句话说布线工具面对的是一个规模庞大到无法精确求解的组合优化问题它只能通过启发式算法反复尝试、迭代改进。约束越紧、设计越复杂这个搜索空间就越大、迭代次数就越多时间自然呈指数级上升。这个道理有点像搬家装箱综合阶段相当于把你家的东西先分门别类放纸箱布局阶段相当于决定每个纸箱放房间的哪个位置布线阶段则相当于把箱子之间的连接线路全部拉好还得保证走廊不堵、所有通道都走得通。后面这个环节最费时间因为一个走线调整了可能连带着几十条相关路径都要重新算。1.2 真正决定编译耗时的几个变量抛开工具版本差异决定一次FPGA编译要跑多久的因素我总结下来主要是这四个。第一是设计规模。LUT、FF、BRAM、DSP这些资源占用越多逻辑层次越深综合和布局布线的工作量就越大。很多做图像处理、AI加速、软件无线电的项目动辄几十万LUT这个体量下就算只是增量编译也要十几分钟全量编译轻松上两位数小时。第二是时序约束的情况。约束越是紧张工具就要花越多的时间去尝试满足建立时间、保持时间。哪怕设计规模差不多约束宽松的工程可能两三个小时就跑完了约束紧的工程六七个小时也未必收敛。另外那些跨时钟域、多周期路径、伪路径约束如果写得不到位工具还会在根本不重要的路径上浪费大量算力。第三是工具的策略参数。Vivado和Quartus都提供了多种综合策略、布局策略、布线策略不同策略之间的耗时差异可以达到两到三倍。比如布局阶段有Quick、Default、Explore几种模式布线阶段有Quick、Default、Aggressive、Alternate Router等模式选错策略会在性能和速度之间吃大亏。第四是硬件资源和系统环境。CPU核心数、内存容量、磁盘读写速度、操作系统都会直接影响工具的执行效率。这一块我后面会详细展开但提前说一个结论——同样的工程在Linux服务器上比在Windows工作站上普遍能快15%到30%这个差距在高负载编译时尤其明显。2. 加速思路总览把13小时压到5小时靠的是组合拳2.1 先想清楚你到底需要多快的编译在动手折腾各种优化手段之前我建议你先回答一个问题你的使用场景下编译速度的合理目标是什么如果是做RTL功能验证大多数时间都在跑仿真编译比特流可能一天就那么一两次那把编译从13小时优化到8小时意义不大因为这些时间大多数时候机器在待机真正卡住你的是仿真回归速度。如果是做时序收敛调试一天要改多版约束编译时间直接决定你一天能迭代几轮那加速的收益就非常大。如果是做产线版本发布编译时间只影响发布节奏你更需要的是稳定可复现的流程而不是追求极限速度。我自己当时的情况是典型的中期调试阶段——逻辑功能已经基本稳定但时序收敛一直不理想每天都要根据上一轮的时序报告调整约束或局部RTL然后重新编译验证。这个阶段编译一次13小时就意味着一天只能试一次方案收敛效率极低。所以我的目标非常明确把完整编译时间压到8小时以内这样至少能保证白天上班时间完成一次迭代如果能压到6小时以内那下午还能再改一轮一天就能跑两个版本。2.2 四个投入产出比最高的加速方向围绕这个目标我梳理出了四个方向的优化手段。这些手段单独拎出来任何一个效果都有限但组合起来收益是相乘的不是相加的。第一个方向是硬件和系统层。换更高主频的CPU、增加核心数、加大内存、把工程目录放到NVMe固态硬盘上、把操作系统从Windows换成Linux。这两项能带来20%到35%的整体提升投入是一次性的。第二个方向是工具参数的调优。Vivado的多线程设置、布局布线策略的选择、增量编译开关这些在同一个工程上能让单次编译缩短10%到25%。这部分不需要额外成本但需要你对每个参数的实际效果有所了解。第三个方向是工程结构的调整。把设计划分成多个OOC模块、设置合理的层次化约束、启用Block Reuse功能让工具在局部改动时只重新编译受影响的部分。这个方向的收益在不同项目之间差异很大但做得好能把日常迭代的编译时间压缩一半以上。第四个方向是流程编排层面的技巧。多个seed并行跑、用多台机器分担不同seed的布线、在综合阶段提前做时序预估等。这相当于用机器数量换时间虽然提高了资源占用但墙钟时间能显著下降。这四个方向不是按顺序一条条执行的而是要根据你的实际情况挑着用。我在后面几节会逐个展开讲每个方向的具体做法和实测数据。3. 硬件和系统层把编译引擎的底子打好3.1 CPU、内存、磁盘怎么选才不拖后腿FPGA编译过程中的综合和布局布线都是计算密集型任务对CPU的多核性能和内存带宽都有要求。先说CPU。很多人选CPU的时候只看核心数觉得核心越多越快结果买了32核的机器跑Vivado还是慢。问题在于Vivado并不是所有阶段都能完美利用多核综合阶段的线程利用率相对较低布线阶段虽然有多线程版本但真正能线性加速的部分也不是全部。实测下来Vivado 2021.2在四核到八核这个区间内核心数增加带来的加速比较明显超过十二核之后收益就明显递减。相比核心数CPU的单核主频反而对综合和布局阶段影响更大因为很多子任务是串行依赖的单核快就是真的快。我当时的机器从4核4线程的旧工作站换到8核16线程、主频5.0GHz左右的新机器编译时间直观地缩短了将近三成。再说内存。这一步容易被低估。FPGA编译过程中网表数据、布线资源图、时序分析结果都常驻内存内存不够时会触发大量交换写入磁盘性能瞬间崩盘。以我那个二十多万LUT的设计为例布线阶段峰值内存占用大约在16GB到20GB之间。如果你的设计上了五十万LUT甚至百万LUT内存建议直接上到64GB。我的建议是32GB起步大型设计64GB别在这上面省钱。内存不足导致的性能暴跌比CPU差两个档次还严重。最后说磁盘。工程目录所在磁盘的读写速度对编译时间的影响主要体现在两个方面一是工程文件、检查点文件、报告文件大量写入时机械硬盘和NVMe固态硬盘的差距被放大二是增量编译时工具需要反复读取和比较之前的检查点磁盘速度快能让这个过程明显变快。我搬到NVMe之后光读检查点这一步就省了不少时间。还有个小细节工程目录尽量不要放在网络磁盘或者云同步目录里哪怕网络延迟是几毫秒级别在成千上万次小文件读写下积累起来也很可观。3.2 操作系统选Linux还是Windows关于操作系统我直接说结论同样的Vivado版本、同样的工程、同样的CPULinux下完整编译时间大概比Windows下快15%到30%。这个差距不是玄学主要原因是Linux下文件系统的元数据开销更小、进程调度更高效而且Vivado布线引擎的内存访问模式在Linux上表现更好。我当时是在Windows上做了前期开发和RTL仿真然后把综合和实现流程整个搬到一台Linux服务器上跑。刚开始心里没底怕切换环境引入问题后来发现Vivado在Linux下的表现非常稳定甚至综合后的网表文件、检查点文件放到Windows里继续跑实现也完全兼容。如果你手头有可用的Linux机器哪怕是通过远程SSH也强烈建议把重活交给Linux处理。远程编译还有一个附带好处编译不影响你本地做其他事情不会因为编译占满CPU导致你连浏览网页都卡。3.3 Vivado多线程参数的正确打开方式Vivado里和线程相关的参数有好几个很多人只知道一个general.maxThreads但实际上布局和布线阶段还有独立的线程控制。最常用的全局设置是在Vivado Tcl Console里执行set_param general.maxThreads 8这个命令要放在综合和实现步骤之前可以在GUI的Tcl Console里执行也可以写进综合和实现的Tcl脚本里。更好的方式是打开Vivado安装目录下的init.tcl文件把这一行写进去这样每次启动Vivado都会自动加载。除了全局参数布局阶段可以用place.maxThreads控制布线阶段可以用route.maxThreads控制。实测中布线阶段对多线程的利用率相对较高但线程数超过物理核心数后反而可能因为线程切换开销而变慢。我机器是8核16线程设置成8个线程是最优的设成16反而布线慢了将近5%。这里有个小坑需要注意很多教程会建议把maxThreads设成CPU核心数减一理由是留一个核心给操作系统。这个说法在Windows上有一点道理但在Linux服务器上实测差异很小。你可以直接用物理核心数或者物理核心数减一两者选哪个都行但不建议超过物理核心数。4. 工程结构和工具策略让每一次编译都花在刀刃上4.1 增量编译能不能用、怎么用才不翻车Vivado提供了增量编译模式原理是复用上一次编译的布局布线结果只对设计中有变动的部分重新处理没变动的逻辑直接沿用上一次的布局和走线。用法非常简单在Vivado Tcl脚本里上一次编译后指定输出检查点文件这次编译时加上增量选项# 第一次全量编译后导出检查点 write_checkpoint -force ./checkpoints/post_route_full.dcp # 后续增量编译时读入上次检查点并开启增量模式 read_checkpoint ./checkpoints/post_route_full.dcp synth_design -incremental -part xcvu9p-flga2104-2L-i注意这里的synth_design增量模式是针对综合的实现阶段的增量是另外一套参数。实现阶段用增量通常是在布局阶段读取上一次的布局检查点open_checkpoint ./checkpoints/post_route_full.dcp place_design -incremental route_design我一开始觉得增量编译是万能药但实践下来发现它的适用场景很有限。它能给你带来稳定收益的场景是逻辑规模大、改动非常小比如只改了某个子模块内部的少量逻辑、整体布局没有大变化。这种情况下增量编译确实快有时候能快百分之六七十。但增量编译有个很坑的地方是如果设计整体时序很紧张增量编译因为沿用了旧布局新加入的逻辑和旧逻辑之间的位置关系未必合理反而可能导致时序不收敛。另外如果改动的逻辑影响了模块间连接关系、或者改动了端口和时钟结构增量编译出来的结果可能出现黑盒错误或者布线失败。所以我的使用习惯是日常小改动用增量模式快速看结果每隔几次增量编译之后做一次全量编译作为校准和最终验证。这样既保证了日常迭代速度又防止增量编译累积出隐性时序问题。4.2 Out-of-Context 模块化编译把大工程拆成小工程Out-of-ContextOOC模块化编译是一个经常被忽略但收益很大的优化手段。它把一个模块单独综合生成独立的网表和检查点后续其他模块的修改不会触发这个模块重新综合同时还能为这个模块做独立的布局优化。在我的项目里有一个图像缩放模块、一个DDR读写控制模块、一个PCIe接口逻辑这三个模块基本稳定不动了。我把它们设置成OOC模式综合阶段只花很少的时间加载它们的检查点布局布线时这些模块内部的走线也基本保持上一次的结果。这样每次修改主逻辑时这三个大块头不再重复参与全流程计算整体编译时间能省下10%到15%。设置OOC的方法有两种。一种是在Vivado GUI界面里选中对应模块右键点击Set OOC Mode。另一种是在Tcl脚本里对要设为OOC的模块单独指定综合选项synth_design -top module_name -mode out_of_context -part xcvu9p-flga2104-2L-i write_checkpoint -force ./checkpoints/module_name_synth.dcp需要注意的是OOC模块综合时会忽略部分顶层约束你需要在模块内部自己定义端口的时序约束或者借用XDC文件里的create_clock约束。如果约束不全综合出来的模块网表可能在顶层集成时出现时序问题反而拖慢整体收敛。与OOC配合使用的是Block Reuse功能这是Vivado 2019.2之后引入的。它可以在实现阶段直接复用上一次布局布线好的物理块效果相当于把OOC和增量实现结合起来。使用的核心设置是set_property BLOCK_REUSE_CACHE_DIR ./block_reuse_cache [current_project] # 在第一次完整编译通过后导出可复用的物理块 write_block_reuse -force # 之后每次编译时如果模块没有改动工具会自动从缓存中复用物理块 set_property STEPS.SYNTH_DESIGN.ARGS.BLOCK_REUSE 1 [get_runs synth_1]实践上Block Reuse对时序收敛的整体效果比纯增量编译更可控一些因为复用的是一个完整物理块不会破坏模块内部的布局一致性。但Block Reuse对RTL编码风格有要求模块端口最好固化内部改动用寄存器使能或参数化方式实现否则每次改模块内部结构都会打破复用条件。4.3 合理使用布局布线策略不盲目追求最高性能Vivado和Quartus都提供了不同的实现策略但很多人只盯着“Performance”系列策略觉得时序性能更强的策略就更好。实际上默认的探索策略Explore和高性能策略Performance Explore往往比默认策略慢一倍以上因为它们会同时跑多个方向来寻找最优解。在调试阶段我的做法是先用默认策略Default快速跑出版本看时序报告大致了解哪里需要改。只有到了要收敛时序的收尾阶段才切换到Performance Explore策略去争取那最后的几十皮秒。同样道理布线阶段可以用Quick模式先快速看一眼大致的拥塞和时序情况再到最后出正式版本时用Default或者Aggressive模式。有人可能担心用Quick模式看不准时序我的经验是Quick模式的时序数据虽然正负偏差可能有几十皮秒但相对排序是可信的。也就是说它能准确告诉你哪条路径是最差的至于具体差多少到正式布线时才需要精确值。还有一个容易被忽略的参数是综合阶段的retiming和flatten_hierarchy。这两个参数如果打开会显著增加综合时间但对布局布线的时序收敛帮助不一定明显。调试阶段可以把flatten_hierarchy设置为rebuild综合速度快不少到最终发布版本再使用full。4.4 多个seed并行跑用机器数量换墙钟时间布线引擎的起点是随机种子seed不同的seed对应不同的初始布局最终收敛的时序和布线耗时都有差异。这是一个天然的并行化窗口——同一份网表用不同的seed在多个机器上同时跑布局布线谁先跑出可接受的时序结果就用谁的。这个技巧在时序收敛僵持阶段特别有效。当时我的工程布线阶段经常要跑三个小时以上我就准备了三台机器分别用seed 1、seed 2、seed 3同时跑同一次实现。最快的一台两个半小时跑完而且时序结果比均值还好。虽然总计算量大了但你等待的墙钟时间直接砍掉近三分之一。Vivado里设置seed的方法是set_property STEPS.PLACE_DESIGN.ARGS.SEED 2 [get_runs impl_1]在跑之前可以先用pre-route阶段的时序预估来判断设计是否还有希望。Vivado提供了一种方式在布局完成后、布线之前做一次快速的时序预分析用estimate_timing或者看Place Design后的时序报告。如果布局阶段都红了一大片那布线之后再怎么努力也很难收敛可以直接回头改约束或代码不用硬等着布线跑完。这一步能省下大量无效的布线等待时间。5. 一次次攒出来的实测记录13小时到5小时每一步都是什么效果5.1 原始状态设备、工程、时间基线为了让你对优化效果有个直观的认识我把当时的基准环境和每一步的实测数据列出来。当时的工程情况Vivado 2021.2UltraScale架构FPGA逻辑规模约26万LUT12个时钟约束两条较紧的跨时钟域路径。机器是Windows 10工作站CPU是8核16线程的i9-9900K内存32GB工程放在SATA固态硬盘上。整个流程用的是默认策略、全量编译没有开启任何增量或复用功能。这个配置下完整编译一次的时间是12小时50分钟到13小时10分钟之间几次测试误差在正负二十分钟以内。其中综合1小时40分钟布局2小时30分钟布线7小时50分钟最后的比特流生成和报告大约50分钟。5.2 每一轮优化做了什么、拿到了什么收益我逐步应用优化手段每一步都记录了完整编译的时间变化。要注意的是这些优化不是按顺序单纯累加的有些手段之间存在依赖关系所以收益会随着后续叠加略有变化。第一轮是系统层优化我把工程迁移到Linux服务器上服务器CPU是AMD Ryzen 9 5950X16核32线程内存加到64GB工程放在NVMe固态硬盘Vivado的maxThreads设置为16。第一次迁移后完整编译时间变为9小时20分钟。相比原始时间缩短了近29%。这个阶段收益最大主要来自Linux系统的效率提升和更强的CPU单核性能。第二轮是策略优化综合阶段使用默认策略不变布局阶段从Default切到WLFree一种偏向减少线长的布局策略布线阶段先用default跑一轮完整编译。策略调整后完整编译时间变为8小时10分钟。WLFree策略在布局阶段比Explore快还能减少后续布线压力但要注意的是并非所有设计都适用建议先小样本测试。第三轮是工程结构调整把三个大模块设置为OOC模式并启用Block Reuse缓存。这次改动涉及工程设置需要重新综合OOC模块并导出缓存首次切换时多花了1小时左右做准备工作但之后每次全量编译时间降到了6小时50分钟。OOC模块复用的收益约为一个半小时主要是省去了三个大模块内部重新综合和布线的时间。第四轮是流程编排在综合阶段之后加入时序预估脚本先跑一轮place_design并快速看时序报告有严重问题就直接回改代码不进入布线阶段同时准备了三台机器并行跑三个seed的布线。这个阶段在单机上完整编译时间并没有显著缩短但你实际等待的时间大幅下降。我记得有一次综合布局后发现时序红了一大片直接回头改RTL算下来这轮迭代只花了3小时比之前跑完整布线再发现问题快了近半天。第五轮是增量编译的日常化把增量编译模式加到了日常迭代流程中。在最终全量编译稳定通过后每次小改动都走增量编译实测时间在2小时30分钟到3小时之间。每一次全量编译稳定通过后导出检查点并启用增量模式。在这之后的日常版本中大多数迭代都从增量编译开始只有增量无法收敛或者改动范围较大的版本才转为全量编译。综合这些优化全量编译的稳定时间最终落在4小时50分钟到5小时30分钟之间日常增量迭代则基本在3小时以内。5.3 时间压下来之后整个开发节奏都变了这个变化你可能觉得不就是机器跑得快了点吗但对FPGA开发流程的影响是巨大的。首先是迭代密度。之前一天改一版就不错了现在一天能跑三到四轮完整验证时序收敛的试错成本大幅降低。很多之前因为“跑一次太贵”而不敢做的激进尝试比如调整流水线深度、修改跨时钟域约束现在都敢放手去试了。其次是联调效率。我之前有个习惯是先把RTL改得比较“确定”了才敢跑综合实现因为每次跑完发现小问题要等太久。现在不同了心态变得轻松很多——改一个信号直接跑一轮增量编译半小时出结果验证没问题了就继续往下走有问题的位置一眼就能定位到是这次改动引入的。最后是问题定位。编译快了之后我可以在不同的seed之间做对照实验看一条路径的时序瓶颈到底是因为布局位置不好还是布线资源紧张。在多个seed的结果都出现同一条路径超时的情况下基本可以确定是逻辑结构本身的问题而不是布线运气差。这种区分在之前13小时一轮的节奏下几乎是不可想象的。6. 常见问题与排查技巧实录6.1 问题速查表我在整个优化过程中遇到不少问题有一些属于典型的新手坑整理出来方便你对照排查。现象可能原因排查与解决maxThreads设置后没生效参数没写在综合之前或被综合脚本覆盖把set_param写进init.tcl或在Tcl脚本最前面就执行增量编译提示DCP版本不匹配上次导出的检查点文件与当前工程版本不一致确保read_checkpoint读取的是上一次完整编译的最终dcp文件Block Reuse后出现黑盒错误模块端口或内部层次发生了变化复用条件被打破关闭Block Reuse重新综合OOC模块导出新缓存OOC模块综合后集成时报时序错误OOC综合时缺少必要的时钟约束在OOC综合的XDC中单独创建模块所需时钟约束布线阶段内存占用过高系统卡顿内存分配不足触发了操作系统交换加大内存容量或把工程放到NVMe上减轻交换影响多个seed结果差异极大设计时序余量过紧属于正常现象以最优seed为准多个seed里取最好的一个作为参考Linux远程编译比本地还慢工程文件放在网络磁盘IO成为瓶颈编译前把工程同步到本地NVMe跑完再同步回去6.2 几个我踩过的坑值得单拎出来说第一个坑是关于threads参数。刚开始我以为maxThreads设置得越大越好直接把5950X的32线程全部交给Vivado结果布线时间反而比16线程还长原因是线程间同步和内存访问冲突的开销超过了并行收益。后来我做了几组对照测试发现16线程和12线程差别不大32线程明显变差。不同版本Vivado对多线程的支持程度不同旧版本甚至只能在综合阶段开启多线程布局布线阶段仍然单线程工作。建议你自己做几次梯度测试找到一个最优点。第二个坑是关于增量编译和Block Reuse混用。理论上两者可以同时开启但实际上容易出现检查点文件互相覆盖的问题。如果实现阶段用增量编译同时又开了Block Reuse工具可能从错误的位置读取或写入缓存文件导致时序结果莫名其妙变差。我的做法是把两个功能分开用大改动用全量编译加Block Reuse小改动用增量编译关掉Block Reuse两种模式不会交叉。第三个坑是关于并行跑多seed的资源调度。那个阶段我用了三台机器并行跑seed但其中一台机器因为磁盘空间不足在中途写检查点失败整个实现白跑了两小时。后来我给每台机器写了一个简单的脚本跑之前自动检查磁盘剩余空间、内存大小、CPU核心数不满足条件直接不进编译流程。这种看起来很基础的小脚本在长时间编译场景下是保命的存在。第四个坑是关于综合阶段的OOC设置。我当初为了节省时间一口气把六个模块都设成了OOC结果模块之间的接口时序约束频繁出问题反而花了很多时间在约束调试上。后来我把OOC模块缩减到三个真正稳定且独立的模块效果才达到预期。OOC不是越多越好它适合那些接口固定、内部稳定、跨模块交互少的逻辑块。6.3 编译加速的边界和取舍最后我想聊聊加速这件事的边界。不是所有编译时间都能被压掉也不是所有工程都值得花大力气去优化编译速度。如果你的设计规模只有几万LUT完整编译本来就只要一两个小时那花大量精力去搞OOC、Block Reuse、多机器并行其实是得不偿失的。编译加速的投入和收益和你的工程规模、迭代频率、团队协作方式强相关。大设计、高迭代频率、多人协作的团队编译加速带来的收益最大。还有就是编译加速不能以牺牲编译可靠性为代价。增量编译和Block Reuse模式跑出来的结果和全量编译在极端情况下可能存在细微差异尤其是时序收敛比较勉强的设计。我建议在最终版本回片或者交付之前一定要做一次干净的全量编译对比时序报告里的WNS最差负时序裕量和TNS总负时序裕量确认和增量编译的结果一致再放心使用。我自己现在的习惯是这样的正常情况下开发节奏是“改代码→增量编译快速验证→积累几轮改动后做一次全量编译校准”大版本交付之前再做一次干净的完整编译并和增量结果交叉验证。这套流程下来编译从原来卡脖子的瓶颈变成了一个可以灵活安排的普通环节。如果你正被动辄十几个小时的编译折磨我建议你别急着换电脑先看看自己卡在哪个阶段——是布线太久还是时序收敛反复然后针对性地选一两个方向做优化收益会很快显现出来。