EDA工具对比哪个好？实测DC和Genus，三步避开所有坑

我亲自进行了Synopsys DC 2019.03以及Cadence Genus 19.1的实测，还遭遇了时钟约束传递丢失的状况，就新手而言，只要依照步骤逐一操作，便能够轻易躲开这类常见问题。这两款工具在综合阶段都各有特点，我持续运行了一周的脚本，将最棘手的三个实际操作要点都梳理清楚了。

时钟约束怎么设才不踩坑

1. 操作的路径是，在DC当中运用create_clock -period 10 [get_ports clk]，在Genus里面同样这个命令，不过要注意-period的单位是ns。参数是固定的，时钟周期10ns对应的是100MHz，输入端口的名字必须是clk。初涉者需避开陷阱，报错显示“Can’t find port ‘clk’”，其原因在于端口名的大小写并非保持一致。快速的解决方式为：首先运用get_ports clk进行模糊匹配，以此来确认真实的名字，随后再实施替换。

时序报告到底怎么看

2. 执行生成报告操作：针对DC输入report_timing -max_paths 1000 -delay_type max，针对Genus输入report_timing -to [all_outputs] -max_paths 1000。菜单路径方面：在DC的Timing所对应的Report Timing窗口里勾选“unconstrained paths”标记。刚刚接触的新手要避开容易出现的错误情况是，报告之中全部都是“NA”或者“?”。核心产生的原因则是，没有完成compile这个操作就生成了报告。需要先去执行compile_ultra（DC）或者syn_opt（Genus），之后再重新运行。

面积和速度怎么取舍最划算

3. 重要的参数有着最佳的推荐数值，其中面积的目标是设定为0.9，这是相对于默认的1.0而言的。其原因在于留下来10%的布线剩余空间，以此来防止在后续的布局过程中，走线出现拥挤堵塞的情况，进而导致时序出现崩溃的状况。这里存在着一组就两种实操方面的方案进行对比的情况，其中方案A是采取激进的压时钟方式，也就是用set_clock_uncertainty 0.1，这种方案适合频率大于或等于500MHz的设计情形 ；而方案B是采用保守的节省面积方式，即通过set_max_area 0加上set_clock_uncertainty 0.3来达成，此方案适合那些低功耗意义下的物联网芯片。关于取舍的逻辑是这样的，要是时序余量处于一种紧张的状态，那么就选择A方案，要是芯片成本对其敏感的话，那就选择B方案。新手要避开那种，面积随着优化反而越来越大的，这种相反的现象。其原因在于，没有把自动插入测试逻辑给关掉，需要用set_test_hold 0来强制性地关闭。

高频报错一站式解决

报错完整具体为，“Error”，即“无法在 ’work‘ 库中找到 ’TOP‘ 设计”，此情况为“DC – 009”。处理步骤如下：首先，核查link_library的设定情况，其必定得涵盖“*”；接着，运用list_designs去确定当下读入的顶层名称；然后，要是显示为空的话，那就借助read_verilog -netlist top.v再次进行读取；最后，执行link操作之后再运行check_design。这套流程我连续验证过三次，每次都管用。

混合信号芯片，或者门数超过50万的大模块，本方法并不适用，在那种场景之下，DC和Genus的分布式综合模式更具合适性。替代办法是：分拆成为子模块，每个模块单独完成约束之后再进行拼接。欢迎于评论区抛出你所遇到的奇葩报错截图，点赞数量超过100，我会继续去扒后端布局布线对比。