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

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