Verilog以及VHDL所倡导的的代码准则

举报
李锐博恩 发表于 2021/07/15 08:20:41 2021/07/15
【摘要】 文章目录 写在前面正文前缀关于大写的说明关于初始化信号的注意事项Xilinx related HDL coding guidelinesAltera's Recommended HDL Coding StylesLattice HDL Coding Guidelinesopencores_coding_guidelines 参考资料 写在前面 对于代...

写在前面

对于代码准则这个话题,各个公司或者机构都有各自的要求,但是他们之间的统一性在于这样一个目的:

  1. 提高代码的可读性,使代码易于理解;
  2. 编写代码的统一性,规范代码设计;
  3. 使得代码不容易出错。

如果做到这些呢?它们有一些共性,我们最好在编写Verilog以及VHDL时统一这些规则,以便达成共识!

我搜集了互联网上公开的各种资料,对这个话题进行总结如下!

正文


前缀

i_   Input signal 
o_   Output signal 
r_   Register signal (has registered logic) 
w_   Wire signal (has no registered logic) 
c_   Constant 
g_   Generic (VHDL only)
t_   User-Defined Type  

  
 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

你有没有遇到过这种情况?

在不太规范的大型工程设计,阅读例化模块时,在繁多的端口列表中难以区分输入输出,不得不进入具体的模块中,去寻找输入输出关系,耗费眼力也耗费体力,让人苦恼不堪!
于是抱怨Verilog以及VHDL的可阅读性,其实不然,上面的前缀可以解决这个基本的烦恼,如果统一对输入输出变量的命名方式,也就是使用上述前缀,是一个不错的习惯!

下面根据重要性程度分别对其介绍:

i_和o_前缀:

这是您应该采用的最重要的样式! 太多的设计人员没有表明他们的信号是实体/模块的输入还是输出。 浏览代码以确定信号方向可能非常困难且烦人。 另外,一个名为“data”且为输出的信号比名为“ o_data”的信号更难通过搜索在代码中找到。 示例:i_address,o_data_valid。


r_和w_前缀:

这是您需要使用的第二重要的样式。 指出您的信号是reg类型还是wire类型,对于编写好的代码非常重要。 Verilog的优势在于它可以迫使您将信号声明为reg或wire,但是VHDL却没有这样的要求! 因此,这种样式对于VHDL编码器尤其重要。 用r_声明的所有信号都应具有初始条件。 在时序process中(在VHDL中)或always(在Verilog中),用w_声明的所有信号都绝对不能出现在赋值运算符的左侧。 示例:r_Row_Count,w_Pixel_Done。


c_,g_ 和 t_(前缀):

这些在编码时很有帮助。 c_表示您正在引用VHDL中的常量或Verilog中的参数。 g_用于所有VHDL泛型。 t_表示您正在定义自己的数据类型。 我发现这些有帮助。 示例:c_NUM_BYTES,t_MAIN_STATE_MACHINE。 对于状态机,我喜欢使用所有大写字母…例如 IDLE,DONE,CLEANUP。 在过去,我使用s_来指示状态,但是我已经不用了。 首选项更改为使用c作为前缀。

关于大写的说明

是否要大写信号名称取决于您。 如您在上面的示例中看到的那样,除前缀之外,我将所有不是输入或输出的信号都大写。 如果您更愿意将信号命名为r_Row_Count或r_row_count而不是r_ROW_COUNT,那么这完全取决于您。 我建议您保持一致! VHDL不区分大小写,因此r_ROW_COUNT与r_Row_Count相同,但是在Verilog中不是这样。 Verilog区分大小写,因此维护大写规则非常重要! 当您只想创建一个信号时,您不想意外地创建两个不同的信号,否则您将度过非常糟糕的时光。

关于初始化信号的注意事项

人们普遍存在一个误解,认为FPGA中的寄存器需要复位信号才能初始化。 这是不正确的,FPGA寄存器可以具有初始值。所有FPGA都可以初始化为零或非零值。 实际上,最佳实践是在设计中复位尽可能少的触发器,而是依靠初始化所有触发器。 这样做的原因是,您添加到触发器中的每条复位线都会占用布线资源和功耗,并使您的设计更难以满足时序要求。

您应遵循的规则是:所有寄存器(由r_前缀标识)应始终具有初始条件。 禁止对wire型(用w_前缀标识)施加初始条件。 当您仿真设计时,在仿真甚至开始之前,所有信号都应为绿色。 如果这是真的,那么您会更快乐。

当然,上面是通用的规则,各大公司还有各自推荐的规则,例如:

Xilinx related HDL coding guidelines

Xilinx related HDL coding guidelines1

ug901-vivado-synthesis

Xilinx_HDL_Coding_style

Altera’s Recommended HDL Coding Styles

内容太多,各位参考资料:

Altera’s Recommended HDL Coding Styles

Lattice HDL Coding Guidelines

[Lattice HDL Coding Guidelines](file:///D:/Downloads/HDLcodingguidelines.pdf)

opencores_coding_guidelines

opencores_coding_guidelines

参考资料

  1. nandland coding-style-recommendations-vhdl-verilog
  2. Altera’s Recommended HDL Coding Styles
  3. [Lattice HDL Coding Guidelines](file:///D:/Downloads/HDLcodingguidelines.pdf)
  4. opencores_coding_guidelines
  5. springer
  6. Xilinx related HDL coding guidelines1
  7. Xilinx_HDL_Coding_style

文章来源: reborn.blog.csdn.net,作者:李锐博恩,版权归原作者所有,如需转载,请联系作者。

原文链接:reborn.blog.csdn.net/article/details/106872978

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。