⚠️本文目的为 个人学习记录 及 知识分享。因个人能力受限存在解读不正确的可能。若您参考本文进行产品设计或进行其他事项并造成了不良后果本人不承担相关法律责任文章目录定义标准第一层标准第二层标准第三层标准定义标准笔者认为高质量、可交付的标准 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呢
如何写好一份SDC——流程篇
发布时间：2026/5/28 2:26:31
⚠️本文目的为 个人学习记录 及 知识分享。因个人能力受限存在解读不正确的可能。若您参考本文进行产品设计或进行其他事项并造成了不良后果本人不承担相关法律责任文章目录定义标准第一层标准第二层标准第三层标准定义标准笔者认为高质量、可交付的标准 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呢
