ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

数字后端Floorplan实战:从数据流分析到Macro摆放优化

数字后端Floorplan实战:从数据流分析到Macro摆放优化 一谈到数字后端的Floorplan很多刚开始接触项目的朋友第一反应就是“摆Macro嘛把Memory和IP放整齐就行”等到真的上手跑完一圈布局布线才发现问题全堆在Floorplan阶段埋下的坑里——绕线拥塞爆炸、时序收敛困难、IR Drop超标最后只能靠一遍又一遍手动挪Macro来救火。我在几个项目的Floorplan阶段摸爬滚打之后最大的体会是Floorplan的核心不是“摆得好看”而是“摆得省线”。这句话听起来简单做起来却需要从Data Flow出发把数据流的走向映射成物理空间的走线需求再结合绕线资源的预估才能在项目初期就把风险和问题解决掉而不是等到Route阶段再后悔。这篇文章我会结合自己在数字后端项目里的实际操作经历从Data Flow分析、Macro摆放策略、走线资源预估到优化技巧把整个Floorplan流程里我觉得最关键、也最容易被忽略的细节拆开讲清楚。适合正在做后端集成、或者准备数字后端面试的朋友参考内容偏实战有不少是我自己踩过的坑和试出来的经验。1. 内容整体设计与思路拆解1.1 为什么Floorplan不能上来就摆Macro很多Floorplan新人拿到design之后第一反应是打开Innovus或者直接看综合后的netlist然后对着IP清单开始摆放。这个流程其实有很大的问题因为你根本不知道数据从哪里来、到哪里去也不知道模块之间的交互到底有多密集纯靠空间直觉去摆Macro本质上是在赌运气。我自己的习惯是Floorplan的第一步永远是先把Datapath理清楚。拿到RTL之后先花时间看架构文档把关键的数据通路画出来——比如视频处理芯片里数据从DDR进来之后会经过解码模块、图像处理模块、编码模块最后再写回DDR。整个过程就是一个单向的数据流中间可能还有几级buffer和SRAM作为暂存。把这个数据流的顺序理清楚之后你再去看Macro摆放思路就会完全不一样。举个实际例子我之前做过一个ISP相关的项目顶层有好几个大Memory如果单纯按面积均匀分布确实看起来非常整齐。但绕线的时候发现Memory到处理模块之间的走线全部穿过整个芯片congestion直接爆表。后来重新分析了Data Flow把Memory按照数据读写的顺序摆放走线长度大幅缩短congestion问题自然就解决了。这说明一个道理物理位置必须跟随逻辑流向而不是跟随美观。1.2 把逻辑数据流翻译成物理空间关系所谓“数据流翻译成物理空间关系”本质上是一个映射过程。逻辑上模块A的输出必须经过模块B的输入物理上这两个模块就不应该离得太远。而且不只是模块本身和它们相关的所有Macro、IO、Pin都应该朝着同一个方向布局。具体来说我通常会把数据流拆成几个关键要素源端口、目的端口、中间存储节点和控制信号路径。源端口和目的端口决定了大方向中间存储节点通常就是SRAM和Register File决定了Macro的位置控制信号路径一般走线不长但是数量众多摆放时也要留出足够的通道。在Floorplan阶段我常用的方法是在Innovus里先创建一张Floorplan Sketch把各个模块的边界大致画出来然后把Data Flow用连线的方式标注在图上。这个阶段不需要精确到具体的track数量重点是看数据流的方向关系。如果某些模块之间的交互方向和Floorplan的物理方向矛盾就要提前调整模块的相对位置而不是等到绕线时才发现。2. 核心细节解析与实操要点2.1 Macro摆放不能只看面积还要看走线需求Macro摆放中最常见的一个误区是只关注面积利用率认为只要面积放得下就算成功。面积确实要关注但走线资源的预留同样关键。一个Macro如果周边有大量的Pin需要连接那么它的周围就要留出足够的布线通道否则即使面积上没有溢出绕线资源也会严重不足。我实际操作中的做法是在摆放Macro之前先把所有Macro的Pin数量统计出来重点关注pin count高、连接模块多的Macro这些往往是走线资源消耗的大头。比如一个DMA模块旁边的SRAM如果它既要连接上游的数据总线又要连接下游的寄存器配置总线那么它的两侧都需要预留充裕的走线空间否则pin access就会变成瓶颈。另一个很容易被忽略的点是Macro的Pin方向。很多SRAM的Pin是分布在左右两侧的如果你把两个SRAM面对面贴得很近中间的走线通道就会非常窄反而浪费了整体的布线资源。所以摆放Macro的时候我会刻意让Pin密集的一侧朝向有足够空间的方向或者让两个Macro之间间隔足够的距离这就是所谓“用面积换走线资源”的权衡。2.2 Data Flow分析法在Floorplan中的具体操作Data Flow分析在Floorplan中的具体操作我会分成三个步骤提取数据流图、标记关键路径、映射物理区域。提取数据流图这一步简单来说就是把RTL里的模块连接关系梳理出来。没有现成工具的时候我一般用Verilog的例化关系手动梳理也可以用综合工具生成层次化原理图辅助分析。关键是要把数据从一个模块到另一个模块的路径找全包括直连路径、经过中间模块的路径和经过寄存器暂存的路径。标记关键路径这一步是从提取出的数据流图中找出对时序影响最大、走线最密集的路径。比如跨模块的FIFO读写路径、多次迭代累加的运算路径这些路径上的Macro要尽量靠近路径上的寄存器要尽量同步摆放在数据流方向上避免信号来回穿越。映射物理区域这一步就是真正把数据流图翻译成Floorplan的物理布局。我会先画一个大致的floorplan草图把输入端放在一侧输出端放在另一侧中间按照数据流的方向依次排布各功能模块和Macro。如果设计有多个独立的数据流就用物理上的隔离或者guard ring来划分区域避免不同数据流之间的信号相互串扰或者走线交叉。2.3 面积与Utilization的平衡技巧面积利用率Utilization是Floorplan阶段另一个必须关注的指标但它不是越高越好。很多人以为利用率做到80%以上才算“优秀”但在实际项目中过高的利用率会让后端工具在布局和绕线时的余量非常小一旦出现局部密度不均congestion就会快速恶化。我的经验是对于包含大量Macro的设计Floorplan阶段的target utilization通常控制在65%~75%之间比较合理。如果设计中有很多标准单元比如CPU子系统那么利用率可以稍微高一些如果设计中含有很多大块SRAM和模拟IP利用率就要适当放低因为Macro本身会阻挡走线层导致可行的绕线资源变少。需要提醒的是utilization的计算方式在工具里默认是标准单元面积加Macro面积除以模块总面积但走线资源往往和Macro的实际阻挡有关。所以我在摆放完Macro之后会额外用工具查看一下每个区域的局部密度预估而不是只看整体utilization这一个数字。3. 实操过程与核心环节实现3.1 Innovus中创建Floorplan的准备工作在Innovus里做Floorplan第一步是load design。通常我们会从综合后的netlist开始读入之后需要对design做一个基本的检查包括确认是否有missing cell、是否有未连接的pin因为这些问题会直接影响后面的摆放。读入design之后我会先设置floorplan的基本参数包括chip size、die area、IO位置和core utilization。这里的chip size可以直接根据芯片的target size输入也可以通过工具自动估算。自动估算时Innovus会按照你设定的utilization反向计算出一个core面积我一般会在此基础上再额外增加5%~10%的余量作为后续优化的buffer。设置好floorplan基本参数后还需要创建power stripe的规划。很多新手会忽略这一步觉得电源网络放到后面再做也来得及。但实际上电源地网络的走向和宽度对走线资源的影响非常大如果M4层被power stripe占满那么水平方向的信号走线就只能在M5层完成对于高密度设计来说这会造成严重的绕线资源不足。3.2 Macro自动摆放与手动调整的配合Innovus里提供了多个自动摆放Macro的指令比如place_macro和相关选项可以在指定区域内按照data flow或者timing自动摆放Macro。自动摆放的优点是可以快速得到一个相对合理的初始解特别适合Macro数量多、手动摆放工作量大的场景。不过自动摆放的结果通常不能直接用还需要结合模块信息和数据流手动调整。我的工作流是先用自动摆放得到一个初始floorplan然后打开GUI按层次化结构把模块的instance和Macro高亮出来对照自己分析的数据流图逐个调整Macro位置。手动调整的时候有几个小技巧比较实用一是利用Align功能把同类的Macro对齐这样摆放更整齐也有利于后续的绕线二是利用Spacing功能控制Macro之间的间距避免pin access区域过小三是根据FlyLines也就是模块之间的连接线的方向来微调Macro的位置FlyLines密集的区域说明走线需求高需要确保有足够的空间。3.3 用FlyLines和前期布线验证走线资源FlyLines是Floorplan阶段评估走线资源非常好用的一个工具。当你在Innovus里显示FlyLines时工具会根据当前floorplan和netlist的连接关系画出所有net的两个连接点之间的直线。如果FlyLines密集地穿过某个区域就说明这个区域的走线需求量非常大。我通常在Macro摆放初步完成后会打开FlyLines全局观察一遍重点看有没有出现大面积交叉或汇聚的区域。出现汇聚说明模块划分或者Macro摆放的方向有问题需要把数据流相关的模块整体移动一下而不是单独挪某一个Macro。走线资源的验证不能只靠FlyLines的视觉判断还需要做实际的前期布线也就是global routing。在Innovus里可以先执行一次global route通过congestion report来查看各个区域的overflow情况。如果某些区域overflow很高就针对性地调整Floorplan之后再重新跑global route验证反复几次直到congestion满足要求。4. 常见问题与排查技巧实录4.1 Congestion过高时的排查思路Congestion过高是Floorplan阶段最常见的问题也是最能考验后端工程师功力的一点。我自己排查congestion时有一套固定的流程先用global routing的结果找到congestion hotspot然后打开那个区域的FlyLines再看对应的netlist。找到了congestion hotspot之后如果是数据流汇聚导致的就调整Macro位置让数据流分散开如果是power stripe挡住了绕线层就调整stripe的走线层或者宽度如果是pin access问题就通过调整Macro方向和间距来改善。另外一个容易被忽略但影响非常大的因素是Hierarchy boundary。有时候两个子模块之间本来连接很密集但是因为Floorplan时把模块拆得很碎导致连接需要跨越多层边界走线长度和层次都增加反而造成不必要的congestion。这种情况下把关系紧密的模块合并到一个区域或者调整hierarchy的划分是更彻底的解决方案。4.2 时序与绕线资源冲突时的取舍策略在Floorplan阶段时序和绕线资源经常是一对矛盾。为了让关键路径的时序收敛有时需要把相关的寄存器靠得很近但这可能会导致局部区域的走线密度过高引发congestion。反过来为了疏散绕线资源把模块拉开距离又会影响时序。我的取舍经验是在Floorplan阶段优先保证关键路径的走线方向和数据流一致适当容忍某些局部区域的congestion偏高但前提是这些区域的overflow可以后续通过tool优化或者小范围调整解决。如果congestion严重到超过10%的overflow就必须回到物理层面重新规划布局而不是冒险往下走。还需要注意的是不同时钟域之间的路径往往容易被忽略。跨时钟域的同步逻辑通常走线较长如果这些同步器的Macro放在距离太远的位置哪怕时序上可以通过同步器容忍也会消耗不必要的走线资源。所以跨时钟域的逻辑最好也放在数据流路径上的中间位置。4.3 项目实战中的避坑指南前面说了很多理论层面和经验层面的方法最后我再整理几个自己项目里踩过的坑给后面的朋友做个提醒。第一个坑是只看核心利用率不看局部利用率。整体utilization 70%看起来不高但某个区域因为Macro密集堆在一起局部utilization可能超过90%congestion非常严重。所以我建议摆放完Macro之后一定要看density map用颜色区分局部密度直观发现“隐形”的高密度区。第二个坑是忽略Blockage的影响。Floorplan里有些区域被IP或者布局约束圈住了这些Blockage会进一步减少实际可用的走线资源。评估floorplan质量时要把Blockage扣除之后的有效区域算进去而不是只看总面积。第三个坑是IO Pin的分配和Floorplan摆放不一致。IO的位置是封装和系统架构定的但如果你在Floorplan时把IO相关内容摆放在离对应IO很远的位置就会造成大量长距离走线既费资源又伤时序。所以IO规划和Macro规划要同步做让相关逻辑靠近相关IO的方向。第四个坑是前期不考虑Power需求。Power stripe的宽度和间距影响IR drop很多项目在Floorplan阶段忽视power planning到了中后期发现IR drop超标再来加宽加粗电源网络这时候往往需要挪动Macro才能腾出空间代价非常大。所以Floorplan阶段务必同步规划power网络。5. 我的Floorplan优化心得与一套可复用的自查清单最后再分享一些我在实际项目里总结的个人经验和一套自查清单。整理这个清单的初衷是因为Floorplan阶段涉及的因素太多靠脑子硬记容易漏项目用清单可以确保每一步都检查到位。我个人的习惯是每当完成一版Floorplan就会按照这个清单逐条核对宏观区域划分是否和数据流一致Macro摆放是否考虑pin accessFlyLines是否有明显的交叉汇聚局部utilization是否出现超过85%的区域power stripe和信号走线层是否冲突IO分配是否和Floorplan一致热点区域是否预留了足够的绕线空间设计规则约束是否完整比如blockage、region和guard ring是否完全清除了dangling net和unconnected pinfloorplan结果是否和RTL层面的模块划分对应。这十条里面我自己踩过坑最多的是第二条和第六条。第二条是pin access很多时候Macro摆得很整齐但绕线时发现pin的方向不对绕线工具需要绕很大一圈才能连上白白增加了很多走线。第六条是IO分配我在一个chip-level项目里因为IO方向调整而返工过一次从此之后每次Floorplan前都会把IO plan提前和系统架构团队对齐再做Floorplan。其实整个Floorplan的精髓可以用一句话总结先跟着数据流走再考虑绕线资源最后才轮到美观。你只要把数据流读懂了Macro的位置就自然出来了绕线资源的预估也有依据了整个芯片的物理实现就有了一个扎实的地基。反过来如果本末倒置一开始就盯着Macro摆得整不整齐后面大概率要花更多时间在绕线阶段“补窟窿”。希望这篇博客对正在做数字后端Floorplan的朋友有一些帮助。如果你们在实际项目中遇到过更有意思的Macro摆放问题或者有其他优化走线资源的好方法欢迎一起交流。
返回列表