FPGA5-设计验证.ppt

FPGA 设计基础 设计验证 设计验证 随着IC 集成度的不断提高，系统的规模日益庞大且复杂。验证成为了整个ASIC/FPGA 设计流程中的一个瓶颈问题。（目前一个SOC设计中，验证工程师的人数是设计工程师的2倍左右，验证工作占到整个设计的60～70%，而验证代码，则占到了全部代码70～80%左右） 验证工作量远大于系统设计工作量 。 验证技术 基于TestBench的验证 这种方法为设计提供了很好的可控性和可观测性，这种方法有时可称为结构验证法。由于知道设计的内部细节，因此，很容易产生特殊情况的激励，易于检测内部设计的错误，验证环境的建立相对明确、简单，具有较强的针对性，结果检查相对来说也简单一些。 白盒测试法的缺点就是验证人员要知道设计内部的细节。 3、灰盒验证法： 灰盒验证是介于白盒和黑盒验证法之间的一种验证方法。验证人员在既关心规范需求的同时又关心电路的详细设计方案，需要依据两者制定验证方案。 如同黑盒验证方法，灰盒验证方法通过顶层接口控制和观察整个设计，但是又需要验证一些重要的特定的设计细节。 验证工具 验证工具 验证计划和流程 验证计划的内容： 确定设计需要验证的特性（验证内容）； 确定验证策略---系统级/模块级，黑/白/灰盒式验证，激励产生策略，验证响应方式（观察法、记录法、自检查法）。 确定验证方法---具体验证的步骤和方法，如自顶向下/自下向上。 确定验证的质量标准：如功能覆盖率、代码覆盖率等。 确定验证资源和其它的相关问题：包括人力资源、机器资源和软件资源等，也包括验证过程的质量跟踪等方面的问题 验证流程 验证程序(TestBench)的组成 基于断言的验证 基于断言的验证是一种有效的白盒验证方法，它在RTL设计的源程序监视系统的关键行为，特别是在某些特殊情况下的行为。通过断言的方法，可以增加观测点，在仿真过程中及时发现设计错误。 断言： 断言是设计中希望特定性质为真的描述语句，断言的目的是捕获不希望在设计中出现的行为。断言是用于监控或检查施加在设计上的一些规则和假设的一种机制。 断言的实现 断言可以有多种实现方法，其中最常用也最简单的方法是所谓的叙述性的实现方法，即在设计结构中描述断言，断言和设计中的其他结构一起并发地计算。 叙述性断言实际上是一些代码，这些代码中一般需要包含三部分：一是断言的条件，二是报告信息，三是错误的严重程度以及相关的处理。 例如： 不变性断言：assert_always [#(severity_level, options, msg)] inst_name (clk, reset_n, test_expr)， 其中 assert_always： 断言的名称。 inst_name ： 断言的实例化名称； test_expr : 断言的条件，断言在每个时钟的上升沿检查表达式test_expr，如果test_expr为假，也就是在设计中检测到错误，则激活断言。 [#(severity_level, options, msg)] ：断言的参数，severity_level表示错误的严重等级，根据不同的错误等级，进行相应的处理。另外一个是消息msg，用于表示某个性质不成立时候要显示的信息。如果在模拟的过程中，违背了设定的性质，那么就会触发监视器。另外一个是可选的信息options。 下面是Assert_always断言的代码： module assert_always (ck, reset_n, test_expr); input ck, reset_n, test_expr; parameter severity_level = 0; parameter msg=ASSERT ALWAYS VIOLATION; ‘ifdef ASSERT_ON integer error_count; initial error_count = 0; always @(posedge ck) begin ‘ifdef ASSERT_GLOBAL_RESET if (‘ASSERT_GLOBAL_RESET != 1’b0) begin ‘else if (reset_n != 1’b0) begin ‘endif if (test_expr != 1’b1) begin error_count = error_count + 1; ‘ifdef ASSERT_MAX_REPORT_ERROR if (error_count = ‘ASSERT_MAX_REPORT_ERROR) ‘endif $display(%s : severity %0d : time %0t : %m,msg,