公司注册网站系统,信息安全公司前10名,网站开发需要20万,代理做网站的合同在前面一章介绍完施加约束之后#xff0c;接下来要做的工作就是将设计进行综合编译(compile)#xff0c;本文我们将主要讨论综合编译的过程。主要分为这样几个部分#xff1a;
优化的三个阶段及其特点编译的策略编译层次化的设计
一、优化的三个阶段 这一节我们介绍Design … 在前面一章介绍完施加约束之后接下来要做的工作就是将设计进行综合编译(compile)本文我们将主要讨论综合编译的过程。主要分为这样几个部分
优化的三个阶段及其特点编译的策略编译层次化的设计
一、优化的三个阶段 这一节我们介绍Design Compiler进行优化的三个阶段结构级、逻辑级以及门级在不同的阶段DC运用的方法和优化余地是不一样的我们将对这几个阶段的特点和优化方法进行一个介绍这里一起归纳一下希望能加深认识。 上图是这三个阶段的关系图可以看到结构级属于最高的抽象层次当读入Verilog代码或者没有经过映射的db文件后DC的优化从这个阶段层次开始可以说结构级是优化的最高层次所以对DC来说这个层次的综合可以称为高层次综合(High-Level Synthesis)。结构层的下一个优化阶段是逻辑级阶段也是读入映射过的db文件的DC的初始优化阶段。再往下一个阶段是门级阶段也是优化的最后阶段这里所要作的工作主要就是GTECH到工艺库的映射。
1、结构级优化 因为结构级是优化过程中层次最高的一级因此它也是DC可以采用的优化方法最多的一级它的主要优化方法如下图所示 1DesignWare选择 DW选择是结构级优化的一个很主要的特点在这个阶段DC能够根据设计者施加的时序或者面积的约束在DW的不同实现方式中找到它认为最佳的实现方案。比如加法器的实现方式一共有如下几种 其中DW Foundation需要有专门的license而且使用之前还要设置综合库(synthetic library)。
2共享子表达式(Sub-Expressions) 这里的子表达式主要是指数学表达式比如下面这个例子如果按照原来的语句综合会包含6各加法器但是如果表达式之间的公共项提取出来便可以大大的减小面积如下图 如果要直接综合出共享后的电路可以在编写RTL代码的时候强制指定共享项 3资源共享(Resource Sharing) 资源共享的原理与共享子表达式类似只不过这里指的所谓资源是一些HDL的运算符和表达式比如加()、减(-)、乘(*)、除(/)以及大于()、大于等于()、小于()、小于等于()。比如给定一个语句 DC会根据具体的约束条件综合出最符合要求的结构来。
4运算符排序(Operator Reordering) 对于下面这个表达式Z A B C D(输出Z是施加了一定时序约束)DC最初是按照从左至右的顺序计算的也就是说它最初的排序如下 如果几个输入信号到达的时间相同DC会通过运算符排序优化成下图的平衡的结构减小延时: 如果A信号较迟到达则综合出的电路结构会如下 : 2、逻辑级优化 在经过结构级优化之后电路被转化成了工艺无关的GTECH库的形式这级也称为逻辑级对于逻辑级优化来说只有一个方法那就是——结构化 (structure)或者扁平化(flatten)。 1结构化(structure) 结构化是DC在逻辑级的默认的优化方法它是指使用电路的一些中间项构成一个多级的电路结构。如下图的电路一共有三级逻辑下一级的输入是上一级的输出使用这种优化方法一般情况下能综合出兼顾时序和面积的电路来。 结构化电路的典型是奇偶校验电路。
2扁平化(flatten) 扁平化是将所有的组合逻辑打平成乘积项和(SOP)的两级结构类似与可编程阵列逻辑(PAL)。使用这种结构的特点由于没有利用中间项综合后电路面积将会变得很大但是却不一定能取得较好的时序。 扁平化结构的电路和设置扁平化的DC命令如下所示 dc_shell set_flatten true -effort low | medium | high 综合结构化和扁平化的特点可以归纳如下: 由于DC默认是用结构化的方式综合逻辑级电路而且这种方式可以得到兼顾时序和面积的结果因此我们可以先用这种结构化方式优化。在优化后的电路中找出关键路径看看关键路径上有没有符合使用SOP电路的模块再将这些方便使用SOP的模块set_flatten以便取得最佳的效果。
3、门级优化 门级优化是优化的最后阶段它所要完成的任务就是将GTECH的电路映射到最终的工艺库中并且保证映射后的电路不违反设计规则(Design Rule)。 1工艺映射 工艺映射包括组合逻辑映射和时序逻辑映射。组合逻辑映射是指DC使用工艺库中的各种门替换GTECH单元并选择能实现相同逻辑的符合时序及面积要求的单元。 时序逻辑映射的方法和组合逻辑相类似也是出于速度和面积的考虑尽量使用复杂的时序单元吸收一部分组合逻辑。 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经过一段时间的等待后有可能时间会很长优化过程暂停并弹出如下菜单 这里有四个选项设计者可以根据情况作出选择。 DC在编译的过程中会自动打印出一个报表报告编译的总时间设计的面积关键路径的时序违反和总共时序违反情况我们可以根据需要更改打印的列项目 2、分析报告调整策略 一般情况下我们先作一个默认的编译这样一般可以取得既快又准确的结果然后在编译完成后使用一些报告时序的命令并分析它们的输出结果使用的命令主要有 从这些报告中我们可以看到电路中是否有违反的约束如果有那么它是什么类型还有电路中的最大负裕量(worst negative slack)是多少等等。下面我们就几个常见的约束违反情况谈谈纠正它的综合策略
1较大的时序违例 以下图为例 从report_constraint –all这个命令的报告可以看出需要到达的时间是1.20ns而实际到达为2.84ns违反了1.64ns。之所以判断它是一个较大时序违反的情况并不是因为1.64这个绝对值很大而是相比较需要时间而言1.64是一个较大的值。一般而言如果电路中的最大负裕量(简称WNS)所占时钟周期的15以上的话可以认为电路存在较大的时序违反。 确认存在较大时序违反之后下一步就是找出原因消除违反情况。可供参考的步骤有下面几种
检查约束条件看是否有疏漏或错误检查模块划分看组合逻辑是否穿过多个模块重新编译优化后的网表修改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较小的时序违例 以下图为例 从上图看出相比较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] 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的负载。 3、修正保持时间违例 一个时序电路要想正常工作除了必须满足建立时间要求之外也需要满足保持时间要求。虽然保持时间检查和建立时间检查是同样重要的但是我们在实际综合的过程中却不是把它们同时考虑而是更多的把保持时间的检查放到布局后。这是因为
时钟偏移必须要到布局完成后才能得到准确值修正保持时间的通常做法是插入buffer而这可能会增加建立时间违反的可能性并且增大了组合电路的面积保持时间检查用的一般都是电路工作的最佳条件而在这个条件下连线延时往往是被忽略的连线延时也是必须在布局后才准确。如果确定要同时作建立和保持时间检查那么在施加电路约束的时候要加入相应的开关如 以及设置各自的工艺库—— 默认情况下DC不修正保持时间的违反。如果确定要作修正需要先设置一个变量再作检查 dc_shell set_fix_hold [all clocks] dc_shell compile -only_design_rule 加上only_design_rule的开关后编译过程中仅仅更换单元大小并增加buffer以便修正设计规则违反和保持时间违反。
三、层次化设计的编译 一个层次化设计的编译过程包含两个阶段1、将所有的子模块映射到门级2、优化。 在一个层次化的设计中我们可能会遇到下面这种情况 上图中被综合的模块中D_design中含有三个子模块U1、U2和U3其中U1和U3都是由模块Ades例化而来这里的Ades称为多次例化的模块。对于这样一个设计在compile之前使用check_design作检查的时候会报一个warning即设计中存在多次例化的模块(multiple instantiations)如果在这种情况下我们不考虑多次例化的模块(Ades)那么在继续的compile时候程序会终止退出。因此必须对它进行处理这里我们介绍两种方法——uniquify和compile dont_touch。
1、uniquify 使用uniquifyDC会对每个例化的模块作一份拷贝然后对它们分别取一个名字即把不同的例化模块当作不同的两个模块处理。 注意看上图U1和U3两个模块的设计名分别由原来的Ades变成了Ades_0和Ades_1因此在编译时DC会将它们当作两个不同的模块这样就可以根据它们不同的周围环境作优化。 使用uniquify的具体实现方法如下 dc_shell uniquify dc_shell compile 2、compile dont_touch 这种方法先将多次例化的模块作单独的约束和编译然后在整合到上一级模块的过程中将它的属性设置为dont_touch再编译。 上图中U1和U3两个模块的设计名都没有变化只是在编译D_design之前先将Ades编译一次。这样U1和U3实际上是一模一样的模块。 compiledont_touch的实现方法如下 这里的约束文件有两个一个是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 通过对上述两种方法的介绍我们不难看出它们各自的优缺点—— compiledont_touch由于只需要对多次例化的模块编译一次因此可以减少整个设计的编译时间也可以减少内存的使用量。在多次例化的模块很复杂并且工作站的硬件条件有限的情况下使用这种方法的优越性的比较明显的。还有如果这个Ades是一个第三方提供的硬核(hard-core)那么我们也只能使用这种方法。 使用这种方法的缺陷也是显而易见的由于顶层模块在编译的时候Ades设置了dont_touch这就妨碍了DC针对Ades的各个实例周围环境的不同的进一步优化从而使得结果不能真实的反映各个实例周围的环境变化。 uniquify由于把各个多例化模块作为独立的模块来看因此DC可以分别针对它们作出更好的优化从而得到的结果也是比较理想的。缺点就是编译的时间稍微较长但是对于一些不大的模块来说这些是可以忽略的。 正因为uniquify可以综合出更好的结果所以如果一般推荐使用uniquify解决多例化模块的综合问题。
