Amiya · 5月15日

Multi-bit的实现方法和应用 (下)

书接上回,Multi-bit的实现方法和应用 (上),闲言少叙,ICer GO!

image.png

In-place MBFF实现

相较于仅基于逻辑连接的MBFF封装,如果考虑到布局的实际情况,那么就有physical aware的in-place的MBFF封装实现,这种思路可以应用在常见的DCT/DCG/genus\_PLE 等综合流程。
和in-compilre相比,这种in-place的MBFF封装,最大的优势,就是physical aware。譬如如下示意图:

image.png

可见,工具将距离较近的SBFF封装成了MBFF,简单而言,工具的在封装MBFF时候会更为谨慎(严苛),相应的MBFF的封装比率也自然会下降。

这里以DCT为例,它提供了一种in-place的MBFF实现方式:一种基于综合结果的MBFF封装方法。具体实现方法如下

set_multibit_options -mode none
compile_ultra -gate_clock -scan -spg
identify_register_banks
source MBFF_SCR
compile_ultra -gate_clock -scan -incremental -spg

和In-compile相比,这里需要注意两个地方

  • 在compile命令中,跳过MBFF封装步骤
  • 使用spg模式运行compile命令
  • 基于综合结果使用命令identify\_register\_banks,完成MBFF的in-place体交换。效果见下图:
    image.png
    PS:封装后的MBFF的坐标,是在原始SBFF的中间位置
  • MBFF优化后,需要使用compile -incremental进行进一步增量优化,来平抑MBFF带来的QoR影响

这种in-place的MBFF替换有下列好处

  • 基于实际物理布局的情形进行MBFF有效替换:
  1. 相较常规的MBFF有了物理布局影响的考量,可以有针对性地进行MBFF封装,这个对于最终的物理实现有很好的帮助
  2. 传统的in-compilre的MBFF封装,先做封装,再做优化,这样很有可能导致优化受限
  • 可选择的基于WNS的封装方式,可以有效控制MBFF封装对WNS的影响

综上可以看出,如果是使用了in-place方式进行MBFF优化,那么这个布局的结果,一定是要传递给后端版图工具,所以需要SYN和APR联动起来,S家的流程如下:

# SYN flow:
dc_shell> set hdlin_infer_multibit never\|default_none
dc_shell> compile_ultra -gate_clock -scan -spg
dc_shell> identify_register_banks  
dc_shell> compile_ultra -gate_clock -scan -incremental -spg
dc_shell> write_file -format ddc -hierarchy top.ddc

#APR flow:
icc_shell> create_mw_lib ...
icc_shell> read_ddc
icc_shell> ......
icc_shell> place_opt_design -spg ......

可以看到。S家是通过SPG flow将此信息紧密联动的,所以说,如果用户使用了in-place的MBFF的流程,那么需要使用SPG流程完成这个信息的有效传递。相较传统的in-compile的MBFF流程,MBFF的对APR实现的挑战会变小。

APR阶段的MBFF封装


从上述的描述可以看到,综合里边可以有效地处理MBFF的封装实现。对应的,基于MBFF的封装原理,除过上述SPG的MBFF流程外,APR阶段也可以自己对MBFF进行封装,以实现PPA的优化。

市面上常见的APR工具是S家ICC/ICC2和C家的innovus,这两个工具都可以对MBFF进行封装,原理是类似的,具体描述见下:

  • ICC flow

基于对place 步骤的拆解,这里可以分为三个方法

  1. Flow1:SPG flow,参见上述综合的In-place MBFF封装方法
  2. Flow2:coarse placement MBFF flow
icc_shell> create_mw_lib ...
icc_shell> read_verilog
icc_shell> ......
icc_shell> set_banking_guidance_strategy \
            -input_map_file MBFF_map.file \
            -register_group_file MBFF_reg_grp.rpt \
            -output_file MBFF_assembly.tcl
icc_shell> create_placement ...... 
icc_shell> source ./MBFF_assembly.tcl
icc_shell> place_opt_design -skip_initial_placement ......

先配置MBFF的应用策略,再创建粗布局(coarse placement),工具这个时候会根据粗布局的结果,构建MBFF封装方式,这个和in-place的MBFF封装流程类似,然后用户将导出的文件MBFF\_assembly.tcl读入,完成MBFF的封装动作。最后使用place_opt_desing进行增量式优化,完成MBFF的封装实现。上述的两个输入文件:MBFF_map.fileMBFF_reg_grp.rpt都是在DC工具通过命令write_multibit_guidance_files来导出,以便指导ICC的MBFF封装方式。

  1. Flow3:place\_opt MBFF flow
icc_shell> place_opt 
icc_shell> set_banking_guidance_strategy \
            -input_map_file MBFF_map.file \
            -output_file MBFF_assembly.tcl
icc_shell> create_banking_guidance
icc_shell> source MBFF_assembly.tcl
icc_shell> psynopt

基于SBFF的网表,完成正常的place\_opt,然后基于物理布局结果,进行MBFF的封装实现,最后再做一次增量优化,即可完成MBFF的优化实现过程。如下图示例:

image.png

  • INVS flow

相较于S家的多个流程的选择,C家的流程比较简单,这个也符合两家一贯的风格,S家细致贴心,C家直接高效。

C家除过对MBFF的封装(merge)以外,也会支持对MBFF打散(split),这些只需要在place阶段进行直接配置就好

invs_shell> setOptMode \
            -multiBitFlopOpt {true| false | mergeOnly | splitOnly} \
            -multiBitFlopOptIgnoreSDC {true | false}

其中:

multiBitFlopOpt==true:        timing_driven 下的MBFF封装和打散
multiBitFlopOpt==false:    禁止MBFF操作,数据库里边已有的MBFF不受影响
multiBitFlopOpt==mergeOnly:    timing_driven 下做MBFF的封装操作
multiBitFlopOpt==splitOnly:    timing_driven 下做MBFF的打散操作

任何阶段设置了setOptMode配置,任何阶段使用place_opt_design | optDesign等命令,都会根据这个设定进行相应的优化,这个选项也会被完整地保存在invs的数据库中。

在invs的任何优化后的数据库中,可以使用命令reportMultiBitFFs -statistics 对MBFF的替换结果进行统计报告:

image.png

这个评价系统和DC有一些相似之处,但是对于MBFF替换比率的表达,这里采用了Bit Per Flop:平均计算下,单个FF可以承担的FF bit数量。这个值越高,说明MBFF的替换比率就越高,反之亦然。

Invs还提供了一个pin map的报告文件,(PS:这个需要在invs的session里边导出),命令是:dumpMultiBitFlopMappingFile。这个可以生成

  • MBFF的封装(merge)和打散(splie)的动作细节;
  • 原先的SBFF(D/Q)和MBFF(D*/Q*)的pin mapping的对应关系

MBFF的命名

基于上述MBFF的实现方法和流程,MBFF的产生通常分为四种

  • DC的in-compile 封装MBFF
  • DC的in-place封装MBFF
  • ICC的in-place封装MBFF
  • Invs的in-place封装MBFF
  1. 手册给出的示范如下

image.png

但是经过测试,得到的是类似下列的封装方式:

image.png

这种命名方式可能会对formal的mapping有一定挑战,需要注意一下

  1. 第二种和第三种都是in-place的方式,也是使用工具导出的命令进行MBFF的封装,这样如果命名不是很友好,用户可以通过调整脚本进行命名维护,对用户后期的工作较为友好

image.png

这个默认模式就是简单将FF的名字使用”\_”进行连接。

  1. 第四种是invs是在in-place步骤进行封装的,用户对命名不能干预,

image.png

Invs的方法比较友好,前边使用了CDN\_MBIT作为MBFF的引示,中间每一个SBFF都用MB进行引示,这个命名规则比较好理解,formal也比较容易区分。常言道,简洁即简单,看来invs不让用户干预命名,还是对自己的处理很有自信的。

流程梳理和推荐


基于上述陈述,对于MBFF的优化方式已经有了比较全面的理解,这里提供一些具体的数据供各位参考:

  1. DCT采用in-place的MBFF封装流程:

image.png

  1. invs基于netlist,进行的MBFF封装流程

image.png

  1. invs基于DCT in-place的netlist,进行的MBFF封装流程

image.png

结合上述结果,和各个流程的特点,这里有一些建议和推荐

  • MBFF可以在三个步骤进行封装实现:RTL,SYN,APR
  • 综合阶段通常只作封装,不做打散,
  • APR阶段需要基于时序进行封装和打散,timing driven依赖
  • MBFF的封装对SBFF的布局有严重依赖:这点符合timing driven的目的

基于此,这里推荐两个flow供大家选择

  • SYN-APR MBFF flow
  • SYN 打开MBFF优化流程
  • APR需要加载SYN吐出的initial placement DEF或者ddc。
  • APR 使用skip\_initial\_placement 的place\_opt命令,完成对MBFF的APR实现
  • APR MBFF flow
  • 基于SBFF的综合数据,在APR的place\_opt阶段开始实现MBFF
  • 时序驱动模式下,工具可以自动实现后续步骤的MBFF的封装和打散操作

【敲黑板划重点】


MBFF的流程贯穿在整个设计实现,最终的服务对象还是APR和时序分析。通过理解其流程,可以做出适用于自身设计的方案选择,有效利用其优势,让MBFF助力设计实现,

参考资料


Synopsys _Design Compiler® User Guide_
Synopsys _Multibit Register Synthesis and Physical Implementation Application Note_
艾思考后端实现 _芯片设计里的Multi-Bit FF探究_
艾思考后端实现 _Multi-bit的实现方法和应用 (上)_

作者:艾思后端设计
文章来源:艾思后端实现

推荐阅读

更多IC设计干货请关注IC设计专栏。欢迎添加极术小姐姐微信(id:aijishu20)加入技术交流群,请备注研究方向。
推荐阅读
关注数
13198
内容数
1241
主要交流IC以及SoC设计流程相关的技术和知识
目录
极术微信服务号
关注极术微信号
实时接收点赞提醒和评论通知
安谋科技学堂公众号
关注安谋科技学堂
实时获取安谋科技及 Arm 教学资源
安谋科技招聘公众号
关注安谋科技招聘
实时获取安谋科技中国职位信息