3、重构区域规划：静态区域与动态区域的划分、重构区域大小估算、资源预留策略
好，咱们进入正题。这部分内容，说白了就是回答三个问题：哪些逻辑要动？给它留多大地方？怎么保证不动的那部分不出问题？
我在做第一个PR（部分重构）项目时，就踩过一个大坑——区域划得太小，结果动态模块塞不进去，整个编译流程白跑了一整天。嗯，从那以后，我对区域规划就格外上心。
3.1 静态区域与动态区域的划分
先搞清楚概念。静态区域，就是永远在线、不参与重构的那部分逻辑。动态区域，就是可以被替换的“插件”区域。
我个人习惯，把划分原则总结成三条：
- 功能边界清晰：动态模块必须是功能独立的。比如一个视频编解码器、一个加密引擎、一个协议栈。你不能把状态机的一半放在动态区，另一半留在静态区——那会出大问题。
- 接口标准化：动态区和静态区之间，必须通过固定的总线接口或FIFO通信。我见过有人直接用wire连过去，结果重构后时序全乱套了。
- 时钟域明确：动态模块的时钟可以独立，但静态区必须能处理动态区“消失”时的时钟悬空问题。
核心原则：静态区要足够“强壮”，不能依赖动态区的任何信号。动态区掉电或重构时，静态区必须能正常工作。
你想想看，如果静态区里有个逻辑门，它的输入来自动态区。动态区一重构，输入悬空了，静态区就可能产生毛刺。所以，所有跨区信号必须加隔离逻辑——这是硬性要求。
3.2 重构区域大小估算
这个环节，很多新手会拍脑袋。我建议你老老实实做一次综合，看看资源占用。
具体步骤是这样的：
- 把动态模块单独拿出来，做一次完整综合。
- 记录LUT、FF、BRAM、DSP的使用量。
- 乘以一个安全系数——我个人习惯用1.2到1.5倍。
为什么要乘系数？因为布局布线时，资源利用率太高会导致布线拥塞。我曾经有个模块，综合报告显示只用了60%的LUT，结果布局时因为分布太散，布线失败。后来我留了40%的余量，一次通过。
| 资源类型 | 综合用量 | 建议预留 | 备注 |
|---|---|---|---|
| LUT | 12000 | 15000 ~ 18000 | 布线拥塞时需更多余量 |
| FF | 8000 | 10000 ~ 12000 | FF通常比LUT好布 |
| BRAM | 24 | 30 ~ 36 | BRAM位置固定，需对齐 |
| DSP | 16 | 20 ~ 24 | DSP列有限，注意分布 |
小技巧：如果你用的是Xilinx的器件，可以用Tcl命令 report_utilization -cells <模块名> 来查看精确的资源占用。别只看图形界面，那个有时候会四舍五入，不够准。
3.3 资源预留策略
资源预留，说白了就是给动态区“圈地”。你不能让静态区的逻辑跑到动态区的地盘上，否则重构时会冲突。
我常用的方法有两种：
- 物理约束法：在XDC或UCF文件中，用
AREA_GROUP或Pblock把动态区框起来。静态区的逻辑会被工具自动排到外面。 - 黑盒法：把动态模块声明为黑盒，工具不会在里面放任何逻辑。等重构时再加载真正的实现。
我个人更推荐物理约束法。为什么？因为黑盒法虽然简单，但工具可能会把静态区的逻辑“挤”到动态区附近，导致后续重构时布线资源不足。
注意：资源预留不是越大越好。预留太多，静态区的布线路径会变长，时序可能变差。预留太少，动态模块放不下。这个平衡点，需要你根据实际项目来调。
我曾经在一个项目中，把动态区预留了芯片面积的40%。结果静态区的关键路径因为绕路，时序怎么也收敛不了。后来我压缩到25%，动态模块勉强塞下，静态区的时序也达标了。嗯，这就是个典型的“挤一挤”案例。
3.4 知识体系总览
下面这张图，把咱们刚才讲的内容串起来了。你可以把它当作一个检查清单，做项目时对照着看。
这张图里，三个主节点对应咱们讲的三个核心步骤。底部的“时序收敛 + 资源不冲突”是最终目标。你做完区域规划后，可以拿这张图自检一遍，看看有没有遗漏。
总结一下：区域规划不是一次性的工作。随着设计迭代，你可能需要反复调整区域大小和位置。我建议你在项目早期就建立一套自动化脚本，每次综合后自动生成资源报告，这样调整起来就快多了。
好了，这部分内容就到这里。记住，区域规划做得好，后面的重构流程就顺风顺水。做不好，嗯...你可能要加班了。
公众号:蓝海资料掘金营，微信deep3321