FPGA开发流程及编程思想.ppt

FPGA开发流程及编程思想,简化的开发流程,需求定义,设计输入,设计综合,设计实现,配置下载,功能仿真,系统测试,设计验证,实际的开发流程,需求定义,设计输入,设计综合,设计实现,配置下载,综合结果分析,实际电路验证,静态时序分析,时序仿真,系统整合验证,功能仿真,需求定义,需求决定设计 “这个设计是做什么用的？” “要实现什么功能？” “有什么要注意的地方？” 需求是容易发生变更的 大师说过，没有哪个设计需求更改少于三次的，唯一一次只更改过两次需求的情况，是那个可怜的家伙在送第三次变更需求来的路上，被车给撞了。 你不能决定需求是否发生变更，但你可以做到当需求更改时，你所需要做出的调整最小。,原理图输入（对大型设计很少使用） 硬件描述语言VerilogHDL，VHDL HDL语言是硬件描述语言，不是硬件设计语言 用硬件电路设计思想来编写HDL,先有鸡，还是先有蛋？,always(posedge clk) if(!rst_n) a = 8b0; else a = a + 1b1;,？ 是因为，我们这样写了，a就会被综合成同步计数器； 还是因为，这样写a会被综合成同步计数器，我们才如上写。,你知道它们会综合成什么？,代码1： always (posedge clk) begin if (ce) b = in, b0:14; end assign out = b15;,代码2： reg 31:0 c511:0 ; always ( posedge clk) begin addr_reg = addr; if (we) caddr = din; end assign out = caddr_reg;,设计综合,软件开发工具 Altera： QuartusII Xilinx ： ISE Lattice：IspLever 第三方 Synplicity： Synplify Pro,综合结果分析,看看综合结果，了解你的代码消耗了多少reg、lut资源，综合估计频率多快，最差路径是哪条。 尽量消除每一个warning，如果warning无法消除，请确认该warning于结果无害。 有没有这种情况：代码A比代码B，速度更快、消耗资源更少、功能更强、运行更稳定？,功能仿真,仿真工具 Altera： QuartusII Xilinx： ISE Lattice： IspLever 第三方Monter：ModelSim,仿真测试方法,正确性测试 又称功能测试，基本的方法是构造一些合理输入，检查是否得到期望的输出。 容错性测试 检查程序在异常条件下的行为。通常构造一些不合理的输入来引诱程序出错。容错性好的程序能确保系统不发生无法意料的事故。,设计实现,实现工具 Altera： QuartusII Xilinx： ISE Lattice：IspLever,静态时序分析,观察Static Timing Analyse结果，原则上不允许出现时序违规。 如果出现时序违规 （1）调整实现选项 （2）修改约束条件 （3）修改代码拆分最差路径 其中修改代码改掉最差路径是治本之法。,下载调试,内嵌式逻辑分析仪 Altera：SignalTap Xilinx： ChipScope Lattice：Reveal 示波器 示波器也是有力的调试工具。,调试困境,功能仿真，看不出错误 用示波器点测，看不出错误 用内嵌式逻辑分析仪捕获数据，看不出错误 最终结果就是不对,软件调试,主要指通过功能仿真（ModelSim）查找问题 实践证明，很多后期调试发现的问题，其实在仿真阶段就能发现，只是因为测试激励不完备，前期仿真没能暴露出来。,硬件调试,首先，请确认你的硬件工作正常 通过示波器、内嵌式逻辑分析仪等工具获取波形或数据查找问题 除了你对自己程序的了解，还需要熟悉所用FPGA的架构、资源等情况，还需要清楚外接芯片的接口时序，了解外围电路的分布。,调试方法,逐级跟踪 如果不是最后一步出错，那就是最后一步的前一步出错；如果不是前一步出错，就是前一步的前一步出错，总之，有一步出错，找到那一步。 使用多种工具 不论是ModelSim、SignalTap、ChipScope、Reveal、示波器各有各的优缺点。 在合适的地方，选用合适的工具。,倒霉定律,担心有理 你所担心的地方，通常是错误发生的地方。你很确定的地方，通常很少发生错误，你不能很确定的地方，就难说了。 人与机器 与机器相比，人更容易犯错误。芯片没有正常工作，我们会怀疑芯片坏了，但大多数时候会发现是芯片没有配置对（程序原因），或者是有只管脚短路或虚焊了（还是人为）。,不要C，要软件工程,虽然Verilog HDL语法与C语言有些相似，但是有些在C语言好的语法习惯，于FPGA设计而言却是不合适的，甚至是背道而驰的。 我们需要的是软件工程的思想。,抛弃你的C语言习惯,assign data = (frame_head_valid) ? frame_head_reg : (rtl8305_mtxen_dly) ? rtl8305_mtxd_dly : (frame_tail_valid) ? frame_tail_reg : 8h00;,always(posedge clk or negedge rst_n) if(!rst_n) cnt = 10d639 | (sync = 1b0 ,例1：,例2：,软件工程,软件工程经过三十年的发展，已经积累了相当多的方法，但这些方法不是严密的理论。实践人员不应该教条地套用方法，更重要的是学会“选择合适的方法”和“产生新方法”。 程序员脑子里的软件工程观念会无形地支配其怎么去做事情。,把软件工程思想植入你的设计,软件工程的目标是提高软件的质量与生产率，最终实现软件的工业化生产。 好的软件工程方法可以同时提高质量与生产率，质量与生产率之间不存在根本的对立。 质量第一，生产率第二。如果一开始就追求高生产率，容易使人急功近利，留下隐患。宁可进度慢些，也要保证每个环节的质量，以图长远利益。,软件工程模型,线性模型,渐增式模型,软件开发的基本策略,复用 模块标准化 复用就是指“利用现成的东西”。复用不仅要使自己拿来方便，还要让别人拿去方便。 分而治之 模块划分 把复杂的问题拆分成较为简单的一个个子问题，逐个解决。 优化与折衷 优化工作不是可有可无的事情，而是必须要做的事情。折衷是指通过协调各个质量因素，实现整体质量的最优。,一些有争议的观点,争议：编程时是否应该多使用技巧？ 观点：就软件开发而言，技巧的优点在于能另辟蹊径地解决一些问题，缺点是技巧并不为人熟知。若在程序中用太多的技巧，可能会留下隐患，别人也难以理解程序。 鉴于一个局部的优点对整个系统而言是微不足道的，而一个错误则可能是致命的。作者建议用自然的方式编程，少用技巧。简单的说，就是少一些个性，多一些共性。,一些有争议的观点,软件中的错误是否可按严重程度分等级？ 作者观点：在定量分析时，可以将错误分等级，以便于管理。 开发人员应该意识到：所有的错误都是严重的，不存在微不足道的错误。这样才能少犯错误。,需求分析为什么困难,有几种原因使需求分析变得困难 （1）客户说不清楚需求； （2）需求自身经常变动； （3）分析人员或客户理解有误。,需求自身经常变动,让我们先接受“需求会变动”这个事实吧，免得在需求变动时惊慌失措。 尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定的需求上，否则将会吃尽苦头。 一定要清楚“做什么”和“不做什么”。如果含含糊糊，日后扯皮的事情就多。,程序设计,参考编程规范 内功深厚的武林高手出招往往平淡无奇。同理，编程高手也不会用奇门怪招写程序。良好的编程风格是产生高质量程序的前提。 编程技巧博大精深，非简单语言可以描述。掌握语法基础，博览众家代码，多实践，35年，或有所成,测试与改错,编程大师说：“任何一个程序，无论它多么小，总存在着错误。” 初学者不相信大师的话，他问：“如果一个程序小得只执行一个简单的功能，那会怎样？” “这样的一个程序没有意义，”大师说，“但如果这样的程序存在的话，操作系统最后将失效，产生一个错误。” 但初学者不满足，他问：“如果操作系统不失效，那么会怎样？” “没有不失效的操作系统，”大师说，“但如果这样的操作系统存在的话，硬件最后将失效，产生一个错误。” 初学者仍不满足，再问：“如果硬件不失效，那么会怎样？” 大师长叹一声道：“没有不失效的硬件。但如果这样的硬件存在的话，用户就会想让那个程序做一件不同的事，这件事也是一个错误。” 没有错误的程序世间难求。,测试的阶段,设计验证,需求定义,设计输入,设计综合,设计实现,配置下载,综合结果分析,实际电路验证,静态时序分析,时序仿真,系统整合验证,功能仿真,测试的目的,测试的目的是为了发现尽可能多的缺陷。 测试总是先假设程序中存在缺陷，再通过仿真调试来发现并最终改正缺陷。理解这一点至关重要。 如果说测试的目的是为了说明程序中没有缺陷，那么测试人员就会向这个目标靠拢，因而下意识地选用一些不易暴露错误的测试示例。这样的测试是虚假的。,测试的真理,测试只能证明缺陷存在，而不能证明缺陷不存在。 这个真理告诉我们，对于一个复杂的系统而言，无论采取什么样的测试手段都不能证明缺陷已经不复存在。 在实践中，考虑到时间、费用等限制，不允许无休止地测试。,测试分工,开发人员应该执行“白盒”测试，即测试源程序的逻辑结构以及实现细节（“白盒”指看得见程序的内部结构）。 独立测试小组应该执行“黑盒”测试，即按照规格说明来测试程序是否符合要求（“黑盒”指看不见程序的内部结构）。 测试有助于提高软件的质量，但是提高软件的质量不能依赖于测试。软件的高质量是开发设计出来的，而不是靠测试修补出来的。,正确对待测试,一个错误自身也许很微小，但是程序存在错误这件事很严重。能否做好测试与改错工作，思想认识和办事态度是最关键的。 程序员应该把测试当成份内之事，不要依赖于外界的“黑盒测试”。 程序出了错误一定要改错，但是“编写优质无错”的程序才是根本的解决之道。,维护,软件维护是既费神又费钱的工作。 良好的编程风格意味着良好的可理解性，可以降低维护的代价。 如果测试与改错工作