📚 课程目录第4章模块划分策略

4. 模块划分策略：基于功能、基于时钟域、基于物理位置、基于复用性

模块划分这件事，说简单也简单，说复杂也复杂。我见过不少新手，一上来就把整个设计塞进一个模块里，结果后端跑起来那叫一个痛苦——时序收敛难、布线拥塞、ECO改不动。说白了，模块划分就是给芯片做“空间规划”，划得好，后面省心一大半。

我个人习惯把模块划分策略归纳为四个维度：功能、时钟域、物理位置、复用性。这四个维度不是互斥的，实际项目中往往是组合使用。你想想看，一个模块可能既是一个独立功能块，又跑在单独时钟域里，还恰好被放在芯片的某个角落。

这是最直观的划分方式。把设计按功能模块拆开，每个模块负责一个明确的子任务。比如一个SoC芯片，你可以拆成CPU核、GPU、内存控制器、外设接口等。

这样做的好处很明显：

我在项目中遇到过一个问题：一个通信芯片的基带处理模块，功能上拆得很细，但模块间有大量数据交互，导致顶层连线特别长，时序根本收不拢。后来我们把几个紧密耦合的子模块合并了，才解决问题。

我的建议：功能划分时，要关注模块间的“通信密度”。如果两个子模块之间交互频繁，考虑合并成一个模块，减少顶层连线。

时钟域划分，说白了就是把跑在不同时钟频率下的逻辑分开。这是后端设计中非常关键的一步。

为什么要按时钟域划分？

我曾经接手过一个项目，设计者把所有逻辑都放在一个模块里，但内部有四个不同的时钟域。结果时钟树综合时，工具试图把所有时钟域平衡在一起，导致时钟偏斜大得离谱。后来我们把每个时钟域拆成独立模块，各自做时钟树，问题就解决了。

注意：跨时钟域路径一定要做同步处理。我见过有人把异步信号直接连到寄存器上，结果流片回来功能时好时坏，查了两个月才发现是跨时钟域没处理好。

这个策略更偏后端视角。根据芯片的物理布局，把逻辑分配到不同的区域。比如一个芯片有多个处理器核，每个核放在一个独立的物理区域里，这样布线更短，时序更容易收敛。

物理位置划分的典型场景：

我记得有个项目，芯片面积很大，顶层布线特别长。我们把设计按物理位置拆成四个象限，每个象限独立做布局布线，最后通过顶层走线连接。这样每个象限的时序都很好收敛，整体时序也达标了。

  关键点：物理位置划分要结合floorplan来做。先确定大模块的摆放位置，再根据位置来调整模块边界。

这个策略考虑的是长远利益。把那些可能被多个项目复用的逻辑，单独做成一个模块。比如DMA控制器、SPI接口、I2C控制器等。

复用性划分的好处：

我建议在项目初期就考虑复用性。哪怕当前项目只需要一个简单的SPI接口，也把它做成一个独立的、参数化的模块。这样下个项目需要更复杂的SPI时，直接改参数就行，不用重新写。

经验之谈：复用模块要特别注意接口标准化。我见过一个团队，每个项目都自己写UART模块，接口定义都不一样，结果想复用都复用不了。后来统一了接口规范，才真正实现模块复用。

实际项目中，我不会只用一种策略。通常的做法是：

这个流程不是线性的，往往需要来回迭代几次才能找到最优方案。

  核心原则：模块划分没有标准答案，只有最适合当前项目的方案。多花点时间在划分上，后面会省很多时间。

嗯，模块划分这件事，说到底就是“分而治之”的思想。但怎么分、分多细，需要根据项目实际情况来定。我见过有人把模块拆得太细，结果顶层连线比模块内部还复杂；也有人把模块做得太大，导致后端工具跑不动。

我的建议是：先粗后细，逐步迭代。一开始可以分得粗一些，随着设计深入，再逐步细化。这样既不会一开始就陷入细节，也不会到最后才发现划分不合理。