Design Compiler指南——设计综合过程

        在前面一章介绍完施加约束之后,接下来要做的工作就是将设计进行综合编译(compile),本文我们将主要讨论综合编译的过程。主要分为这样几个部分:

  • 优化的三个阶段及其特点
  • 编译的策略
  • 编译层次化的设计

一、优化的三个阶段

        这一节我们介绍Design Compiler进行优化的三个阶段:结构级、逻辑级以及门级,在不同的阶段,DC运用的方法和优化余地是不一样的,我们将对这几个阶段的特点和优化方法进行一个介绍,这里一起归纳一下,希望能加深认识。

Design Compiler指南——设计综合过程_第1张图片

        上图是这三个阶段的关系图,可以看到,结构级属于最高的抽象层次,当读入Verilog代码或者没有经过映射的db文件后,DC的优化从这个阶段层次开始,可以说,结构级是优化的最高层次,所以对DC来说,这个层次的综合可以称为高层次综合(High-Level Synthesis)。结构层的下一个优化阶段是逻辑级阶段,也是读入映射过的db文件的DC的初始优化阶段。再往下一个阶段是门级阶段,也是优化的最后阶段,这里所要作的工作主要就是GTECH到工艺库的映射。

1、结构级优化

        因为结构级是优化过程中层次最高的一级,因此它也是DC可以采用的优化方法最多的一级,它的主要优化方法如下图所示

Design Compiler指南——设计综合过程_第2张图片

1)DesignWare选择

        DW选择是结构级优化的一个很主要的特点,在这个阶段DC能够根据设计者施加的时序或者面积的约束在DW的不同实现方式中找到它认为最佳的实现方案。比如加法器的实现方式一共有如下几种

Design Compiler指南——设计综合过程_第3张图片

        其中DW Foundation需要有专门的license,而且使用之前还要设置综合库(synthetic library)。 

2)共享子表达式(Sub-Expressions)

        这里的子表达式主要是指数学表达式,比如下面这个例子,如果按照原来的语句综合,会包含6各加法器,但是如果表达式之间的公共项提取出来,便可以大大的减小面积,如下图

Design Compiler指南——设计综合过程_第4张图片

        如果要直接综合出共享后的电路,可以在编写RTL代码的时候强制指定共享项:

Design Compiler指南——设计综合过程_第5张图片

3)资源共享(Resource Sharing)

        资源共享的原理与共享子表达式类似,只不过这里指的所谓资源是一些HDL的运算符和表达式,比如加(+)、减(-)、乘(*)、除(/)以及大于(>)、大于等于(>=)、小于(<)、小于等于(<=)。比如给定一个语句

Design Compiler指南——设计综合过程_第6张图片

        DC会根据具体的约束条件综合出最符合要求的结构来。

4)运算符排序(Operator Reordering)

        对于下面这个表达式Z <= A + B + C + D(输出Z是施加了一定时序约束),DC最初是按照从左至右的顺序计算的,也就是说它最初的排序如下

Design Compiler指南——设计综合过程_第7张图片

        如果几个输入信号到达的时间相同,DC会通过运算符排序优化成下图的平衡的结构,减小延时:

Design Compiler指南——设计综合过程_第8张图片

        如果A信号较迟到达,则综合出的电路结构会如下 :

Design Compiler指南——设计综合过程_第9张图片

2、逻辑级优化

        在经过结构级优化之后,电路被转化成了工艺无关的GTECH库的形式,这级也称为逻辑级,对于逻辑级优化来说,只有一个方法,那就是——结构化 (structure)或者扁平化(flatten)。

Design Compiler指南——设计综合过程_第10张图片

1)结构化(structure)

        结构化是DC在逻辑级的默认的优化方法,它是指:使用电路的一些中间项构成一个多级的电路结构。如下图的电路一共有三级逻辑,下一级的输入是上一级的输出,使用这种优化方法一般情况下能综合出兼顾时序和面积的电路来。

Design Compiler指南——设计综合过程_第11张图片

        结构化电路的典型是奇偶校验电路。

2)扁平化(flatten)

        扁平化是将所有的组合逻辑打平成乘积项和(SOP)的两级结构,类似与可编程阵列逻辑(PAL)。使用这种结构的特点由于没有利用中间项,综合后电路面积将会变得很大,但是却不一定能取得较好的时序。

        扁平化结构的电路和设置扁平化的DC命令如下所示:

Design Compiler指南——设计综合过程_第12张图片

dc_shell > set_flatten true -effort low | medium | high

综合结构化和扁平化的特点,可以归纳如下:

Design Compiler指南——设计综合过程_第13张图片

        由于DC默认是用结构化的方式综合逻辑级电路,而且这种方式可以得到兼顾时序和面积的结果,因此我们可以先用这种(结构化)方式优化。在优化后的电路中找出关键路径,看看关键路径上有没有符合使用SOP电路的模块,再将这些方便使用SOP的模块set_flatten,以便取得最佳的效果。 

3、门级优化

        门级优化是优化的最后阶段,它所要完成的任务就是将GTECH的电路映射到最终的工艺库中,并且保证映射后的电路不违反设计规则(Design Rule)。

Design Compiler指南——设计综合过程_第14张图片

1)工艺映射

        工艺映射包括组合逻辑映射时序逻辑映射。组合逻辑映射是指DC使用工艺库中的各种门替换GTECH单元,并选择能实现相同逻辑的符合时序及面积要求的单元。

Design Compiler指南——设计综合过程_第15张图片

        时序逻辑映射的方法和组合逻辑相类似,也是出于速度和面积的考虑,尽量使用复杂的时序单元吸收一部分组合逻辑。 

 Design Compiler指南——设计综合过程_第16张图片

2)设计规则检查(DRC)

        对于工艺库的单元而言,Foundry都指定了每个单元的工作条件的限制,比如最大电容(max_capacitance)等等,这些限制也可以称为设计规则(Design Rule),在设计规则限定的范围内,Foundry提供的参数才有实际的意义。比如一个单元允许的最大电容为5pf,而实际工作电路中出现的电容值为10pf,那么这时,便违反了设计规则,单元的参数也就不能确保是准确的了。

        因此,DC在作门级优化的时候,在映射的过程中也会检查电路的设计规则,一般的做法是在单元中插入buffer增加驱动能力,或者将小驱动的单元替换为大单元。设计规则检查分为两个过程——DRC I 和DRC II 。

        DRC I是指Design Compiler在不影响电路的时序和面积的前提下修正违反规则的一些单元,如果在这个前提下不能完全修正,则要进行下一步的检查,即DRC II,这一步的修正必然是以牺牲一部分时序和面积为代价的。

二、编译策略

        编译过程是指设计经过三个阶段的优化,最终形成门级网表的过程,在这一节里,我们主要就编译的策略,它包含如下几方面的内容——

  • 中断编译的方法
  • 从报告中检查时序,调整策略
  • 修正保持时间违反(Hold time violations)

1、中断编译的方法

        在DC-Tcl的界面下,当我们键入compile命令时,DC就开始了编译,也就是优化的过程。优化是在设计规则的条件下,运用不同的算法,综合最终出满足时序和面积的电路。优化首先是时序驱动(timing-driven)的一个过程,其次再是面积。如果找到了一个满足时序和面积等约束的电路,编译将会停止;如果通过种种编译仍不能满足时序,编译也会停止下来;另外,我们也可以人为的中断编译。

        人为中断编译的方法是键入Ctrl-C,经过一段时间的等待后(有可能时间会很长),优化过程暂停,并弹出如下菜单:

Design Compiler指南——设计综合过程_第17张图片

        这里有四个选项,设计者可以根据情况作出选择。

        DC在编译的过程中,会自动打印出一个报表,报告编译的总时间,设计的面积,关键路径的时序违反和总共时序违反情况,我们可以根据需要更改打印的列项目:

Design Compiler指南——设计综合过程_第18张图片

2、分析报告,调整策略

        一般情况下,我们先作一个默认的编译,这样一般可以取得既快又准确的结果,然后在编译完成后使用一些报告时序的命令,并分析它们的输出结果,使用的命令主要有

Design Compiler指南——设计综合过程_第19张图片

        从这些报告中,我们可以看到电路中是否有违反的约束,如果有,那么它是什么类型,还有电路中的最大负裕量(worst negative slack)是多少,等等。下面我们就几个常见的约束违反情况,谈谈纠正它的综合策略

1)较大的时序违例

        以下图为例

Design Compiler指南——设计综合过程_第20张图片

        从report_constraint –all这个命令的报告可以看出,需要到达的时间是1.20ns,而实际到达为2.84ns,违反了1.64ns。之所以判断它是一个较大时序违反的情况,并不是因为1.64这个绝对值很大,而是相比较需要时间而言,1.64是一个较大的值。一般而言,如果电路中的最大负裕量(简称WNS)所占时钟周期的15%以上的话,可以认为电路存在较大的时序违反

      确认存在较大时序违反之后,下一步就是找出原因,消除违反情况。可供参考的步骤有下面几种:

  1. 检查约束条件,看是否有疏漏或错误
  2. 检查模块划分,看组合逻辑是否穿过多个模块
  3. 重新编译优化后的网表
  4. 修改RTL代码   

重新编译(Re-Compile)

        当重新读入映射后的网表进行重新编译时,DC会自动将门级的网表重新返回到GTECH的结构,相当于逻辑级。然后分别进行逻辑级和门级的优化,但是同时也可以进行DesignWare的替换。

        如果设计者仅仅将映射后的网表拿来再做一次compile,编译后的结果并不会不一定会比原来的好,无非把以前做过的优化再跑一遍。因此,重新编译之前会改变一些参数,如——改变设计约束、改变set_structure和set_flatten参数以及改变编译的map_effort

改变map_effort重新编译

        对设计进行编译的时候,有三种编译级别可以选择,它们分别时低级、中级和高级。

dc_shell > compile -map_effort low | medium | high

        不同的级别编译要求的编译时间和编译结果都各不相同,compile –map_effort low编译时间最短,但是结果不一定好,它一般用于设计预估(Design Exploration),不用在重新编译环节。
compile –map_effort medium是DC默认的编译级别,大多能在一定的时间内得到较为满意的结果。这也是我们推荐的初始编译级别。

        compile –map_effort high 编译的过程中会使用前面的级别中没有的算法,因此它所要求的时间是最多的,结果也是相对最好的。这种级别一般用在重新编译的阶段。

修改RTL代码

        修改源代码所能取得的效果是最直接的,同时也是代价最高的。修改代码后,DC会从最上层的结构级开始优化,前面也讨论过,越上层次的优化方法越多。所以通常这样得到的结果也越满意。但是,修改代码也不一定放之四海皆准的方法,因此并不是所有的设计我们都能获得源代码,同时也不是可以随便修改的。

2)较小的时序违例

        以下图为例

Design Compiler指南——设计综合过程_第21张图片

        从上图看出,相比较1.20的允许路径延时,0.10的负最大裕量(WNS)是比较小的(小于15%),而且已经认定了约束和模块划分都是正确的,那么应该怎样修复这个错误呢?

        这里主要讲一下Incremental Mapping:

dc_shell > compile -incremental_mapping

        这个开关告诉DC,在重新编译的时候不需要把网表返回到GTECH结构,因此也不需要作逻辑级优化,速度也较一般的编译更省时间。这里DC所要作的是进行门级单元的替换,即在不违反设计规则的情况下用延时小的单元替换延时较大的单元。另外,如果读入的是db格式的网表,在这个阶段也可以进行DesignWare的替换。

        如果要同时优化多条路径,需要使用另外一个命令——set_critical_range。这个命令设置的critical_range是以WNS的值为基准的,优化的是和这个值的绝对值差设置值的那些路径。因此,如果设置值为0,那么就仅仅优化一条关键路径。

dc_shell > set_critical_range 2 [current_design]

Design Compiler指南——设计综合过程_第22张图片

3)设计规则违反

        有些时候的时序违反是由于设计规则违反引起的,比如说一个单元的扇出(fanout)过大,导致它的transition time的时间迅速增加。对于这种情况,我们可以通过

dc_shell > report_net -connections -verbose

dc_shell > report_timing -net

        两个命令审查连线的连接和负载情况。

        要修正设计规则的错误,可以使用一个编译的开关:

dc_shell > compile -only_design_rule

        如下面这个例子,为了满足最大电容的规则,在A端口的内部加上了一个buffer,用于缓冲N路径对A的负载。

Design Compiler指南——设计综合过程_第23张图片

3、修正保持时间违例

        一个时序电路要想正常工作,除了必须满足建立时间要求之外,也需要满足保持时间要求。虽然保持时间检查和建立时间检查是同样重要的,但是我们在实际综合的过程中却不是把它们同时考虑,而是更多的把保持时间的检查放到布局后。这是因为

  • 时钟偏移必须要到布局完成后才能得到准确值
  • 修正保持时间的通常做法是插入buffer,而这可能会增加建立时间违反的可能性,并且增大了组合电路的面积
  • 保持时间检查用的一般都是电路工作的最佳条件,而在这个条件下,连线延时往往是被忽略的,连线延时也是必须在布局后才准确。

        如果确定要同时作建立和保持时间检查,那么在施加电路约束的时候要加入相应的开关,如:

Design Compiler指南——设计综合过程_第24张图片

        以及设置各自的工艺库—— 

        

        默认情况下,DC不修正保持时间的违反。如果确定要作修正,需要先设置一个变量再作检查 :

dc_shell > set_fix_hold [all clocks]

dc_shell > compile -only_design_rule

        加上only_design_rule的开关后,编译过程中仅仅更换单元大小,并增加buffer,以便修正设计规则违反和保持时间违反。

三、层次化设计的编译

        一个层次化设计的编译过程包含两个阶段:1、将所有的子模块映射到门级,2、优化。

          在一个层次化的设计中,我们可能会遇到下面这种情况

Design Compiler指南——设计综合过程_第25张图片      

        上图中,被综合的模块中D_design中含有三个子模块U1、U2和U3,其中U1和U3都是由模块Ades例化而来,这里的Ades称为多次例化的模块。对于这样一个设计,在compile之前使用check_design作检查的时候会报一个warning,即设计中存在多次例化的模块(multiple instantiations),如果在这种情况下,我们不考虑多次例化的模块(Ades),那么在继续的compile时候程序会终止退出。因此,必须对它进行处理,这里我们介绍两种方法——uniquify和compile + dont_touch。 

1、uniquify

        使用uniquify,DC会对每个例化的模块作一份拷贝,然后对它们分别取一个名字,即把不同的例化模块当作不同的两个模块处理。

Design Compiler指南——设计综合过程_第26张图片

        注意看上图,U1和U3两个模块的设计名分别由原来的Ades变成了Ades_0和Ades_1,因此在编译时,DC会将它们当作两个不同的模块,这样就可以根据它们不同的周围环境作优化。

        使用uniquify的具体实现方法如下

 dc_shell > uniquify

dc_shell > compile

2、compile + dont_touch

        这种方法先将多次例化的模块作单独的约束和编译,然后在整合到上一级模块的过程中将它的属性设置为dont_touch,再编译。

Design Compiler指南——设计综合过程_第27张图片

        上图中,U1和U3两个模块的设计名都没有变化,只是在编译D_design之前先将Ades编译一次。这样U1和U3实际上是一模一样的模块。

        compile+dont_touch的实现方法如下

Design Compiler指南——设计综合过程_第28张图片

        这里的约束文件有两个,一个是Ades的Aconstraints.tcl,另一个是D_design的Dconstraints.tcl,并且在source后一个约束文件之前要对编译过的Ades设置成dont_touch。
在设置了dont_touch属性之后,编译D_design的时候就会忽略Ades,这样有好处也有坏处,好处是可以保护模块不被修改,但是这样同时也限制了DC对U1和U3的进一步的优化。 

3、uniquify Vs compile + dont_touch

        通过对上述两种方法的介绍,我们不难看出它们各自的优缺点——

        compile+dont_touch由于只需要对多次例化的模块编译一次,因此可以减少整个设计的编译时间,也可以减少内存的使用量。在多次例化的模块很复杂并且工作站的硬件条件有限的情况下,使用这种方法的优越性的比较明显的。还有,如果这个Ades是一个第三方提供的硬核(hard-core),那么我们也只能使用这种方法。

        使用这种方法的缺陷也是显而易见的:由于顶层模块在编译的时候Ades设置了dont_touch,这就妨碍了DC针对Ades的各个实例周围环境的不同的进一步优化,从而使得结果不能真实的反映各个实例周围的环境变化。

        uniquify由于把各个多例化模块作为独立的模块来看,因此DC可以分别针对它们作出更好的优化,从而得到的结果也是比较理想的。缺点就是编译的时间稍微较长,但是对于一些不大的模块来说,这些是可以忽略的。        

        正因为uniquify可以综合出更好的结果,所以如果一般推荐使用uniquify解决多例化模块的综合问题

你可能感兴趣的:(逻辑综合,数字IC,DC,综合)