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了。