FPGA入门之我见-foreveryoung的笔记
转自：http://www.cnblogs.com/foreveryoung/
|
1.写在前面 很早就想写这么篇短文，和大家交流学习的些许经验和心得。但一直有各种干扰，致使一拖再拖，这阵子赶上米国佬过圣诞，咱也忙里偷闲，赶紧把这篇短文码掉。。嘿嘿。 2.为什么要写 群里时常有新人呈周期性的问诸如，“我该如何学HDL？”，“非阻塞和阻塞有啥区别？”之类的问题。在此，笔者扯两句自己的学习体会，对这些问题一并予以回答。
3.English required 英文资料不一定能培养出优秀的FPGA工程师，但拒绝英文资料的工程师至多是个合格的工程师。
如图所示，纵轴代表综合水平，横轴代表时间，理论决定了由经验带动的水平提升的上限。而如果能经常参考英文资料，上限可以适当提高，如图中的虚线。 在一开始便强调英文的重要性是因为学习FPGA第一手的资料是大量的官方资料，如tutorial，user guide，cock book，handbook，application note，white paper等。 读者不能指望永远参考翻译的二手资料吧，何况很多还都严重脱节行业发展现状。
4.FPGA不是单片机 关于这点，很多人反复强调，但遗憾的是，把FPGA当单片机玩的人仍前赴后继。笔者琢磨着有可能是入门方法有误。 回想一下我们是咋学单片机的？买一本教材，了解一下IO口和控制字，然后开始画流程图，用C编程，做各种经典实验。 而当转到FPGA时，很自然的会借鉴“单片机模式”，买一本HDL的书，发现Verilog和C长还挺像，很轻松的啃完HDL，然后就开始“编程序”。待编完后，一点按钮，一口气从综合做到PAR（ISE和QuartusII都能一个按钮跑整个flow），然后仿真。仿真OK？皆大欢喜。不OK？改code。咋改？不清楚。 这个过程中最大的问题在于把FPGA最大的硬件本色当成黑盒处理：黑盒的输入是code，输出是仿真。 当把黑盒漂白成白盒，大致知道这盒子里有些啥，干了些啥，那在笔者看来才算是入门了。漂白粉是啥同志们应该猜到了：FPGA的结构。 推荐阅读： a) 采用Cyclone与Cyclone-II系列器件进行设计.pdf b) altera: Cyclone II Device Handbook.volume1 c) xilinx: ug380~ug389(spartan6)
5.HDL不是C，结构决定HDL 上面说到FPGA的结构是漂白粉，这节承接上文继续： 时序逻辑的敏感列表为啥只能有时钟和复位？如下： always@（posedge clk or negedge rst_n） 而不能再加个使能： always@（posedge clk or negedge rst_n or posedge CE） 也不能双沿触发： always@（posedge clk or negedge clk） 也不能沿触发 + 电平触发： always@（posedge clk or gated_logic） 这一切究竟是为啥呢。。 无他，结构如此。下图是cycloneII的一个基本单元LE（logic element）：
右下角那个寄存器看到了吧，单沿触发，异步复位，同步使能。所谓结构决定HDL也。 顺便再看一下寄存器的复位端有个小圆圈，表示低电平复位，所以我们这样写： always@（posedge clk or negedge rst_n） 再截个spartan3E的：
看出点名堂了吧。xilinx的寄存器是高电平复位，所以如果你是xilinx用户，那就要这样写： always@（posedge clk or posedge rst_n） 再来说一个经典的模型：FSM。为什么FSM推荐使用one-hot编码？如果读者有兴趣，可以做一个实验，会发现one-hot的解码电路一般都是小于4输入，也就是能用一个4输入LUT搞定。假设FPGA中的LUT是100输入，那即使解码电路再复杂点也能hold住了不是。 推荐阅读： a) 设计与验证：Verilog HDL。 b) Verilog HDL 程序设计与应用 王伟编 c) Clifford E. Cummings的论文，http://www.sunburst-design.com/papers/ d) 大唐电信FPGACPLD数字电路设计经验分享
6.掌握主动权 由于综合器的算法限制，只有当我们的HDL满足一定的coding style，才能映射出我们想要的东西，比如前面说的对寄存器的建模对敏感列表的限制和要求。而有些复杂元件要求的coding style则更复杂，比如memory、乘法器。 这时更好的选择是直接调用软件提供的各种module，altera使用megawizard，xilinx使用core generator。这样不但直接告诉综合器我想要的是什么，把解释权掌握在设计人员自己手里，而且由于这些module一般都是经过优化（基于器件）后的网表，性能上会比自己写的更好，更灵活。 当然调用module也意味着在不同vendor之间转换将成为一个额外的问题。所以有些设计为了兼容各家的产品而故意不使用module。 到这里为止，经常是新人止步的地方，即所有的精力和视野都放在数字前端。要成为高手，后端的内容具有一票否决权。
7.综合（synthesis）与映射（mapping） 由于synplify廉颇老矣，外加两家vendor，altera有了自己的Qis，xilinx有了自己的XST，使得整个设计流程都已经高度集成化。集成化带来了方便，相对的也容易使刚入门的人犯晕。在此笔者不多做解释，直接上图比较，相信能说明问题。 *************************************************** module training(clk, rst_n, ce, ina, inb, outa); input clk; input rst_n; input ce; input ina; input inb; output outa; reg ina_reg1; reg ina_reg2; reg ina_reg3; reg inb_reg1; reg inb_reg2; reg inb_reg3; reg outa; always@(posedge clk) begin ina_reg1 <= ina ; ina_reg2 <= ina_reg1 ; ina_reg3 <= ina_reg2 ; inb_reg1 <= inb ; inb_reg2 <= inb_reg1 ; inb_reg3 <= inb_reg2 ; outa <= ina_reg3 & inb_reg3; end endmodule *************************************************** 在altera中综合后：
映射后：
而同样的code在xilinx中综合后：
映射后：
可以看出两家vendor综合的结果是一样的，这时还没对应到具体的FPGA底层上，只是RTL级的网表。 但映射后就明显不同了，altera使用的是多个常规的寄存器，而xilinx使用的是SRL16移位寄存器（当然不是说xilinx就更好，只是这个特列更利于xilinx特性的发挥而已）；并且出现了buffer和LUT，说明映射后的网表已经对应到FPGA的底层结构上了，这时才真正具有FPGA特色。 从映射开始便进入了非新人（不一定是高手，但一定不是刚入门的）的专属领域，即数字后端。 推荐阅读： a) 逻辑综合器的故事
8.布局布线（place & route，PAR） 前几天有人问笔者：用chip planner看布局布线后的网表，为啥有些逻辑放得很近，有些放的远。 一般来说这个问题没有标准解，因为PAR具有一定随机性（seed，effort level等都会影响，甚至HDL中的一个小小改动都会影响）。当然也有一些常见的原因，比如：
上图的寄存器就处于左右为难，里外不是人的纠结状态。。 推荐阅读： a) 2011.2.25_增量编译 by foreveryoung
9.时序 还有人还问了笔者一个问题，IO时序不太理想，怎么优化？笔者的回答是首先先做IO的register packing。而能这么做的基础是IOB中有一个寄存器专门负责处理这种情况的。还是那句话，如果了解FPGA的结构，这些问题将不再是问题。 说到时序，当然要说静态时序分析（static timing analysis，STA）。不是所有时序问题都需要做时序约束才能解决，但是不了解时序分析的基础知识，很多要求的coding style是无完美解释通的。 比如，都在说少用if-else，而要用case，为啥？答曰，因为逻辑层级少。那为啥逻辑层级少更好？ 又比如，关于异步复位，大都处理成异步复位同步释放，那么为什么这种结构能有效解决亚问题的问题？ 再比如，有些初学者不习惯使用PLL，而喜欢用寄存器计数分频或者门控信号作为时钟，即通常所说的ripple clock和gated clock。为什么在FPGA设计中不推荐这两类时钟？ 如果有时序分析的基础，这些问题能得到很直观的理解和体会。 第八点和第九点只是告诉刚入门的新人，有这么个东西，等入门了以后表忘了有这么个领域需要攻克。 推荐阅读： a) 通向FPGA之路---七天玩转Altera之时序篇V1.0 b) 时序优化实验部分 V1.0 by foreveryoung 9.广告 以下是我做的一些笔记。 a) 2011.2.25_增量编译 by foreveryoung b) Netlist Viewer by foreveryoung c) 通向FPGA之路---七天玩转Altera之基础篇V1.0 d) 通向FPGA之路---七天玩转Altera之时序篇V1.0 e) 通向FPGA之路---七天玩转Altera之验证篇V1.0 f) 状态机设计 by foreveryoung V2.0
后记： 上文提出了很多为什么，笔者没有直接给出答案，留给读者自己探索了。如果想就这些问题进行进一步交流，请加群：91968656。当然，除去因相关理论不足导致的问题，很多时候当有疑问时，首先因做的是自己尝试，然后通过观察RTL viewer或technology map viewer，仿真等手段验证。所谓大胆假设，小心求证。 好了，笔者原还想扯一下优化，但转念一想，已经扯了九点，九乃大数，便作罢。而且一次扯太多容易让人产生疲倦感。故本文到此为止。下次有机会再补充。 完 2011.12.25 foreveryoung 上海 posted @ 2011-12-25 13:17 foreveryoung 阅读(1160) 评论(7) 编辑
2011年4月14日 #
3.1 介绍 SignalProbe是唯一不需要使用JTAG的调试工具。由下图可以看出，相比于直接在工程中引出一个测试引脚，SignalProbe不改变原有设计。同时SignalProbe使用多余的IO引脚来输出信号。
一般在以下几种情况使用SignalProbe： （1）有外部测试设备的存在； （2）目标设计器件为FPGA或者CPLD； （3）器件内部资源剩很少或者根本没有剩余； （4）有剩余的IO引脚； （5）无需等待过长的编译时间，很容易将内部信号布线到调试端口； （6）无需JTAG。 以前的设计一般都保留有测试引脚，调试阶段这些调试引脚成为了设计的一部分，而使用SignalProbe可以尽量使测试和设计分离。 使用SignalProbe好处有： （1）简单易用； （2）Fitter来处理SignalProbe的信号布线，所以设计者只需指定源节点（sourece node）和目标引脚即可，编译报告会报告从内部节点到引脚的延迟时间。 （3）加入SignalProbe后不会影响已编译的设计的布局，被测试的信号的Fmax不会改变，布线可能会有些许更改。 （4）可以结合增量编译，节省编译时间。 总的来说，SignalProbe进行调试是设计没有留JTAG的无奈之举，但是有些场合不支持SignalTapII的CPLD则只能选择SignalProbe。而且当器件的资源利用率很高，即已经没有足够的资源在设计中加入SignalTapII的时候也只能选择SignalProbe。当然SignalProbe有个最大的好处除了占用很少的资源外就是设计无需重新编译，适配器会完成探测源和目标引脚之间的布线，而且重新全编译之后原来加入的SignalProbe会自动消失。 SignalProbe的主要使用步骤如下： 1）保留足够的测试引脚； 2）编译设计（可选），如果设计已经全编译，则无需编译； 3）分配SignalProbe source； 4）如果需要加入流水线寄存和时钟； 5）执行SignalProbe编译； 6）Program device； 3.2 设计流程 （1）全编译 使用SignalProbe之前需要全编译工程。打开SignalProbe Pins，如图。
下图为SignalProbe Pins的界面。【Current and potential SignalProbe pins】栏中Number列出的为未使用的引脚，选择合适的引脚作为探针输出。
（2）分配SignalProbe source 本节主要论述【SignalProbe pin settings】栏的【Pin name】和【Source】。 【Pin name】： Pin name是所设置的输出引脚的名字，Node Finder里的Filter选Design Entity（默认）。选择好以后注意改名，因为他和被选择信号的名字重复会导致出错；也可以不用Node Finder而直接命名。
【Source】： Source node name—Specifies the signal name that you want to route to the SignalProbe output pin in the Current and potential SignalProbe pins list. Source可以是组合逻辑的节点（node）、寄存器、LEs 、 Memory block、 DSP block outputs或者后适配网表的引脚（pin）。有些内部节点可能无法找到，因为该节点可能在综合时被优化掉，或者该节点无法布线到SignalProbe的引脚。在Source栏的Node Finder里的Filter选SignalProbe（默认）。
（3）增加流水线寄存器 可以手动设置从SignalProbe Source到SignalProbe Pin的寄存器个数来同步数据和控制SignalProbe输出的恢复时间（latency）。SignalProbe自动把他们插入其布线路径中。 当添加了寄存器后，SignalProbe会尝试对寄存器进行布局来满足时序：把寄存器放置在靠近SignalProbe Source的地方来满足Fmax的要求，放置在靠近IO的地方来满足Tco的要求。如下图所示。
如需要设置上述寄存器，在SignalProbe Pins里勾选【SignalProbe enable】。
参数说明： Clock—Specifies the clock signal name to use as a clock to register the output of the SignalProbe node. You must specify a clock signal name and the number of registers to use if you want to register the output of the SignalProbe node. Registers—Specifies the number of registers to insert before the output of the SignalProbe pin. You must specify the number of registers to use and a clock signal name if you want to register the output of the SignalProbe node. （4）确认 设置好上述参数，点击
3.3 执行SignalProbe编译 （1）SignalProbe编译 通过SignalProbe编译来对设置好的SignalProbe引脚进行布线。当前设计的布局布线仍保留。SignalProbe编译完成如下功能：
选择Processing -> Start -> Start SignalProbe Compilation
查看Tecnology Map Viewer。选中dataa[0]_test，右键->filter，选source。如下图所示，探针已经加入。
（2）分析SignalProbe布线错误 下面提到的问题可能导致编译出错： （1）SignalProbe source到SignalProbe引脚之间因布线拥挤（routing congestion）而无法布线。 （2）添加的SignalProbe source不存在或无效。 （3）输出引脚不可用。 如果布线拥挤导致无法编译成功，可以在SignalProbe Pins里勾选“Modify latest fitting results during SignalProbe compilation”。不过此设置会改变原设计。 （3）理解SignalProbe编译结果 涉及到SignalProbe的编译报告有两处： （1）The fitting results and status
（2）The timing results
posted @ 2011-04-14 13:12 foreveryoung 阅读(266) 评论(1) 编辑
2011年4月11日 # 前言：在《基础篇》和《时序篇》之后是《验证篇》，但考虑到之前两篇收到的反馈有限，故把第三篇《验证篇》拆分为若干段分批发于博客，希望能依次带动互动。 1. 验证及调试工具介绍 Altera提供了如下七种验证调试工具： （1）SignalTapII Logic Analyzer 可以在系统分析器件内部节点和I/O引脚信号。SignalTapII使用FPGA资源，根据用户定义的触发条件将信号数据通过JTAG接口显示在SignalTapII文件中。使用前需要确保有足够的片上存储器资源，也因此不支持CPLD。 （2）SignalProbe 可以在系统分析器件内部节点和I/O引脚信号。SignalProbe使用剩余未用的器件布线资源和IO资源，在最近一次布局布线的基础上进行增量式地布线，将选定信号送往外部逻辑分析仪或示波器。适用于片上存储器资源不多的情况。 （3）外部逻辑分析仪接口（LAI） 可以在系统分析器件内部节点和I/O引脚信号。如果片上存储器资源有限，并希望用外部逻辑分析仪来验证大量内部的数据总线，可以使用LAI。 （4）In-System Sources and Probes 使用JTAG来驱动和采样内部节点的逻辑值。当系统还不完整的时候可以利用该工具模拟众多的输入激励。 （5）In-System Memory Content Editor 用来显示和编辑片上存储器。 （6）Virtual JTAG Altera提供的一个IP核，使用器件逻辑资源实现JTAG接口电路的功能。 （7）系统控制台（system console） Tcl控制与实例化的硬件模块的通讯。用于系统级调试。 以上除SignalProbe，其余的调试工具都需要使用JTAG来控制和读写数据。
以下把七个工具分两类进行大致的比较。 （1）SignalTapII、LAI和SignalProbe用来查看RTL网表里的信号。 任何需要使用JTAG的调试工具都需要使用大概200个逻辑单元（LEs）来搭建平台。如果同时使用多个调试工具，此部分逻辑可以共享。 除此以外，SignalProbe只使用少量布线资源，不使用逻辑和存储器资源，信号和引脚成一对一的关系； LAI使用少量逻辑资源，不使用存储器资源，信号和引脚成多对一的关系，一个测试引脚最多可对应256个信号； SignalTapII需要使用逻辑和存储器资源，使用量的多少由采样信号的数目和触发条件的复杂程度决定（基本触发条件一般使用300到400个LE，每添加一个节点增加大约11个LE），但不使用除JTAG以外的其他引脚。
（2）In-System Sources and Probes、Virtual JTAG、System console和In-System Memory Content Editor除了能查看RTL网表里的信号外，还允许在运行的时候输入值。 Virtual JTAG让高级用户可以开发定制的JTAG平台；In-System Sources and Probes适用于调试控制信号；In-System Memory Content Editor适用于输入大量测试数据。 posted @ 2011-04-11 11:46 foreveryoung 阅读(238) 评论(0) 编辑
2010年12月31日 # 说明： 由目录可见，贴出的仅为时序优化的实验部分，还有理论部分仍在翻译和整理完善过程中。如果本文反响良好，则预计于1月中旬发布。本实验全程翻译altera官方提供的实验手册和工程，除了翻译外，还把原文中关于“很明显，你可以看见。。”替换成图片，毕竟无图无真相。 又官方提供实验为QuartusII 8.0平台，我使用的是10，故适当更改了一些内容，如大家使用的平台不同，稍作修改即可。 由于本文为初稿，可能翻译略显粗糙，欢迎拍板！ 2010.12.31 foreveryoung QQ：298467204 Email：sunyibin1987@hotmail.com 目录： 3.4 实例解析 3.4 实例解析 提供两个例子来说明如何在实际工程中进行时序优化。 3.4.1 General Timing Optimization
本例工程名lab_design，使用POS-PHY level 3连接两个系统。当数据由POS-PHY level 3 receiver接收后，“packet check”模块计算数据包是否正确。之后数据包经过FFT和一系列FIFO（使用一个外部FIFO来增加存储容量），算送给另一个设备。 本例中有三个时钟域，一个100Mhz的外部时钟域，一个195Mhz的内部时钟域，一个133Mhz时钟域（驱动外部FIFO）。 3.4.1.1 Step 1: Open project and compile 1．全编译工程。查看Compilation Report，如下图所示，Timequest Timing Analyzer目录下的Setup Summary报告SCLK时钟域出错。
3.4.1.2 Step 2: Run report to Analyze failing paths in TimeQuest to determine cause 1．打开TimeQuest
1．从Tasks栏选择Report Timing，运行一个SCLK时钟域的setup analysis report。 按如下填写： To clock SCLK Analysis type Setup Paths (Report number of paths) 200 Output (Detail level) Summary
得到的报告如下，全是错误。初看可能全无头绪。
可以用以下三条建议来查找并优化时序：
3.4.1.3 Step 3: Fix parity checking logic failures 第一个需要修复的路径是驱动奇偶校验器检错电路的逻辑。 1．点击“From Node”栏，前四个列出的如下图：
右键第一条路径，选择Report Worst-Cast Path。在Statistics栏里可以看到logic level有12条，再看Data Arrival Path栏里的计算可见，这么多logic level贡献了大部分的时序违规。
2．接下来，可以通过Technology Map Viewer验证之前的分析。在Data Arrival Path右键选择Locate Path，如图。
由上图可见，在last_data和parity_error两个寄存器之间有12个logic level，这很好的验证了本章小节“3.3.1 Too many logic levels”所述情况，解决方法如下：
3．在用上述方法修正时序违规之前，有必要先确认fitter的布局没有问题。这可以通过Chip Planner查看。同样在Data Arrival Path右键选择Locate Path，选择Chip Planner。 右下图可见，本条路径中所有的nodes都在两个相邻的Logic Array Blocks（LABs）中，只有一些走线穿过其中。这是个很好的布局，所以可以确定问题处在过多的logic level上。
4．为了修复这条路径，可以增加pipeline registers。这是个可行的解决方案，因为本设计中当校验出错时，出错信息不需要立即被捕获，即延时几个时钟周期是可接受的。具体的实施步骤是在源代码中增加寄存器，减少logic level。 5．更改好源代码。
再次全编译。打开Timequest。选择Tasks栏下的Report Timing。按如下填写： To clock SCLK To [get_pins iPACKET_CHECK|parity*|datain] Analysis type Setup Paths (Report number of paths) 20 Output (Detail level) Summary 通过报告可以发现，本路径已经时序收敛。 3.4.1.4 Step 4: Fix remaining timing failures 1．再次从Tasks栏选择Report Timing，运行setup analysis report。按如下填写。 To clock SCLK Analysis type Setup Paths (Report number of paths) 200 Output (Detail level) Summary 点击“To Node”栏，可见许多时序违规的路径都有一个同样的To Node，即sop_error（packet error flag的起点），这个信号来自receiver block的FIFO地址寄存器。这表示这些时序违规可能可以一次全部修复。
右键上图第一条路径，选择Report Worst-Case Path。从Statisitcs栏中观察到logic level只有3级，故问题可能不在这里。
2．在Data Path栏中右键，Locate Path，选Technology Map Viewer。
由上图可见，本路径由一个RAM block和3级logic，说明问题不是“3.3.1 Too many logic levels”所述logic level太多。 再次观察上图，图中RAM输出的路径由3级组合逻辑组成，换句话说，总的register-to-register delay包括RAM block和3级组合逻辑。这可能是问题所在。 3．再次观察Data Path，如下图，观察第六行最大的一个延时（3.374），显示的Type是cell delay，表示这个延时是通过一个cell的延时。从Location和 Element可知，这个cell是M4K memory block。 这条路径不能像上节那样手动加寄存器，因为RAM是一个MegaCore，无法手动修改，用多周期约束可以修复这条路径，但是功能上可能会出错。 故排除上面两种方法后，可以使用物理综合的register re-timing，当然使用此功能将导致编译时间的延长。
4．打开物理综合。使能Perform register retiming。
再次全编译。打开编译报告，可见时序全部收敛。
3.4.2 Timing Optimization using PLLs 本例讲述如何使用PLL来改善时序结果，本工程实现一个二维离散余弦变换（two-dimensional discrete cosine transform：DCT）。 3.4.2.1 Step 1: Open project and compile 1．全编译工程。查看Compilation Report。打开TimeQuest Timing Analyzer栏，在Setup Summary里发现时序违规。
3.4.2.2 Step 2: Analyze failing path in TimeQuest 1．打开Timequest，按如下操作。
由上图可知，前23条路径违规，这些路径都在输出（dct_out和data_valid）和驱动输出的寄存器之间。而且他们都超过1ns。据此可以看看输出寄存器是不是布局良好。 2．选中第一条路径，右键，Report Worst-Cast Path。
可见不是“3.3.1 Too many logic levels”所述logic level过多造成的时序违规。 3．也不是“3.3.2 Fan-out signals”所述的Fan out太多造成的时序违规。
4．也不是“3.3.3 Conflicting physical constraints”所述的物理约束冲突造成的时序违规。因为查看第五行，选中它所对应的data_valid~reg0，右键Locate Path，选Chip Planner。
下图区域为IO区，data_valid~reg0放置在IOC_X0_Y20_N1（在IO cell block中），这表示这个寄存器已经放置在离设备IO最近的位置（能保证最好的输出建立时间）。
5．也不是“3.3.4 Conflicting timing assignments”所述问题。因为本例的SDC文件中只约束了IO和clock。而如果有牵涉到此寄存器布局的内部约束，他应该是倾向于把寄存器拉出IO cell。 6．排除以上四种情况后，可以初步判断问题是在“3.3.5 Tight timing requirements”
部分引用“3.3.5 Tight timing requirements”所述内容，我们可以加多周期约束，或者重新计算时序约束以验证是不是过约束（比如output maximum delay）。本例采用的是用PLL来对output clocks进行移相。 3.4.2.3 Step 3: Add PLL and synchronization register and analyzer timing
图中的two_d_dct_new模块即原来的设计，本节在此基础上加了PLL来驱动此模块。PLL的c1输出clk_out。 1．全编译工程。从Compilation Report中的Timequest Timing Analyzer栏中可见时序都收敛了。 因为PLL可以有效减少clock tree delay，使设计中的clock-to-output时间减少，output delay时序也收敛了。 2．通过查看报告可以验证。打开Timequest，还是选择Tasks栏中的Report Timing。
To栏填data_valid； Detail level填Full Path；
由上图可见，第7行的PLL贡献了一个-5.049ns的移相，这把data arrival time减小到足够满足设计输出的setup time时序要求。 posted @ 2010-12-31 12:22 foreveryoung 阅读(610) 评论(3) 编辑
|
浙公网安备 33010602011771号