Open Source EDA
模拟部分
| Synopsys | Cadence | Other | |
|---|---|---|---|
| Schematic | Custom Compiler | Virtuoso | |
| Simulation | Hspice | spectre/Ultrasim | ngspice |
版图工具
| Synopsys | Cadence | Other | |
|---|---|---|---|
| Layout | Custom Compiler? | Virtuoso | Laker(SpringSoft) |
| DRC&LVS | Diva | Calibre(MentorGraphics) |
数字前端部分
| Synopsys | Cadence | Other | |
|---|---|---|---|
| Digital Simulation | Vcs/Verdi | irun/ncverilog | verilator/iverilog |
| Logic Synthesis | Fusion compiler/Design Compiler | Genus | yosys |
| DFT | Fusion compiler/DFT Compiler/TestMax | Modus | |
| ATPG | TeraMAX |
数字后端部分
| Synopsys | Cadence | Other | |
|---|---|---|---|
| PnR | Fusion Compiler/ICC2/ICC/Astro | Innovus | |
| RC Extraction | StarRC | QRC | |
| STA | PrimeTime | Tempus | |
| Formality | Formality | ||
| Power | RedHawk |
官网：
https://solvnetplus.synopsys.com/s/
https://solvnet.synopsys.com/DownloadCenter/dc/product.jsp
https://eft.synopsys.com
https://spdocs.synopsys.com/dow_retrieve/latest/vg/eman/PDFs/ExecutionManager_UserGuide.pdf
VCS用户手册！
https://spdocs.synopsys.com/dow_retrieve/latest/home_public/vcs.html
Verdi 用户手册
https://spdocs.synopsys.com/dow_retrieve/latest/home_public/verdi.html
FileZilla
To use the third-party FileZilla GUI tool to download software from the Synopsys Electronic File Transfer (EFT) system, do the following:
Open FileZilla and Click File > Site Manager > New Site
Create a Site Name such as SNPS-EFT
Under the General tab, enter the following information:
Protocol: FTP - File Transfer Protocol
Host: eft.synopsys.com
Port: Leave blank unless you are required to use a specific port
Encryption: From the drop-down, choose Require Explicit FTP over TLS
Logon Type: Normal
User: <SolvNetPlus_username>
Password: <SolvNetPlus_password>
Click OK to save your changes
To Connect to EFT, click the SNPS-EFT icon (link)
Or Click File > Site Manager > SNPS-EFT > Connect
After you are connected to Synopsys EFT, under the Remote Site: window (on the right) you will see various folders, such as Incoming, MyFiles, MySiteFiles, and sitennnn.
Click sitennnn > MyProducts > rev and look for the folder with the product name and version. Click the product name folder, then choose the files you wish to download. (You can use the Ctrl or Shift keys to select multiple files.) Right-click the selected files and choose Transfer.
Besides the sitennnn/MyProducts/rev (revenue) directory containing the latest product releases, other product directories under sitennnn/MyProducts include auth (patch releases) and rev_o (archived revenue products).
NOTE: For products that use the Synopsys Installer, the product files will be named *.spf or *.part0n. Typically, you will need to download one or more "common" and OS "platform" files (for example, *common.spf and *linux64.spf). The Synopsys Installer is a separate download, in the sitennnn/MyProducts/rev/installer_v directory. For assistance on using the Synopsys Installer, see the Installation Guide.
OpenROAD Tool Flow
OpenROAD-flow官方教程
OpenROAD-flow源码
yosys源码
OpenROAD源码
TritonRoute源码
带你了解强大的Cadence家族，你可能只用到了它1/10的工具
基于Ubuntu20部署OpenROAD-Flow(更新于2020.11.23)
https://theopenroadproject.org/
https://openroad.readthedocs.io/en/latest/
https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts
本文翻译自OpenROAD官网提供的文献 OpenROAD: Toward a Self-Driving, Open-Source Digital Layout Implementation Tool Chain
我们在这篇文章中描述 OpenROAD 的范围和最初的成果。OpenROAD 是 DARPA IDEA 计划里的一个项目，致力于实现 24-hour, "no human in the loop" 的数字版图生成，跨越集成电路，软件，版图领域。如果成功，OpenROAD 将减少成本，专业知识，进度和高风险性这些阻碍系统设计者的问题，达到 IDEA 的目标：民主化硬件设计 (democratization of hardware design). 几个新颖的技术方向由 IDEA 的 24-hour, "no human in the loop" 目标引出，他们包括：
此外，开源的自驱动 (self-driving) 工具的开发，伴随着大量的技术和文化挑战，这是一件难度极高的项目("moonshot")
在过去的十年里，正当硬件设计工具和设计方法取得进步的时候，半导体行业失去了对产品设计成本的控制，如图1. 今天，成本，专业知识，高风险这些障碍阻挡了设计者使用先进的技术进行硬件设计。话句话说，硬件设计的创新受困于
特别地，在 IC 领域，布图自动化以高级技术节点的方式，已经集成到巨大的，极其复杂的软件产品当中。然而，设计能力的缺失——例如，伴随底层设备的进步和模式技术的提升，相应地去提高产品质量的能力——在过去的十年里变得明显，甚至在一些先进的公司也是如此。 因此，为了满足产品和计划的需求，如今的前沿 SoC 产品公司必须将大的设计团队进行划分，每个单独的设计模块交给一个小团队去完成，并且每个团队里的设计者都有对应方面的专业知识。DoD 研究员和开发团队没有足够的资源来执行这样的策略，因此他们的硬件设计周期一般在 12-36 个月。
为了克服上述的限制，跟上摩尔定律下的 SoC 指数级增长的复杂性，DARPA IDEA 计划旨在开发一个全自动的，"no human in the loop" 电路版图生成器，使没有电子设计经验的使用者也能够完成电子硬件的物理设计。OpenROAD("Foundations and Realization of Open, Accessible Design") 项目起始于2018年6月，作为 DARPA IDEA 计划的一部分。OpenROAD 的首要目标是减少阻碍系统设计者进行硬件设计的成本，专业知识，高风险行这些障碍。团队的贡献者包括来自 Qualcomm, Arn 和由加州大学圣迭戈分校领导的多所大学。OpenROAD 力图开发一个全自动的开源工具链，用于数字版图生成，遍及管芯，管壳，和电路板，最初注意力放在SoC设计的RIL-to-GDSII阶段。更详细地来说，我们的目标是以源码的形式发布一款可生成 tapeout 的工具，并且采取自由的协议，期望成为 EDA 界的 Linux ("Linux of EDA")
三个创新的基本技术突出了 OpenROAD 团队为达到 no-human-in-loop (NHIL), 24-hour turnaround time (TAT) 的策略。
一个互补的的准则是通过版图生成中的 "选择自由" ("freedom from choice") 来减少设计和工具的复杂性，这可以提高可预测性，避免在设计过程中进行迭代。图2 显示了基础技术的协同作用和解决方案空间的限制。
OpenROAD的方法寻求为EDA工具、学术-产业合作和学术研究本身建立一个新的范式。OpenROAD 的目的在于克服在EDA领域根深蒂固的 "culture", "critical mass / critical quality" 障碍, 建立开源的观念。为了启动这个项目，我们带来了:
我们看到，机器学习、问题划分和分解、并行分布式搜索和优化的紧密结合是实现目标的关键。
本文的其余部分将概述 OpenROAD 在github上部署的工具和流程的当前状态。数字IC版图生成 (“RTL-to-GDSII”) 领域的早期验证点和校准已经在包括16nm FinFET技术在内的多个设计实现中获得。
OpenROAD的版图生成工具链由一组开源工具组成，这些工具将 RTL Verilog、constraints (.sdc)、liberty (.lib) 和 technology (.lef) 文件作为输入，目的是生成可用于流片的 GDSII 文件。图3说明了与单个OpenROAD任务对应的工具流。这些包括逻辑综合 (logic synthesis, LS)，floorplan (FP) 和 power delivery network (PDN) 的产生，布局，时钟树综合 (CTS)，布线和版图生成。
开源LS的主要短板在于时序意识 (timing awareness) 和优化。OpenROAD已经找到了实现时序驱动综合的两种途径。
floorplan 和 PDN 由 TritonFPlan 完成，他有两个主要组成部分。
这些配置文件是必须的，因为学术开源工具开发者(或，他们的工具)无法从芯片制造商那里看到完整的未加密设计实现细节。我们在下面第四部分中讨论这个问题。TritonFPlan 使用混合大小布局器 (RePlAce) 来进行初始化全局布局。生成的宏全局定位提供了一个起始点，由此来探索 floorplan 的解决方案。对于每个有着固定的宏和PDN的 floorplan 解决方案，我们再次使用我们的 placer (RePlAce)，根据估计的总的线长标准，以确定最佳 floorplan. 限制包括只支持矩形，以及宏的数量小于100。
RePlAce 是一款基于静电模拟的开源分析布局器，采用BSD协议。在OpenROAD中，RePlAce用于在 floorplanning 期间混合大小(宏和单元)布局，用于在给定 floorplan 中的标准单元布局，以及在时钟树综合(CTS)期间用于时钟缓冲区合法化。时序驱动布局通过集成 FLUTE, OpenSTA 达到，并伴随信号网重加权迭代 (a signal net reweighting iteration) 。时序驱动的 TDRePlAce 工具采用标准LEF/DEF、Verilog、SDC 和 Liberty 格式进行输入，并包含一个快速RC估计器用于寄生参数提取 (parasitics extraction)。目前正朝着使用商业格式 (LEF/DEF/Verilog) 启用布线驱动的方向努力。图4显示了由密歇根大学内部设计顾问小组生产的小型RISCV基块(foundry 16nm技术)的 RePlAce 布局。
TritonCTS基于GH-Tree(广义H-Tree)范式，对低功率、低偏移和低延迟时钟分布进行时钟树综合(CTS)。采用动态规划算法找到一个最小估计功率的时钟树拓扑结构，并且与给定的延迟和偏移目标一致。线性规划用于产生下沉聚类 (sink cluster) 和时钟缓冲区布局。叶级布线可以使用单干Steiner树或Prim-Dijkstra算法。
在版图生成流程中，TritonCTS 与 布局器placer (RePlAce)和 布线器router (TritonRoute)之间有接口。布局器用于使所插入的时钟缓冲器合法化 (legalization)。布线器映射 sink pins 到 将被用于时钟树布线的GCELLs. TritonCTS的输入是LEF、布局的DEF、布局过的gate-level Verilog、配置文件和库描述文件。(对于每个foundry，需要一个一次性的库特性描述 (library characterization)。目前，这个库的特性描述由 foundary 或 工具使用者使用商业EDA工具来完成。TritonCTS 的输出是带缓冲的布局DEF，带缓冲的门级Verilog，和时钟树全局布线，以ISPD18布线指导格式。TritonCTS 在 GitHub 上公开。早期的验证采用了16nm和28nm的 foundry 技术。处理多个时钟源、非默认布线规则等方面的改进正在进行中。
TritonRoute使用LEF和布局的DEF，然后在给定全局布线方案下，对信号网络和始终网络，以布线指导格式，进行详细布线。在进行详细的布线之前，TritonRoute 使用快速逼近算法对全局布线方案进行预处理，以确保每个网络都有一个Steiner树结构。在详细布线阶段，在保持网络连通性的同时，尽量减少拥塞和线的长度。然后在每层的基础上迭代地解决详细的布线问题，并将每一层划分为互不相交的布线面板。面板布线问题是一个最大加权独立集(MWIS)问题，并采用基于混合整数线性规划 (MILP) 的方法并行求解。MWIS 优化分配布线需考虑：(1) 层内和层间连接，(2) 线长和最小化，以及 (3) 各种设计规则。通过多次迭代的面板布线策略，正确处理了面板间和层间的设计规则，实现了分配布线的最大化。到目前为止，TritonRoute支持主要的TSMC16 metal 和 cut spacing rules，即 LEF58_SPACING，LEF58_SPACINGTABLE 和 LEF58_CUTCLASS。早期的评估显示，在TSMC16设计块中，间隔规则违规减少了大约1/10。详细的布线流程，集成和优化本地网络布线，是达到100%完成、DRC-clean布局能力的下一步。
OpenROAD项目正在开发的其他元素包括上述的 “基础技术”(机器学习、分割、并行优化), 设计性能分析背板 (寄生参数提取、静态时序分析和功率/信号完整性), 云基础设施工具/流程部署 和机器学习，“内部设计顾问”任务，相应的在包和PCB领域的自驱动版图生成功能。本部分概述了其中几个项目元素的状态。
OpenSTA 是商业 Parallax timer 的开源版本，采用 GPL3 协议。Paralla timer 引擎已商业性地提供近20年，并已被纳入许多的 EDA 和 IC公司的时序分析工具中。2018年9月，OpenSTA 在 GitHub 上开源。开发者James Cherry在最初的版本中增加了Arnoldi延迟计算、功率报告和其他功能。OpenSTA已经确认支持多个高级的 foundry nodes，并支持标准的时间报告样式。到目前为止，OpenSTA计时器已经集成到TD-RePlAce (时间驱动增强版的 RePlAce )、物理感知综合 ( Yosys ) 和 门级工具( TritonSizer ) 中。图5(a) 显示了来自OpenSTA的端点 timing slack 和一个商业 signoff timer 的比较。图5(b)显示了OpenSTA和商业 signoff timer 之间端点 slack 差的分布。
在OpenROAD的方法中，寄生参数提取(PEX)工具运行一个 foundry 的设计工具包(PDK)，以建立线电阻、地电容和对同一层或上下相邻层线的耦合电容的线性回归模型。一个基本的用例是流程中的另一个工具(例如，CTS，全局布线，定时分析)调用PEX，提供一个由感兴趣的线路和它的邻近组成的输入DEF文件。提供的输出文件包括提取的寄生参数。图6(b) 对比了从测试网得到的电阻和电容的实际值和预测值，验证了回归模型，显示出良好的拟合。预期的演进包括连接PEX功能到未来可能的广泛的 IDEA 物理设计数据库，并扩展模型拟合方法，以实现低开销的寄生参数估计器，用于时序驱动布局，在全局布线期间的串扰估计，等等。
我们的电力完整性分析工作的一个关键目标是实现整个SoC的电力传输网络(PDN)布局策略的单通道、正确和安全结构规范。我们的电力传输网络(PDN)综合工具将芯片区域划分为多个区域，并在每个区域选择一组可用的PDN布线模板(参见上文 Floorplanning 讨论中提到的 “config” 文件)。这些模板是可缝合的，因此当它们邻接时，它们遵守所有的设计规则。PDN工具接受一组预定义的模板 (图6(a))、早期(floorplanning 阶段) 的用于设计的布局DEF，以及可用的功率分析信息(例如，我们的OpenSTA工具可以提供基于实例的功率报告)。然后，一个经过训练的ML模型在每个区域确定一个安全模板。一个早期的原型表明，基于机器学习的方法可以成功地交付一个满足给定(例如，1mV静态)IR drop规格的PDN。
为了让用户利用OpenROAD工具以及其他协作者开发的工具，云基础设施项目旨在提供端到端无缝的用户体验。在我们的云部署中，用户将他们的Git repo 预定到我们的云系统。设计更改推送到Git repo后，OpenROAD流程会自动编译，当流程完成时，用户会收到一封电子邮件通知。然后用户可以通过浏览器下载结果文件。如果需要，用户还可以在基于web的前端监控流程的进程。我们的云部署是弹性的，当更多的用户登录到服务时，或者当用户请求并行处理能力时，它会利用更多的计算资源。例如，该服务可以弹性地部署多台机器来运行带有多个随机种子的工具(例如placer)，从而在给定的时间预算内获得更好的结果。或者，结合全局设计分区，云部署可以在一个云实例上并行地运行每个设计分区，从而最大限度地提高并行速度，最大限度地减少设计周转时间。
为了使机器学习(ML)和最终自驱动的OpenROAD 流程的大规模应用成为可能，我们正在开发METRICS 2.0[8]，它可以作为一个统一的、全面的设计数据收集和存储基础设施。METRICS 2.0 字典提供了一个标准化的度量标准列表，适合在工具或流程执行期间收集，以捕获关键设计参数以及设计流程中各种工具的结果。我们还提出了基于 JavaScript Object Notation (JSON) 的数据日志系统架构，以及基于MongoDB数据库的数据存储和指标检索系统架构。图7演示了 METRICS 2.0系统架构。计划的体系结构消除了创建数据库模式的需要，并支持无缝数据收集。METRICS 2.0与TensorFlow等机器学习框架紧密结合，后者为MongoDB的读写提供了简单的接口，并支持机器学习算法的快速部署。
根据 NHIL 和 24-hour 周转时间的要求，启动OpenROAD工具链时，必须以可靠的试运行 floorplans 作为流程起点，以最小化运行故障的可能性。这是“系统级设计” (system-level design)(IDEA TA-2)和 “版图生成” (layout generation)(IDEA TA-1，我们在OpenROAD中提到)之间的一个关键环节。通过在每个IP中嵌入物理实现信息(例如，使用行业标准IP- xact描述中的供应商扩展机制)，以及利用特定的技术和工具链的参数和统计模型，可以增强SoC的早期总体规划评估。通过组合和详细说明这些信息，可以对面积和性能进行早期评估，从而在可行的 floorplan 中指示可能失败的候选人，或建议设计实现进行微调 (硬宏模块的布局、分组、寄存器片插入等)。
上述的工具构成一个工具链，该工具链产生可用于产生准备最终验证和制造的设计。最初的支持平台是CentOS 6。为了评估流程，我们团队中的非工具开发团体(例如，U. Michigan, Qualcomm 和 Arm)对我们的工具输出进行精细的分析，并为工具开发人员提供目标校准指标。在这里，我们利用了一个基于现有设计的测试用例套件，这些设计之前已经准备好了，这些设计的复杂性(从小块到整个芯片)和工艺(例如，16nm和65nm)都有。我们的测试用例套件还包括不断开发的顶尖复杂的SoCs。持续的集成测试套件在开发期间会分别验证这些工具，并跟踪回归指标和特性影响。
我们近期将继续开发上述工具和流程。更广泛地说，我们还将寻求解决各种技术、结构和文化上的挑战，这些挑战在项目开始时就已经很明显了。
一个关键的技术挑战是开发设计自动化技术以及能够在SoC、package (PKG)和PCB领域协同优化的版图生成流。今天，SoC、PKG和PCB工具和流程基本上是脱节的，即使不需要数月，也需要数周时间来通过手工迭代来整合这三种设计。为了在PKG和PCB领域提供NHIL、24小时的周转时间，一个统一的规划工具是必不可少的，它可以在三个数据库之间无缝协调，并实现快速迭代。图8展示了我们设想的统一规划工具。统一规划工具还将包括优化引擎，使用分析和ML方法来评估三个设计之间空间复杂性的权衡。
其他一些技术挑战包括以下内容。(1) 在IC设计中，设计过程数据“小而贵”——在这里，获得一个数据点可能需要三周时间来运行一个工具流——挑战了机器学习，“智能”工具和流的开发。(2) 对硬件设计和设计工具的测量和建模的新的共同标准的需求必须与 foundry 和商业EDA的 IP 相兼容，这可能会影响到未来 “Linux of EDA” 的参与度。(3) 在硬件设计过程中，很难辨别现在需要“人类智能”，但必须被“机器智能”所取代的关键节点。
几个结构性的挑战源于我们作为学术工具开发者的身份，工具链必须生产出可流片的GDSII。(1) OpenROAD工具可能不具备 foundry-qualified，这意味着OpenROAD工具和工具开发人员将无法读取加密的高级节点 PDKs。通过构建 tapeout 数据库来实现安全性和正确性，OpenROAD工具需要配置文件和一次性的 “OpenROAD kit” 元素，用于每个foundry的实现。(2) OpenROAD对时序、寄生参数和电力/信号完整性的分析和评估器都不是“签收”验证器。因此，在整个布局生成流程中，需要额外的性能保护。而且，流程之后的验证可以由设计者和/或 foundry 进行。(3) OpenROAD工具由非商业t团体开发发布。商业EDA供应商接收bug/增强请求，并附带一个测试用例，该测试用例展示了存在问题的bug或行为。相反，由于封锁 NDA / IP限制，我们收到的错误报告不太可能伴随着测试用例。这使得错误修复和增强过程变得复杂。
最后，我们的外联努力寻求文化的改变和潜在开发人员和工具使用者社区的参与。例如，在学术研究领域，一个实验室的代码就是它的竞争优势，而自由的开源仍然很少见。我们希望OpenROAD和IDEA/POSH项目能帮助推动这方面的文化变革。关于工具使用者，我们观察到商业化的工具总是由“高级用户”来驱动产品价值——也就是说，那些对特定工具的成熟和能力有着深厚兴趣的付费客户。传统上，高级用户使用新工具来应对前沿挑战，并积极推动工具改进。对于OpenROAD来说，找到我们的“超级用户”是一个非常重要的需求，特别是因为他们能够在源代码级别改进工具和流程。
在本文中，我们回顾了OpenROAD的范围和现状，这是 RPA IDEA 计划里的一个项目，旨在开发一个自驱动的，开源的的数字版图生成工具链。上面的只是一个简要说明。我们欢迎反馈、参与和贡献。
译者注：限于本人知识水平有限，原文中一些专业词汇还没有找到合适的对应，故暂且只能保留英文名称。如有翻译出错或者不通的地方，请在评论区告知。另外，也推荐有兴趣的小伙伴直接去看看原文，其中的单词和语法不是很难。
最近看到一篇非常好的文章，是关于一个外国团队做了不同数字芯片实现工具的效果比较，更确切的说是Cadence和Synopsys全系列的Digital Implementation工具在大规模复杂设计优化上的最终PPA结果比较。大家知道比较广义的数字芯片实现流程包括从综合到signoff的所有阶段，而这里主要比较的将是下图高亮的部分，也就是综合、DFT、PnR加上STA的部分，大致如下如所示：
而针对这些步骤，Synopsys和Cadence分别提供了全套的工具来支持：
在这里我们只讨论针对先进工艺的次世代实现工具，因此ICC和Encounter不在讨论之列。上述工具中大部分大家应该都熟悉，或者至少听说过。Fusion Compiler作为Synopsys提出的fusion技术的集大成者，将RTL2GDS流程融合到同一个工具中，并在综合和PnR中调用ICC2和DC的优化算法，旨在进一步提高PPA。而Cadence以Innovus为突破口配合Genus和Modus，已经具备完整的实现工具流程，加上QRC+Tempus已经取得台积电7nm认证，补齐可数字实现的时序signoff工具，已经具有相当实力。
为了全面对比PPA和runtime，本次对比专门设计了一个规模较大，频率较高的设计，并配合使用先进工艺来全面评估各种工具的实力。本次结果对比所使用的设计样本的基本信息如下:
针对上述设计规模和时钟频率，一共采用了几种流程来进行综合、DFT、PnR和时序signoff：
我们一起看看他们各自的表现如何：
这可以算是很长时间内业界的标准流程了，实验结果显示在runtime方面主要是DC太慢，而ICC2只能算中规中矩，因此花费了最长的时间；而由于ICC2的QoR不尽如人意，为了达成3.2GHz的目标，不得不进行多次优化迭代；PT属于标准流程，乏善可陈，但是PT-ECO的physical aware不好用，迭代次数较多，而且有些buffer竟然插到boundary外面去了，实在是让人不可思议。这个现象我倒是没遇到过，不过PT-ECO不好用确实深有体会。
在上述标准流程的结果不理想的情况下，该团队遂和Synopsys反馈他们遇到的的DC runtime和ICC2的QoR问题。Synopsys说等他们的新工具出来问题都能迎刃而解，我本人表示怀疑。而且这并不能解决现实问题，在和他们沟通的过程中，发现一共有两队人马分别开发维护DC和新工具'Descartes'，后者貌似可能是DC2，但是新工具还不能开放使用，最后用Fusion Compiler来做实现，用PT来signoff。不过这个流程除了runtime，其他的竟然都是最差的。Fusion Compiler我自己也试过，后端部分基本上就是ICC2，脚本可以无缝切换，默认效果一般，此外会有一些advanced feature，不过有些需要额外的license，所以没有过多尝试。
这个流程只是把ICC2换成的Innovus，本来以为会有很多问题，但是却出奇的顺利，业界应该有不少公司在这个流程上做了大量工作和反馈，因此现阶段的流程比较成熟。Innovus在各个阶段展现都展现出了令人满意的结果，尤其是在pre-CTS阶段实现了复杂时钟树的嵌入，效果拔群。另外在Innovus实现阶段也没有开启任何advanced feature, 仅仅是比较标准的流程。基于这个流程的结果已经在Timing, Power和Runtime三个方面全面优于前面的流程，因此可以看出，根本性的差别确实出在ICC2和Innovus之间。
既然Tempus已经取得了台积电7nm认证，那么试试它也没有什么坏处。而且Cadence确认了Tempus的精度不输于PT，甚至可能更准，与Spectre的误差在3%之内。另外Cadence声称他们在所有数字工具中使用"common engines"，好处之一就是可以直接在Innovus里面做Tempus ECO来加速收敛过程。我认为这里更重要的是可以不必在PnR阶段再去费时费力调correlation，或者增加额外的margin来应对PnR工具和STA工具的误差。
这里有两个大动作，一个是Genus做综合，另一个是Modus做DFT。由于设计本身的DFT电路已经放在RTL里面了，只用Modus做scan stiching就不难了。而Genus做综合的特别之处在于Cadence声称这是'true physical synthesis'，即在综合早期既可以贴近Innovus的标准做placement，而结果也显示datapath上的组合逻辑确实有比较大的改善。其实Synopsys也一直想往DC里面嵌ICC2的引擎来做placement，不过目前效果都不是特别理想。这组整体上的QoR也是所有流程中最出色的，不仅完成了既定的3.2GHz目标，而且略有余量，总体功耗也最低，如此效果只能说amazing了。另外这里的RC提取换成了QRC，效果和StarRC没什么区别，不过QRT+Tempus的runtime比StarRC+PT要快1.5-2倍。
不得不说，如此结果让作为Synopsys长期用户的我吃惊不小，以前虽然双方工具都用过，也感觉得到Innovus优化方面做得更好，但是从未定性定量做过对比，也不知道实际数字上的差距如此惊人。做过后端的人都知道，100ns左右的TNS如果依靠工程师的分析，优化和调整来完全修干净是要花相当大的精力和时间的，而仅仅通过切换工具就能达成，工程师们简直不要太开心。另外也想借此机会对Synopsys提个建议：你们可长点心吧！要说ICC2被别人超越是有部分原因在于Innovus在开发和发布时机上的出奇制胜，那么作为传统护城河的DC和PT都要被攻克了，这难道不能说明问题了么？现阶段用户全部转Cadence工具的最大阻碍在于巨大的用户惯性和迁移成本，但是个人认为这种阻碍在绝对的PPA优势面前是很脆弱的。由衷期待后续双方再接再厉，再出精品，也让我们工作轻松一点。
感觉全文都在给Cadence打广告，Cadence应该给这个团队打钱，然后顺便分我一点...有兴趣读原文的请点下面链接。