Verilog代码可移植性设计

标签：Verilog代码可移植性
Verilog代码可移植性设计Verilog代码可移植性设计
1. 参数定义
localparam，实例代码如下：
module tm1(
clk,rst_n,
pout
);
input clk;
input rst_n;
output[M:0] pout;
localparam N = 4;
localparam M = N-1;
reg[M:0] cnt;
always @(posedge clk or negedge rst_n)
if(!rst_n) cnt <= 0;
else cnt <= cnt+1'b1;
assign pout = cnt;
endmodule
其实所谓localparam即local parameter（本地参数定义）。

简单的说，通常我们习惯用parameter在任何一个源代码文件中进行参数定义，如果不在例化当前代码模块的上层代码中更改这个参数值，那么这个parameter可以用localparam代替。

而localparam定义的参数是可以如parameter在上层文件中被更改的。

具体的区别待parameter的用法实例后大家就能明白。

parameter，实例代码如下：
module tm1
#(parameter N = 4)
(
clk,rst_n,
pout
);
input clk; //外部输入25MHz时钟
input rst_n; //外部输入复位信号，低电平有效
output[M:0] pout;
localparam M = N-1;
reg[M:0] cnt;
always @(posedge clk or negedge rst_n)
if(!rst_n) cnt <= 0;
else cnt <= cnt+1'b1;
assign pout = cnt;
endmodule
tm1.v的上层模块中，可以用lvdsprj.v模块中的方式对其已经定义的parameter参数进行重新定义，而相应的localparam定义是不可以在lvdsprj.v模块中进行重新设定的。

Lvdsprj.v模块的代码如下：
module lvdsprj(
clk,rst_n,
pout
);
input clk;
input rst_n;
output[M:0] pout;
localparam N = 5;
localparam M = N-1;
tm1 #(.N(5))
uut1(
.clk(clk),
.rst_n(rst_n),
.pout(pout)
);
endmodule
在verilog设计中，我们习惯将状态机的状态量用parameter来申明定义，它的适用范围通常是某个代码模块，或者其相关的上一层模块可对其进行重新申明定义。

而如果工程中有多个模块里要用到同样的
2. 宏定义
从定义方式上看，verilog语法中的宏定义和C还是略有区别，如verilog中的宏定义如下：
`define M 5
在使用该宏定义值时，通常M应该表示为`M。

之所以不是很提倡滥用宏定义，是因为它不像parameter那么“中规中矩”的作用有某几个特定的源代码文件中。

一旦`define被编译，其在整个编译过程中都有效，只有当遇到`undef 命令才能使之失效。

也即它通常会影响工程的其他模块，尤其当多个同样宏名定义时，如果不注意有可能照成定义的混乱。

3. 条件编译
`ifdef、`else 和`endif，这些编译指令用于条件编译，如下所示：
`ifdef windows
parameter SIZE = 16
`else
parameter SIZE = 32
`endif
在编译过程中，如果已定义了名字为windows的文本宏，就选择第一种参数声明，否则选择第二种参数说明。

` else程序指令对于`ifdef 指令是可选的。

条件编译其实是很有用的，尤其在代码移植过程中。

在工程中，如果我们编写某段代码逻辑（可能不止一段），而在实际应用中并不需要（或者只是作为调试使用，或者可能在别的工程中使用），通常的做法可能是将该部分逻辑进行注释。

而当再次希望使用这部分代码的时候，一个常见的问题出现了，取消注释的时候往往可能不记得哪些逻辑是和这个功能块相关并被注释了。

因此，这个时候条件编译就派上用场，可以省去我们很多的郁闷时间。

特权同学过去对这个命令很不感冒，通常只是感觉很多有用的没用的代码在那里显得很紊乱，殊不知其实某些情况下它还是很“给力”的。

以上提到的三种常见参数定义和编译指令，在一个好的工程中应该是频频出现。

毕竟用好了它们对于代码的重用（移植）和升级是非常有帮助的。

特权同学在工作中常常需要重用以前的设计模块，也常常需要将工程移植到新的器件或类似的应用中。

遇到过不少恼人的问题，也许只是简单的几个小疏忽，却常常花费数日在纠错。

究其根本原因，都是因为代码的原型设计不够规范，代码的可重用性考虑欠缺。

总结过去遇到的一些常见问题，简单的归纳几点心得：
① 工程中一些通用常量的定义多用parameter或`define，便于更改。

② 部分暂时不需要的功能块用`ifdef来“注释”。

③ 模块的进出信号接口尽量标准化（可以是比较“官方”的标准化，当然也可以是自定义的“草根”标准化），利于将来的复用。

④ 注释要清晰明了，不说废话，即便在一个代码源文件里，也尽量将各个不同的功能块代码“隔离”。

⑤ 配套文档和说明必不可少。

⑥ 信号命名尽量“中性”化。

比如某模块的时钟输入是25MHz，那么可以取个中性的信号名clk，而不需要取clk_25m，但必须在注释中标明频率。

这样做的好处是将来移植到时钟输入为50MHz或是其他频率的应用中，不必再费劲的改clk_25m为clk_50m了。