如何写好一份SDC——流程篇
⚠️本文目的为 个人学习记录 及 知识分享。因个人能力受限，存在解读不正确的可能。若您参考本文进行产品设计或进行其他事项并造成了不良后果，本人不承担相关法律责任
文章目录
- 定义标准
- 第一层标准
- 第二层标准
- 第三层标准
定义标准
笔者认为高质量、可交付的标准 SDC 应当满足以下三个维度。这三个标准由浅入深，构成了评价 SDC 完善程度的三个等级
第一层
SDC 语法正确，时钟结构符合预期，没有漏掉约束的路径
第二层
约束真实且合理，I/O 边界约束具有真实的物理意义
第三层
模式（Mode）与场景的完整覆盖，为后端留够友好的余量
第一层标准
1、再写完初始的sdc之后，要依次经过SPYGLASS LINT、SPYGLASS CONSTRAINTS、SPYGLASS CDC工具检查
可以做什么：它可以检查你的 SDC 语法对不对，有没有把两个没有同步处理的时钟域漏设 set_clock_groups，基于结构和静态规则进行分析。
不可以做什么：无法分析真实的物理延迟，AND Cell的delay是多少？时钟树的Clock Skew是多少？工具都不知道，无法判断信号能否在1ns跑完这件事。
条件：当清完全部Error，保证所有Waring都是waive之后可以进入下一步。
2、再完成SPYGLASS检查后，要经过Design Compiler综合工具生成网表
可以做什么：顾名思义进行综合，load sdc、rtl、lib等文件后对电路进行compile，生成网表并在该过程中尽可能优化PPA。使用check_timing结合RTL进一步检查sdc有无未被约束的endpoint，是否缺少输入/输出延迟，有无组合逻辑环等问题，对于sdc在完整性上进行检查。
不可以做什么：无法给出真实的时序分析，DC为了速度，它的时序计算引擎是粗略的、近似的。如果SDC 里写了一个极度不合理的约束，DC 为了满足它，可能会塞入上百个 Buffer，导致面积爆炸。DC 可能会报 Timing Met，但代价是交出一个后端根本无法布线的畸形网表。
条件：check_design/check_timing没有问题，时序违例在可接受的范围内（比如时钟周期的10%），且使用Formality完成formal check后可以进入下一步。
至此第一层意图得到满足
第二层标准
再完成formal check后，经过Prime Time去执行STA
可以做什么：使用 CRPR 时钟重收敛悲观度去除、PBA 基于路径的分析等算法在不同的corner下去计算延迟。如果在 PT 里看到了巨量且荒谬的违例，往往意味着SDC 约束写错了，误导了 DC，导致 DC 综合出了垃圾网表。
在前端阶段，可以使用lib自带的线负载模型进行相对真实的时序分析。在该阶段面向第二层意图对sdc进行迭代，在时序报告中如果发现了一条很长的跨模块组合逻辑路径时序不满足，在有RTL 设计意图支撑下可以添加Exception。借助时序报告验证约束参数正确与否，去查阅厂商的 Datasheet，或者跟系统架构师对齐，根据板级走线和 PHY 的真实出pin延迟，精确设定 set_input_delay 和 set_output_delay。
不可以做什么：此时我们使用的lib提供的线负载模型（WLM），而不是后端提供SPEF文件，因此时序分析依旧不准确。
条件：check_timing是clean或者是可接受的，并且时序违例的合理的，可以交给后端进行布局布线等操作。
至此第二层意图得到满足
第三层标准
在和后端的battle中持续优化sdc的约束数值。目前笔者还没走到这一步，等有了经验再更新。
思考：
既然DC和PT都无法提供准确的时序分析，何时对特殊路径设置MCP和set_false_path呢？