Design Compiler
目的与配置
解析RTL，将逻辑映射到特征化的标准单元，优化时序/面积/功耗，并导出实现网表。DC输出是逻辑实现结果，并非物理实现或签核结果。
从用户配置的环境或工具配置文件中解析dc_shell。
发现实际的版本、支持的选项、许可证和本地文档。
使用环境发现；不要假定特定的安装目录、账户、许可证端点或启动shell。
将安装清单、日志和文档索引保存在私有本地状态中。
调用与命令约定
直接从准备好的环境中使用配置的可执行文件。保留其包装器文件名；更改调度程序的调用名称可能会选择不同的产品。请在该版本的文档中确认交互模式和批处理模式约定。 本参考提供命令候选，不证明其存在于每个版本中。
dc_shell -f design.tcl
对于支持的阶段脚本，flow.py 无需shell包装器即可捕获命令、状态、日志、工件和检查点。工具可能提供具有不同语义的本机接口来处理类似的标志。
输入与输出
有序的Verilog/SystemVerilog/VHDL源文件、顶层模块、参数/宏定义/包含路径、目标/链接 .db 库、批准的SDC；需要时还包括UPF和物理参考。记录复位语义和DesignWare依赖性。.lib转换需要可工作的Library Compiler；请验证其本地可用性。
映射后的 .v、.ddc、导出的 .sdc、综合 .svf；设计、约束、面积、时序、功耗和QoR报告。保留未映射/解析的证据以及原始RTL/SDC哈希值。教程库面积以库单位表示，而非声明的平方微米值。
阶段操作
在构造新命令之前，检索已安装命令的语法、参数类型、默认值、限制、示例、功能需求和设计状态前提条件。确定每个操作是查询状态、更新派生状态、修改设计还是导出工件。
| 阶段 | 命令或本机过程 | 前提条件和检查 |
|---|---|---|
| RTL | analyze elaborate link check_design | 逻辑库和有序源文件必须解析每个必需的引用。 |
| 约束 | read_sdc check_timing report_clock | 检查时钟定义、所有接口延迟、恢复/移除、例外和未约束的端点。 |
| 映射 | compile compile_ultra | 使用 compile -map_effort medium/high；compile_ultra 需要其功能许可证和模式前提条件。 |
| 检查 | report_area report_timing report_power report_qor | 读取单位、活动假设和路径覆盖率；无适当活动时，功耗仅为估算值。 |
| 导出 | set_svf write_file write_sdc | 在转换前启用SVF；同时导出映射网表和检查点。 |
Tcl、检查与文档
current_design；get_designs *；get_cells -hierarchical；get_clocks *；report_hierarchy；check_design；check_timing。对于Synopsys集合，使用 sizeof_collection 而非Tcl的 llength。
对于Tcl接口，将路径/参数构造为Tcl列表，使用支持的集合API处理集合，捕获错误并检查显式命令返回值。语法有效的Tcl文件不能证明命令可用性。对于本机驱动程序，请使用其记录的输入格式。
python3 scripts/docs.py search '' --tool design-compiler --limit 20
# 当存在多个匹配时，选择已安装的版本/安装。
# 使用以下命令检索返回的条目：python3 scripts/docs.py show DOCUMENT_ID
示例从包目录运行。阅读命令发现以了解私有索引创建、限定检索、运行时可用性和生命周期检查。手册条目可能描述变量或诊断信息，而非可调用命令。缺少文档仍然是选择不支持命令的障碍。
受控参数与依赖关系
映射努力（中等/高）、增量编译、PDK允许的缓冲/单元选择、面积与时序的侧重。compile_ultra -timing_high_effort_script 和 -area_high_effort_script 是两种不同的策略；在组合开关前检索限制条件。重定时、层次结构更改和时钟门控会改变验证责任，需要新的等价性证据。
较小的面积可能会增加延迟和扇出。物理感知/拓扑设置需要物理库和RC工艺；不要仅仅因为它们存在就启用它们。时钟周期和接口预算保持不变。更改后的网表会使Formality和所有下游检查点失效。
记录原始/建议值、报告支持假设、手册参考、有效阶段和预期指标。使用优化进行有界比较，并保持功能不变和硬约束。
故障恢复与验证
在调整之前，诊断源顺序、宏定义、未解析引用、库选择和约束。对照功能意图审查推断出的锁存器和多驱动器。不支持的命令需要已安装版本的文档。许可证或加载器失败需要修复环境。
捕获命令/状态、内部日志、报告和状态/检查点标识。对原因进行分类，查阅相关安装文档并应用最小干扰的合理纠正。恢复上一个有效传入检查点的可写副本并重新运行受影响的阶段。在保留更改之前比较已验证的指标；保留被拒绝的尝试。使用故障排除进行恢复决策。
功能更改需要明确的授权。不要放宽时序要求、移除必要约束或绕过验证来报告成功。当没有合理的纠正措施或配置的预算耗尽时，停止操作，并报告需要哪些输入或环境修复。
模板与验收
检查实际输出和特定产品的报告是否符合请求的范围。对于综合/实现，要求映射/链接的工件和保留的约束；在转换后重新证明功能。对于验证，要求完整的覆盖率和干净的必需检查。对于仿真/调试，要求预期的任务/测试能够完成，并附带审查过的诊断信息。
将文档验证、Tcl语法检查、工具执行、阶段验收和端到端签核证据分开保存。生成的流不是经过验证的实现。有关所需证据边界的详细信息，请参阅执行契约和验证范围。