原创 Motorala推荐的Verilog代码规范.(Verilog).(翻译)

一. 文件命名

规则 1: 每个文件中只包含一个设计单元
理由: 便于修正.

规则 2: 文件命名协定
<设计单元名称>.<扩展名>
理由: 便于理解设计单元constructs及文件内容.
如: spooler.v    // spooler模块的同步Verilog代码描述

规则 3. 模拟和数字Verilog文件
每个单一文件必须包含: (1)模拟(analog)Verilog(用.va文件后缀); 或(2)数字Verilog(用.v文件后缀); 或(3)清晰的模\数混合Verilog(用.va文件后缀).
理由: 模拟的编译器也许不能操纵数字的架构; 反之亦然.

二. HDL编码项目命名

规则 4: 允许的字符集
命名中必须包含字母, 数字或下划线[A-Z, a-z, _] (见 规则5)
例外: 不允许使用连续的下划线.
理由: 双下划线在硬件竞争中是不工作的.

规则 5: 命名的首字符
命名必须以字母开头, 而不是数字或下划线 (见 规则4)
理由: 以数字或下划线开头的命名, 可能会引起工具冲突.

规则 6: 所有命名必须是唯一的无关项
理由:  在Verilog(语法敏感)和VHDL(语法不敏感)中的设计转换中, 很可能受语法不敏感的设计风格影响.

规则 7: 信号的一致性
理由: 和VHDL相比, Verilog和许多支持VHDL的工具都一样是语法敏感. 及时辨别信号的类型(如: 低电平有效的信号或时钟)有助于调试.

规则 8: 常量, 参数和标签区块要大写
理由: 提供了一种可以辨别那些在仿真中不需要经过数据转换的实体的机制.

规则 9: 信号, constructs和实例化标签要小写
理由: 从在仿真中数据不变化的实体中区别信号和constructs, 以及在设计中保持一致的视觉和感觉.

规则 10: 有意义的信号和变量名称
小写的名称必须包含信号和变量的意图.
理由: 描述是什么, 而不是怎样去做, 有助于理解设计.
如: data_bus, set_priority

规则 11: 有意义的常量名称
常量名称一定要描述常量的意图. 根据意图可以很明显地看出常量的类型, 及不是端口的名称. 常量需大写.
理由: 有意义的名称对于常量来说, 非常重要.
如: 好的名称: SBUS_DATA_BITS, MEMORY_WIDTH, CLK_PERIOD
如: 差的名称: ADDRESS_SIZE 并不明晰, 当它指的是数的位宽或地址空间的长度

规则 12: 有意义的construct名称
construct的名称如functions, modules, tasks等,必须根据它们要做什么而不是怎么样去做来命名. construct名称必须小写.
理由: 描述是什么, 而不是怎样去做, 有助于理解设计.

规则 13: 有意义的实例化标签
实例化标签要根据construct指定的要实现什么, 而不是怎样去做来命名.
理由: 描述是什么, 而不是怎样去做, 有助于理解设计.
如: addr_decode, bit_stuff, sbus_if

规则 14: 用下划线分隔包含许多单词的名称
理由: 增加可读性
如: ram_addr

规则 15: 低电平有效信号命名使用 _b
理由: 有意义, 一致性的名称, 有助于理解设计.
如: enable_data_b, reset_b

规则 16: 时钟信号命名使用 _clk
理由: 有意义, 一致性的名称, 有助于理解设计.
如: fifo_transmit_clk
例外: 明显包含时钟的信号名称(如: system_clock, clk32m).

规则 17: 未连接(Unconnected)的输出信号命名使用 _uc
理由: 当关于未连接信号的警告出现时, 如果该名称以_nc结尾, 这样该信号就会很明显地被知道是未连接, 而不是存在的错误.

规则 18: 信号捆绑(bundling)
不相干的信号不能被捆绑成总线.
理由: 易于理解module.

方针 19: 三态信号命名使用 _z
理由: 有意义, 一致性的名称, 有助于理解设计.
如: ram_data1_z

方针 20: 状态机信号命名使用 _next
理由: 有意义, 一致性的名称, 有助于理解设计.
如: transmit_next

方针 21: 测试模块信号命名使用 _test
理由: 有意义, 一致性的名称, 有助于理解设计.
如: parallel_clk_test

方针 22: 扫描(scan)使能(enable)信号命名使用 _se
理由: 有意义, 一致性的名称, 有助于理解设计.

方针 23: 模拟信号命名使用 _ana
理由: 当区别模拟信号时, 有助于理解设计. 尤其是当使用图像查看器时, 更加有用.

方针 24: 信号名称的多后缀优先性
从高到低:
1. _b
2. _z
3. _clk
4. _next
最高优先级的后缀被推荐为信号名称的最靠后的后缀.
如: ram_data1_z_b, receive_clk_b

方针 25: 参数化变量命名使用 _PP
理由: 有意义, 一致性的名称, 有助于理解设计.
如: NUM_COLUMNS_PP

方针 26: 信号名称的长度应该小于28个字符
短的名称可读性较强. 但28个字符不包括层次(hierarchy).
理由: 长的名称可能会引起工具的冲突.

方针 27: 避免缩略语除了常用已知的缩略语
理由: 使用有意义的名称.
例外: 一般所知的缩略语, 如RAM,和loop counters. loop counters可能被命名为单个字母, 如I或N, 因为它们代表索引. 一些后端工具会连接所有层次的名称, 以及给予有限的名称总长度. 在那种情况下, 缩略语是多层次名称所必须的. 但这些缩略语必须以注释的方式来阐明.

方针 28: 文档和附加命名协议
任何在module中使用的缩略语要记录在档案中是被推荐的. 任何在module中使用的协议都要添加到必要的协议中, 或推荐的SRS, 然后记录到档案中.
理由: 对于原始设计者来说,很明显的缩略语, 当再次被使用到时, 有可能不再那么清晰.

方针 29: 层次间名称的一致性
层次间或整个IP中, 信号或设计单元的名称应该保持一致.推荐关联多个实例化的名称因该有名称索引.
理由: 增加可读性, 消除歧义, 在综合中避免缓冲器置入.

方针 30: Verilog名称应该与档案中的名称相同
理由: 便于理解HDL模块.

注: 选译Motorala的Verilog HDL Coding - Semiconductor Reuse Standard