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