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 A,naly,s,e,结果，原则上不允许出现时序违规。,如果出现时序违规,（,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&sync_buf=1),cnt=10h0;,else,cnt=cnt+1;,例,1,：,例,2,：,软件工程,软件工程经过三十年的发展，已经积累了相当多的方法，但这些方法不是严密的理论。实践人员不应该教条地套用方法，更重要的是学会“选择合适的方法”和“产生新方法”。,程序员脑子里的软件工程观念会无形地支配其怎么去做事情。,把软件工程思想植入你的设计,软件工程的目标是提高软件的质量与生产率，最终实现软件的工业化生产。,好的软件工程方法可以同时提高质量与生产率，质量与生产率之间不存在根本的对立。,质量第一，生产率第二。如果一开始就追求高生产率，容易使人急功近利，留下隐患。宁可进度慢些，也要保证每个环节的质量，以图长远利益。,软件工程模型,线性模型,渐增式模型,软件开发的基本策略,复用 模块标准化,复用就是指“利用现成的东西”。复用不仅要使自己拿来方便，还要让别人拿去方便。,分而治之 模块划分,把复杂的问题拆分成较为简单的一个个子问题，逐个解决。,优化与折衷,优化工作不是可有可无的事情，而是必须要做的事情。折衷是指通过协调各个质量因素，实现整体质量的最优。,一些有争议的观点,争议：编程时是否应该多使用技巧？,观点：就软件开发而言，技巧的优点在于能另辟蹊径地解决一些问题，缺点是技巧并不为人熟知。若在程序中用太多的技巧，可能会留下隐患，别人也难以理解程序。,鉴于一个局部的优点对整个系统而言是微不足道的，而一个错误则可能是致命的。作者建议用自然的方式编程，少用技巧。简单的说，就是少一些个性，多一些共性。,一些有争议的观点,软件中的错误是否可按严重程度分等级？,作者观点：在定量分析时，可以将错误分等级，以便于管理。,开发人员应该意识到：所有的错误都是严重的，不存在微不足道的错误。这样才能少犯错误。,需求分析为什么困难,有几种原因使需求分析变得困难,（,1,）客户说不清楚需求；,（,2,）需求自身经常变动；,（,3,）分析人员或客户理解有误。,需求自身经常变动,让我们先接受“需求会变动”这个事实吧，免得在需求变动时惊慌失措。,尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定的需求上，否则将会吃尽苦头。,一定要清楚“做什么”和“不做什么”。如果含含糊糊，日后扯皮的事情就多。程序设计,参考编程规范,内功深厚的武林高手出招往往平淡无奇。同理，编程高手也不会用奇门怪招写程序。良好的编程风格是产生高质量程序的前提。,编程技巧博大精深，非简单语言可以描述。掌握语法基础，博览众家代码，多实践，,3,5,年，或有所成,测试与改错,编程大师说：“任何一个程序，无论它多么小，总存在着错误。”,初学者不相信大师的话，他问：“如果一个程序小得只执行一个简单的功能，那会怎样？”,“这样的一个程序没有意义，”大师说，“但如果这样的程序存在的话，操作系统最后将失效，产生一个错误。”,但初学者不满足，他问：“如果操作系统不失效，那么会怎样？”,“没有不失效的操作系统，”大师说，“但如果这样的操作系统存在的话，硬件最后将失效，产生一个错误。”,初学者仍不满足，再问：“如果硬件不失效，那么会怎样？”,大师长叹一声道：“没有不失效的硬件。但如果这样的硬件存在的话，用户就会想让那个程序做一件不同的事，这件事也是一个错误。”,没有错误的程序世间难求。,测试的阶段,设计验证,需求定义,设计输入,设计综合,设计实现,配置下载,综合结果分析,实际电路验证,静态时序分析,时序仿真,系统整合验证,功能仿真,测试的目的,测试的目的是为了发现尽可能多的缺陷。,测试总是先假设程序中存在缺陷，再通过仿真调试来发现并最终改正缺陷。理解这一点至关重要。,如果说测试的目的是为了说明程序中没有缺陷，那么测试人员就会向这个目标靠拢，因而下意识地选用一些不易暴露错误的测试示例。这样的测试是虚假的。,测试的真理,测试只能证明缺陷存在，而不能证明缺陷不存在。,这个真理告诉我们，对于一个复杂的系统而言，无论采取什么样的测试手段都不能证明缺陷已经不复存在。,在实践中，考虑到时间、费用等限制，不允许无休止地测试。,测试分工,开发人员应该执行“白盒”测试，即测试源程序的逻辑结构以及实现细节（“白盒”指看得见程序的内部结构）。,独立测试小组应该执行“黑盒”测试，即按照规格说明来测试程序是否符合要求（“黑盒”指看不见程序的内部结构）。,测试有助于提高软件的质量，但是提高软件的质量不能依赖于测试。软件的高质量是开发设计出来的，而不是靠测试修补出来的。,正确对待测试,一个错误自身也许很微小，但是程序存在错误这件事很严重。能否做好测试与改错工作，思想认识和办事态度是最关键的。,程序员应该把测试当成份内之事，不要依赖于外界的“黑盒测试”。,程序出了错误一定要改错，但是“编写优质无错”的程序才是根本的解决之道。,维护,软件维护是既费神又费钱的工作。,良好的编程风格意味着良好的可理解性，可以降低维护的代价。,如果测试与改错工作做得好，后期的维护代价就能降低。反之维护代价就升高。,清晰、正确和完备的文档能降低维护的代价，错误百出的文档还不如没有文档。,低效,大学科研机构里的软件维护工作恐怕是做得最差的了。几乎每一批新的研究生都会把毕业生留下的软件臭骂一通，然后全部推到重做。到他毕业该走时，就轮到别人骂他的工作了。如此轮回，最终没有什么成果留下。,如果希望软件系统能活下，必须要对它进行维护。,如果希望软件系统有效益，则必须设法降低维护的代价。,THE END,谢谢！,