一谈到数字后端的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 access；FlyLines是否有明显的交叉汇聚；局部utilization是否出现超过85%的区域；power stripe和信号走线层是否冲突；IO分配是否和Floorplan一致；热点区域是否预留了足够的绕线空间；设计规则约束是否完整，比如blockage、region和guard ring；是否完全清除了dangling net和unconnected pin；floorplan结果是否和RTL层面的模块划分对应。
这十条里面，我自己踩过坑最多的是第二条和第六条。第二条是pin access，很多时候Macro摆得很整齐，但绕线时发现pin的方向不对，绕线工具需要绕很大一圈才能连上，白白增加了很多走线。第六条是IO分配，我在一个chip-level项目里因为IO方向调整而返工过一次，从此之后每次Floorplan前都会把IO plan提前和系统架构团队对齐，再做Floorplan。
其实整个Floorplan的精髓可以用一句话总结：先跟着数据流走，再考虑绕线资源，最后才轮到美观。你只要把数据流读懂了，Macro的位置就自然出来了，绕线资源的预估也有依据了，整个芯片的物理实现就有了一个扎实的地基。反过来，如果本末倒置，一开始就盯着Macro摆得整不整齐，后面大概率要花更多时间在绕线阶段“补窟窿”。
希望这篇博客对正在做数字后端Floorplan的朋友有一些帮助。如果你们在实际项目中遇到过更有意思的Macro摆放问题，或者有其他优化走线资源的好方法，欢迎一起交流。
