CDC工作量评估

stancao

RT，28nm上的主流多媒体SOC做一次完整的CDC大约要花多久？

假设只有一个人做，非老手。。。目前只跑过spyglass的training labs...

哦，design都已经ready了。。。绝大部分ip都是arm/snps的，少数接口，系统控制/pinmux、clock/reset等自己写的。

求有经验的高手帮忙评估。。。

y23angchen

cdc是慢慢迭代的过程。  

1. 先将顶层的基本的约束写好，  包括时钟， 复位， input output 的时钟域。
2. 如果有设计上规划的subsystem， 建议将subsystem 单独做，然后将sgdc/waiver读入进来。
3. 各种需要固定值的case analysis写好。
4.一些不方便弄的模块，如iomux，可以用黑盒处理 assum path。
5.有些模块不需要检查，不关心其内部cdc，只关心其input 和output是否OK，如clock divider,  golden 的async bridge 等
6. 各种ahb/apb reg 配置的静态信号写出quasi_static
run  查看结果。
分析每一条报出来的ERR，或者添加约束， 或者添加waive。（建议添加约束，可能可以将大量相同原因的ERR都清掉， 而waive则只能一条一条waive 太吃力）。 有些不太确定的path，一定要喊module owner一起看，切不可随意waive。

继续run。 继续添加约束or waive。

直到最后，所有的ERR没有了。。。。

这是一个大工程。

写的不太好，大概是这么个流程。

rvisk

我怎么感觉搞反了呢。不应该是设计者提供cdc的所有内容吗
后端去check吗

y23angchen

回复 3# rvisk


   后端会管cdc的问题吗？最多会报出来，有条path  timing violation， 让你来看是不是真实path。
   cdc 是rtl design时候遇到的问题， 为什么会是后端去管这事情？

rvisk

回复 4# y23angchen


   我是看了你cdc的收敛流程，感觉变后端了。
   我表达意思，前端设计的时候把所有CDC的东西，得到这个东西不是靠工具，靠自己去后期去忽略，设计的时候就设计好了。

   原来我们做设计的时候，凡是CDC的地方都是调用标准的module，看到名字就知道这地方是跨时钟域的

rvisk

回复 4# y23angchen


   我是看了你cdc的收敛流程，感觉变后端了。
   我表达意思，前端设计的时候把所有CDC的东西，得到这个东西不是靠工具，靠自己去后期去忽略，设计的时候就设计好了。

   原来我们做设计的时候，凡是CDC的地方都是调用标准的module，看到名字就知道这地方是跨时钟域的

y23angchen

回复 6# rvisk


我不知道其他公司怎么弄的，反正我们这里流程就是这样子了。

如果说需要做CDC的地方都有特殊标记， 那要是没做跨时钟域处理，也就是没有标记。
后端怎么去看这个没做跨时钟域处理的地方是否有问题？


还是不懂为什么是后端去check这件事。
如果对于一个新写的模块需要做CDC，难道不是designer 自己去把这事弄好，还需要后端来帮忙？




我理解的后端是把FLOOR PLAN 做好， 把CTS 做好， timing 满足， 符合各种DRC。 就好了。

stancao

回复 2# y23angchen


   您谦虚了。。。总结的很好，和spyglass的培训建议的流程是一致的呢。

   就想请问一下这样一个full chip cdc的大工程以您经历过的项目来讲，大概会花多少时间收敛啊？假设从soc的所有代码ready开始做，designer也相当配合review的话。

stancao

回复 3# rvisk


不是的哈，CDC是前端设计的问题，后端是管不了的。。。

像您说的跨时钟调用成熟的跨时钟Module是一种很好的设计习惯，很可能大概率就避免了cdc的问题，即使不做cdc也无所谓（就我经历过的项目不做cdc分析也能顺利TO甚至量产的）。

做cdc就是为了防止有些跨时钟的地方designer自己设计但没有考虑周全，降低设计风险,增加TO成功的信心...

y23angchen

回复 8# stancao

      取决于设计， 如果代码量很大， 时钟又很复杂， 那run 一次得几个小时。
      跑一轮， 然后看一遍，应该一天时间就过去了。
      具体要看迭代几轮了。

      还是先让 module owner 先把自己负责的模块的一些约束先给出来， 这样让负责cdc 的人员工作量小一些。