Lockup latch的用法，看这个就够了！
文章右侧广告为官方硬广告，与吾爱IC社区无关，用户勿点。点击进去后出现任何损失与社区无关。
本公众号秉承 “越分享越有价值，越分享越幸运” 的理念，致力于数字 IC 后端实现方面（涉及逻辑综合，布局布线，静态时序分析，物理验证等）的技术经验交流和分享。目前短期计划是每周更新两篇技术干货分享，年度目标是实现 2018 年度发表 100 + 篇技术原创文章。
同时，小编也开通了知识星球，满足部分粉丝特别的需求（比如平时技术上或者职业规划等方面有比较多的困惑）。欢迎有兴趣的朋友加入。另外明天星球上会发布高性能 CPU 模块的设计实现教程。
吾爱 IC 社区公众号之前推送过一篇文章，简单分享过 LOCKUP LATCH 的概念及其应用。今天将带大家深入来了解 Lockup latch 实际的应用。
听说 Latch 可以高效修 hold 违例（Timing borrowing 及其应用）
Lockup Latch
如下图所示，DOMAIN1 和 DOMAIN2 分别为两个 clock domain，在 func mode 下两个 domain 不存在相互交互的 path。因此，在做时钟树综合（CTS）时，会各自独立长 clock tree，即他们之间的 clock latency 可能存在较大的差异。在 func 模式下不会有任何问题。
但是，在做 DFT 的时候，我们将 DOMAIN1 和 DOMAIN2 的寄存器串在一条链上了。在 scan shift 时是有问题的。他们之间是需要做 hold check（比如 DOMAIN2 的 clock latency 比较长）。对应的 setup 和 hold 检查波形图如下图所示。从波形图中得知，hold violation 比较大。为了解决这个较大的 hold violation，需要在 DOMAIN1 和 DOMAIN2 之间插入 LOCKUP LATCH，从而改善较大的 hold violations。
Positive or Negative Level Latch?
- Launch flipflop 正沿触发，capture flipflop 也是正沿触发
这种情况需要加一个
低电平传输的 Lockup Latch
。也是最常见的 case。
- Launch flipflop 负沿触发，capture flipflop 是正沿触发
这种情况无需加 Lockup Latch。
- Launch flipflop 负沿触发，capture flipflop 也是负沿触发
这种情况需要加一个
高电平传输
的 Lockup Latch。
- Launch flipflop 正沿触发，capture flipflop 是负沿触发
这种情况留给各位思考，自己画波形图就可以知晓
深入浅出讲透 set_multicycle_path，从此彻底掌握它
Lockup Latch 应该加在哪里？
这里以第一种情况为例（即 Launch flipflop 和 capture flipflop 均是正沿触发的情况）。通过以上的分析得知，需要在这两个 domain 之间加 Lockup latch，才能够显著减少 hold violations。那么问题来了，这个 Lockup latch 应该加在靠近 Domain1，还是靠近 Domain 2?
- 靠近在 Domain2 中
将 Lockup latch 加在靠近 Domain2 中后的简易电路结构如下图所示。由于时钟树综合阶段工具会做将 Lockup latch 和 Domain2 中的寄存器做 balance，因此 clock skew 会比较小，这里假设 skew 为 0。对应的 setup 和 hold 检查波形如下图所示。
从波形图中得知，Domain1 中的 DFF 到 Lockup latch 的并没有改善（与之前 Domain1 中 DFF 和 Domain2 中 DFF 的 hold 一样大）。因此，这种 Lockup latch 加的方式是不正确的。
- 靠近 DOMAIN1 中
将 Lockup latch 加在靠近 Domain1 中后的简易电路结构和波形图如下图所示。
从波形图得知，Domain1 中的 DFF 到 Lockup latch 的 hold 明显得到了改善。同样 Lockup latch 到 Domain2 中的 DFF 的 hold 也没有问题。虽然 setup 检查变严格了，但是由于 scan 模式下，
scan clock 是低速的
。所以 setup 也没有问题。
加 buffer 抑或加 LOCKUP?
众所周知，传统修 hold violation 的方法就是插 buffer。理论上当你的 hold violations 比较大的情况，都可以采用 insert Lockup latch 的方法来解决（
Func 下慎重，需要确认不影响逻辑功能
）。比如在某个 endpoint 点存在 1ns hold violation，此时你可能需要在这个 endpoint 上插几十个甚至上百个 hold buffer。这种方式解决 hold violation 存在以下几方面的弊端。
-
Hold buffer 太多，可能导致 routing congestion 问题
-
Hold buffer 太多，可能导致 power consume 问题
-
由于 large skew 和 OCV 效应，timing 在各个 corner 下 variation 会比较大，容易导致 setup 和 hold 冲突
关于 setup 和 hold 冲突的解法方法，会推送在小编的知识星球上。有需要的可以关注起来。
LOCKUP LATCH 的应用
- Clock skew 非常大的情景
Clock skew 特别大，往往是由于前端设计时，时钟结构规划不合理导致的。比如 scan clock 和 func clock 太早分开。一方面可以通过前期
更改时钟电路结构
。另一方面可以后期 Timing fixing 阶段
通过 ECO 方式加入 Lockup latch
。关于如何做这种 ECO 留给各位思考，其实很简单。
- uncommon clock path 非常长
在吾爱 IC 社区之前推送的关于时钟树综合的分享中，提到想得到一个比较好的，比较小的 clock skew，一定要将 uncommon clock path 做到最短。Uncommon clock path 越长，受 OCV 的影响越大，不同 corner 下 variation 越大，hold 越不好收敛。
小编知识星球简介：
在这里，目前已经规划并正着手做的事情：
-
ICC/ICC2 lab 的编写
-
基于 ARM CPU 的后端实现流程
-
利用 ICC 中 CCD（Concurrent Clock Data）实现高性能模块的设计实现（
本周四发布
） -
其他内容待定
在这里，各位可以提问（支持匿名提问，提问从此不再害羞），小编会在 24 小时内给予解答（也可以发表你对数字后端设计实现中某个知识点的看法，项目中遇到的难点，困惑或者职业发展规划等）。
反正它是一个缩减版的论坛，增强了大家的互动性。更为重要的是，微信有知识星球的小程序入口。星球二维码如下，可以扫描或者长按识别二维码进入。目前已经有
十八位
星球成员，感谢这十八位童鞋的支持！欢迎各位铁杆粉丝加入！（
星球的门槛将越来越高，成员满 20 后，由目前的 128 元调整为 168 元
）
相关文章推荐（不看保证后悔）
深度解析 Create_clock 与 Create_generated_clock 的区别
clock jitter 是否对 hold time 有影响？（文末有福利）
为什么时钟树上要用 clock inverter(min pulse width check)
PBA（Path Base Analysis）想说爱你不容易（静态时序分析基础篇）
【惊呆了！】你居然还在用 flatten 方式进行 timing signoff
合理的时钟结构能够加速 Timing 收敛（时钟树综合中级篇）
【机密】从此没有难做的 floorplan(数字后端设计实现 floorplan 篇)
听说 Latch 可以高效修 hold 违例（Timing borrowing 及其应用）
秒杀数字后端实现中 clock gating 使能端 setup violation 问题
教你轻松调 DCT 和 ICC 之间 Timing 与 Congestion 的一致性
Scan chain reordering 怎么用你知道吗？
数字后端实现时 congestion 比较严重，你 hold 得住吗？
Final netlist release 前，你应该做好哪些工作?
深入浅出讲透 set_multicycle_path，从此彻底掌握它
数字后端实现时 congestion 比较严重，你 hold 得住吗？
时钟树综合（clock tree synthesis）基础篇
好了，今天的码字就到这里了，
原创不容易，喜欢的可以帮忙转发和赞赏，你的转发和赞赏
是我不断更新文章的动力。小编在此先谢过！与此同时，吾爱 IC 社区（
52-ic.com
）也正式上线了。吾爱 IC 社区（
52-ic.com
）是一个专业交流和分享数字 IC 设计与实现技术与经验的 IC 社区。如果大家在学习和工作中有碰到技术问题，欢迎在微信公众号给小编留言或者添加以下几种联系方式进行提问交流。
打赏的朋友，请长按下方二维码，识别小程序进行打赏，欢迎砸钱过来！小编晚饭能不能加个鸡腿，全靠它了，呵呵！
作者微信：
