1. 设计目的
-
module-
硬件建模：用于描述数字电路的结构和行为（如组合逻辑、时序逻辑、连线等）。
-
层次化设计：支持模块化设计，可嵌套其他模块或接口（
interface）。 -
仿真周期内持续存在：在整个仿真过程中保持活跃（如
always块持续执行）。
-
-
program-
验证环境：专为测试平台（Testbench）设计，用于验证
module的功能。 -
避免竞争条件：通过隐式的时序控制（如
initial块和时钟同步），减少与设计的时序竞争。 -
自动结束仿真：当
program中的代码执行完毕后，仿真会自动终止，无需手动调用$finish。
-
2. 执行时序
-
module-
行为与硬件并行：
always、assign等语句在仿真时间步内并行执行。 -
可能导致 竞争条件：若测试代码直接写在
module中，采样和驱动的时序可能与设计代码冲突。
-
-
program-
行为更接近软件：代码通常以
initial块为主，按顺序执行，与设计的时序解耦。
-
3. 结构限制
-
module-
可包含硬件相关结构：
always、assign、gate、UDP、module实例化等。 -
可包含
initial块（但通常仅用于简单测试）。
-
-
program-
禁止使用
always：防止因持续执行导致仿真无法结束。 -
推荐使用
initial和final：测试逻辑一般写在initial块中，final块用于结束前的清理。 -
通常不实例化硬件模块（如
module或interface）。
-
4. 生命周期
-
module-
从仿真开始到结束一直存在，除非显式销毁。
-
-
program-
当
program中所有initial块执行完毕后，自动结束并触发仿真终止。
-
5. 现代验证趋势
-
program的替代方案：
随着验证方法学（如 UVM）的普及，program的使用逐渐减少。现代测试平台更倾向于：-
使用
module搭配interface和clocking block。 -
利用类（
class）、事务级建模（TLM）等高级验证结构。
-
总结
| 特性 | module | program |
|---|---|---|
| 用途 | 硬件设计 | 测试平台（Testbench） |
| 时序行为 | 并行执行（硬件仿真） | 顺序执行（软件风格） |
| 代码结构 | 支持 always、assign 等 | 仅支持 initial、final |
| 仿真生命周期 | 持续整个仿真过程 | 执行完毕后自动终止 |
| 竞争条件处理 | 需手动同步时序 | 隐式时钟同步（通过 clocking） |
