[静态时序分析简明教程(十)]模式分析与约束管理

一、写在前面

一个数字芯片工程师核心竞争力是什么?不同的工程师可能给出不同的答复,有些人可能提到硬件描述语言,有些人可能会提到对于特定算法和协议的理解,有些人或许会提到对于软硬件的结合划分,作者想说,这些说法,其实对也不对,硬件描述语言,翻来覆去无非是always和assign这几个语句的反复使用,而一些基础的协议算法深究起来其实也并不复杂,于作者而言,在常规的技能以外,有两项额外的技能颇为重要,其中之一便为sdc/STA的分析能力,它的重要之处在于作为桥梁建立了前端和后端的连接,虽然对于DE工程师而言,初版交付的sdc往往不甚准确,也没有办法通过这份sdc生成一份无误的timing report,但sdc的内容体现却是完完整整的将时序约束从行为级的描述映射到了gate level这样一个真实的电路层次上面。
写此专栏,一为学习记录,二为交流分享,以犒粉丝读者。

1.1 快速导航链接·

静态时序分析简明教程(一)绪论
静态时序分析简明教程(二)基础知识:建立保持时间,违例修复,时序分析路径
静态时序分析简明教程(三)备战秋招,如何看懂一个陌生的timing report
静态时序分析简明教程(四)时钟常约束
静态时序分析简明教程(五)生成时钟
静态时序分析简明教程(六)时钟组与其他时钟特性
静态时序分析简明教程(七)端口延迟
静态时序分析简明教程(八)虚假路径
静态时序分析简明教程(九)多周期路径
静态时序分析简明教程(十)组合电路路径
静态时序分析简明教程(十一)模式分析与约束管理
静态时序分析简明教程(十二)浅议tcl语言

二、模式分析

如今的设计非常复杂,同一芯片在不同的时间点可以执行多种功能,最简单的,比如在正常的模式下,执行视频编解码的功能,而在debug模式下, 其中的dft部分会通过jtag读出特定寄存器的值以此来满足debug需求。因此,设计需要满足不同模式的需求,也就是不同条件下的sdc需求和sta需求。

请考虑如下图所示的电路,其中的实线路径为功能路径(正常模式),虚线的路径为扫描路径(debug路径)
在这里插入图片描述
实际的电路中会选择哪一条路径呢?
这其实是由SE这个端口所决定,若SE为1,即扫描路径(F1->F2/SI),若SE为0,即功能路径(F1->F3),这里我们假设这部分电路再正常工作的条件下时钟周期为10ns,而在扫描路径的条件下,时钟周期是40ns,这很合理不是吗?对于debug条件下,并不需要高频时钟约束。
我们发现,我们需要写两部分的约束,分别对应其低频条件和高频条件,指定其工作模式。我们可以通过set_case_analysis这条语句来实现, 因此有了下面这两部分的时序约束:

create_clock -name SysClk -period 10 [get_ports CLK]
set_case_analysis 0 [get_ports SE]
create_clock -name TstClk -period 40 [get_ports CLK]
set_case_analysis 1 [get_ports SE]

三、约束管理

3.1 自顶向下的方法

将整个芯片看成单个设计单元,将约束施加在顶层,这种方法的优点是拥有一个简单的使用模式,优化相对简单,但是缺点是无法扩展,因此不大适用于真正的大型设计。

3.2 自底向上的方法

将大芯片分成子芯片,再将子芯片分为模块,为每个模块创建约束,这种方法的优点是易于扩展,可以单独的修改每一个模块的sdc约束,但是在集成合并的过程中可能会出现不满足时序的情况,因为模块级的约束无法看见其相邻模块的时序冗余和时序关系,这会导致多次迭代来满足整个芯片的时序要求。

四、总结

为了区分芯片的不同模式,我们使用set_case_analysis的语句来进行sdc的约束,而针对于整体的约束管理来说,我们区分出自顶向下的方法和自底向上的方法,其各有利弊,我们可以将其结合,来进行实际芯片的约束管理。

猜你喜欢

转载自blog.csdn.net/weixin_43698385/article/details/132286713