1. 从“时钟”到“数据”：Data to Data Checks到底是什么？
刚接触静态时序分析（STA）的朋友，一听到“时序检查”，脑子里蹦出来的肯定是“时钟”。没错，我们最熟悉的Setup和Hold检查，主角就是时钟信号：发射时钟（Launch Clock）和捕获时钟（Capture Clock）。它们像两个严格的裁判，一个负责说“数据可以出发了”，另一个负责说“数据必须在这之前到达终点”，检查的是数据在时钟沿之间的“旅行时间”。
但芯片内部的世界远比这复杂。很多时候，我们需要关心的不是数据对时钟的响应，而是两个数据信号之间的“默契”。比如，一个控制信号（SCTRL）必须提前于数据信号（SDA）稳定下来，系统才能正确锁存数据；或者一个使能信号必须在地址信号变化之后保持一段时间，防止误操作。这时候，时钟裁判暂时“退场”，检查直接在两个数据引脚之间进行。这就是Data to Data Checks，也叫数据到数据检查。
你可以把它想象成一场没有发令枪的接力赛。A选手（数据信号A）的起跑时间，直接决定了B选手（数据信号B）必须在何时之前或之后到达某个位置。STA工具需要检查的，就是这两位选手之间的相对时间差是否满足规则。这个规则，就是我们用set_data_check约束命令告诉工具的。
我刚开始用这个约束时也犯过嘀咕：没有时钟边沿做参考，工具怎么知道“提前”或“之后”是相对于哪个时间点呢？其实，秘密就在于相关的时钟引脚（related clock pin）。我们约束时，会指定一个参考时钟。对于Setup检查，工具会看数据信号A是否在数据信号B的相关时钟有效沿之前足够早到达；对于Hold检查，则看是否在该时钟沿之后足够晚才变化。这个“相关时钟沿”，就是那个隐形的裁判坐标。
2. 零周期Setup Check：一个反直觉的“陷阱”
Data to Data Checks本身概念不难，但里面藏着一个非常容易让人掉坑里的“魔鬼细节”，那就是零周期（Zero-Cycle）Setup Check。这也是很多设计新手看时序报告时最懵圈的地方：报告出来的Hold检查路径，怎么和自己想的不一样？
我们先来理解正常的、非零周期的Data to Data Setup检查。假设我们约束信号SCTRL必须比信号SDA提前至少2.1ns到达（Setup要求），参考时钟是CLK，周期为10ns。工具会怎么检查呢？
- Launch Edge（发射沿）：对于SDA来说，它的发射沿是CLK的某个有效沿（比如上升沿）。
- Capture Edge（捕获沿）：对于Setup检查，捕获沿和发射沿是同一个时钟沿。
177
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
