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

一、写在前面

一个数字芯片工程师的核心竞争力是什么？不同的工程师可能给出不同的答复，有些人可能提到硬件描述语言，有些人可能会提到对于特定算法和协议的理解，有些人或许会提到对于软硬件的结合划分，作者想说，这些说法，其实对也不对，硬件描述语言，翻来覆去无非是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的约束，而针对于整体的约束管理来说，我们区分出自顶向下的方法和自底向上的方法，其各有利弊，我们可以将其结合，来进行实际芯片的约束管理。