上一篇讲的是每一行代码该写成什么形态。这一篇问的是更靠前的问题：这块电路的形态本身，由谁在什么时候决定。

一款要交付给多个客户的控制器，不可能为每种配置各写一份源码。应用模式要覆盖端点、根端口、双模式与交换端口；数据通路位宽有若干档；链路宽度从一条通道到十六条；缓冲深度、功能数量、可靠性特性各有开关。这些维度乘起来，就是交付方要面对的全部组合。参数化与生成式写法，就是把这份组合空间收进一条代码线的手段。

需要先划清一条边界：参数化属于实现内部的工程约定，不属于对外协议。协议只规定外部可观察的行为——链路如何训练、寄存器如何被访问、错误如何上报——从不规定代码如何组织。因此本篇的举证材料与前二十一篇不同，落在语言标准的求值规则、标准组织的封装描述格式、开源项目与工具链的公开约定，以及厂商控制器公开的可配维度上。

一、复制源码为什么必然失败

不用参数化时，覆盖多档配置最直接的办法是复制源码再逐份修改。它的失败方式是可以预告的，而且是四条同时发生。

补丁只打到一部分副本。同一处缺陷需要在若干份源码里各修一次，漏掉任意一份，那条分支就带着缺陷进入交付。副本之间发生行为漂移。某一份副本因为局部优化改了写法，几个月后它和上游不再是同一个模块，而名字还相同。新增功能无法自动传播。每加一个特性都要在全部副本上各实现一次，工作量随配置数线性放大。差异不可见。两份副本之间究竟哪里不同，只能靠人工比对，改动评审时无法确认这次修改会不会影响另一档配置。

参数化的收益正来自把这四条逐一对掉：修一次处处生效、副本不再存在因而不会漂移、新特性随代码线传播、配置差异收敛为参数取值因而可以被逐条列出与评审。

所以准确的表述是：参数化不是让代码更优雅，而是把配置差异从源码里提出来，变成一份可枚举、可检查、可评审的数据。它的直接产物不是更短的代码，而是一份受支持的配置清单。

二、常量分四层，选错一层就会出错

语言提供的常量机制不止一种，选错层次是参数化设计里最容易被忽略的一类错误。判别的两个坐标是求值时机与能否被覆盖。

三个差别必须记住。

一、能否引用层次名。展开期常量不能引用层次名，因为它们必须在设计层次建立起来之前就求值完毕；静态只读常量可以，因为它在层次已建好之后才计算。这解释了为什么「从另一个实例里取一个常量」只能用只读常量。

二、能否作为结构尺寸。数组维度、端口位宽、生成条件都要求展开期常量，因此只能用参数或局部参数。用只读常量需要满足静态求值条件，用运行期变量则直接不合法。

三、有没有类型检查。带类型声明的参数会在展开期检查覆盖值是否与声明类型相容，能挡掉给整型参数传实数、给字符串参数传整数这类错误；宏没有类型检查。这正是宏在配置场景下被语言级参数取代的直接原因——它不是「不安全」，而是「检查不到」。

参数与局部参数的分工，实质是在代码里划出对外契约与内部实现：能被覆盖的是契约，不能被覆盖的是实现细节。

module fifo #(     parameter int DATA_W = 32,      // 契约：外部可覆盖     parameter int DEPTH  = 16       // 契约：外部可覆盖 ) (     ... );     // 内部派生量：不允许外部篡改，否则会与 DEPTH 不一致     localparam int ADDR_W = (DEPTH == 1) ? 1 : $clog2(DEPTH);     localparam int CNT_W  = ADDR_W + 1;   // 多一位用于区分满与空 endmodule

把地址位宽写成参数是常见错误：它看起来更灵活，实际上制造了「深度与地址位宽可能互相矛盾」的入口。凡是能由其他参数算出、且结果唯一确定的量，都应当是局部参数。

三、参数在哪一步被定死

展开是这样一件事：定位被实例化的模块、对它们施加参数值、运行生成表达式，从而建立起完整的设计层次。教学材料给出的类比很贴切——它大致相当于 C 语言里的预处理阶段。仿真器、综合器、形式验证工具都有各自的展开步骤，参数在这一步被折叠进每一个引用它们的表达式里。

由此得到三条直接推论。参数不同，就是不同的电路：同名模块以不同参数实例化两次，展开后是两个不同的模块，各自有一份独立的硬件；参数相同则在层次里共用同一个模块。参数不是运行期变量：仿真开始后它已经是常数，软件写不动它，也不会出现在寄存器视图里。参数错误的暴露点很靠前：越界、非次幂、互相矛盾的取值会在展开阶段就表现异常——前提是有人写下了检查。

最容易被混淆的一处是：宏与参数都能实现「同一个开关切换两种实现」，但发生的位置完全不同。用宏做配置开关的代价是，它绕过了参数体系——无法被当成参数向下传递，无法参与类型检查，也不会出现在工具报出的参数列表里。这就是为什么开源风格指南普遍要求「顶层参数优先于全局宏」。

还有一条自检方法可以直接用：数一数层次报告里的模块数。名为同一模块、参数不同的两次实例化，展开后应当出现在报告的不同条目里；数不对，说明参数没传到位。

四、生成式写法：把参数值翻译成结构

生成构造是展开期的语句，效果相当于「自动写下新的代码」。它们能包含模块实例、过程块、连续赋值与声明，三副面孔分别解决三个问题。

循环生成复制结构。用生成循环专用的整型变量索引，把主体复制若干份，这是把「位宽参数」变成「真实实例数量」的标准手段。三条约束必须记住：循环变量只能是生成循环专用对象，不能当信号使用；循环边界必须静态，上界只能用参数、局部参数或字面量；过程循环不能实例化模块——把模块实例化写进过程式的循环里是常见错误，工具会直接拒绝，过程循环只能复制语句，生成循环才能复制结构。

条件生成选择结构。关键点在「未选中的分支不产生硬件」。这一点与运行期条件语句的区别值得单独强调。

generate   if (HAS_PARITY) begin : gen_parity     assign parity = ^data;   end else begin : gen_no_parity     assign parity = 1'b0;   end endgenerate

分支生成做多路选择。当实现方案有多个具名变体时，用分支生成按参数选择其一，比串联多层条件生成更清楚——三个变体写三层嵌套的条件生成，可读性会迅速下降。

还有一条在风格指南里几乎一致的硬性要求：每个生成块都要显式命名，条件生成的每一条分支都要命名，循环生成的主体也要命名。原因是生成块的名字构成被生成实例的层次名——命名一致，跨工具的层次名才一致，波形、约束、调试脚本才能复用。未命名的生成块不仅难调试，部分工具还会直接报错。

五、非法配置要挡在综合之前

语言在过程代码之外提供了四个展开期系统任务。它们与仿真期的同名任务不同：其参数只能是格式化串与常量表达式，生成结构展开之后仍然留在模型里的调用会被执行。

工具报出这些消息时，按标准要求须包含三项：调用处的文件名与行号、调用所在作用域的层次名、以及用户给出的消息文本。三项合起来，定位一个错误配置几乎不需要额外排查。

落点有两种，优先前者。推荐把检查直接写在模块体里——过程代码之外的条件判断会被当作条件生成，因此可以按条件触发展开期任务，也可以写成过程之外的立即断言。备选是写进初始化块内，它也能抓到错误，但变成仿真期的失败：每个实例各报一次，报错发生在仿真启动之后而非展开阶段。开源项目中常见的参数检查宏即属此类，它胜在写法统一、可批量施加，代价是暴露点晚一步。

该检查什么，可以固定为五类关系。

成本对比很清楚：在展开期拦住一个非法配置，代价是改一行参数、重跑一次展开；漏到仿真期才发现，代价是跑到半程发现读数不对，回头逐层检查参数传递链。两者的时间差通常是一到两个数量级，而写这些检查的成本是每个模块几行代码。

六、单一真源与逐层转发

覆盖方式有三种，取舍很明确。命名覆盖在实例化时按名字给出参数值，与顺序无关，新增参数不会破坏既有调用点，可读性也高，应当一律采用。位置覆盖按声明顺序给值，参数表一调整就会静默错位，工具不会报错，因为类型可能仍然相容。用层次路径从外部改值属于遗留写法，在语言层面已被标记为应当避免：它破坏层次分析，工具无法只读一个模块就确定它的参数值，综合流程也不接受这种写法。

真实项目里最重要的模式是单一真源加逐层转发：一个量的取值只在一处定义，逐层向下转发，中间层不改变它的语义。

// 顶层：唯一定义处 localparam int BUS_W = 64;  // 逐层转发（名字不变、值不变） ip_block_a #(.BUS_WIDTH(BUS_W)) u_a (...); ip_block_b #(.BUS_WIDTH(BUS_WIDTH)) u_b (...);   // 子模块内继续同名转发 ip_block_c #(.BUS_WIDTH(BUS_WIDTH)) u_c (...);

它的好处是改动半径可预测：改顶层一处，所有下游模块自动重算自己的派生常量。反过来说，一旦某层在转发时做了运算——例如把位宽乘二再传下去——下游就再也无法回溯到真源，配置的一致性只能靠人工维持。

传递链有三种断法，每一种都不报错。

由此得到三条硬规则：参数名应在全设计范围内保持一致；转发层只做搬运、不做运算；每个接受参数的模块都应有一条展开期检查，用于确认收到的取值落在本项目支持的档位里——最后这条同时也能兜住「忘了转发」这一类错误，因为默认值通常不在支持清单里。

七、位宽与符号：被参数化放大的两类陷阱

由存储深度推导地址位宽的函数，在输入为 1 时返回 0；而硬件里不存在零位宽的信号，写成「推导值减一至零」的位选形式就会得到非法的负索引。正确写法是把这一档单独兜住。

// 危险：深度为 1 时得到非法位宽 localparam int ADDR_W = $clog2(DEPTH);  // 安全：显式处理下界 localparam int ADDR_W = (DEPTH == 1) ? 1 : $clog2(DEPTH);

另有两点需要留意：该函数在输入为 0 时未定义，不同工具可能给出不同结果，不能依赖；它属于较晚版本的语言特性，工具链较老时可能不支持，需要自定义等价的可综合函数替代。

位宽不匹配是另一类静默缺陷。参数化把位宽变成了变量，于是「看起来够用」的判断不再可靠。主流开源工具已经能对两类问题分别给出诊断：一类是表达式被扩展（例如用较窄的索引去选择一个较大的数组），一类是被截断。这两类在功能仿真里通常跑得过，直到出现某个特定输入组合才暴露。

修正手法有三种：用自动定宽的字面量，避免手工数字位数算错；用拼接显式加宽、用部分选择显式收窄；用类型转换显式改变位宽。工程上的共识是——宁可显式写长一点，也不让工具按默认规则替你决定位宽。

符号性在参数化下更危险。前一篇已经核验过规则：只要一个操作数是无符号，整个比较就被拉到无符号域；而位选择与部分选择的结果总是无符号。参数化把这一点放大了——参数本身可能是无符号整型，用它参与比较或运算时，有符号性靠声明决定，靠肉眼看不出来。因此带符号的参数应当显式声明符号性，混用有符号与无符号的表达式应当显式转换。

推导出的位宽到底是多少，可以用语言提供的查询能力核对：查询信号或表达式的位宽、查询某个类型名。在验证侧这一点尤其方便——打印特化之后的类型名，可以直接确认在这个参数组合下环境里拿到的是哪一种类型。

八、参数还是寄存器：一条判据

同一个配置需求，往往既可以做成编译期参数，也可以做成软件可写寄存器。判断准则只有一条：改动它是否需要重新综合、重新布局布线。

有一条边界情形值得单独说。「某功能存在与否」看起来天然该做成参数，但如果该功能的开关不改变任何位宽、只影响控制路径，做成寄存器位也是可行的。寄存器位方案保留灵活性，不必重新综合；参数方案省面积，逻辑真的被删掉。取舍点是：这个功能在多少比例的客户配置里会被关掉。只在少数配置里关闭的功能，做成寄存器位更划算。

反之有一条必须避免的反模式：把结构量做成寄存器位。软件能写、但硬件不支持对应的结构改动，结果就是写入无效、读回为零——这既是文档负担，也是现场调试的陷阱源头。若因架构原因必须保留这类寄存器位作为占位，必须在寄存器文档中显式标注写入无效、读值恒零，并且它的默认值要参与第 18 篇所说的硬连零契约检查。

这一节还接回第 18 篇的一条暗线。参数决定寄存器映射的形态：功能数量决定每个功能的配置空间块，链路宽度与端口形态决定相关寄存器的存在与位宽，可靠性特性的开关决定对应的状态位是否存在。因此寄存器生成必须在参数取值确定之后进行——那一篇的生成流有一个前提没有展开，它的输入其实是由本篇的参数集确定的。

九、交付物：一份参数传递方案

本篇的交付物是一份可执行的参数传递方案，共十六项，分三组：A 组规定语言机制怎么用，B 组规定检查与传递怎么做，C 组规定流程与签核怎么走。

代表性配置矩阵的选法有五条原则：取极值，面积与时序的边界通常出现在最小与最大位宽处；覆盖每项可选特性的开与关各一次；取依赖链上刚好满足与刚好违反的组合，用来验证检查逻辑本身是否生效；纳入要对外出具结果的合规性与互操作配置；纳入已签订单里出现过的组合，交付责任落在这些组合上。

如果资源紧张，优先落地六条，它们覆盖了绝大多数实际事故：常量分层、仅用命名覆盖、生成块一律命名、位宽推导兜住下界、展开期检查至少覆盖取值域与跨参数关系、单一真源且中间层不改变语义。

最后是两处容易被忽略、代价却不小的提醒。

一是覆盖率的可达性随配置变化。某配置下未选中的生成分支根本不存在，对应的覆盖点永远无法命中。如果不按配置管理豁免，覆盖收敛曲线会出现「永远差几个点」的僵局，团队会浪费大量时间去追不可达的覆盖点。二是验证环境自己也必须参数化，而且与设计同源。常见事故是设计侧参数改了、环境侧还留着旧值，双方各自自洽，回归全绿而实物不符。参数传递方案必须包含这一条：两侧参数取自同一处真源，并在仿真启动时确认一致。

还剩一条工程判断需要交代清楚。参数化会让「改动的影响面」变得模糊：改一个默认值，可能同时改变几十个实例的行为，而工具不会像对端口改动那样报警。可行的做法是把参数默认值的改动视同接口变更，纳入同等强度的评审与回归，并在提交说明中单独列出受影响的配置。

同样值得说明的是收益与成本的曲线形状：参数化的收益随配置数量增长而增长，成本却从第一个模块就开始付出——额外的检查、额外的层次、额外的一轮签核。因此它在单模块、单配置阶段确实像负担，在多配置交付阶段则是唯一可行方案。判断自己处在哪一段，比争论要不要参数化更有意义。