可维护，可移植的verilog工程设计技巧

       忙碌的一年即将结束了，去年对我来说有痛、有纠结、有忙碌、有喜悦、有快乐、有幸福，如五彩丝绸一般，极度绚烂的一年！
        从我们创业以来，很多朋友送来支持和祝福，当然，也有很多朋友担心我会慢慢放弃技术这条路，会停止我之前一直进行的技术经验共享。
        2013年的确很忙，但我仍然抽空写了几篇技术文档和经验感受分享。可毕竟一个人的精力有限，我一个人的经验分享改变不了什么……最早的时候我分享设计，但后来想授人鱼，不如授之以渔，于是开始分享设计思路和经验；但现在想来，分享设计思路和经验，不如分享自己乐于总结和分享的理念，在这个层面上，鱼和渔又有了新的指代。
        现在，我们有了公司，公司技术大咖小咖都支持我的做法，开始了技术经验的总结。我会从中选出一些技术含量较高，质量好的跟喜欢电子的朋友们一起分享。我不知道我们的公司能存活多久，但我们坚持着从事科技前沿的东西，我们的目标不只是单纯的赢利，我们还可以把更多前沿的技术带给更多的人。
        下面附件是我们团队一位“神秘咖”总结的FPGA设计技巧。因为分工配合的需要，他刚刚转入FPGA开发不久，用他的话说，等以后写的文档水平能被他自己认可了，才署名……我觉得这篇文档质量挺高，可以看出总结整理的非常用心，很适FPGA刚入门的朋友们参考。

完整的pdf文档下载： 可维护，可移植的verilog工程设计技巧.pdf (241.29 KB, 下载次数: 26)

2016-4-15 01:54 上传

点击文件名下载附件





--------------------------------------------------------------
以下是pdf部分内容预览：

TIDERIP——新手上路 A

随着集成电路发展的脚步，28nm 技术已经大规模应用在 FPGA 领域，FPGA 开发者面 临着日趋庞大的系统设计。笔者也在这段时间开始接触带有硬核ARM 的 Cyclone V，Quartus 也华丽丽地升级到了 13.1 版本。随着硬件平台及开发环境的更迭，项目版本的更新，深深 感觉到代码的可维护性，可移植性异常重要，所以写下这篇笔记，笔者接触 FPGA 的时间 并不长，水平有限，就当做抛砖引玉吧。

一，工程设计层次化，结构化

要编写可维护、可移植的工程首先要对设计进行层次化、结构化设计。不要急于 Coding，先整理思路，做好体系结构和模块的划分。一个设计任务需要按照功能或者类别分 成若干个可独立操作的模块，每个模块又可以细分下去，这样可以由若干名工程师同时设计， 当然也可以选用商业模块。通过这样的逐次分解与模块的例化，整个工程能以设计树的方式 绘出。

如图 1 所示：

这样的设计在后期维护以及移植的时候可以根据具体要求更新部分模块，尽量少地改 变其他部分的代码和时序。（由于 FPGA结构的原因，即使修改部分模块，也会对整体的布 局布线造成改变，需要对时序进行约束，而这又是另外一个课题了）

二，模块及例化 设计要做到可维护，可移植，对底层模块的要求较高，要求尽量做到功能独立、可重入。

功能独立便于移植裁剪、系统维护的时候可以只对部分模块进行修改。而模块的重入性

越高，维护和移植的时候修改的代码量就越小，只对底层模块修改即可，上层行为级模块可 不做修改。

Verilog 中以例化的方式调用其他功能模块，与 C 语言等软件函数调用不同的是，硬件 描述语言的例化是实实在在的电路，同一个功能模块的多次例化分别是独立的实体，而不是 软件函数简单的复用。所以，上面的两种设计技巧只是从 coding 的方面考虑问题，而 FPGA 向来要求从硬件的角度去考虑问题，底层模块的修改，意味电路结构，布局布线，时序都发生了变化，可维护性和可移植性在硬件的角度需要更多考虑。详细的例化语法这里不做详述，大家可参考夏宇闻老师的《verilog 数字系统设计 教程》。

Verilog 模块有两种编辑方法：原理图输入和 verilog 代码输入方式。原理图输入的方式

胜在结构清晰，而代码输入方式则更便于移植和仿真。(一般我们都用 Modelsim进行仿真， 目前还无法对原理图输入的方法进行仿真。不过可以把原理图转换成 verilogHDL文件再进 行仿真，方法是菜单栏 File-->Creat/Updata-->CreatHDLdesignfilesformcurrentfile）

三，Parameter 参数传递

Verilog 中可以用 parameter 定义一个标识符代表一个常量，有助于提高程序的可读 性，同时也方便了模块例化的可维护性和可扩展性，简单举例：可以对总线的位宽进行 parameter 的定义，这样就可以很方便地修改总线容量。由于它是 verilog 所特有的参数传递 方法，我们在这里详细说明一下，Parameter语法格式如下：

parameter 参数名 1 = 表达式, 参数名 2 = 表达式,  .......  参数名 n = 表达式；

（这里建议参数名使用大写字母，方便和变量区分开,而表达式必须是常量表达式。）

举例

module Box( X,Y);

parameter LENTH = 100, WIDTH = 50, HIGH = 25;

......

...... endmodule

以下是在 verilog 文件中例化模块时传递参数常用的两种方法：

1、module_name #( parameter1, parameter2) inst_name( port_map);

例如例化上面模块 Box              #(80,40,20)              box_1( X1, Y1) ;

Box_1 中实际引用的 LENTH , WIDTH, HIGH 分别为 80,40,20。

2、defparam

defparam heirarchy_path.parameter_name = value;

还是用上面的例子：

module Top( X,Y);

Box box_2( X2,Y2);

endmodule

module Annotate;

defparam

Top.box_2. LENTH =80; Top.box_2. WIDTH =40; Top.box_2. HIGH =20;

endmodule

Box_2 中实际引用的 LENTH , WIDTH, HIGH 分别为 80,40,20。

在原理图文件中传递参数的方法比较简单，例化的 Box 模块如下图，参数以表格的方 式在例化的 block/symbol 旁边出现，我们只需要修改表格中的值就可以了。

（这里需要注意的是，如果在表格中修改了参数的值，即使我们修改该模块的源文件中 parameter的初始值，再重新生成 block/symbol，然后 update原理图中的该 block/symbol，也 无法改变实际使用中引用的 parameter的值，也就是说，一切以表格中的值为准）

四，宏定义 和 条件编译

`define 宏定义对系统的可维护，可移植上的作用和 parameter 类似，区别是两者的作 用域不同，parameter 作用于声明的那个文件，`define 从编译器读到这条指令开始到编译结 束都有效，或者遇到`undef 命令使之失效。（还有一个小区别是 parameter前面没有“`”）

`define 和 C 语言上的 define 用法很类似，所以在这里不作详述。 条件编译常常和宏定义配合使用，用来对一部分程序内容进行选择性编译。语法如下：

`ifdef 宏名（标识符） 程序段

`endif

条件编译可以很好地增强程序的可移植性，比如 Verilog 代码中的一部分可能适用于某 个编译环境，但不适用于另一个编译环境。如设计者不想为两个环境设计两个版本的 verilog 设计，就需要对部分代码进行条件编译。

五，代码可读性 代码的可读性不会影响到程序的功能，但是维护和移植的工作毕竟要人来做，所以能

以更少的时间读懂代码，就能更效率地完成工作。在使用 verilog 进行 Coding 的过程中，以 更少的代码，完成更多的工作，并不一定表示代码的效率更高，因为编译器和综合器会对代 码进行优化。

代码的可读性要求写代码要规范，风格统一，注释简洁，verilog 的风格和 C 语言类 似，所以在此我不对代码规范作过多的笔墨，大家有兴趣可以参考Altera 官网上的 Code style 相关的 PPT。

（我个人的一个设计小习惯是在工程中新建一个文本文档，菜单栏 File-->New-->Textfile，在这个文档中详细记录一些设计思路和版本更新记录，配合代码中的注释，可以很快 对工程进行深入理解）

原理图输入才是 FPGA 设计与其他编程语言不一样的地方，所以我详细的讲一下如 何在 Quartus 中完成可读性更高，条理结构清晰的原理图输入方式，下面简单介绍下如何使 用原理图输入的方式完成图 1 的设计：

底层功能模块还是采用 verilog 代码输入，如图 1 所示的模块 A1,A2,B1,C1,C2，需要 将它们生成 block/symbol 以方便原理图输入的时候例化，方法是在工程管理器窗口的 file 页 右键点击要生成 block/symbol 的文件，选择 Creat symbol files for current file。如图 2

图 2 verilog 文件生成 block/symbol

图 1 所示的中间模块 A,B,C 同样采用原理图输入方式，可以使用底层模块刚刚生成 的 block/symbol。方法为双击原理图的空白处，在弹出的窗口中，双击 library 中 Project 目 录下的 block/symbol

图 3 放置 block/symbol

以模块 A 为例，需要例化 A1,A2 模块，根据功能连接，并放置输入输出端口（方法： 可在图 3 所示的 name 输入 input 放置输入端口，输入 output 放置输出端口），图 4 是编辑完 的模块 A:

图 4              模块 A

模块 A 的原理图编辑完成后，也需要生成 block/symbol 以便顶层模块 Top 例化，方法 和底层模块生成 block/symbol 的方式不同，需要在该原理图为当前页的时候，在 Quartus 菜 单栏选择 File，在 File 的下拉菜单中选择 Creat/Updata 中的 Creat block/symbol files for current file，将会在工程目录下生成和模块同名的.bsf 文件。如图 5 所示

图 5 原理图文件生成 block/symbol

之后就可以在顶层模块的原理图文件中添加相应 block/symbol 了。图 1 中的模块 B,C 可以选

择同样的办法。

顶层模块选择采用原理图输入，例化 A，B，C 后，加入相关功能逻辑和端口后完成 全部设计，如图 6：

图 6 顶层模块 Top

在顶层模块原理图中，只有模块 A,B,C 可见，结构简单。可以双击 A,B,C 任一模块 就可以看到下一层的构成，由此可见系统层次分明，有助于对系统的理解和维护。

原理图输入的方法更贴近硬件工程师的思维，所以层次感很强，对系统理解也没有 verilog 代码文件那么抽象。但是构建可维护，可移植的设计思想和什么方式输入是没有关 系的，模块 A,B,C 以及 TOP 使用 verilog 代码输入的方式也同样能实现相应的功能，关键是 对模块功能的理解及分类，这无关于编辑和例化模块的形式。