如何做physicalawaresynthesis及需要注意的点

这期内容当中小编将会给大家带来有关如何做physical aware synthesis及需要注意的点，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。

创新互联公司服务项目包括凭祥网站建设、凭祥网站制作、凭祥网页制作以及凭祥网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，凭祥网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到凭祥省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！

方法学上，感谢DEF 架起了前后端之间的桥梁，DEF 将 floorplan 的信息传递给综合工具，使其可以在逻辑优化时考虑真实的『物理信息』，并根据DEF 的约束做placement 及global route , 依据global route的结果估算net delay，与此同时也做congestion 优化，完成所谓的 physical aware synthesis。

工具端，C跟S都跳脱不出方法学，只是实现方式上有所差别而已，S家的physical synthesis 除了要设physical 相关的变量之外，大概还需要额外三个东西（此处完全凭不靠谱的记忆，如有谬误请指正）：1) dc_shell -topo; 2) create MilkWay DB; 3) compile_ultra -spg。本文将以C 家的Genus 为例来陈诉如何做physical aware synthesis。讲工具的套路都是从输入跟输出说起，然后再一一展开，下图是从Genus physical RAK上抠的图（RAK是一系列简单的lib，C家每个工具都有多个RAK, 在C家网站上可以下载到，强烈建议下载学习）。

Genus physical 的输入除了 lib/rtl/sdc 之外，还必须要有tech lef/ std cell lef/ macro cell lef; DEF; QRC tech file。

LEF:tech lef/std cell lef/ RAM lef 由foundry 提供，sub-block lef 由后端提供。

• 用命令：set_attribute lef_library $lef_files 读入，必须将tech lef 放在lef file list的首位；必须要读全用到的所有cell 的lef，否则在log 中会看到警告：『由于某个cell 的物理信息不可用，所以该cell 被设成了不可用。』

• Genus 从LEF 中读入如下信息：

• CAPACITANCE CPERSQ

• EDGECAPACITANCE

• RESISTANCE RPERSQ

• SITE

• WIDTH 

• Coupling capacitance

• Capacitanceper unit of area

• Fringing capacitance

QRC: QRC由foundry 提供，是个加密文件。

• 用命令：set_attribute qrc_table_file $qrc_files 读入.

• Genus 从QRC 中读入如下信息：

• PROCESS_VARIATION

• BASIC_CAP_TABLE

• width

• Cc

• Carea

• Cfrg

DEF:floorplan 信息，由后端提供，后端大佬们说这是P&R 的灵魂所在，是基石是一切成功的基础。

• 在Innovus 用Defout -floorplan -NoStdCell写出一个包含以下部分的DEF，此处有注释。

• 在Genus 中用命令read_def 读入DEF file. Genus在读DEF 时会check DEF 的Quality 并会报出相关的warning, 读完DEF 后会生成一个如下的summary 报告，请修正需要修正的Error 跟Warning。

• 读完DEF 后用命令 check_floorplan 进一步check DEF 的quality, 并及时修正Error 跟 Warning。

在输入干净了之后就可以命令工具开始做带物理信息的逻辑优化了，Genus 采用的是early physical，即从最开始就带着physical 信息做优化。Genus physical整个优化过程由syn_gen -physical, syn_map -physical, syn_opt -physical/ spatial 三步构成。建议在做完每一步优化后就写一个db 出来，在debug 的时候可以根据需求读入不同阶段的db, 比如debug 前后端module placement 的 correlation, 可以读入syn_gen 后的DB 起GUI highlight module place 跟Innovus 的module place 对比。

Genus physical 有两种flow, 两个flow 的区别是：

• syn_opt 所用option 不同，一种是：syn_opt -physical. 另一种是：syn_opt -saptial。

• syn_opt -physical 会调用Innovus 来做placement 跟global route，结果是legalize 的，后端如果吃入Genus 写出的netlist + DEF 则只需要run place_opt_design -incr 即可。

• syn_opt -spatial 用Genus 内嵌的placement 引擎做placement 跟 global route，结果不是legalize 的，后端需要run full place_opt_design.

• 两个flow 的相关变量有差别，用户可以根据自己的设计、工艺跟团队构成选择相应flow。

综合完成后，需要check 综合的quality，对于physical aware synthesis 除了PPA 还需要关注 overflow，此处说两点：

• 用report_timing -physical -gui 可以在layout 中highlight 出完整的timing path，是debug timing最基本的一招而且十分有效，可以看数据流、看走线，看bufferring. 

• report congestion可以report 出overflow，打开congestion map 去看congestion 是由什么引起的，然后对症下药。如：跟macro 相关的congestion 需去找后端确认floorplan 是否需要调整；跟结构相关的congestion 是否在综合时需要对这些结构设置map_to_mux, 以使其保持mux 结构而非替换成大量的OAI/ AOI; 如是cell堆积引起的congestion，找AE 确认是否有变量让工具可以将congestion 严重区域的cell 推散。

上述就是小编为大家分享的如何做physical aware synthesis及需要注意的点了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注创新互联行业资讯频道。