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