随着功能复杂度的快速提升，对芯片的要求也是随着提高，所以现在一款芯片的开发，往往需要数十人，长达几个月的共同开发才能完成。

因为Verilog HDL的语法相对开放，所以每个人开发的Verilog HDL之间的差异也是非常的大。但是一个设计团队之间，进行RTL模块的交叉review、相互调用是非常频繁的事情，所以为了增强RTL代码的可移植性，以及review的效率，我们通常在一个项目开始的时候，会统一整理一个RTL编码规则，里面的内容包括，命名的规则、单词的缩略原则，一些标准电路的常用写法等等。往往这个编码规则会写的很具体，但是个人认为，这是非常有必要的。在前面的三篇文章中，我们已经聊了一些，今天的文章，我就继续来聊一聊一般常见的规则。

RTL推荐编码规则

• 多使用function/task等功能。在编码过程中，我们通常出现一个功能在多处调用的情况，所以我推荐多使用function和task。并且，如果这个功能在不同设计者中有交叉条用的话，建议可以作为一个通用IP进行推广，这样就可以使得效率最大化。不过需要注意的是，因为可能出现多人调用的情况，所以在IP或者是function/task内部，做好注释，方便别人调用和阅读。
• 循环语句使用。循环语句的使用，一定要注意。循环语句可以减少RTL的行数，使得代码变得简洁，但是有几个点是要注意的。第一，循环的次数一定要固定，不然综合工具不能很好的综合。第二，要注意不能因为使用了循环语句，使得RTL变得难以阅读。

• 寄存器组的使用。寄存器组在一定程度上面也可以减少RTL的行数，但是要注意，因为引入了多维数组，所以在debug的时候，需要使用高版本的waveform显示工具，这样可以直接显示寄存器组，方便调试。在一些低版本的的工具里面，寄存器组是不能显示的，这样就无法进行debug，影响debug进度。
• 给always块起一个标号。因为一个设计中，有非常多的always块，所以为了方便调试，我们可以给一些关键的always块起一个标号，这样就能方便的多。但是要注意的是，标号不能和之前定义的信号名、变量名相同。
• 数据类型只是用IEEE定义的标准类型。在RTL设计过程中，有的时候，设计者处于自己方便的角度，会自己去定义一种新的数据类型或者子类型，需要强调的是，这种自定义的方式是不推荐的，如果非要自己定义，那么必须保证自定义的这些数据类型或者子类型是基于IEEE的标准的。

小结

今天的文章，我们接着之前的文章，给出了一些编码的规范，看起来特别琐碎，但是却是非常重要。个别是function/task、循环语句等等。如果您对内容有什么建议或者疑问，欢迎和我进行讨论。