FPGA设计流程指南.doc

H:\精品资料\建筑精品网原稿ok（删除公文）\建筑精品网5未上传百度

FPGA设计流程指南

前言
本部门所承担的FPGA设计任务主要是两方面的作用: 系统的原型实现和ASIC的原型验证。编写本流程的目的是:
l 在于规范整个设计流程, 实现开发的合理性、 一致性、 高效性。
l 形成风格良好和完整的文档。
l 实现在FPGA不同厂家之间以及从FPGA到ASIC的顺利移植。
l 便于新员工快速掌握本部门FPGA的设计流程。

由于当前所用到的FPGA器件以Altera的为主, 因此下面的例子也以Altera为例, 工具组合为 modelsim + LeonardoSpectrum/FPGACompilerII + Quartus, 但原则和方法对于其它厂家和工具也是基本适用的。
V目 录
1. 基于HDL的FPGA设计流程概述 1
1.1 设计流程图 1
1.2 关键步骤的实现 2
1.2.1 功能仿真 2
1.2.2 逻辑综合 2
1.2.3 前仿真 3
1.2.4 布局布线 3
1.2.5 后仿真( 时序仿真) 4
2. Verilog HDL设计 4
2.1 编程风格( Coding Style) 要求 4
2.1.1 文件 4
2.1.2 大小写 5
2.1.3 标识符 5
2.1.4 参数化设计 5
2.1.5 空行和空格 5
2.1.6 对齐和缩进 5
2.1.7 注释 5
2.1.8 参考C语言的资料 5
2.1.9 可视化设计方法 6
2.2 可综合设计 6
2.3 设计目录 6
3. 逻辑仿真 6
3.1 测试程序( test bench) 7
3.2 使用预编译库 7
4. 逻辑综合 8
4.1 逻辑综合的一些原则 8
4.1.1 关于LeonardoSpectrum 8
4.1.1 大规模设计的综合 8
4.1.3 必须重视工具产生的警告信息 8
4.2 调用模块的黑盒子( Black box) 方法 8
参考 10
修订纪录 10

1. 基于HDL的FPGA设计流程概述
1.1 设计流程图

( 1) 设计定义

( 2) HDL实现

逻辑仿真器
( 3) 功能仿真

逻辑综合器
( 4) 逻辑综合

逻辑仿真器
( 5) 前仿真

FPGA厂家工具
( 6) 布局布线

( 8) 静态时序分析
逻辑仿真器
( 7) 后仿真

( 9) 在系统测试

说明:
l 逻辑仿真器主要指modelsim, Verilog-XL等。
l 逻辑综合器主要指LeonardoSpectrum、 Synplify、 FPGA Express/FPGA Compiler等。
l FPGA厂家工具指的是如Altera的Max+PlusII、 QuartusII, Xilinx的Foundation、 Alliance、 ISE4.1等。

1.2 关键步骤的实现
1.2.1 功能仿真

RTL代码

调用模块的
行为仿真模型

测试程序
( test bench)

测试数据

逻辑仿真器

说明:
”调用模块的行为仿真模型”指的是RTL代码中引用的由厂家提供的宏模块/IP, 如Altera 提供的LPM库中的乘法器、 存储器等部件的行为模型。

1.2.2 逻辑综合
设置综合目标和约束条件

调用模块的
黑盒子接口

RTL代码

逻辑综合器

HDL网表
( netlist)

EDIF网表
( netlist)

说明:
”调用模块的黑盒子接口”的导入, 是由于RTL代码调用了一些外部模块, 而这些外部模块不能被综合或无需综合, 但逻辑综合器需要其接口的定义来检查逻辑并保留这些模块的接口。

1.2.3 前仿真

逻辑综合器

调用模块的
行为仿真模型

测试数据

测试程序
( test bench)

HDL网表
( netlist)
逻辑仿真器

说明:
一般来说, 对FPGA设计这一步能够跳过不做, 但可用于debug综合有无问题。

1.2.4 布局布线

逻辑综合器

设置布局布线约束条件

FPGA厂家工具

EDIF网表
( netlist)

调用模块的
综合模型

SDF文件
( 标准延时格式)

HDL网表
( netlist)

下载/编程文件

1.2.5 后仿真( 时序仿真)

测试数据

SDF文件
( 标准延时格式)

FPGA基本单元仿真模型

测试程序
( test bench)
FPGA厂家工具

HDL网表
( netlist)

2. Verilog HDL设计
基于将来设计转向ASIC的方便, 本部门的设计统一采用Verilog HDL, 但针对混合设计和混合仿真的趋势, 所有开发人员也应能读懂VHDL。
Verilog HDL的学习可参考[1][2]。
2.1 编程风格( Coding Style) 要求
2.1.1 文件
（1） 每个模块( module) 一般应存在于单独的源文件中, 一般源文件名与所包含模块名相同。
（2） 每个设计文件开头应包含如下注释内容:
l 年份及公司名称。
l 作者。
l 文件名。
l 所属项目。
l 顶层模块。
l 模块名称及其描述。
l 修改纪录。
请参考标准示例程序[3]。
2.1.2 大小写
（1） 如无特别需要, 模块名和信号名一律采用小写字母。
（2） 为醒目起见, 常数( `define定义) /参数( parameter定义) 采用大写字母。
2.1.3 标识符
（1） 标识符采用传统C语言的命名方法, 即在单词之间以”_”分开, 如: max_delay、 data_size等等。
（2） 采用有意义的、 能反映对象特征、 作用和性质的单词命名标识符, 以增强程序的可读性。
（3） 为避免标识符过于冗长, 对较长单词的应当采用适当的缩写形式, 如用‘buff’代替‘buffer’, ‘ena’代替‘enable’, ‘addr’代替‘address’等。
2.1.4 参数化设计
为了源代码的可读性和可移植性起见, 不要在程序中直接写特定数值, 尽可能采用`define语句或paramater语句定义常数或参数。
2.1.5 空行和空格
（1） 适当地在代码的不同部分中插入空行, 避免因程序拥挤不利阅读。
（2） 在表示式中插入空格, 避免代码拥挤, 包括:
赋值符号两边要有空格;
双目运算符两边要有空格;
单目运算符和操作数之间可没有空格,
示例如下:
a <= b;
c <= a + b;
if (a == b) then ...
a <= ~a & c;
2.1.6 对齐和缩进
（1） 不要使用连续的空格来进行语句的对齐。
（2） 采用制表符Tab对语句对齐和缩进, Tab键采用4个字符宽度, 可在编辑器中设置。
（3） 各种嵌套语句特别是if...else语句, 必须严格的逐层缩进对齐。
2.1.7 注释
必须加入详细、 清晰的注释行以增强代码的可读性和可移植性, 注释内容占代码篇幅不应少于30%。
2.1.8 参考C语言的资料
要形成良好的编程风格, 有许多细节需要注意, 能够参考资料[4], 虽然它是针对C语言的讨论, 但由于Verilog HDL和C语言的形式非常近似, 因此里面提到的很多原则都是能够借鉴的。
2.1.9 可视化设计方法
为提高设计效率和适应协同设计的方式, 可采用可视化的设计方法, Mentor Grahpics的Renoir软件提供了非常好的设计模式。
2.2 可综合设计
用HDL实现电路, 设计人员对可综合风格的RTL描述的掌握不但会影响到仿真和综合的一致性, 也是逻辑综合后电路可靠性和质量好坏最主要的因素, 对此应当予以充分的重视。
学习可综合的HDL请参考 [5][6] [7]。
学习设计的模块划分请参考[8]。
2.3 设计目录
采用合理、 条理清晰的设计目录结构有助于提高设计的效率、 可维护性。建议采用类似下面的目录结构:
( 1)
design
src
( 源代码)
syn
( 综合)
sim
( 仿真)
par
(布局布线)

( 2)
design
ver1
ver2
src
( 源代码)
syn
( 综合)
sim
( 仿真)
par
(布局布线)
src
( 源代码)
syn
( 综合)
sim
( 仿真)
par
(布局布线)

3. 逻辑仿真
考虑到性能和易用性, 首选的逻辑仿真器是Mentor Graphics的modelsim。
3.1 测试程序( test bench)
测试程序对于设计功能和时序的验证有着举足轻重的影响, 测试激励的完备性和真实性是关键所在, 有以下原则须遵循:
（1） 测试激励输入和响应输出采集的时序应当兼顾功能仿真( 无延时) 和时序仿真( 有延时) 的情况。
（2） 对于周期较多的测试, 为提高效率, 尽可能采用程序语句来判断响应与标准结果是否一致, 给出成功或出错标志, 而不是经过观察波形来判断。
（3） 采用基于文件的测试是很好的办法, 即由matlab或spw等系统工具产生测试数据, 测试程序将其读入产生激励, 再把响应结果写入到文件, 再交给上述工具进行处理或分析。
（4） 仿真器支持几乎所有的Verilog HDL语法, 而不但仅是常见的RTL的描述, 应当利用这一点使测试程序尽可能简洁、 清楚, 篇幅长的要尽量采用task来描述。
3.2 使用预编译库
在进行功能仿真和后仿真时都需要某些模块的行为仿真模型和门级仿真模型, 如Altera Quartus里的220model.v( LPM模块行为仿真模型) 和apex20ke_atoms.v( 20KE系列门级仿真模型) , 为避免在不同的设计目录中多次编译这些模型, 应当采用一次编译, 多次使用的方法。具体做法如下( 以20KE门级库为例) :
1: 在某个工作目录下新建一库名 apex20ke, 将apex20ke_atoms.v编译到其中。
2: 在图形界面中的Load Design对话框中装入仿真设计时, 在Verilog 标签下指定预编译库的完整路径。( 见下图)

4. 逻辑综合
当前可用的FPGA综合工具有Mentor Graphics 的 LeonardoSpectrum, Synplicity的Synplify和Synopsys 的FPGA CompilerII/FPGA Express, LeonardoSpectrum由于性能和速度最好, 成为我们首选的综合器, FPGA CompilerII/FPGA Express由于能够和Design Compiler代码兼容也可用。见参考[9]
4.1 逻辑综合的一些原则
HDL代码综合后电路质量的好坏主要取决于三个方面: RTL实现是否合理、 对厂家器件特点的理解和对综合器掌握的程度。参考[10]中有比较全面的讨论。
4.1.1 关于LeonardoSpectrum
LeonardoSpectrum对综合的控制能力比较强, 但使用也略为复杂, 故需要在使用前尽量熟悉其功能, 才能取得较好的综合结果。
当出现综合结果不能满足约束条件时, 不要急于修改设计源文件, 应当经过综合器提供的时序和面积分析命令找出关键所在, 然后更改综合控制或修改代码。
在LeonardoSpectrum .1b以前的版本输出的 .v 网表都不能用于仿真。
4.1.1 大规模设计的综合
l 分块综合
当设计规模很大时, 综合也会耗费很多时间。如果设计只更改某个模块时, 能够分块综合。如有设计 top.v 包含 a.v和b.v两个模块, 当只修改a.v的话, 能够先单独综合b.v, 输出其网表b.edf, 编写一个b模块的黑盒子接口b_syn.v, 每次修改a.v后只综合top.v、 a.v、 b_syn.v, 将综合后的网表和b.edf送去布线, 能够节约综合b模块的时间。
l 采用脚本命令
当设计规模比较大时, 综合控制可能会比较复杂, 能够考虑采用脚本控制文件的方式进行综合控制, modelsim、 LeonardoSpectrum和Quartus都支持TCL( Tool Command Language) 语言, 采用脚本控制能够提供比图形界面更灵活和更方便的控制手段。
4.1.3 必须重视工具产生的警告信息
综合工具对设计进行处理可能会产生各种警告信息, 有些是能够忽略的, 但设计者应该尽量去除, 不去除必须确认每条警告的含义, 避免因此使设计的实现产生隐患。
这个原则对仿真和布局布线同样适用。
4.2 调用模块的黑盒子( Black box) 方法
使用黑盒子方法的原因主要有两点:
一是HDL代码中调用了一些FPGA厂家提供的模块( 如Altera的LPM模块) 或第三方提供的IP, 这些模块不需要综合, 而且有些综合器也不能综合( 如FPGA CompilerII/FPGA Express能够综合包含LPM的代码而LeonardoSpectrum不能) 。因此须提供一个黑盒子接口给综合器, 所调用的模块到布局布线时才进行连接。
二是方便代码的移植, 由于厂家提供的模块或第三方提供的IP一般都是与工艺有关的, 直接在代码中调用的话将不利于修改, 影响代码移植。
下面以调用Altera的LPM库中的乘法器为例来说明。调用这样一个模块需要这样一个文件: mult8x8.v( 可由Quartus的MegaWizer Plug-in Manager产生) , 代码如下:
// mult8x8.v
module mult8x8 (dataa, datab, result);
input [7:0] dataa;
input [7:0] datab;
output [15:0] result;

// exemplar translate_off
// synopsys translate_off
lpm_mult lpm_mult_component(
.dataa (dataa),
.datab (datab),
.aclr (1'b0),
.clock (1'b0),
.clken (1'b0),
.sum (1'b0),
.result (result)
);
defparam
lpm_mult_component.lpm_widtha = 8,
lpm_mult_component.lpm_widthb = 8,
lpm_mult_component.lpm_widths = 16,
lpm_mult_component.lpm_widthp = 16,
lpm_mult_component.lpm_representation = "SIGNED",
// exemplar translate_on
// synopsys translate_on

endmodule