ic integration和icenterprise architectt的区别
点击联系发帖人
时间：2017-07-03 07:18
当前位置： >>
IC测试技术―设计验证
Digital Circuit Functional Verification 本课程的目的:1. 建立数字集成电路的测试概念与基本方法； 2. 测试是基于数字集成电路的功能； 3. 用于电路的功能设计阶段； 4. 对于数字集成电路而言，是前工序阶段，对前工序的 结果正确定进行测试验证； 5. 适用于FPGA或CPLD设计的功能电路测试; 6. 目标：解决testbench建立的问题 为什么要研究测试1. 随着门电路数目和系统复杂性以指数倍增，在产品 设计中使工程师最费神的将会是：功能测试。 2. 硬件设计人员中间调查发现，60%到80%的时间是 花在测试上的。 3. 使得系统测试更加快捷和精确的关键在于工具的改 进和方法的革新 4. 测试方面缺乏成熟而系统的理论指导 5. 未来最好的测试方法将会是独立于开发工具的，以 便于随时采用更为先进的方法来进行测试 预备知识1. 用VHDL和Verilog来对硬件设计进行功能测试， 至少要对其中的一种语言有基本的了解 2. 最好能有建立可综合(synthesizable)模型的经 验，并且能熟练使用VHDL或Verilog来进行模拟 (simulators)。 3. 对数字硬件设计有一个基本的了解 第一章什么是测试？What is Verification ? 什么是测试？一个验证某个设计的功能是否正确实现的过程。 在此处: 测试并不是一个或一系列的测试平台本章主要内容1. 测试的基本概念，包括其重要性和花费 2. 各种测试方法及其特点，检测和测试的区别 3. 测试对于设计方案再用的重要性 1.1 测试平台对于VHDL和Verilog来说，测试平台是指为一种产生预 先设定的输入序列，然后观测响应的代码。 通常用VHDL和Verilog来实现，但可能同时包括外部数 据文件和C语言程序。 测试平台和测试对象的结构一个完全封闭的系 统 ，既没有外部输 入，也没有外部输 出 普遍适用的测试平 台模型TestbenchDesign Under Verification测试的目的: 1) 确定向测试对象输入向量， 2) 2)预期的测试对象输出。 1.2 测试的重要性测试占去总投入的70%以上? 集成电路上可能集成数以百万计的门电路。 ? 在可再用IP和片上集成系统（SoC）中，测试占去总投入的 70%以上。 ? 设计人员中要分出专门的人去进行测试，其中包括专职从事 测试的人员。测试人员通常是RTL设计人员的两倍。 ? 设计方案完成以后，建立测试平台的代码占代码总量的 80%。 同步作业可以缩短测试时间? 如果能同步作业，就可以有效的使用闲置的人力物力以缩短测试 时间。 ? 例如，在地上挖一口井，同步作业的方法就是给更多的工人提供 更多的铁锹。 ? 测试中采用同步作业的方法是建立测试平台和功能测试的过程与设计的实现过程同时进行。 提高抽象可以缩短测试时间? 提高抽象程度，开发人员就可以不必顾及某些细节而提高效率。 ? 提高抽象程度通常就意味着减少控制，因此必须慎重采用。 ? 较高的抽象程度也要求开发人员懂得一些抽象技术以及如何取得 理想的效果。 自动化技术能减少测试时间? 自动化技术要求过程规范，预先明确定义输入和输出。 ? 并非所有的过程都能自动完成。 ? 测试面临同样的问题。因为功能，接口，协议和转换格式的不 同，不可能从已有方法中找到一种普遍适用的自动测试技术。 ? 测试过程部份实现自动化还是可能的，尤其在应用领域不是那么 宽广的情况下，更是如此。 ? 对测试进行了一些标准定义，可能有助于在不久的将来实现自动 化。 1.3 重会聚模型(Re convergence Model)The reconvergence model is a conceptual representation ofthe verification process. It is used to illustrate what exactly is being verified Transformation测试什么？测试的目的是保证 传输(transformation)结 果和预先设想的一致。Re-convergent paths in verificationVerificationVerification of a transformation can only be accomplished through a second reconvergent path with a common source. The transformation can be any process that takes an input and produces an output. 1.4 人的因素 (The Hunan Factor)因素: 一个人或一个组从头到尾独立完成Example: RTL codingA design team interprets a written specification document and produces what they believe to be functionally correct synthesizeable HDL code. Usually, each engineer is left to verify that the code written is indeed functionally correct.Reconvergent paths in ambiguous situationRTL Coding Interpretation Specitication Verification 缺馅? 同一个人负责RTL编码和测试，测试又需要对测试要求作出具体说明，那么其 所根据的往往是这个说明，而非测试要求本身。 ? 可以通过测试来验证设计是否符合设计人员对测试要求所作的说明。 ? 如果说明本身是错误的，则测试永远都无法达到其要求。任何人为介入都会导致不稳定和不可重复 弥补措施? 自动化 ? 简化 ? 冗余 1.4.1自动化 (Automation )? Eliminate human Intervention. ? 自动化可以消除人为错误，因为它完全排除了人为介 入。 ? 并不是所有的过程都可以实现自动化，尤其是那些没 有很好定义，仍然需要人的创造性的场合，比如硬件 设计 14.2 简化(Poka-Yoka )? 把整个过程分解为简单可靠的步骤，只有在需要取得期望结果的特定步 骤才引进人为介入。 ? 这种技术在质量管理领域又叫poka-yaka。 ? 其离完全的自动化也只有一步之遥，所以它也只适用于严格定义了标准 转换步骤的过程。 14.3 冗余(Redundancy )? 求每个传输对象都是一式两份，传输过程则由两个人分别独立完 成，或对两个完全独立的传输过程的每一个输出结果进行比较，来 验证其结果是否一致。 ? 只有在高度可靠的情况下才使用，比如空运系统。 ? 在某些方面如果对产品的重新设计和更新成本更大，也可以采用这 种方法，例如ASIC设计。RTL coding Interpretation Specification Interpretation Redundancy in an ambiguous situation enables accurate verificationVerification 1.5 测试什么(WHAT IS BEING VERIFIED? )形式测试 形式测试分为两类：等量测试和模型测试。 1.5.1等量测试 (Equivalence Checking )Equivalence checking compares two modelsSythesis RTL or Netlist Equivalence Checking Equivalence checking paths RTL or NetlistIt can compare two netlists比较两个网表，以确保扫描链的插入，时间树的综合，以及人 为修改等，不会改变电路的功能 It can detect bugs in the synthesis software? 验证网表是否正确实现了原来RTL代码的功能。 ? 等量测试可以用来检验合成工具的可靠性。在少数场合，等量测试 可以检验手写RTL代码是否实现了门级设计要求。? 等量测试可以证明两种RTL编码在逻辑上等价。为了获得更好的合成效果， 对源代码作了一些小的修改，而又不影响其功能，就可以通过证明等价而避 免繁琐的模拟。Equivalence checking found a bug in an arithmetic operator 1.5.2 模型测试Model Checking模型测试技术是形式测试技术的最新发展成果，采用这种技 术可以检验一种设计的断言和特征。比方说，设计中的所有状态 机可以独立检测。还有一种功能更为强大的测试可以预测是否会 发生死锁。 另外一种可以进行形式测试的断言跟接口有关。首先用形式 描述语言来描述接口，然后用工具来检测它。例如，一个断言可 能会作如下定义，一旦产生了ALE信号，就会随之产生DTACK或 ABORT信号。 RTL coding Specification Interpretation RTL Model CheckingAssertionsFigure : Model checking paths模型测试技术困难之处在于利用对设计要求所作的说明，来鉴别所要检测的 断言。 在所有的断言中，只有一个子集可以进行检测。现有技术不能检测高级断 言，因此也不能保证能正确实现其复杂功能。 一种理想的情况是，在特定的寄存器状态下，异步传输（ATM）信元以相关 顺序输出。但模型测试技术不能做到这一点。 1.5.3 功能测试 (Functional Verification )功能测试的主要目地是确保设计能实现预期功能。功能测 试就是为了使设计符合其要Functional verification paths 功能测试局限You can prove the presence of bugs, but you cannot prove their absence ? 除非设计要求以精确的语法诉诸于正规的语言，否则无法证明设计 是否符合要求。 ? 描述设计要求的文件是由人用自然语言写成的，而各人正确表达自 己意思的能力又各不相同，人们可以对同一文件作出不同的解释。 ? 功能测试能够显示设计是否符合要求，但无法完全证明这一点。 ? 我们可以因为一点小小的不一致就说设计没有实现预期功能，反之 则不然：没有人能证明它完全一致。 1.5.4 建立测试平台(Testbench Generation )? 测试平台生成程序：按照代码覆盖规律，或利用某些经过证明的 结果，对源代码进行分析。 ? 生成测试平台，可以用来增加代码覆盖，或检验设计方案的某些 性质。 测试平台生成程序局限及用途Designer input is still required. The jury is still out on the usefulness at these tools. 测试对象通常都是RTL代码，没有重重会聚点。测试人员要判 断测试平台所给的激发信号是否有效，如果有效，则要知道预期的 输出结果，并把它和设计的输出比较 模型测试产生的测试平台不仅能用来描述某项特性可能不符 合要求，或者什么样的输入顺序可能引起错误。而且可以用来检 测到设计要求中没有考虑到的非正常状态，或者为解决问题提供 调试环境。 1.6 功能测试方法FUNCTIONAL VERIFICATION APPROACHES功能测试可以用三种不同但互补的方法： 黑箱测试 (black-box ) 白箱测试 (white-box ) 灰箱测试 (grey-box ) 1.6.1 黑箱测试(black-box Verification )黑箱测试是在对设计的具体情况一无所知的前提下进行的，所有的 测试都是利用外部接口，而不考虑起内部状态，更不知道其结构和 实现方法。 缺点: 缺乏可视性和可控性，很难进行状态组合或独立测试某些功 能，也难以观察它对输入的反应或找到问题所在之处。从出现问题 到它在输出结果中表现出来通常都有很长的延时。 优点: 不用考虑测试对象是如何实现其功能的，无论它是用ASIC， FPGA，电路板，还是用软件实现的，都无关紧要。黑箱测试可以 不考虑一项设计的实现方法，而只检测它是否实现了其功能 改进：在一些大型复杂设计中，黑箱测试可以作些非功能性的改进，以便实现某种程度的可视性和可控性。 例: 可以用一些可软件读写的寄存器来控制或观察内部状态，或修改 所处理数据的长度，以尽可能减少测试时间。这些寄存器在正常运行 时并不起作用，它们只是在原始系统的组合阶段才用到。黑箱测试方法的建立可以和设计同步进行，因为它是唯一可以事前 对设计本身一无所知的测试方法。 1.6.2 白箱测试 White-Box Verification白箱测试就是对测试对象的内部结构完全可见和可控。 优点：可以很快对状态和输入结果进行组合，或独立测试某项功能。 它能在测试的过程中随便观测任何结果，并能立即发现运行中出现的 错误。 缺点：和测试对象本身联系太紧密，换一个测试对象就不行了，也不 能用于将来的重新设计。它要求对设计过程有详细的了解，才能知道 要预设什么样的条件，要观察什么样的结果。 白箱测试和黑箱测试具有很强的互补性。 白箱测试能保证设计特定功能的实现，例如计数器到达计数终值翻 转，以及数据正确的传输过程和顺序。 1.6.3 灰箱测试(grey-box Verification)灰箱测试是在黑箱测试的独立性和白箱测试的依赖性之间取一个 折中。 因为前者不能完全测试设计的每一个部份，而后者太麻烦了。 灰箱测试可以通过最高级接口来控制和观测设计对象，这一点和 黑箱测试是相同的。同时也有针对设计特定功能的专门测试。 它对别的测试对象也可能适用，但这时候充其量也就只能当黑箱 测试用了 1.7 检测与测试的比较( TESTING VERSUSVERIFICATION )保证在功能上 实现设计要求最后的硬件结构和制 造工艺中的网表一致Thoroughness of testing depends on and observability of internal nodes.controllability 1.7.1 扫描测试(Scan-Based Testing )目的：扫描检测在某种程度上解决检测覆盖问题 方法：把所有的寄存器组成一个很长的串行链。在正常的状态下，寄存器正常工作，在扫描状态下，寄存器则表现为一个很长的移位 寄存器。 扫描检测方法? 进行扫描检测时，检测对象必须置于扫描状态，再用一个输入量移位通 过所有的寄存器。 ? 把检测对象置为正常状态，外加一个单时钟周期，把扫描状态下的正常 运行结果载入寄存器。 ? 再一次把检测对象置为扫描状态。由寄存器输出结果（同时输入下一个 变量），并把它和期望值比较。 为了能插入扫描链和自动产生检测形式，设计必须受到一些限制。这些 限制包括：完全的同步性，没有导出时钟和门控时钟，只能使用时钟的 单个边沿，等等。 1.7.2 为测试而设计? 设计方案作某些修订，以适应测试的要求。 ? 因为功能测试所花的时间是设计本身的两倍，所以完全有必要在设计 上多花点时间，以简化测试过程。 ? 正如设计中插入扫描链可以增加可检测性而不增加功能一样，应该在 设计中加入非功能性结构和特征以适应测试的需要。 ? 要求在一个项目的开始就考虑到测试，尤其是在制定要求的阶段。 ? 设计本身不仅要回答“要实现什么功能？”，而且要回答“如何来进行测 试？”。 ? 典型的技术包括: 额外提供可软件编码的的寄存器，以控制和观察内部 地址，或用另外的可编程器件来隔离或绕过某些功能部件。 1.7.3 测试与设计方案再用芯片上集成数量巨大的晶体管，而晶体管设计人员的数量却是有限的，唯 有用设计方案再用才能解决这个矛盾。 设计能够被再用的关键是取得别人的信任： 设计再用最大的障碍是人为差 异，设计人员都不大愿意在自己的设计过程中引进不熟悉的方法和结果，他 们认为别人设计的没有自己亲自设计的好，或着不如自己设计的可靠。 是否值得信任的特征是看有没有一个适当的测试过程。如果能向用户证明该 设计曾按照要求从头到尾认真测试过，那么就能取得用户的信任。 再用一项设计，只能通过功能测试来证明其正确性。因此，可再用设计和一 般的设计比起来，更需要通过测试来取得信任。 可再用设计需更加结构化，更具有可编程性，方能满足不同的环境条件和不 同的应用，所以所有可能的结构和应用都要测试到。可再用设计所有的特点 都要展示给用户，并作出测试。 1.8 测试费用(THE COST OF VERIFICATION )? 测试是一个看似永远都不会结束的过程。 ? 测试的目的是保证一个设计不出错，但任何人都不能证明设计完全没 错。 ? 测试只能证明有错，而不能证明无错，多花点时间，总能找到错误 的。问题是： a) 错误是否严重到值得花时间去寻找的地步？ b) 在测试上花的时间越多，在一定时间内能找到的错误就越少。 c) 到了后来，就几乎没有错误了。 d) 最后，花的时间越来越多，找出的错误越来越少，甚至找不出错误了。 功能测试判断类似统计假设检验。检验的假设条件是：设计是否能正确实现其功 能？答案可以是“是” 或“否” ，但两种答案都有可能出错。 两种错误答案分别是II型错误和I型错误 Error Bad Design Good Design Type I (False Negative)不严重：在没有错误的地方找 出错误。通过测试就把答案从 否定改为肯定，错误不再有。No Error Type II (False Positive)严重：测试没 有找到错误。 一个错误的设 计可能过关， 从而造成严重 的后果。 什么时候才算测试完？了解测试过程的大致进度，尽管不可能精确知道，但由此 可以推算出完成整个工作需要多长时间。 第三章所讲的测试策划过程介绍了一种方法，使得测试的 负责人能更好的估计完成测试所需要投入的时间和人力物 力。 第二章测试工具The Verification Tools 本章将介绍在现代功能测试环境中所用到的工具? 模拟程序：对功能测试来说是必不可少的。 ? 代码覆盖工具：可以使得测试中某些单调的任务自动执行，并增加 功能测试输出结果的可信度。 ? 测试人员任务：使用必要的工具来保证测试结果并非II型错误，也 即确保不出现代码错误不被发现。 ? 项目主管：保证用预定的资金，按预定的计划出产品，责任是使 手下的开发人员用恰当的工具，以充份的自信来完成自己的工 作。同时要判断寻找功能缺陷的花费是否已经超过了改进功能所 带来的效益，而这个工作尤为重要，本章所介绍的某些工具能帮 找到这个临界点。 2.1 检错工具 ( LlNTING TOOLS )Linting tools find common programmer mistakes.? 检错（lint）一词源于一个专门用来检测C语言程序错误的UNIX设 备。当Dennis Ritchie最开始发明C语言的时候，它并不象现在的 ANSI-C和C++这么安全可靠，也比不上Pascal和ADA。检错程序 允许编程者尽可能快的发现常规错误，而不是在测试的过程中发 现了致命错误以后才知道。 ? 检错程序能够找到错误，使编程者能在执行程序或发生重大错误 之前改正它们。运行时检错将需要一个运行时的调试程序，并且 要花好几分钟，而检错程序则只需要几秒钟，后者效率更高。 检错程序的优点：不需要激发，也不要说明期望的输出结果。它们的检错完全是静 态进行的，本身就自带了期望的输出结果。检错程序的局限性? 检错程序并不能找出源代码中的所有错误，它只是通过分析源代 码的结构来判断何处出错，而算法错误和数据流错误则发现不 了。 ? 检错程序在检错时有时表现得很固执。为了避免犯II型错误―即肯 定为错，常常犯检查出并不存在的错误，结果导致I型错误―否定 为错。 解决方法? 细心过滤错误信息 ：分析输出结果，把那些事实上不存在的错 误排除掉，就不必为查找根本没有的错误而浪费时间。更重要 的是，它可以避免一个真正的错误随着众多的假错误被忽略。 ? 正确的命名习惯有助于判断一个警告是否值得注意 ? 对于检查潜在的真实错误来说，逐行检查仍具有不可替代的作 用。 ? 编写源代码时就应该检错。判断一个错误的真假的最好时间是 在刚写完代码的时候。 ? 保证代码的可读性和可维护性 Linting Verilog Source CodeVerilog is a type-less language.(弱类语言)Linting Verilog source code catches common errors.Linting Verilog source code ensures that all data is properly handled without accidentally dropping or adding to it. The code in Sample 2-5 shows a Verilog model that looks perfect, compiles without errors, but produces unintended results under some circumstances. (编译无错，但在某种环境下出错) Sample 2-5. Potentially problematic Verilog code module tristate_buffer(in,out,enable): parameter WIDTH=8; input [WIDTH-1:0] in: output [WIDTH-1:0] out: assign out=(enable)? In : ’ end module Problems may not be apparent under most conditions.问题：位宽不匹配错误，out 定义8位，赋值8位高阻，32位系统中 其余位扩展赋值“’b0” Linting VHDL Source CodeBecause of its strong typing, VHDL does not need linting as much as Verilog.Lilnting can find unintended multiple driversSample 2-6. Erroneous multiple
use ieee.std_logic_1164.all entity my_entity is port (my_input: in std_logic); architecture sample of my_entity is signal s1: std_ begin statement1: s1 &= my_ statement2: s1 &= not my_Lilnting can find unintended multiple driversMultiple drivers. VHDL compiler. undetected 代码检查 (Code Reviews)? 代码检查是由人工完成的 ? 作用：在测试和模拟之前找出功能错误和编码格式错误。? 为了找出自动检错工具发现不了的错误，源代码将由多人过目。? 可通过代码检查来评估一个源文件的可维护性以及其代码的正确 性，还能发现编码格式方面的问题。 ? 能完全读懂代码，很容易找到功能错误及疏忽遗漏之处。 2.2 模拟 (SIMULATORS)在实现前模拟，可以及时的发现错误，改正错误 模拟是现实近似。为了降低难度，模拟中很多特征都 简化了，甚至被忽略。 模拟实际能实现的是对设计的说明进行，而且还必须 以严格的语法来说明。 不能确定模拟和实际的差别。不能证明模拟完全无 错，其功能的正确性和模型的精确性始终值得怀疑。 2.2.1 激励与响应 (Simulation requires stimulus)? 模拟要求提供一个测试平台 ? 本课程目标是如何建立测试平台。 ? 测试平台提供设计所需的输入，模拟器依据设计会作出响应。? 设计者本人根据模拟器的输出结果来判断设计的正确性。 ? 在一定条件下给了模拟器一个激发信号后，检查其输出，判断 其响应是否符合要求。 2.2.2 事件驱动模拟 (Event-Driven Simulation )Simulators are never fast enough. Outputs change only when an input changes.只有输入变化时才进行模拟。因此模拟程序是由输 入的变化驱动的，称事件驱动。 Change in values, called events, drive the simulation process. Sample 2-9. VHDL model for an XOR gate XOR_GATE: process(A, B) begin if A = 3 then o&='0'; else o& ='1' end process XOR_GATE;当且仅当A,B变化 时，才执行后面 的程序 Sometimes, input changes do not cause the output to change? 输入变化，即使输出不变化，也进行模拟 ? 满足事件触发条件 2.2.3 基于时钟周期的模拟 (Cycle-Based Simulation)触发Event-drive Simulator view of a synchronous circuit Cycle-based simulators collapse combinatorial logic into equations.? When the circuit description is compiled, all combinatorial functions are collapsed into a single expression that can be used to determine all flip-flop input values based on the current state of the fan-in flip-flops. ? During simulation, whenever the clock input rises, the value of all flip-flops is updated using the input value returned by the precompiled combinatorial input functions. Cycle-based simulations have no timing information.? This great improvement in simulation performance comes at a cost: all timing and delay information is lost. 不考虑定时与延迟信 息 ? Cycle-based simulators assume that the entire design meets the set-up and hold requirements of all the flip-flops. 设计满足触发器 建立和保时的时间要求 ? When using a cycle-based simulator, timing is usually verified using a static timing analyzer. 基于时钟周期的模拟，使用静态时序 分析器分析时序 Cycle-based simulators can only handle synchronous circuits. (仅能用于同步电路)? Cycle-based simulators further assume that the active clock edge is the only significant event in changing the state of the design. 有 效的时钟边沿触发状态改变 ? All other inputs are assumed to be perfectly synchronous with the active clock edge. 所有输入被有效的时钟边沿同步 ? Therefore, cycle-based simulators can only simulate perfectly synchronous designs.仅能用于同步设计 ? Anything containing asynchronous inputs, latches, or multipleclock domains cannot be simulated accurately. 2.2.4 共同模拟Co-Simulators设计中的同步部份用的是时钟驱动，而其它部份用的是事件驱 动。两种模拟结合起来共同完成模拟功能。Multiple simulators can handle separate portions of a design All simulators operate in locked-step.? During co-simulation, all simulators involved progress along the time axis in lock-step. ? All are at simulation time T1 at the same time and reach the next time T2 at the same time. ? This implies that the speed of a co-simulation environment is limited by the slowest simulator.Performance is decreased by the communication and synchronization overhead. Translating values and events from one simulator to another can create ambiguities. Co-simulation should no be confused with single-kernel simulation 2.3第三方模型 (THIRD-PARTY MODELS)Board-level designs should also be simulated. 板级的设计通常都包括从第三方买来的部件，有时 这些部件是可编程的，如存储器，PLD，和FPGA。必 须对设计进行测试，以保证ASIC之间，和第三方部件之 间能够兼容。 You can buy models for standard parts It is cheaper to buy models than write them yourself Your model is not as reliable as the one you buy. 2.3.1 硬件模块 (Hardware Modelers)What if you cannot find a model to buy?You may be faced with procuring a model for a device that is so new or so complex, that no provider has had time to develop a reliable model for it.You can &plug& a chip into a simulator.A hardware modeler is a small box that connects to your network. A real physical chip that needs to be simulated is plugged in it. 2.4 示波器 (WAVEFORM VIEWERS)Waveform viewers display the changes in signal values over time Waveform viewers are used to debug simulationsA waveform viewer can play back the events that occurred during the simulation that were Simulation Engine Event Database FileRecording waveform trace data decreases simulation performance. Do not use a waveform viewer to determine if a design passes or fails. Some viewers can compare sets of waveforms. How do you define a set of waveforms as &golden&? And are the differences really significant? 2.5 代码覆盖CODE COVERAGE概念源于软件工程，用来判断测试是否充分，代码是否有 没测试到的。代码覆盖处理实例1. Code must first be instrumented 2.Trace Information is collected at runtime 3. Statement and block coverage are the same thing 4. block boundaries may not be that obvious代码覆盖最常用的是语句覆盖，过程覆盖和表达覆盖 语句覆盖(模块覆盖 )模块是由一系列语句构成的，只要执行其中一条语句，整 个模块就会随之执行。Sample. Block vs. statement execution if (dtack == l'b1 ) begin: acked as &= 1'b0; data &= l6'hZZZZ; bus_rq &= l'b0; The block named acked is state &= IDLE; executed entirely whenever the expression endin the if statement evaluates to TRUE. 模块之间并没有明确的界限 Sample. Blocks separated by a wait statement address &= 16#FFED#; ale rv &= '1'; &= '1';The wait statement may have never completed and the process was waiting forever.wait until dtack ='1'; read_data := ale &= '0' ; 2.5.1语句覆盖 (Statement Coverage)语句覆盖用 来计算在测试的 过程中共有多少 行代码得到了执 行，它提供一个 图形用户接口来 显示所有的源代 码，以及有那些 语句没有执行。√□ □ □√ √ √ √ √ √Example of statement coverage. if (Parity == ODD||parity == EVEN) begin tx &= compute_Parity(data, parity); # ( tx_time ); end never be executed tx&=l'b0; #(tx_time); if(stop_bits==2) begin tx&=1'b0; #(tx_time); end Why did you not execute all statements?无法执行的代码是无效的，删除无效代 码可减少无序性，增加源程序可维护 性。 2.5.2 过程覆盖(Path Coverage)There is more than one way to execute a sequence of statements. Path coverage measures all possible ways you can execute a sequence of statements. example of statement and path coverage 2.5.3 表达覆盖 Expression Coverage两个相互独立的条件可以使第一条if语句引起then语句的执行。 表达覆盖就是统计执行一段代码的方法数。尽管语句覆盖已达 100%，表达覆盖却只有50%。 2.5.4 What Does 100 Percent Coverage Mean?? 代码覆盖表示的是测试过程对源代码的覆盖程度，但 它并不能辨别测试过程是否正确。 ? 对代码覆盖的结果进行描述时应该有所保留。这些结 果可以用来鉴别没有被测试的特殊情况，或用来检测 在执行的过程中出现的特征。 ? 代码覆盖可以体现测试工作的全面性，可以了解测试 范围有多广，但这并不是唯一的指标。 ? 代码覆盖率较低表明测试工作尚未完成，但代码覆盖 率较高并不就表明测试工作已经完成。 2.6 测试语言( VERIFICATlON LANGUAGES)? Verification languages can raise the level of abstraction. ? VHDL and Verilog are simulation languages, not verification languages. Verilog偏重的是初级应件结构，所以它不能支持高级数据结 构，也不具备面向对象的特征。VHDL比较适合于大型项目，它 封装了所有的信息，并严格按定义好的接口传送。有必要创造一 能克服Verilog和VHDL的这些缺点的专门的测试语言 。 ? Proprietary verification languages exist. 三种企业专用的测试语言：Verisity的elSpecman, Synopsys 的VERA,Chronology的Rave。 2.7 版本控制 (REVISION CONTROL)版本控制解决的问题 Are we all looking at the same thing? Files must be centrally managed. It must be easy to get at all the files, from a single location. 2.7.1 The Software Engineering ExperienceHDL models are software projects Free and commercial tools are availableTo help manage files, software engineers use source control management systems.All source files are centrally managed所有对源文件的存取和修改都由管理系统来管理。所有的设计 人员和用户都是通过管理系统来交流，而不是直接在工作目录下存 取文件。 The history of a file is maintained.源代码管理系统不仅支持文件的最新版本，而且保存着每个文 件的不同版本。优点：文件恢复为以前的版本，文件从一个版本转换为另一个版本。文件恢复为修改以前。The team owns all the files文件就不再属于某一个人所有，名义上是设计人员分别负责不 同的模块，但只要允许的话，任何人都可以对文件作修改。 测试人员可以不依赖于设计人员而对文件进行改错。资源管理 系统可以通过同步修改来对文件进行修改。 2.7.2 Configuration ManagementEach user works from a view of the file system? 两个用户从不同的角度看管理系统中的源文件，不能确定都采用最新 的版本。 ? 文件经常在没来得及检查出错误之前就作了修改，是极为麻烦的事。 Configurations are created by tagging a set of versions所有的文件管理系统都用标识符来代指文件的各个版本，以后 涉及到文件的这个版本时就可以用标识符，而不必知道其版本号。Configuration management translates to tag management Example tags for release managementTag Name Submit Bronze Silver Gold To_Synthesis TO_Layout Version M_. N ON _YYMMDD Description Ready to submit to functional verification. Author has verified syntax correctness and basic level of functionality. Passes a basic set of functional testcases. Release is sufficiently functional for integration. Passes all functional testcases. Passes all functional testcases and meets coding coverage guideiine5 (requires additional corner-case testcases). Ready to submit to synthesis. Usually matches &Silver& or &Gold&. Ready to submit to layout. Usually matches &Gold&. Version that was manufactured. Matches corresponding 'To-Layout& release. Future versions of the same chip will move tags beyond this point. Some meaningful release on the specified date. 2.7.3 Working with ReleasesViews can become out of date as new versions of files are checked into the source management system database and tags are moved forward.Releases are specific configurations. Users must update their view to the appropriate release. You can be notified of new releases 2.8 ISSUE TRACKING问题追踪? 测试人员的任务就是发现错误，真正令人伤脑筋的是发现不了 错误。 ? ? 出错是正常的，它与硬件设计人员的能力无关 即使是最有经验的软件开发人员写出的代码也是可能出错的， 最简单的常用程序也不例外。 ??问题：已经发现错误，下一步该怎么办？发现了问题就应该解决，所有的设计小组都有专门的系统，用来追踪 问题，解决问题。 2.8.1 What is an Issue? 何谓问题？什么是值得追踪的问题 追踪问题的代价不应该比问题带来的损失更大。先决定什么 问题值得追踪，然后再建立适当的追踪系统呢，它可以保证设计 的功能正确。 任何足以影响系统功能的都可以称之为问题： a) 在测试平台的运行过程中发现的错误显然是值得追踪的。 b) 说明文件中的模糊和不完整之处也应该追踪，但排版错误不在此例。 c) 结构上的错误也算。 d) 在设计和测试的过程中发现的错误都应该追踪。 e) 如果想采用一个新的测试箱，也应该追踪。 When in doubt track it.判断它是否值得追踪的唯一标准是看它对设计正确性的影响程 度。如果问题不解决就会导致整个设计出错，当然就该进行追踪。 并不是所有的问题所造成的影响都是一样的，有的对设计的功能造 成直接的影响，有的只是造成间接的，次要的影响。所有的问题应 该给一个优先计别，并按优先级排序。You may choose not to fix an issue有些问题，通常都是不太重要的，可以忽略。设计小组可以决 定对于某个特定的项目来说，有些问题是可以接受的，它们可以留 到下次改进时再解决。 2.8.2 The Grapevine System树状系统Issues can be verbally reported.最简单，用得最普遍的问题追踪系统。 发现了一个错误之后，直接找到设计者并和他讨论（即使你不是 设计人员也行），其他人听到你们的讨论之后也可能加入进来，简单 的问题马上就可以解决，复杂的问题可以留待以后多找点人来讨论。 问题的优先级别是设计人员根据解决的迫切性来决定的。It works only under specific conditions? 特别适用规模较小，联系紧密，工作都比较相似的设计小组。 ? 如果小组中有成员不在一起，不能很快进行交流，不适用。 ? 假如问题通过讨论解决了，任何人都不必负责实施解决方案。 局限性.? 系统不对历史作任何记录，一旦一个问题得到了解决，无法再回 看整个解决过程。 ? 如果解决方法迟迟不能付诸实施，则这个问题可能被重复访问多 次。 ? 如果提出的解决方案不能解决问题，可能会导致设计人员不断试 验以前的解决方法，从而陷入一个死循环。 ? 由于没有历史记录，很可能就会重复以前的错误，无法从以前的 错误中吸取教训。 ? 因为每个人可能碰到的都是一类问题，所一他所知道地也往往很 有限。 2.8.3 The Post-It System 溯源系统Issues can be tracked on little pieces or paper.当设计小组的规模增大，或人们不再能随心所欲的进行交流，就要 用到3M溯源系统。 方法：每个人都在其监控器上贴上一些说明性的纸片。优点：弥补了树状系统权限不明的缺陷，纸片是谁的，谁就负责找 到解决方法。 缺点：有时权限也是模糊的。往往是因为纸片掉到地下被清洁工扫 走了，问题就被“解决”了 由于溯源系统不存在优先级别的问题，可能会导致以 下情况：一个错误对一个设计人员很关键，但负责解决这个错误的人却 因为种种原因而优先解决其它的问题。 所有的问题都看起来差不多，好象没有任何一个显得比其它的 更加迫切需要解决。 受个人能力的限制。因为缺乏历史记录，问题往往被重复访 问，错误也重复产生。 2.8.4 The Procedural System 分步系统Issues can be tracked at group meetings.问题通过email等自由的形式提出来，其中比较重要的则在小 组会议上解决。 ? 由于涉及到了全组人员，并是在会议时间解决，所以可以调动全 组人员集思广益解决问题。 ? 这样做要把大量的时间用于开会 ? 只用于很重要，很关键的问题，而数量庞大的小问题，则还是采 用树状系统或溯源系统。Only the biggest issues are tracked. 2.8.5 Computerized System 推算系统Issues can be tracked using databases. 系统特点：? 突出的问题总是被反复强调，问题可以分配给某个人或某些人， 因此要解决问题只要找相应的人就可以了。 ? 如果有必要的话，计算机推算系统还会按天或按周向你报告状 态。 ? 系统对每个解决方法都保存历史记录，通过记录不同的方法及其 效果，就可以保证每个方法只用一次而不再重复。 ? 可以很快查看类似问题的解决过程，而避免犯相似的错误。 关于问题追踪的选择计算机推算系统尽管具有一系列优点，但常常还是不管用。最大的 困难在于使用起来不方便，而树状系统和溯源系统是随时可用的。 如果日程一定，工作量一定，你要报告一个简单的问题，你会选择 哪种方法： ① 直接找到负责解决这个问题的人，向他报告。 ② 把问题写在一个纸条上，给（1）中的那个人（如果他不在，则把纸 条贴在他的计算机屏幕中央）。 ③ 把对问题的说明输入问题追踪数据库，不要离开自己的工作站。 你可能选择费时费力最少的一种，但如果你的小组要成功使用计算 机推算系统，则你选择的方法应该尽可能的不打断成员们的进度选 择和他们的工作和工具最接近的。 第三章测试计划The Verification Plan 目的： 首次测试成功 怎样测试 怎样建立测试平台 3.1 THE ROLE OF THE VERIFICATION PLAN 测试计划的作用Traditionally, verification is an ad-hoc process在传统的设计中，测试是留给每个设计人时间允许时自己去完 成。 习惯在系统组合中多花时间，也不预先留下改错的余地。Tools exist to help determine when you are done工具可以帮你进行测试。代码覆盖率，错误发现率和代码修改率 能让测试者估计离预定目标还有多远。即确定什么时候做完。 3.1.1 Specifying the Verification明确测试You need a tool to determine when you will be done(确定什么时侯完成)必须明确确定测试何时能按要求完成。 测试计划涉及的问题： 根据需要完成的工作具体说明，确定需要多少 人，需要持续多久，需要做什么工作等。 Start from the design specification.从设计说明开始在进行测试之前，必须为要测试的对象制定详细的 说明文件。 设计要求是设计和测试总的根据，它是不能变的。 测试平台的结果和测试对象的结果不一致，由设计 要求来决定谁对谁错。 The verification plan is the specification document for the verification effort测试计划就是测试的说明文件事先没有一个详细的说明文件， 是不可能设计出集成几百万个门 电路的集成电路的。 测试所花的时间是设计本身的一 到两倍测试时需 要详细的 说明文 件，即测 试计划 3.1.2 Defining First-Time Success 首次测试成功? 测试计划要求设计小组先确定什么是首次测试成功 ? 它是一种正确测试所有基本功能的方法首次测试成功的方法? 确定在什么样的条件下能实现什么样的功能，会作出什么样的 响应。 ? 测试要求还要说明什么功能是优先的，什么功能是可选的。 ? 如果时间较紧，在首次测试成功的要求中去掉一些功能是比较 明智的。 From the verification plan, a detailed schedule can be created 从测试计划得到详细时间表? 测试计划制定了一条界线，越过了这条界线，就会影响产品的 成功上市。 ? 写出了测试计划，就会知道要建立多少测试平台，知道它们的 复杂程度和相互依赖程度。 ? 可以制定详细的测试时间表，给资源分配测试平台，使得测试 尽可能能够同时进行。 ? 一旦测试所有必要功能的测试平台建立起来了，RTL又通过了 测试，设计就可以交货了，在此以前则不行。 The team owns the verification plan.团队拥有测试计划? 让每个设计人员认识到测试计划的重要性。 ? RTL设计人员的任务不仅是设计出RTL，更重要的是让它能正常运行 ? 每个人都应该参与测试计划的制定，以保证其完整性和正确性。This process is not revolutionary. 此过程不是创新的 3.2 LEVELS OF VERIFICATION测试的层次Verification can be performed at various levels of granularity. 测试可以在不同粒度水平上进行 ? 制定测试计划的首要问题是确定测试的层次 ? 每个设计都是由好几个层次组成的 ? 物理层：如印刷电路板，FPGA和ASIC， ? 逻辑层：如组合单元，可再用组件和子系统。 Application of different levels of verification 测试的不同层次应用? 每个层次都有自己最适 用的场合和对象 ? 和传统的设计过程相比, 采用可再用组件的设计 有很大变化, 变化范围 包括物理层内从单元级 测试开始处到系统级测 试结束处 ? 设计采用了可再用组件 之后, 并没有减少对测 试的依赖程度 ? 单元级和系统级的界限 是一个逻辑概念, 而非 一个物理概念. Deciding between levels of granularity involves tradeoffs划分更细, 则可控性和可观察性更强, 更易于测试, 要 建立所需的条件和状态组合以观察响应是否符合预期值, 也要容易的多. 如果划分较大的话, 要对较小的部分进行整合, 测试 时可控性和可观察性要差得多 Verifying at a given level of granularity requires stable interfaces任何测试对象都必须有相对稳定的接口并实现预定的功能 如果接口和功能不断的发生改变, 则测试平台也要不断改变, 也就 很难加以改进. 一旦决定在一定的划分级别上进行测试, 则应该及早的规定其接 口和整体功能, 并尽可能的保持不变 最好是每个级别都有自己的要求说明文件. 3.2.1 Unit-Level Verification单元级测试Implementation determines the content of this partition? 设计单元是按逻辑来划分的, 是为了便于实现和合成 ? 可能比较简单(如FIFO和状态机), 也可能比较复杂(如PCI从接口 和DSP数据通道). ? 随着在实际过程中不断的暴露初始设计的缺陷和不足, 其接口和 功能会不断的改变? 在测试时通常没有独立的要求说明文件可资利用. Use ad-hoc(对等) verification for design units. 对设计单元使用对等测试 ? 因为设计单元不断的在发生改变, 所以最好进行对等测 试, ? 由设计者测试单元的基本功能, 确保RTL代码中没有语 法错误, 并且实现了基本功能, ? 不需创建回归检测组件来获得较高的代码覆盖率. Unit-level verification may be required in large devices 大的器件可能需要单元级测试 ? 对于较大, 较复杂的ASIC和FPGA来说, 从ASIC和FPGA 进行测试可能不能获得理想的功能覆盖, ? 内部高灵敏度的复杂功能模块, 只有进行单元级测试才 能获得足够的可控性和可观察性. ? 单元级测试的每个功能单元最好都有自己的要求说明 文件 Architect the design to facilitate unit-level verification 为方便单元级测试构建设计? 比较复杂的设计, 需进行单元级测试, 那么就要注意使单元级测试尽 可能的完善和完整. ? 划分时使所要测试的功能完全包含在一个单元中, 并能独立的进行 测试, ? 一旦通过了测试, 在进行更高级别的测试时就可以假设这些功能是 正确的. ? 如果在单元级测试的功能和别的单元有接口, 在更高的级别上就要 重新进行测试, 以确保其组合也是正确的. 3.2.2 Reusable Components Verification 可再用组件测试Reusable designs are independent of any particular use 可再用设计独立于所有的特对应用? 可再用组件是完全独立设计的, 它可以在别的设计中原封不动的 采用. ? 其可再用的范围可以是一种产品, 一系列产品, 甚至是能用到其功 能的任何产品. ? 它必须就某种用途进行完全独立的设计和测试 Verification components can be used as well 测试元件也可以再用? 可再用组件通常用标准接口来设计, 这些接口根据标准片上总线或 是工业标准的外部物理接口来设计. ? 用来激发和监测这些接口的测试组件本身也可以在不同的测试环境 中用于测试不同的可再用组件 ? 当组件众多时, 可以较好的减少投入, 压缩开支. ? 第6章将详细讲述如何构造一个测试平台, 使之能够创建和使用可再 用测试组件. Reusable components need a regression test suite 可再用元件需要回归检测组件? 可再用组件在很多设计中都用到, 如果为了改正发现的 问题或是为了增强其功能, 而不得不作出修改, 则要保证 它向后兼容. ? 在修改后用回归检测组件来检测其兼容性, ? 用常规测试很难检验新组件和原来组件的等价性, 除非 所做的修改不是功能上的 ? 更正问题和增加功能都使得设计和原来的不等价 They need thorough functional coverage. 需要完全的功能覆盖如果用户不相信组件比他自己设计的更好, 他是不会采用 的. 要取得用户的信任, 就要用详加说明的, 完整的测试过程 来证明组件的正确性和稳定性. 3.2.3 ASIC and FPGA VerificationThe physical partition is an ideal verification level They may have to be treated as systems FPGAs now require an ASIC like verification process 3.2.4 System-Level Verification 系统级测试? 系统是由独立的测试组件构成的逻辑概念 ? 一个系统可以是由几个可再用组件构成的 ? 可以是一个片上系统ASIC, 也可以由不同的印刷电路板上的几个 ASIC组成,Logical, system partition The verification focuses on interaction 测试专注于相互关系系统级测试是忽略单个组件的具体功能而注重其相互 关系, 功能在组件级测试中已经测试过, 进行系统测试的前提是单个组件的功能正确. The testcase defines the system? 系统是一个逻辑概念, 可以由任意数目的组件构成 ? 采用和测试哪个系统取决于相关的测试实例, ? 为了减少模拟, 最好采用最小可能的系统来执行测试实 例 ? 由于可能采用的系统很多, 所以要规定一个标准系统. 同一个系统可以用于很多测试实例 3.2.5 Board-Level VerificationBoard-level models are generated from the board design tool 从板级设计工具中产生板级模型? 目的：是确保插件板所确定的连接正确 ? 可以当作一个系统来进行功能测试 ? 插件板设计模型必须由插件板设计工具自动生成. ? 保证测试对象就是所要生产的产品, 在设计和模拟对象之间必须 有直接的联系 Many components on a board do not fit in a digital simulation environment 板上的元件不适合数字仿真环境? 插件板级模型最大的困难是为所有的组件建立适当的模型 ? 使用第三方资源和硬件模型 ? 模型带来某些误差：如 1) 电容在数字仿真系统中的描述，2) 模拟器件, 连接器, 光藕和很多其它的元件在数字环境中转换和传输Board-level parasitic can be modeled 板级寄生效应模拟? 寄生效应可能影响插件板功能的正确性 ? 插件板中信号传输速率的提高, 传输线效应也变得逐渐重要 ? 在设计ASIC时就不得不考虑它们最后在电路板中的实际应用. 3.3 VEIFICATION STRATEGIES测试策略Decide on a black or white-box approach for various levels of granularity. 根据粒度级决定用黑箱或白箱模型处理? 如果给定了所要测试的功能, 就要制定相应的测试策略 ? 要确定测试的粒度, 还要确定每个粒度所采用的测试实例的类型 ? 测试实例可以是白箱或黑箱, 取决于测试对象内部结构的可见性以及 对它的了解程度 Decide on the level of abstraction where the tescases will be specified. 确定测试实例的抽象级? 确定主要测试的抽象程度, ? 抽象程度越高, 测试对象的粒度越大, 时序和激发和响应之间 协调的可控性变差, 容易产生大量的激发信号并需测试较长 时间的响应 ? 如果需要对具体的测试实例进行控制, 则要降低抽象程度 A processor interface could be verified at the cycle or device driver level (处理器接口可以)在时钟或设备驱动 级测试处理器接口可以在单个的读和写周期级别进行测试, 需要每个测试实例对存储器映射寄存器有较深的了解, 并知 道如何对其进行编程 接口也可以在设备驱动器级别进行驱动, 测试实例也可以调用较高级别的子程序来完成操作， 每一 项操作都是由很多的读周期和写周期来说明存储器映射寄存器, 但测试实例可以不管这些具体细节. 3.3.1 Verifying the Response测试响应Plan how you will check the response 计划如何检验响应? 进行激发相对来说容易些, 可以控制激发的时序和过程 ? 难就难在测试响应检测相对困难, 需要确定预期输出, 并要证明测 试对象所产生的就是预期输出. ? 在”预测输出” (后页章节)提出了几种方法, 可以用于输出测试 Some responses are difficult to verify in the simulation 测试中某些响应的分析是困难的? 建议采用自检测试平台( 见”测试输出” ) ? 有时在人看来一目了然的响应, 测试平台却很难测试, ? 例：测试图形引擎就必须验证图形中包含具体内容, 自检在检测图中的 单个像素点会很有效, 然而, 人在检验整个填充红色的整个圆时效率要高 的多 ? 测试策略就必须找到一种方法, 使得这些测试实例自动运行. Detect errors as early as possible 尽可能早的检出 错误? 如果在模拟过程中产生一系列输出结果, 随后能和参考值进行比 较, 效率可以高得多。 ? 输出结果可以在模拟过程之外进行进一步处理, 以确定模拟成功 与否 ? 及早发现错误可以提高效率。如果响应能在模拟过程中进行检测, 就能在出错时及时发现错误, 改正起来要容易得多. 3.3.2 Random Verification随机测试Random verification still provides valid stimulus 随机测试提供有效的模拟 ? 随机测试中, 输入是由合法的单个操作来控制, 如读 周期和以太网数据包 ? 所谓随机指的是这些操作的顺序和传送的数据 Random verification will create conditions you did not think of. 可产生预料之外的条件 ? 随机模拟可以产生你在编写测试计划时没有考虑到的 情况 ? 用途：产生意外情况和边缘条件, 能校正测试人员在编 写测试平台时的偏差 ? 它产生的激发信号更接近实际情况, ? 当正在建立一两个接口的测试实例, 随机激发还可以用 来产生其它接口上的后台运行. They are complex to specify and code.随机模拟说 明和编码复杂? 数据和操作的顺序必须和测试对象在实际中一致 ? 随机模拟要说明数据和操作的范围和分布. ? 更为复杂的是预测预期输出－既然不知道要产生什么 样的激发信号, 又怎么知道其响应? ? 随机测试必须找到一种方法, 能检测到非法响应 Random simulations are usually used at the system level 随机模拟常用于系统级? 因为实现起来比较复杂, 所以随机测试通常用于粒度较 大的情况 ? 很多设计单元和较小的模块都能有单独的模拟环境. 一 种可行的方法是进行随机测试, 以测试计划, 源代码和 功能覆盖为依据, 随机模拟完全可以包含进单个的测试 实例里面. 3.4 FROM SPECIFICATION TO FEATURES 从说明到特性? 编写测试计划的第一步是从说明文件中统计出要测试的 特性 ? 系统工程师和RTL编码人员, 要继续提出所要测试的附 加特性 ? 附加特性在要求说明中必须一目了然, 对设计的目的和 特点不了解的人也能看懂 Label each feature 标记每一个特性? 所有的特性都应该有标记并附加简短的说明 ? 在说明这些特性时还要说明哪些需要测试, 以及如何 在设计中实现该特性 ? 每个特性都应该有索引, 可以在要求说明文件中找到 详加说明的章节或段落, ? 最好是在要求说明文件中也有索引, 可以在测试计划 中检测到该特性, 例 ：UART设计中的某些特征 ①当UART能够接收一个字并通过CPU接口发送时, 必 须 使清除发送端(CTS)有效, 见UART要求说明文件的 4.2节. ②状态寄存器中的CTS位必须反映CTS端的状态, 见表 A.2. ③当CPU接口可以读取接收数据时, 必须使数据就绪端 (DTR)有效, 见UART要求说明文件的4.1节. ④状态寄存器的DTR端必须反映DTR端的状态, 见表A.2. ⑤数据位串行发送和接收, 先送最低有效位, 见UART要 求说明文件的5.2节. 3.4.1 Component-Level Features组件级特征这里所说的组件, 可以是一个单元, 一个可再用组件, 或者整个的ASIC, 组件级特征完全包含在所要测试的组件中, 其中并不 包括和其它组件的系统级接口, 在测试其正确性时不 需要依赖于更高级别组合的正确性. 大部分的特征都是组件级特征, 在进行系统级测试时 必须假定这些特征都是正确的 3.4.2 System-Level Features系统级特征一个系统可以是一个ASIC, 来自不同电路板的几个ASIC, 整个电路板, 或是整件产品. 系统级模拟结构较大, 运行时间较长, 所以要尽量减少系 统级特征 对于所有的系统级特征, 都要考虑一下能否用组件级特 征来代替 MX ASIC在软件控制的条件下, 可以在ASIC ID0和ID1的数据之间进 行选择，这种选择特征是系统级特征吗?答案是否定的. 该特征完全包含在MX ASIC中, 因此是一个组件级特征 ? 系统级特征通常仅限于连接性, 流控和互操作性, ? 例如, 输入接口和输出接口的连接就是一个系统级特征, 在测试连 接时, 有必要把输入从ID0切换到ID1, 这种切换不是测试的目的, 我 们假定它能实现. ? 另一个系统级测试实例是MX ASIC中的FIFO, 它能通过ID0和ID1 产生反压, 并中止数据传送, 直到清除阻塞 3.4.3 Error Types to Look For查找错误类型Assume design tools do not introduce functional errors 假定设计工具不会引起功能错? 在列举所要测试的特征时, 我们都在无意中假设了一定会出错并且 一定能被找出来, ? 功能测试能够找出设计的功能错误, 但设计工具如果有问题它就无 能为力了 ? 功能模拟能够保证测试对象能按要求实现功能, 但前提是设计者自 己不出错 ? 比如, 在门级线网表运行所有的功能测试平台只能证明合成工具没 错, 要做到这一点, 采用正规测试或静态定时工具其实更好些. Likely errors are different based on the capture tool used. 相似的错，使用不同工具检出是有名同的? 用不同的检测工具, 所检测出来的错误类型也就不一样, ? 如果用的是原理图检错工具, 检测出来的就会是连接错误, ? 总线中数据位倒序, 和总线中单个位没连接之类的错误, 在RTL编码 和逻辑合成环境中, 就不易检测到这类错误, ? 如果总线连接正确, 要么所有的位都正确, 要么都不行. ? 检错工具能检测到一些连接上的问题, 如一条线上的多路驱动器, 或 者输出结果丢失, 对于这类错误, 它更为实用些 Look for functional errors.查找功能错误? 在基于合成的设计中常见的错误包括极性错误, 违反协议和计算错 误 ? 在原理图检测过程中证明有用的激发信号在RTL检测中就不一定 管用, 一对0和1的转换, 如”0xAAAA”后接”0x5555”, 就可以实现检测. ? 在数据流中使用签名是另外一种检测功能错误的好方法, 签名可以 是一个序列号, 用以检测数据丢失和数据重复, 签名还可以鉴别数 据的源址和目的址. 例如, 和写周期的地址相关的数据可以包括一 部分地址并能鉴别发送该周期的总线 3.5 From Features to Testcases 从特征到测试实例3.5.1 Prioritize 优先级别? 并非所有的特征都是同等的重要, 对所有的特征统计完后, 就必须对 它们排列优先级别, ? 在实现功能或满足客户需要方面, 有些特征是”必不可少”的, 决定了 是否能首次测试成功, 这些特征的测试决定了项目是否能如期完成 ? 测试”必不可少”特征的测试平台处于关键路径, 这些”必不可少”的特 征必须在所有可能的配置和用法选项中进行测试 Less important features receive less attention? 有些特征是”应该有的”, 但它们在设计时并不是优先考虑的, 它们只 是用来扩展功能或为了在竞争中获得有利地位, ? 保证基本功能的实现前题, 在时间和资源允许的情况下, 可以对这 类特征进行仔细的测试, ? 但如果时间不允许或是有更重要的特征等着测试, 也可以不必测试.Some features are verified only as time allows? 还有一类”最好有的”特征, 它们完全是可选的, 而且只是在时间允许 的情况下才测试, 并也只是粗略的测试一下 ? 一般设计的进度安排都比较紧, 所以一般都没有测试 Make an informed decision when cutting back on the verification effort.? 对所要测试的特征排列优先级别, 这样项目经理在进度较紧的情况 下, 就可以酌情取消某些测试, ? 如果时间更为紧迫的话, 还可以取消某些”应该有的”特征的测试. ? 省却对某些 ”应该有的”特征的测试的话, 就要对项目的市场目标重 新进行评估 3.5.2 Group into Testcases 组合成测试实例特征分类? 特征可以进行分类, 某些特征在测试时用相似的配置, 粒度和测试 方法 ? 为了提高效率, 同一类特征可以分配给一个测试人员 ? 例, 所有和CPU接口有关的特征应该归为一类, UART的波特率, 数 据位和奇偶产生的测试应该归为一类。 ? 每一类特征的测试构成一个测试实例. 标注? 每个测试实例都应该进行标注, 并对其目的进行简短说明 ? 说明中应该列举所有在测试实例中测试的特征 ? 每个特征也应该给出注释, 说明在哪一个测试实例中测试, ? 如果特征没有注明相应的测试实例, 就不会得到测试. ? 测试实例的说明中要列举已经假定实现了的特征, 根据这些, 可以确 定测试的顺序, 确定哪些测试可以并行处理. ? 要说明测试实例的激发信号的顺序和特点, 例如, 要描述各种操作和 总线周期, 对于随机测试实例, 还要说明输入数据的范围和分布, 以 及操作的类型. ? 测试实例不仅要给出预期响应, 还要说明如何确定响应是合法的, 这 包括预期的数值, 定时和协议, ? 例： 数据包处理器的输出只有在目的地址和输出端口一致的情况下 才算是正确的, 或者, 还可以加上一个更严格的要求, 来自不同源址 的数据包以一定的顺序产生, 并服从一定的形态分布. ? 更为明确的方法是直接列出所要查找的错误, 例如, 看一个数据包的CRC校验值是否正确, 还可以检查互斥事件, 比如同时向FIFO写入full和empty值, 如果一个测试人员对设计不是很了解的话, 明确所要查找的错误可以 使他写出更为可靠的测试平台. ? 别相信一个测试平台没有产生任何出错信息, 每个测试实例都会插入 一些错误, 以便确认是否能被测试平台检测到, 如果没有检测到出错, 只能证明测试实例失败, 比如, 测试UART的奇偶位的测试实例会故意 弄错奇偶位, 来看测试平台是否能检测出 第四章 行为硬件描述语言BEHAVIORAL HARDWARE DESCRIPTION LANGUAGES 大部分的硬件设计人员都有一种“RTL思维模式”, 一 个合格的测试人员应该打破这种思维模式 要想有效的完成测试工作, 你必须精通行为(也就是 不可合成的和高度算法化的)描述方式 为了正确可靠的使用VHDL和Verilog的行为结构, 必 须了解其模拟算法的边缘作用和该种语言的局限性, 还要知道如何去避免, 而在建立RTL模型时就不用了 解这么多. 4.1BEHAVORAL VERSUS RTL THINKING 行为思维模式和RTL思维模式之比较建立RTL模型和建立行为描述模型的区别几乎所有的硬件设计人员在建立可综合的模型时都比较得心 应手, 因为这时仅局限于一个定义好的VHDL和Verilog集合, 只需 要遵循某一种编码风格即可。毕竟有很多的RTL编码指导书可供 借鉴, 这些书可以帮助设计人员有效的进行设计, 可以实现体积小, 高速和低功耗。 例4-1所示的指导规则就可以帮助设计人员中的新手避免不必要的硬件组件设 计, 如锁存器, 内部总线和三态缓存之类. 更重要的是, 这些指导规则可以在可综合 的模型和门级设计之间维持等价行为, 如例4-2所示.例4-1 避免不必要的硬件结构的 RTL编码指导规则 为了避免锁存, 组合模块所有 的 输出值设为缺省值. 为了避免内部总线, 不要从两 个不同的always模块给regs赋值 (只对Verilog而言). 为了避免三态缓冲, 不要 赋’Z’(VHDL) or 1’bz(Verilog)例4-2 保持模拟行为等价的RTL编 码指导规则 所有的输入都要列入组合成模 块的敏感量列表. 时钟和异步复位必须列入串 行时钟的敏感量列表. 在给reg赋值, 准备作为一个触 发器的情况下, 要采用非阻塞赋 值 是否遵从了可合成集合和正确的编码规则, 很容易就可以通过检错工具 进行检测 如果经过几个月的锻炼, 设计人员基本上就可以接受这种方式： 状态机 操作符 多路选择器 解码器 锁存器 时钟 Do not use RTL-like code when writing test-benches可合成子集在描述特定设计的实现时是足够的 VHDL和Verilog可合成子集是由合成方法来描述的, 用来说明硬 件结构和寄存器之间的逻辑转换, 符合逻辑合成规则. 如果只是建立测试平台, 而没有用硬件来实现, 这时可合成子集 就远远不够了. 两种硬件描述语言都有着丰富的结构和语句, 如果在建立测试平 台时还局限于RTL思维模式, 局限于设计底层硬件结构时的编码 方式, 将不能完全体现这种语言的作用, 测试工作也会变得单调 而复杂 4.1.1 Contrasting the Approaches 两种编码方式的比较例：一个简单的握手协议, 用VHDL或Verilog来实现? 检测到在产生一个请求信号(REQ)之后产生了一个应答信号(ACK) ? 检测到应答信号之后, 就清除请求信号, 随后应答信号也被清除 type STATE_TYP is (… , MAKE_REQ, RELEASE,…); signa1 STATE, NEXT_STATE: STATE_TYP; … COMB: process (STATE, ACK) begin NEXT_STATE &= STATE; case STATE is … when MAKE_REQ =& REQ &= ‘1’; if ACK ='1' then NEXT_STATE &= RELEASE; end if: when RELESE =& REQ &= ’0’ ; if ACK = '0' then NEXT_STATE &=...; … end process COMB;RTL思维模式举例硬件设计人员有着RTL 思维模式, 所写的对应的 VHDL代码需要用28行代码和两个过程 来实现, 如果状态机更为复杂的 话, 还需要两个额外的状态 SEQ: process (CLK) begin if CLK' event and CLK ='l' then if RESET = '1' then STATE &=...; else STATE &= NEXT_STATE; end process SEQ; 行为描述思维模式测试人员有着行为思维模式, 只会注重协议的行为, 而不会用状 态机来实现, 相应的代码如下, 其功能只是用简单的四条语句来 描述process begin … REQ &= ’l’; wait until ACK ='l'; REQ &= ’0’; wait until ACK ='0'; …? 检测到在产生一个请求信号(REQ) 之后产生了一个应答信号(ACK) ? 检测到应答信号之后, 就清除请求 信号, 随后应答信号也被清除 采用行为描述模型可以提高模拟性能假设在请求信号和对应的响应信号之间有较长的延时, 可合 成模型将在时钟的每个转换点执行SEQ过程(因为该过程对 时钟信号敏感), 而行为模型则一直在监测应答信号的状态, 只有在协议完全 满足时才恢复运行 如果应答信号有10个时钟周期的延时, 这意味着该过程的执 行次数从可合成模型中的40次减少到行为描述模型中的2次, 或者说模拟性能提高了1900%. 4.2 You Gotta Have Style !必须有自己的风格可合成子集对编码方式有所限制, 有些不太熟练的硬件设计人员 写出来的RTL代码既难懂, 又难维护, 行为描述模型有着完全的自由, 很多很熟练的设计人员写出来的 测试代码也是既不简练, 可维护性也不好 4.2.1 A Question of Discipline关于严谨的问题Write maintainable, robust code.写可维护的代码 Invest time now save support time later.在编码时多 投入一点时间，在维护时要省很多事 4.2.2 Optimize the Right Thing进行合理的优化注意设计的可维护性, 在编写可合成代码时也是如此 在对代码进行优化之前, 要确定它的确需要优化, 如果它已经符合 所有的要求, 就没有必要进行优化了 在编写代码时，可维护性是最重要的一个方面, 因为人们在代码的 理解和支持上投入最多. 压缩代码行数一般没有什么经济价值, 除非能提高代码 的可维护性, 例：如果按一行50个字符计算, 减少一行代码只能节省50个字节的存储 空间, 现在100G的硬盘价格还不到$200, 省一行也不过是省了 200*8*50/100G 。 节省的打印时间, 按每秒钟一字节算, 如果一个设计人员一年的劳动 价值是10万美元的话, 那么也只是省了0.69美元。 如果因此而降低了它的可理解性, 使得运行时间延长了5分钟, 那么 成本就要增加4.17美元。 综合节省和增加的成本, 总的成本增加了3.48美元, 并且这只是省一 行的代价。 对代码的性能进行优化会增加成本assign next_grant[0]= ~reset & (request[0] & 如果代码已经符合要求, 就不要进行 (~request[1]Olast_winner )); 优化, 可合成代码也是如此。 Sample Synthesizeable code for 2-bit assign next_grant[l] = round robin arbiter ~reset & (reguest[l] & modu1e rrarb(reguest, grant, reset, (~request[0]| ~last_winner)); clk); assign winner = input [l:0] ~reset & ~next_grant[0] & output [l:0] (last_winner O next_grant[l]); always @ (posedge clk) last_winner = reg last_winner grant = next_ reg [1:0] end wire [1:0] next_ endmodule优化会降低代码的可维护性, RTL code can be too close to schematic capture例中在某些方面还是注意了可维护性: 标识符示意明确, 也注 意了某些行的缩进问题. 然而, 它在实现可合成解码时用了一连串的赋值语句, 这表明 该设计人员是从布尔等式的角度考虑的, 甚至是从原理图的角 度考虑的, 而没有着眼于功能. 这种设计方法使得哪怕对设计作很小的改动都很困难, 如果 你想进一步确定到底难在何处, 不妨在没有请求信号时观察 last-winner寄存器的内容 另一个潜在的问题是在always模块中赋值时所产生的竞态条件 Specify function first. Optimize implementation second - and only if needed.Synthesizeable code for 2-bit round robin arbitermodule rrarb (reguest, grant, reset, clk); input [l:0] output [1:0] reg [l:0] reg last_ always @ (posedge clk)begin if (reset) begin grant &= 2'b00; last_winner &= 0; end. else begin grant &= 2'b00; if (reguest != 2'b00) begin: find_ case (reguest) 2' b01: winner = 0; 2' b10: winner =1; 2' b11: if (last_winner == 1'b0) winner = 1; else winner = 0; endcase grant[winner] &= 1'b1; last_winner &= end end end 可维护性 endmodule 4.2.3 Good Comments Improve Maintainability 适当的注释可以提高可维护性加上注释能减少投入 有人可能会说减少代码的行数能使程序语句较少, 更加清晰, 但是, 注释的首要目的是提高代码的可维护性, 没人能说代码行 数越少越好。 注释和代码一样, 也有好差之分, 过时的和没用的注释比没有注 释还要糟, 因为它会引起误解。 含义模糊的代码用处也不大, 在注释代码时最容易犯的毛病是直 接重复该行的作用, 如例所示。- -- Increment addrPoor comment：addr: = addr + 注释应该说明代码的目的, 它提供的信息是对设计本身不是 很了解的人所不知道的. Sample 4-8 Proper comments -- In burst mode, the bytes are written in -- Consecutive addresses. Need to access the -- next address to verify that tone next byte -- was properly saved. addr := acdr + l: 在注释代码时, 应该假设你的用户对该语言很精通, 但对设计本身 不是很了解。 最理想的状况是, 不看一个文件的源代码而只看其注释也能知道 它实现了什么功能。 4.3 STRUCTURE OF BEHAV1ORAL CODE 行为描述代码的结构如何对行为描述代码进行构造和封装, 以获得最好的可维护性 封装可以隐藏实现细节并对可再用的 代码打包. RTL models require a well-defined structure strategy RTL模型须要好的结构构造代码的过程把功能的各部分分配给各个模块和实体 模块和实体合起来实现整个设计的功能 在构造可合成代码时通常只考虑到合成工具的限制, 而没有 考虑功能. Testbenches are structured according to functional needs 根据功能构建Testbench用VHDL和Verilog行为描述代码实现的测试平台不存在类似的 工具方面的限制, 你可以随意的构造代码。 为了提高可维护性, 行为描述代码当然最好是根据功能或用途 来构造。 如果一个功能特别复杂, 可以把它分成较小的, 易于实现的子功 能。 如果一个功能要用到很多次, 最好单独进行构造和测试, 这样在 重复使用时就不用再投入时间。 表 Available constructs forVHDstructuring code VerilogModule Function Task ModuleEntity and architecture Function Procedure Package and package body 4.3.1 Encapsulation Hides Implementation Details 封装可以隐藏实现细节封装是构造方法的一个具体应用, 封装的主要思想是隐藏实 现细节并把其功能和实现过程分离。 目的：只要接口不变, 就可以对实现过程进行修改和优化而 不影响用户。 最简单的封装方法是尽可能的采用局部变量, 这样可以避免 和代码中其它用到该变量的部分产生冲突。 Sample ：Improper encapsulation of loc always begin for (i=0; i&32; i=i+l) begin … end end alwavs beqin for (i=l5; i&=0; i=i-l) begin. … end end例中所示的问题：两个always模块在循环语 句中都用寄存器 i 作为计 数器, 但 i 又是一个全局 变量 可能会引起相互冲突, 产 生不可预料的结果. In Verilog, put local declarations in named blocksbegin/end模块中声明 寄存器 对递增量进行封装, 最 好就是在每个always模 块中进行局部定义只要正确封装, 局部变量 就不会被其它的always或initial 模块访问, 也就不会产生不可 预料的结果。Sample. Proper encapsulation of local objects always begin: b1ock_1 for (i=0; i&32; i=i+1) begin ... end end always begin: b1ock_2 for (i=15; i&=0; i=i-1) begin ... end end Verilog中另一个可以定 义局部寄存器的场合 是任务和函数, 在VHDL中, 可以在任 何begin关键字之前进 行定义Sample. Local declarations in tasks and input [7:0] begin … end endtask function [3l:0] input [31:0] Val1; input [3l:0] val2; reg [32:0] begin sum=val1+val2; averaqe=sum/2; end end function 4.3.2 Encapsulating Useful Subprograms 封装有用的子程序有些函数和过程在整个项目甚至很多测试平台中都能用到, 如 果在每个用到的地方都进行拷贝, 无疑会增大维护的难度, 因 为它对所产生的信息也会进行拷贝 VHDL有一种程序包可以对在多个实体和结构中用到的定义 量进行封装 Verilog不能做到这一点, 但它有其它的方法可以实现这个目的. Example: error reporting routines错误报告程序如：在很多测试平台中用到的过程是出错报告例程, 为了获得一致 的出错报告格式，在模拟的过程中要用一系列标准的例程来产生 出错信息 在VHDL中, 它是用程序包中的过程来实现的。 在Verilog中, 它是用任务来实现的。 Verilog packages can be simple include filesSample. Using tasks packaged using ‘include file in Ver ‘ include. “syslog.vh.” initial begin ... if (...) error ('Unexpected response\n& ); ... end endmodule封装方法： 把任务放在一个文件 中, 通过一个编译器指 令把它包含进将要用 到它的模块中去。 Tasks can be packaged in a module and used using a hierarchical name. 封装方法：把任务 放进模块, 然后包 含在模拟过程中 能够独立编译Sample 4-13. syslog.vh: packaging tasks using ‘include file in Verilog input [80*8:1] begin $write ('WARNING at %t: %s&, $time, msg); end input [80*8:1] beqin $write(“-ERROR- at %t: %s', $time, msg); en input [80*8 l] begin $write (&*FATAn* ac %t: %s', $time, msg); End end
begin $write(&simulation completed\n&); $ end endtask Sample 4-14. Packaging tasks using a module in Verilog. Module sys initial begin warnings = 0; errors = 0; input [80*8:l] begin $write(&WARNING at %t: %s”, $time,'msg); warnings = warnings + 1; end endtask ... endmodule Sample 4- l5. Using tasks packaged using a module in Verilog M Intital begin ... if (. . . ) syslog error (“unexpected response”); ... end endmodule 4.3.3 Encapsulating Bus-Functional Models 封装总线功能模型总线功能模型：通过任务和过程用复杂的波形和协议把数据赋 给测试对象 总线功能模型被很多测试平台用到, 如果它所模拟的是一个标准 接口, 如一个PCI总线或是Utopia接口, 甚至可以在不同的项目中 用到。正确封装有利于重复利用.? 图：一个总线功能模型的模块图 ? 它按预定的协议驱动底层信号并 采样 ? 子程序可以用来对特定的数值进 行处理（过程接口）。 Sample 4_16 Encapsulating bus-functional models in VHDL use ieee.std_logic_1164. package cpu is subtype byte is std_logic_vector(7 downto 0); procedure write( variable wadd:) variable wdat: signal addr: signal data: signal rw: out std_ signal ale: out std_ signal vald: out std_logic); use ieee.numric_std. package body cpu is procedure write( variable wadd: variable wdat: signal addr: signal data: signal rw: out std_ signal ale: out std_ signal vald: in std_logic) is constant Tas: time=10VHDL总线功能模型是用程 序包中的过程来实现的begin if vald /='0' then wait until vald = '0'; addr &= std_logic_Vector(unsigned(wadd,8)); data &= std_logic_vector(unsigned(data,8)); rw &=’0’; wait for T ale &= ’l’; wait until vald =‘1'; Ale &= '0'; In VHDL, use procedures with signal arguments In Verilog Task arguments are passed by value only在Verilog中, 用任务来实现总线功能模型(底层信号直接传给 任务), 在任务的调用和返回的过程中, Verilog的自变量是通过value来 传递的, 在其它时间不能通过接口向任务赋值或是任务读值。 Sample 4-17. Task arguments in Verilog are passed by value Module arbiter task request output bus_ input bus_ begin //The new value does not “flow” out bus_rq &= 1’b1; end endtask endmodule例4-17所示的任务： 在任务返回之前给busrq赋值不会对外部造成 任何影响 任务在wait语句检测到 bus-gt信号置位之前不 会返回 调用任务时bus-gt的值 不会改变. Sample 4-18. Signal interface on Verilog package module arbiter ( bus_rq, bus_gt ); output bus_ input bus_ begin //The new value “flows” out through the pin bus_rq &= 1’ //And changes “flow” in as well wait bus_gt==1’b1; end endtask endmodule修改以解决问题： 不通过任务的接口传送 信号, 而通过实现包装的 模ku块接口进行传送 4.4DATA ABSTRACTION数据抽象Synthesizeable models are limited to bits and vectors.逻辑合成方法的局限性使得可合成子集仅限于处理数据格式：位, 位矢量和整数 行为描述代码则没有这种限制, 可以采用任意的数据表述形式Work at the same level as the design under verification.从”工作单元”这种粒度来考虑测试问题。不要让RTL思维模式束 缚，或者影响从更高的抽象级别进行考虑。 Abstracting date in Verilog requires creativity and discipline.VHDL能够很好的支持把数据抽象为更高级的形式 Verilog在这方面要差一点, 但只要采用合适的方法,很多功能能实现 的 Verilog的局限性较强, 将介绍如何用Verilog来实现各种数据抽象 VHDL中实现起来要容易的多, 只要参考相关的语法书即可. 4.4.1 Real Values实数值Use real when verifying DSP designs.测试数字信号处理器件, 实型将很有用处, 用浮点数更容易计算 出滤波器的预期输出值。 例：计算yn = a0 xn + a1xn-1 + a2xn-2 +b1yn-1 + b2yn-2 Constants could be defined using define symbols.最好用define宏定义符来定义在整个测试实例中保持不变 的 值，．如系数。 例：定义系数yn = a0 xn + a1xn-1 + a2xn-2 +b1yn-1 + b2yn-2Sample 4-19. Coefficients defined using define symbols Define Define define define define a0 a1 a2 b1 b2 0.....009672define定义符在编译中是全局 的, 这违反数据封装规则 占用了全局命名空间, 使得别 人不能使用相同的符号 Defining them as parameters is betterSample 4-20. Coefficients defined using parameters 解决方法： Parameter: a0 = 0.500000, a1 = 1.125987, a2 =-0.097743, b1 =-l.009373, b2 = 0.009672; 对于模块来说就是 局部的 定义为参数 Implement the filler equation as a functionVerilog中所有的寄存器都是静态的(也就是说它们在编译时间就分 配好了, 然后就一直保持不变), 所以滤波器的实数值保存在函数局 部定义的寄存器内. Verilog局限性: 实数值不能通过接口传送。解决办法： 在实数值和 64位矢量之间进行转换，分别用$realtobits和$bitstoreal。 VHDL中, 用实数组类型的常量来解决, 优点是能用for-loop语句进 行计算, 这种方法简单有效, 并且和滤波器的数目无关。在Verilog， 可以用一个由64位寄存器组成的存储器, 其中每个存储位置都有一 个系数转化为位矢量。 Sample 4-21. Function computing the next output va input (63:0) real xn_1,xn_2; real yn_1,yn_2; begin //Computer next output value yn = a0 *$bitstoreal(xn)+ a1 * xn_1 + a2 * xn_2 + b1 * yn_1 + b2 * yn_2 + ; //shift state of the filter xn_2 = xn_1; xn_1=$bitstoreal(xn); yn_2=yn_1; yn_1= end endfunction initial begin: test_ //Reset the filter yn.xn_1=0.0; yn.yn_1=0.0; y yn.xn_2=0.0; yn.yn_2=0.0;//compute the response to an impulse = yn($bitstoreal(1.0)); y end end = yn($bitstoreal(0.0)); repeat (99) begin Sample 4-22.Proper implementation in VHDL type real_array_typ is array( natural range&& ) constant a: real_array_typ(0 to 2):= (0=&0.=&1.=&-0.097743); constant b: real_array_typ (1 to 2) := (1=&-1.=&0.09672); Use a conversion function to translate into a fixed point representationSample 4-24. Converting a real function [15:0] to_ input [63:0] value to a fixed point value // fixed-point number format: s1.ffffffffffffff // sign(1=negative // integer portion 1 begin Co_fixpnt = 16'h0000; c = $bitstoreal(coeff); if (c & 0) begin to_fixpnt[15] = 1'b1; c = -c; end to_fixpnt[14:0] = c * 'h4000; end endfunction 有了这些实用函数, 测试平台就变得既容易实现, 又容易理解initial begin: test_ // Initialize prediction funnction yn.xn_1 = 0.0; yn.xn_2 = 0.0; yn.yn_1 = 0.0; yn.yn_2 = 0.0; // Reset the desiqn ... // program the coefficient cpu_write('A0_AdDR, to_fixpnt(a0)); cpu_write('A1_ADDR, to_fixpnt(a1)); cpu_Write('A2_ADDR, to_fixpnt(a2)); cpu_write('B1_ADDR, to_fixPnt(b1)); cpu_write('B2_ADDR, to_fixpnt(b2)); // Verify the response to an impulse inputSample 4-25. DSP testcasexn = 1.0; repeat (100) begin: test_one_ data_in = to_fiXPnt(xn); expect = yn($realtobits(xn)); @ (posedge clk); if (expect !== to_real(data_out))... xn = 0.0; end $ end 4.4.2 Records 记录记录中所描述的是各种各样的信息, 这一节将介绍如何在 Verilog中建立记录. 记录最理想的应用场合是数据包和数据帧, 因为这时控制和信 号信息是和用户信息组合在一起的 Sample 4-26. VHDL record for an ATM cell type atm_payload_type is array (0 to 47 ) of integer range 0 to 255; type atm_cell_typ is record vpi : integer range 0 to 4095; vci : integer range 0 to 65535; pt : bit--vector (2 downto 0); clp : hec : bit_vector (7 downto 0); payload: atm_ payload_ 例ATM信元记录的 VHDL定义 一个ATM信元的固定 长度是53字节, 其中48 个字节是用户数据. Verilog不直接支持 记录, 但可以建立伪 记录 模块中的任何定义 都可以用层名来访 问 一个模块可以只包 括寄存器定义, 以模 仿记录 在进行记录的时候, 每个模块实例模仿 记录的一个域。Sample 4-27. Verilog record for an ATM cell module atm_cell_ reg [11:0] vpi: reg [15:0] reg [ 2:0] reg [ 7:0] req [ 7:0] payload [0:47]; endmo atm_cell_typ cell(); initial begin: test_ cell.vci = 0; ... for (i=0; i&48; i=i+1) begin cell.payload[i]=8'hFF; end end endmodule 4.5 Files文件尽量避免在测试平台中采用内部输入文件测试平台和测试对象的配置管理是相当复杂的, 如果不是有着很 丰富的实践经验, 在测试中很难保证所测试的设计正确, 并且所 用的测试平台也正确。 如果要保证输入文件的正确性, 而这些输入文件通常是由另外一 些文件格式的下标所产生的, 会极大的增加配置管理的复杂程 度。 Verilog存储器进行初始化Sample 4-42. Initializing a Verilog memory using an external file. reg [7:0] pattern [0:55]; initial $readmemh(pattern, &pattern.memh& ); endmodule Sample 4-43.Explicitly initializing a Verilog me reg [7: 0] pattern [0: 55]; initial begin pattern[0] = 8'h00; pattern[1] = 8'hFF;例4-43中产生了Verilog代码 和例4-42中的文件数据等价pattern[55] = 8'hC0 end endmodule 4.5.1 Interfacing High-Level Data Types 高级数据类型接口一般很少对需要测试的设备直接采用高级数据类 复杂的数据结构必须在位级别对测试对象进行读写, 通常还包括 同步信号, 帧信号和握手信号. 第5章讲到如何用总线功能模型从复杂的数据结构对设计进行输 入 4.6 THE HDL PARALLEL ENGINE HDL并列引擎硬件模型设计所必须的三个要素: 连接性 时序性 并行性. 4.6.1 Connectivity Time, and Concurrency 连接性, 时序性和并行性连接性：用简单模块的连接在一起来实现设计。 作图工具就是支持连接性的. 时序性：表述设计的内部状态是如何随时间而变化的 与执行时间的概念不同, 执行时间只是用来计量程序运行 时间的. 并行性：描述相互独立操作并行运行。 4.6.2 Connectivity, Time, and Concurrency in HDLs HDL中的连接}
IC测试技术―设计验证
Digital Circuit Functional Verification 本课程的目的:1. 建立数字集成电路的测试概念与基本方法； 2. 测试是基于数字集成电路的功能； 3. 用于电路的功能设计阶段； 4. 对于数字集成电路而言，是前工序阶段，对前工序的 结果正确定进行测试验证； 5. 适用于FPGA或CPLD设计的功能电路测试; 6. 目标：解决testbench建立的问题 为什么要研究测试1. 随着门电路数目和系统复杂性以指数倍增，在产品 设计中使工程师最费神的将会是：功能测试。 2. 硬件设计人员中间调查发现，60%到80%的时间是 花在测试上的。 3. 使得系统测试更加快捷和精确的关键在于工具的改 进和方法的革新 4. 测试方面缺乏成熟而系统的理论指导 5. 未来最好的测试方法将会是独立于开发工具的，以 便于随时采用更为先进的方法来进行测试 预备知识1. 用VHDL和Verilog来对硬件设计进行功能测试， 至少要对其中的一种语言有基本的了解 2. 最好能有建立可综合(synthesizable)模型的经 验，并且能熟练使用VHDL或Verilog来进行模拟 (simulators)。 3. 对数字硬件设计有一个基本的了解 第一章什么是测试？What is Verification ? 什么是测试？一个验证某个设计的功能是否正确实现的过程。 在此处: 测试并不是一个或一系列的测试平台本章主要内容1. 测试的基本概念，包括其重要性和花费 2. 各种测试方法及其特点，检测和测试的区别 3. 测试对于设计方案再用的重要性 1.1 测试平台对于VHDL和Verilog来说，测试平台是指为一种产生预 先设定的输入序列，然后观测响应的代码。 通常用VHDL和Verilog来实现，但可能同时包括外部数 据文件和C语言程序。 测试平台和测试对象的结构一个完全封闭的系 统 ，既没有外部输 入，也没有外部输 出 普遍适用的测试平 台模型TestbenchDesign Under Verification测试的目的: 1) 确定向测试对象输入向量， 2) 2)预期的测试对象输出。 1.2 测试的重要性测试占去总投入的70%以上? 集成电路上可能集成数以百万计的门电路。 ? 在可再用IP和片上集成系统（SoC）中，测试占去总投入的 70%以上。 ? 设计人员中要分出专门的人去进行测试，其中包括专职从事 测试的人员。测试人员通常是RTL设计人员的两倍。 ? 设计方案完成以后，建立测试平台的代码占代码总量的 80%。 同步作业可以缩短测试时间? 如果能同步作业，就可以有效的使用闲置的人力物力以缩短测试 时间。 ? 例如，在地上挖一口井，同步作业的方法就是给更多的工人提供 更多的铁锹。 ? 测试中采用同步作业的方法是建立测试平台和功能测试的过程与设计的实现过程同时进行。 提高抽象可以缩短测试时间? 提高抽象程度，开发人员就可以不必顾及某些细节而提高效率。 ? 提高抽象程度通常就意味着减少控制，因此必须慎重采用。 ? 较高的抽象程度也要求开发人员懂得一些抽象技术以及如何取得 理想的效果。 自动化技术能减少测试时间? 自动化技术要求过程规范，预先明确定义输入和输出。 ? 并非所有的过程都能自动完成。 ? 测试面临同样的问题。因为功能，接口，协议和转换格式的不 同，不可能从已有方法中找到一种普遍适用的自动测试技术。 ? 测试过程部份实现自动化还是可能的，尤其在应用领域不是那么 宽广的情况下，更是如此。 ? 对测试进行了一些标准定义，可能有助于在不久的将来实现自动 化。 1.3 重会聚模型(Re convergence Model)The reconvergence model is a conceptual representation ofthe verification process. It is used to illustrate what exactly is being verified Transformation测试什么？测试的目的是保证 传输(transformation)结 果和预先设想的一致。Re-convergent paths in verificationVerificationVerification of a transformation can only be accomplished through a second reconvergent path with a common source. The transformation can be any process that takes an input and produces an output. 1.4 人的因素 (The Hunan Factor)因素: 一个人或一个组从头到尾独立完成Example: RTL codingA design team interprets a written specification document and produces what they believe to be functionally correct synthesizeable HDL code. Usually, each engineer is left to verify that the code written is indeed functionally correct.Reconvergent paths in ambiguous situationRTL Coding Interpretation Specitication Verification 缺馅? 同一个人负责RTL编码和测试，测试又需要对测试要求作出具体说明，那么其 所根据的往往是这个说明，而非测试要求本身。 ? 可以通过测试来验证设计是否符合设计人员对测试要求所作的说明。 ? 如果说明本身是错误的，则测试永远都无法达到其要求。任何人为介入都会导致不稳定和不可重复 弥补措施? 自动化 ? 简化 ? 冗余 1.4.1自动化 (Automation )? Eliminate human Intervention. ? 自动化可以消除人为错误，因为它完全排除了人为介 入。 ? 并不是所有的过程都可以实现自动化，尤其是那些没 有很好定义，仍然需要人的创造性的场合，比如硬件 设计 14.2 简化(Poka-Yoka )? 把整个过程分解为简单可靠的步骤，只有在需要取得期望结果的特定步 骤才引进人为介入。 ? 这种技术在质量管理领域又叫poka-yaka。 ? 其离完全的自动化也只有一步之遥，所以它也只适用于严格定义了标准 转换步骤的过程。 14.3 冗余(Redundancy )? 求每个传输对象都是一式两份，传输过程则由两个人分别独立完 成，或对两个完全独立的传输过程的每一个输出结果进行比较，来 验证其结果是否一致。 ? 只有在高度可靠的情况下才使用，比如空运系统。 ? 在某些方面如果对产品的重新设计和更新成本更大，也可以采用这 种方法，例如ASIC设计。RTL coding Interpretation Specification Interpretation Redundancy in an ambiguous situation enables accurate verificationVerification 1.5 测试什么(WHAT IS BEING VERIFIED? )形式测试 形式测试分为两类：等量测试和模型测试。 1.5.1等量测试 (Equivalence Checking )Equivalence checking compares two modelsSythesis RTL or Netlist Equivalence Checking Equivalence checking paths RTL or NetlistIt can compare two netlists比较两个网表，以确保扫描链的插入，时间树的综合，以及人 为修改等，不会改变电路的功能 It can detect bugs in the synthesis software? 验证网表是否正确实现了原来RTL代码的功能。 ? 等量测试可以用来检验合成工具的可靠性。在少数场合，等量测试 可以检验手写RTL代码是否实现了门级设计要求。? 等量测试可以证明两种RTL编码在逻辑上等价。为了获得更好的合成效果， 对源代码作了一些小的修改，而又不影响其功能，就可以通过证明等价而避 免繁琐的模拟。Equivalence checking found a bug in an arithmetic operator 1.5.2 模型测试Model Checking模型测试技术是形式测试技术的最新发展成果，采用这种技 术可以检验一种设计的断言和特征。比方说，设计中的所有状态 机可以独立检测。还有一种功能更为强大的测试可以预测是否会 发生死锁。 另外一种可以进行形式测试的断言跟接口有关。首先用形式 描述语言来描述接口，然后用工具来检测它。例如，一个断言可 能会作如下定义，一旦产生了ALE信号，就会随之产生DTACK或 ABORT信号。 RTL coding Specification Interpretation RTL Model CheckingAssertionsFigure : Model checking paths模型测试技术困难之处在于利用对设计要求所作的说明，来鉴别所要检测的 断言。 在所有的断言中，只有一个子集可以进行检测。现有技术不能检测高级断 言，因此也不能保证能正确实现其复杂功能。 一种理想的情况是，在特定的寄存器状态下，异步传输（ATM）信元以相关 顺序输出。但模型测试技术不能做到这一点。 1.5.3 功能测试 (Functional Verification )功能测试的主要目地是确保设计能实现预期功能。功能测 试就是为了使设计符合其要Functional verification paths 功能测试局限You can prove the presence of bugs, but you cannot prove their absence ? 除非设计要求以精确的语法诉诸于正规的语言，否则无法证明设计 是否符合要求。 ? 描述设计要求的文件是由人用自然语言写成的，而各人正确表达自 己意思的能力又各不相同，人们可以对同一文件作出不同的解释。 ? 功能测试能够显示设计是否符合要求，但无法完全证明这一点。 ? 我们可以因为一点小小的不一致就说设计没有实现预期功能，反之 则不然：没有人能证明它完全一致。 1.5.4 建立测试平台(Testbench Generation )? 测试平台生成程序：按照代码覆盖规律，或利用某些经过证明的 结果，对源代码进行分析。 ? 生成测试平台，可以用来增加代码覆盖，或检验设计方案的某些 性质。 测试平台生成程序局限及用途Designer input is still required. The jury is still out on the usefulness at these tools. 测试对象通常都是RTL代码，没有重重会聚点。测试人员要判 断测试平台所给的激发信号是否有效，如果有效，则要知道预期的 输出结果，并把它和设计的输出比较 模型测试产生的测试平台不仅能用来描述某项特性可能不符 合要求，或者什么样的输入顺序可能引起错误。而且可以用来检 测到设计要求中没有考虑到的非正常状态，或者为解决问题提供 调试环境。 1.6 功能测试方法FUNCTIONAL VERIFICATION APPROACHES功能测试可以用三种不同但互补的方法： 黑箱测试 (black-box ) 白箱测试 (white-box ) 灰箱测试 (grey-box ) 1.6.1 黑箱测试(black-box Verification )黑箱测试是在对设计的具体情况一无所知的前提下进行的，所有的 测试都是利用外部接口，而不考虑起内部状态，更不知道其结构和 实现方法。 缺点: 缺乏可视性和可控性，很难进行状态组合或独立测试某些功 能，也难以观察它对输入的反应或找到问题所在之处。从出现问题 到它在输出结果中表现出来通常都有很长的延时。 优点: 不用考虑测试对象是如何实现其功能的，无论它是用ASIC， FPGA，电路板，还是用软件实现的，都无关紧要。黑箱测试可以 不考虑一项设计的实现方法，而只检测它是否实现了其功能 改进：在一些大型复杂设计中，黑箱测试可以作些非功能性的改进，以便实现某种程度的可视性和可控性。 例: 可以用一些可软件读写的寄存器来控制或观察内部状态，或修改 所处理数据的长度，以尽可能减少测试时间。这些寄存器在正常运行 时并不起作用，它们只是在原始系统的组合阶段才用到。黑箱测试方法的建立可以和设计同步进行，因为它是唯一可以事前 对设计本身一无所知的测试方法。 1.6.2 白箱测试 White-Box Verification白箱测试就是对测试对象的内部结构完全可见和可控。 优点：可以很快对状态和输入结果进行组合，或独立测试某项功能。 它能在测试的过程中随便观测任何结果，并能立即发现运行中出现的 错误。 缺点：和测试对象本身联系太紧密，换一个测试对象就不行了，也不 能用于将来的重新设计。它要求对设计过程有详细的了解，才能知道 要预设什么样的条件，要观察什么样的结果。 白箱测试和黑箱测试具有很强的互补性。 白箱测试能保证设计特定功能的实现，例如计数器到达计数终值翻 转，以及数据正确的传输过程和顺序。 1.6.3 灰箱测试(grey-box Verification)灰箱测试是在黑箱测试的独立性和白箱测试的依赖性之间取一个 折中。 因为前者不能完全测试设计的每一个部份，而后者太麻烦了。 灰箱测试可以通过最高级接口来控制和观测设计对象，这一点和 黑箱测试是相同的。同时也有针对设计特定功能的专门测试。 它对别的测试对象也可能适用，但这时候充其量也就只能当黑箱 测试用了 1.7 检测与测试的比较( TESTING VERSUSVERIFICATION )保证在功能上 实现设计要求最后的硬件结构和制 造工艺中的网表一致Thoroughness of testing depends on and observability of internal nodes.controllability 1.7.1 扫描测试(Scan-Based Testing )目的：扫描检测在某种程度上解决检测覆盖问题 方法：把所有的寄存器组成一个很长的串行链。在正常的状态下，寄存器正常工作，在扫描状态下，寄存器则表现为一个很长的移位 寄存器。 扫描检测方法? 进行扫描检测时，检测对象必须置于扫描状态，再用一个输入量移位通 过所有的寄存器。 ? 把检测对象置为正常状态，外加一个单时钟周期，把扫描状态下的正常 运行结果载入寄存器。 ? 再一次把检测对象置为扫描状态。由寄存器输出结果（同时输入下一个 变量），并把它和期望值比较。 为了能插入扫描链和自动产生检测形式，设计必须受到一些限制。这些 限制包括：完全的同步性，没有导出时钟和门控时钟，只能使用时钟的 单个边沿，等等。 1.7.2 为测试而设计? 设计方案作某些修订，以适应测试的要求。 ? 因为功能测试所花的时间是设计本身的两倍，所以完全有必要在设计 上多花点时间，以简化测试过程。 ? 正如设计中插入扫描链可以增加可检测性而不增加功能一样，应该在 设计中加入非功能性结构和特征以适应测试的需要。 ? 要求在一个项目的开始就考虑到测试，尤其是在制定要求的阶段。 ? 设计本身不仅要回答“要实现什么功能？”，而且要回答“如何来进行测 试？”。 ? 典型的技术包括: 额外提供可软件编码的的寄存器，以控制和观察内部 地址，或用另外的可编程器件来隔离或绕过某些功能部件。 1.7.3 测试与设计方案再用芯片上集成数量巨大的晶体管，而晶体管设计人员的数量却是有限的，唯 有用设计方案再用才能解决这个矛盾。 设计能够被再用的关键是取得别人的信任： 设计再用最大的障碍是人为差 异，设计人员都不大愿意在自己的设计过程中引进不熟悉的方法和结果，他 们认为别人设计的没有自己亲自设计的好，或着不如自己设计的可靠。 是否值得信任的特征是看有没有一个适当的测试过程。如果能向用户证明该 设计曾按照要求从头到尾认真测试过，那么就能取得用户的信任。 再用一项设计，只能通过功能测试来证明其正确性。因此，可再用设计和一 般的设计比起来，更需要通过测试来取得信任。 可再用设计需更加结构化，更具有可编程性，方能满足不同的环境条件和不 同的应用，所以所有可能的结构和应用都要测试到。可再用设计所有的特点 都要展示给用户，并作出测试。 1.8 测试费用(THE COST OF VERIFICATION )? 测试是一个看似永远都不会结束的过程。 ? 测试的目的是保证一个设计不出错，但任何人都不能证明设计完全没 错。 ? 测试只能证明有错，而不能证明无错，多花点时间，总能找到错误 的。问题是： a) 错误是否严重到值得花时间去寻找的地步？ b) 在测试上花的时间越多，在一定时间内能找到的错误就越少。 c) 到了后来，就几乎没有错误了。 d) 最后，花的时间越来越多，找出的错误越来越少，甚至找不出错误了。 功能测试判断类似统计假设检验。检验的假设条件是：设计是否能正确实现其功 能？答案可以是“是” 或“否” ，但两种答案都有可能出错。 两种错误答案分别是II型错误和I型错误 Error Bad Design Good Design Type I (False Negative)不严重：在没有错误的地方找 出错误。通过测试就把答案从 否定改为肯定，错误不再有。No Error Type II (False Positive)严重：测试没 有找到错误。 一个错误的设 计可能过关， 从而造成严重 的后果。 什么时候才算测试完？了解测试过程的大致进度，尽管不可能精确知道，但由此 可以推算出完成整个工作需要多长时间。 第三章所讲的测试策划过程介绍了一种方法，使得测试的 负责人能更好的估计完成测试所需要投入的时间和人力物 力。 第二章测试工具The Verification Tools 本章将介绍在现代功能测试环境中所用到的工具? 模拟程序：对功能测试来说是必不可少的。 ? 代码覆盖工具：可以使得测试中某些单调的任务自动执行，并增加 功能测试输出结果的可信度。 ? 测试人员任务：使用必要的工具来保证测试结果并非II型错误，也 即确保不出现代码错误不被发现。 ? 项目主管：保证用预定的资金，按预定的计划出产品，责任是使 手下的开发人员用恰当的工具，以充份的自信来完成自己的工 作。同时要判断寻找功能缺陷的花费是否已经超过了改进功能所 带来的效益，而这个工作尤为重要，本章所介绍的某些工具能帮 找到这个临界点。 2.1 检错工具 ( LlNTING TOOLS )Linting tools find common programmer mistakes.? 检错（lint）一词源于一个专门用来检测C语言程序错误的UNIX设 备。当Dennis Ritchie最开始发明C语言的时候，它并不象现在的 ANSI-C和C++这么安全可靠，也比不上Pascal和ADA。检错程序 允许编程者尽可能快的发现常规错误，而不是在测试的过程中发 现了致命错误以后才知道。 ? 检错程序能够找到错误，使编程者能在执行程序或发生重大错误 之前改正它们。运行时检错将需要一个运行时的调试程序，并且 要花好几分钟，而检错程序则只需要几秒钟，后者效率更高。 检错程序的优点：不需要激发，也不要说明期望的输出结果。它们的检错完全是静 态进行的，本身就自带了期望的输出结果。检错程序的局限性? 检错程序并不能找出源代码中的所有错误，它只是通过分析源代 码的结构来判断何处出错，而算法错误和数据流错误则发现不 了。 ? 检错程序在检错时有时表现得很固执。为了避免犯II型错误―即肯 定为错，常常犯检查出并不存在的错误，结果导致I型错误―否定 为错。 解决方法? 细心过滤错误信息 ：分析输出结果，把那些事实上不存在的错 误排除掉，就不必为查找根本没有的错误而浪费时间。更重要 的是，它可以避免一个真正的错误随着众多的假错误被忽略。 ? 正确的命名习惯有助于判断一个警告是否值得注意 ? 对于检查潜在的真实错误来说，逐行检查仍具有不可替代的作 用。 ? 编写源代码时就应该检错。判断一个错误的真假的最好时间是 在刚写完代码的时候。 ? 保证代码的可读性和可维护性 Linting Verilog Source CodeVerilog is a type-less language.(弱类语言)Linting Verilog source code catches common errors.Linting Verilog source code ensures that all data is properly handled without accidentally dropping or adding to it. The code in Sample 2-5 shows a Verilog model that looks perfect, compiles without errors, but produces unintended results under some circumstances. (编译无错，但在某种环境下出错) Sample 2-5. Potentially problematic Verilog code module tristate_buffer(in,out,enable): parameter WIDTH=8; input [WIDTH-1:0] in: output [WIDTH-1:0] out: assign out=(enable)? In : ’ end module Problems may not be apparent under most conditions.问题：位宽不匹配错误，out 定义8位，赋值8位高阻，32位系统中 其余位扩展赋值“’b0” Linting VHDL Source CodeBecause of its strong typing, VHDL does not need linting as much as Verilog.Lilnting can find unintended multiple driversSample 2-6. Erroneous multiple
use ieee.std_logic_1164.all entity my_entity is port (my_input: in std_logic); architecture sample of my_entity is signal s1: std_ begin statement1: s1 &= my_ statement2: s1 &= not my_Lilnting can find unintended multiple driversMultiple drivers. VHDL compiler. undetected 代码检查 (Code Reviews)? 代码检查是由人工完成的 ? 作用：在测试和模拟之前找出功能错误和编码格式错误。? 为了找出自动检错工具发现不了的错误，源代码将由多人过目。? 可通过代码检查来评估一个源文件的可维护性以及其代码的正确 性，还能发现编码格式方面的问题。 ? 能完全读懂代码，很容易找到功能错误及疏忽遗漏之处。 2.2 模拟 (SIMULATORS)在实现前模拟，可以及时的发现错误，改正错误 模拟是现实近似。为了降低难度，模拟中很多特征都 简化了，甚至被忽略。 模拟实际能实现的是对设计的说明进行，而且还必须 以严格的语法来说明。 不能确定模拟和实际的差别。不能证明模拟完全无 错，其功能的正确性和模型的精确性始终值得怀疑。 2.2.1 激励与响应 (Simulation requires stimulus)? 模拟要求提供一个测试平台 ? 本课程目标是如何建立测试平台。 ? 测试平台提供设计所需的输入，模拟器依据设计会作出响应。? 设计者本人根据模拟器的输出结果来判断设计的正确性。 ? 在一定条件下给了模拟器一个激发信号后，检查其输出，判断 其响应是否符合要求。 2.2.2 事件驱动模拟 (Event-Driven Simulation )Simulators are never fast enough. Outputs change only when an input changes.只有输入变化时才进行模拟。因此模拟程序是由输 入的变化驱动的，称事件驱动。 Change in values, called events, drive the simulation process. Sample 2-9. VHDL model for an XOR gate XOR_GATE: process(A, B) begin if A = 3 then o&='0'; else o& ='1' end process XOR_GATE;当且仅当A,B变化 时，才执行后面 的程序 Sometimes, input changes do not cause the output to change? 输入变化，即使输出不变化，也进行模拟 ? 满足事件触发条件 2.2.3 基于时钟周期的模拟 (Cycle-Based Simulation)触发Event-drive Simulator view of a synchronous circuit Cycle-based simulators collapse combinatorial logic into equations.? When the circuit description is compiled, all combinatorial functions are collapsed into a single expression that can be used to determine all flip-flop input values based on the current state of the fan-in flip-flops. ? During simulation, whenever the clock input rises, the value of all flip-flops is updated using the input value returned by the precompiled combinatorial input functions. Cycle-based simulations have no timing information.? This great improvement in simulation performance comes at a cost: all timing and delay information is lost. 不考虑定时与延迟信 息 ? Cycle-based simulators assume that the entire design meets the set-up and hold requirements of all the flip-flops. 设计满足触发器 建立和保时的时间要求 ? When using a cycle-based simulator, timing is usually verified using a static timing analyzer. 基于时钟周期的模拟，使用静态时序 分析器分析时序 Cycle-based simulators can only handle synchronous circuits. (仅能用于同步电路)? Cycle-based simulators further assume that the active clock edge is the only significant event in changing the state of the design. 有 效的时钟边沿触发状态改变 ? All other inputs are assumed to be perfectly synchronous with the active clock edge. 所有输入被有效的时钟边沿同步 ? Therefore, cycle-based simulators can only simulate perfectly synchronous designs.仅能用于同步设计 ? Anything containing asynchronous inputs, latches, or multipleclock domains cannot be simulated accurately. 2.2.4 共同模拟Co-Simulators设计中的同步部份用的是时钟驱动，而其它部份用的是事件驱 动。两种模拟结合起来共同完成模拟功能。Multiple simulators can handle separate portions of a design All simulators operate in locked-step.? During co-simulation, all simulators involved progress along the time axis in lock-step. ? All are at simulation time T1 at the same time and reach the next time T2 at the same time. ? This implies that the speed of a co-simulation environment is limited by the slowest simulator.Performance is decreased by the communication and synchronization overhead. Translating values and events from one simulator to another can create ambiguities. Co-simulation should no be confused with single-kernel simulation 2.3第三方模型 (THIRD-PARTY MODELS)Board-level designs should also be simulated. 板级的设计通常都包括从第三方买来的部件，有时 这些部件是可编程的，如存储器，PLD，和FPGA。必 须对设计进行测试，以保证ASIC之间，和第三方部件之 间能够兼容。 You can buy models for standard parts It is cheaper to buy models than write them yourself Your model is not as reliable as the one you buy. 2.3.1 硬件模块 (Hardware Modelers)What if you cannot find a model to buy?You may be faced with procuring a model for a device that is so new or so complex, that no provider has had time to develop a reliable model for it.You can &plug& a chip into a simulator.A hardware modeler is a small box that connects to your network. A real physical chip that needs to be simulated is plugged in it. 2.4 示波器 (WAVEFORM VIEWERS)Waveform viewers display the changes in signal values over time Waveform viewers are used to debug simulationsA waveform viewer can play back the events that occurred during the simulation that were Simulation Engine Event Database FileRecording waveform trace data decreases simulation performance. Do not use a waveform viewer to determine if a design passes or fails. Some viewers can compare sets of waveforms. How do you define a set of waveforms as &golden&? And are the differences really significant? 2.5 代码覆盖CODE COVERAGE概念源于软件工程，用来判断测试是否充分，代码是否有 没测试到的。代码覆盖处理实例1. Code must first be instrumented 2.Trace Information is collected at runtime 3. Statement and block coverage are the same thing 4. block boundaries may not be that obvious代码覆盖最常用的是语句覆盖，过程覆盖和表达覆盖 语句覆盖(模块覆盖 )模块是由一系列语句构成的，只要执行其中一条语句，整 个模块就会随之执行。Sample. Block vs. statement execution if (dtack == l'b1 ) begin: acked as &= 1'b0; data &= l6'hZZZZ; bus_rq &= l'b0; The block named acked is state &= IDLE; executed entirely whenever the expression endin the if statement evaluates to TRUE. 模块之间并没有明确的界限 Sample. Blocks separated by a wait statement address &= 16#FFED#; ale rv &= '1'; &= '1';The wait statement may have never completed and the process was waiting forever.wait until dtack ='1'; read_data := ale &= '0' ; 2.5.1语句覆盖 (Statement Coverage)语句覆盖用 来计算在测试的 过程中共有多少 行代码得到了执 行，它提供一个 图形用户接口来 显示所有的源代 码，以及有那些 语句没有执行。√□ □ □√ √ √ √ √ √Example of statement coverage. if (Parity == ODD||parity == EVEN) begin tx &= compute_Parity(data, parity); # ( tx_time ); end never be executed tx&=l'b0; #(tx_time); if(stop_bits==2) begin tx&=1'b0; #(tx_time); end Why did you not execute all statements?无法执行的代码是无效的，删除无效代 码可减少无序性，增加源程序可维护 性。 2.5.2 过程覆盖(Path Coverage)There is more than one way to execute a sequence of statements. Path coverage measures all possible ways you can execute a sequence of statements. example of statement and path coverage 2.5.3 表达覆盖 Expression Coverage两个相互独立的条件可以使第一条if语句引起then语句的执行。 表达覆盖就是统计执行一段代码的方法数。尽管语句覆盖已达 100%，表达覆盖却只有50%。 2.5.4 What Does 100 Percent Coverage Mean?? 代码覆盖表示的是测试过程对源代码的覆盖程度，但 它并不能辨别测试过程是否正确。 ? 对代码覆盖的结果进行描述时应该有所保留。这些结 果可以用来鉴别没有被测试的特殊情况，或用来检测 在执行的过程中出现的特征。 ? 代码覆盖可以体现测试工作的全面性，可以了解测试 范围有多广，但这并不是唯一的指标。 ? 代码覆盖率较低表明测试工作尚未完成，但代码覆盖 率较高并不就表明测试工作已经完成。 2.6 测试语言( VERIFICATlON LANGUAGES)? Verification languages can raise the level of abstraction. ? VHDL and Verilog are simulation languages, not verification languages. Verilog偏重的是初级应件结构，所以它不能支持高级数据结 构，也不具备面向对象的特征。VHDL比较适合于大型项目，它 封装了所有的信息，并严格按定义好的接口传送。有必要创造一 能克服Verilog和VHDL的这些缺点的专门的测试语言 。 ? Proprietary verification languages exist. 三种企业专用的测试语言：Verisity的elSpecman, Synopsys 的VERA,Chronology的Rave。 2.7 版本控制 (REVISION CONTROL)版本控制解决的问题 Are we all looking at the same thing? Files must be centrally managed. It must be easy to get at all the files, from a single location. 2.7.1 The Software Engineering ExperienceHDL models are software projects Free and commercial tools are availableTo help manage files, software engineers use source control management systems.All source files are centrally managed所有对源文件的存取和修改都由管理系统来管理。所有的设计 人员和用户都是通过管理系统来交流，而不是直接在工作目录下存 取文件。 The history of a file is maintained.源代码管理系统不仅支持文件的最新版本，而且保存着每个文 件的不同版本。优点：文件恢复为以前的版本，文件从一个版本转换为另一个版本。文件恢复为修改以前。The team owns all the files文件就不再属于某一个人所有，名义上是设计人员分别负责不 同的模块，但只要允许的话，任何人都可以对文件作修改。 测试人员可以不依赖于设计人员而对文件进行改错。资源管理 系统可以通过同步修改来对文件进行修改。 2.7.2 Configuration ManagementEach user works from a view of the file system? 两个用户从不同的角度看管理系统中的源文件，不能确定都采用最新 的版本。 ? 文件经常在没来得及检查出错误之前就作了修改，是极为麻烦的事。 Configurations are created by tagging a set of versions所有的文件管理系统都用标识符来代指文件的各个版本，以后 涉及到文件的这个版本时就可以用标识符，而不必知道其版本号。Configuration management translates to tag management Example tags for release managementTag Name Submit Bronze Silver Gold To_Synthesis TO_Layout Version M_. N ON _YYMMDD Description Ready to submit to functional verification. Author has verified syntax correctness and basic level of functionality. Passes a basic set of functional testcases. Release is sufficiently functional for integration. Passes all functional testcases. Passes all functional testcases and meets coding coverage guideiine5 (requires additional corner-case testcases). Ready to submit to synthesis. Usually matches &Silver& or &Gold&. Ready to submit to layout. Usually matches &Gold&. Version that was manufactured. Matches corresponding 'To-Layout& release. Future versions of the same chip will move tags beyond this point. Some meaningful release on the specified date. 2.7.3 Working with ReleasesViews can become out of date as new versions of files are checked into the source management system database and tags are moved forward.Releases are specific configurations. Users must update their view to the appropriate release. You can be notified of new releases 2.8 ISSUE TRACKING问题追踪? 测试人员的任务就是发现错误，真正令人伤脑筋的是发现不了 错误。 ? ? 出错是正常的，它与硬件设计人员的能力无关 即使是最有经验的软件开发人员写出的代码也是可能出错的， 最简单的常用程序也不例外。 ??问题：已经发现错误，下一步该怎么办？发现了问题就应该解决，所有的设计小组都有专门的系统，用来追踪 问题，解决问题。 2.8.1 What is an Issue? 何谓问题？什么是值得追踪的问题 追踪问题的代价不应该比问题带来的损失更大。先决定什么 问题值得追踪，然后再建立适当的追踪系统呢，它可以保证设计 的功能正确。 任何足以影响系统功能的都可以称之为问题： a) 在测试平台的运行过程中发现的错误显然是值得追踪的。 b) 说明文件中的模糊和不完整之处也应该追踪，但排版错误不在此例。 c) 结构上的错误也算。 d) 在设计和测试的过程中发现的错误都应该追踪。 e) 如果想采用一个新的测试箱，也应该追踪。 When in doubt track it.判断它是否值得追踪的唯一标准是看它对设计正确性的影响程 度。如果问题不解决就会导致整个设计出错，当然就该进行追踪。 并不是所有的问题所造成的影响都是一样的，有的对设计的功能造 成直接的影响，有的只是造成间接的，次要的影响。所有的问题应 该给一个优先计别，并按优先级排序。You may choose not to fix an issue有些问题，通常都是不太重要的，可以忽略。设计小组可以决 定对于某个特定的项目来说，有些问题是可以接受的，它们可以留 到下次改进时再解决。 2.8.2 The Grapevine System树状系统Issues can be verbally reported.最简单，用得最普遍的问题追踪系统。 发现了一个错误之后，直接找到设计者并和他讨论（即使你不是 设计人员也行），其他人听到你们的讨论之后也可能加入进来，简单 的问题马上就可以解决，复杂的问题可以留待以后多找点人来讨论。 问题的优先级别是设计人员根据解决的迫切性来决定的。It works only under specific conditions? 特别适用规模较小，联系紧密，工作都比较相似的设计小组。 ? 如果小组中有成员不在一起，不能很快进行交流，不适用。 ? 假如问题通过讨论解决了，任何人都不必负责实施解决方案。 局限性.? 系统不对历史作任何记录，一旦一个问题得到了解决，无法再回 看整个解决过程。 ? 如果解决方法迟迟不能付诸实施，则这个问题可能被重复访问多 次。 ? 如果提出的解决方案不能解决问题，可能会导致设计人员不断试 验以前的解决方法，从而陷入一个死循环。 ? 由于没有历史记录，很可能就会重复以前的错误，无法从以前的 错误中吸取教训。 ? 因为每个人可能碰到的都是一类问题，所一他所知道地也往往很 有限。 2.8.3 The Post-It System 溯源系统Issues can be tracked on little pieces or paper.当设计小组的规模增大，或人们不再能随心所欲的进行交流，就要 用到3M溯源系统。 方法：每个人都在其监控器上贴上一些说明性的纸片。优点：弥补了树状系统权限不明的缺陷，纸片是谁的，谁就负责找 到解决方法。 缺点：有时权限也是模糊的。往往是因为纸片掉到地下被清洁工扫 走了，问题就被“解决”了 由于溯源系统不存在优先级别的问题，可能会导致以 下情况：一个错误对一个设计人员很关键，但负责解决这个错误的人却 因为种种原因而优先解决其它的问题。 所有的问题都看起来差不多，好象没有任何一个显得比其它的 更加迫切需要解决。 受个人能力的限制。因为缺乏历史记录，问题往往被重复访 问，错误也重复产生。 2.8.4 The Procedural System 分步系统Issues can be tracked at group meetings.问题通过email等自由的形式提出来，其中比较重要的则在小 组会议上解决。 ? 由于涉及到了全组人员，并是在会议时间解决，所以可以调动全 组人员集思广益解决问题。 ? 这样做要把大量的时间用于开会 ? 只用于很重要，很关键的问题，而数量庞大的小问题，则还是采 用树状系统或溯源系统。Only the biggest issues are tracked. 2.8.5 Computerized System 推算系统Issues can be tracked using databases. 系统特点：? 突出的问题总是被反复强调，问题可以分配给某个人或某些人， 因此要解决问题只要找相应的人就可以了。 ? 如果有必要的话，计算机推算系统还会按天或按周向你报告状 态。 ? 系统对每个解决方法都保存历史记录，通过记录不同的方法及其 效果，就可以保证每个方法只用一次而不再重复。 ? 可以很快查看类似问题的解决过程，而避免犯相似的错误。 关于问题追踪的选择计算机推算系统尽管具有一系列优点，但常常还是不管用。最大的 困难在于使用起来不方便，而树状系统和溯源系统是随时可用的。 如果日程一定，工作量一定，你要报告一个简单的问题，你会选择 哪种方法： ① 直接找到负责解决这个问题的人，向他报告。 ② 把问题写在一个纸条上，给（1）中的那个人（如果他不在，则把纸 条贴在他的计算机屏幕中央）。 ③ 把对问题的说明输入问题追踪数据库，不要离开自己的工作站。 你可能选择费时费力最少的一种，但如果你的小组要成功使用计算 机推算系统，则你选择的方法应该尽可能的不打断成员们的进度选 择和他们的工作和工具最接近的。 第三章测试计划The Verification Plan 目的： 首次测试成功 怎样测试 怎样建立测试平台 3.1 THE ROLE OF THE VERIFICATION PLAN 测试计划的作用Traditionally, verification is an ad-hoc process在传统的设计中，测试是留给每个设计人时间允许时自己去完 成。 习惯在系统组合中多花时间，也不预先留下改错的余地。Tools exist to help determine when you are done工具可以帮你进行测试。代码覆盖率，错误发现率和代码修改率 能让测试者估计离预定目标还有多远。即确定什么时候做完。 3.1.1 Specifying the Verification明确测试You need a tool to determine when you will be done(确定什么时侯完成)必须明确确定测试何时能按要求完成。 测试计划涉及的问题： 根据需要完成的工作具体说明，确定需要多少 人，需要持续多久，需要做什么工作等。 Start from the design specification.从设计说明开始在进行测试之前，必须为要测试的对象制定详细的 说明文件。 设计要求是设计和测试总的根据，它是不能变的。 测试平台的结果和测试对象的结果不一致，由设计 要求来决定谁对谁错。 The verification plan is the specification document for the verification effort测试计划就是测试的说明文件事先没有一个详细的说明文件， 是不可能设计出集成几百万个门 电路的集成电路的。 测试所花的时间是设计本身的一 到两倍测试时需 要详细的 说明文 件，即测 试计划 3.1.2 Defining First-Time Success 首次测试成功? 测试计划要求设计小组先确定什么是首次测试成功 ? 它是一种正确测试所有基本功能的方法首次测试成功的方法? 确定在什么样的条件下能实现什么样的功能，会作出什么样的 响应。 ? 测试要求还要说明什么功能是优先的，什么功能是可选的。 ? 如果时间较紧，在首次测试成功的要求中去掉一些功能是比较 明智的。 From the verification plan, a detailed schedule can be created 从测试计划得到详细时间表? 测试计划制定了一条界线，越过了这条界线，就会影响产品的 成功上市。 ? 写出了测试计划，就会知道要建立多少测试平台，知道它们的 复杂程度和相互依赖程度。 ? 可以制定详细的测试时间表，给资源分配测试平台，使得测试 尽可能能够同时进行。 ? 一旦测试所有必要功能的测试平台建立起来了，RTL又通过了 测试，设计就可以交货了，在此以前则不行。 The team owns the verification plan.团队拥有测试计划? 让每个设计人员认识到测试计划的重要性。 ? RTL设计人员的任务不仅是设计出RTL，更重要的是让它能正常运行 ? 每个人都应该参与测试计划的制定，以保证其完整性和正确性。This process is not revolutionary. 此过程不是创新的 3.2 LEVELS OF VERIFICATION测试的层次Verification can be performed at various levels of granularity. 测试可以在不同粒度水平上进行 ? 制定测试计划的首要问题是确定测试的层次 ? 每个设计都是由好几个层次组成的 ? 物理层：如印刷电路板，FPGA和ASIC， ? 逻辑层：如组合单元，可再用组件和子系统。 Application of different levels of verification 测试的不同层次应用? 每个层次都有自己最适 用的场合和对象 ? 和传统的设计过程相比, 采用可再用组件的设计 有很大变化, 变化范围 包括物理层内从单元级 测试开始处到系统级测 试结束处 ? 设计采用了可再用组件 之后, 并没有减少对测 试的依赖程度 ? 单元级和系统级的界限 是一个逻辑概念, 而非 一个物理概念. Deciding between levels of granularity involves tradeoffs划分更细, 则可控性和可观察性更强, 更易于测试, 要 建立所需的条件和状态组合以观察响应是否符合预期值, 也要容易的多. 如果划分较大的话, 要对较小的部分进行整合, 测试 时可控性和可观察性要差得多 Verifying at a given level of granularity requires stable interfaces任何测试对象都必须有相对稳定的接口并实现预定的功能 如果接口和功能不断的发生改变, 则测试平台也要不断改变, 也就 很难加以改进. 一旦决定在一定的划分级别上进行测试, 则应该及早的规定其接 口和整体功能, 并尽可能的保持不变 最好是每个级别都有自己的要求说明文件. 3.2.1 Unit-Level Verification单元级测试Implementation determines the content of this partition? 设计单元是按逻辑来划分的, 是为了便于实现和合成 ? 可能比较简单(如FIFO和状态机), 也可能比较复杂(如PCI从接口 和DSP数据通道). ? 随着在实际过程中不断的暴露初始设计的缺陷和不足, 其接口和 功能会不断的改变? 在测试时通常没有独立的要求说明文件可资利用. Use ad-hoc(对等) verification for design units. 对设计单元使用对等测试 ? 因为设计单元不断的在发生改变, 所以最好进行对等测 试, ? 由设计者测试单元的基本功能, 确保RTL代码中没有语 法错误, 并且实现了基本功能, ? 不需创建回归检测组件来获得较高的代码覆盖率. Unit-level verification may be required in large devices 大的器件可能需要单元级测试 ? 对于较大, 较复杂的ASIC和FPGA来说, 从ASIC和FPGA 进行测试可能不能获得理想的功能覆盖, ? 内部高灵敏度的复杂功能模块, 只有进行单元级测试才 能获得足够的可控性和可观察性. ? 单元级测试的每个功能单元最好都有自己的要求说明 文件 Architect the design to facilitate unit-level verification 为方便单元级测试构建设计? 比较复杂的设计, 需进行单元级测试, 那么就要注意使单元级测试尽 可能的完善和完整. ? 划分时使所要测试的功能完全包含在一个单元中, 并能独立的进行 测试, ? 一旦通过了测试, 在进行更高级别的测试时就可以假设这些功能是 正确的. ? 如果在单元级测试的功能和别的单元有接口, 在更高的级别上就要 重新进行测试, 以确保其组合也是正确的. 3.2.2 Reusable Components Verification 可再用组件测试Reusable designs are independent of any particular use 可再用设计独立于所有的特对应用? 可再用组件是完全独立设计的, 它可以在别的设计中原封不动的 采用. ? 其可再用的范围可以是一种产品, 一系列产品, 甚至是能用到其功 能的任何产品. ? 它必须就某种用途进行完全独立的设计和测试 Verification components can be used as well 测试元件也可以再用? 可再用组件通常用标准接口来设计, 这些接口根据标准片上总线或 是工业标准的外部物理接口来设计. ? 用来激发和监测这些接口的测试组件本身也可以在不同的测试环境 中用于测试不同的可再用组件 ? 当组件众多时, 可以较好的减少投入, 压缩开支. ? 第6章将详细讲述如何构造一个测试平台, 使之能够创建和使用可再 用测试组件. Reusable components need a regression test suite 可再用元件需要回归检测组件? 可再用组件在很多设计中都用到, 如果为了改正发现的 问题或是为了增强其功能, 而不得不作出修改, 则要保证 它向后兼容. ? 在修改后用回归检测组件来检测其兼容性, ? 用常规测试很难检验新组件和原来组件的等价性, 除非 所做的修改不是功能上的 ? 更正问题和增加功能都使得设计和原来的不等价 They need thorough functional coverage. 需要完全的功能覆盖如果用户不相信组件比他自己设计的更好, 他是不会采用 的. 要取得用户的信任, 就要用详加说明的, 完整的测试过程 来证明组件的正确性和稳定性. 3.2.3 ASIC and FPGA VerificationThe physical partition is an ideal verification level They may have to be treated as systems FPGAs now require an ASIC like verification process 3.2.4 System-Level Verification 系统级测试? 系统是由独立的测试组件构成的逻辑概念 ? 一个系统可以是由几个可再用组件构成的 ? 可以是一个片上系统ASIC, 也可以由不同的印刷电路板上的几个 ASIC组成,Logical, system partition The verification focuses on interaction 测试专注于相互关系系统级测试是忽略单个组件的具体功能而注重其相互 关系, 功能在组件级测试中已经测试过, 进行系统测试的前提是单个组件的功能正确. The testcase defines the system? 系统是一个逻辑概念, 可以由任意数目的组件构成 ? 采用和测试哪个系统取决于相关的测试实例, ? 为了减少模拟, 最好采用最小可能的系统来执行测试实 例 ? 由于可能采用的系统很多, 所以要规定一个标准系统. 同一个系统可以用于很多测试实例 3.2.5 Board-Level VerificationBoard-level models are generated from the board design tool 从板级设计工具中产生板级模型? 目的：是确保插件板所确定的连接正确 ? 可以当作一个系统来进行功能测试 ? 插件板设计模型必须由插件板设计工具自动生成. ? 保证测试对象就是所要生产的产品, 在设计和模拟对象之间必须 有直接的联系 Many components on a board do not fit in a digital simulation environment 板上的元件不适合数字仿真环境? 插件板级模型最大的困难是为所有的组件建立适当的模型 ? 使用第三方资源和硬件模型 ? 模型带来某些误差：如 1) 电容在数字仿真系统中的描述，2) 模拟器件, 连接器, 光藕和很多其它的元件在数字环境中转换和传输Board-level parasitic can be modeled 板级寄生效应模拟? 寄生效应可能影响插件板功能的正确性 ? 插件板中信号传输速率的提高, 传输线效应也变得逐渐重要 ? 在设计ASIC时就不得不考虑它们最后在电路板中的实际应用. 3.3 VEIFICATION STRATEGIES测试策略Decide on a black or white-box approach for various levels of granularity. 根据粒度级决定用黑箱或白箱模型处理? 如果给定了所要测试的功能, 就要制定相应的测试策略 ? 要确定测试的粒度, 还要确定每个粒度所采用的测试实例的类型 ? 测试实例可以是白箱或黑箱, 取决于测试对象内部结构的可见性以及 对它的了解程度 Decide on the level of abstraction where the tescases will be specified. 确定测试实例的抽象级? 确定主要测试的抽象程度, ? 抽象程度越高, 测试对象的粒度越大, 时序和激发和响应之间 协调的可控性变差, 容易产生大量的激发信号并需测试较长 时间的响应 ? 如果需要对具体的测试实例进行控制, 则要降低抽象程度 A processor interface could be verified at the cycle or device driver level (处理器接口可以)在时钟或设备驱动 级测试处理器接口可以在单个的读和写周期级别进行测试, 需要每个测试实例对存储器映射寄存器有较深的了解, 并知 道如何对其进行编程 接口也可以在设备驱动器级别进行驱动, 测试实例也可以调用较高级别的子程序来完成操作， 每一 项操作都是由很多的读周期和写周期来说明存储器映射寄存器, 但测试实例可以不管这些具体细节. 3.3.1 Verifying the Response测试响应Plan how you will check the response 计划如何检验响应? 进行激发相对来说容易些, 可以控制激发的时序和过程 ? 难就难在测试响应检测相对困难, 需要确定预期输出, 并要证明测 试对象所产生的就是预期输出. ? 在”预测输出” (后页章节)提出了几种方法, 可以用于输出测试 Some responses are difficult to verify in the simulation 测试中某些响应的分析是困难的? 建议采用自检测试平台( 见”测试输出” ) ? 有时在人看来一目了然的响应, 测试平台却很难测试, ? 例：测试图形引擎就必须验证图形中包含具体内容, 自检在检测图中的 单个像素点会很有效, 然而, 人在检验整个填充红色的整个圆时效率要高 的多 ? 测试策略就必须找到一种方法, 使得这些测试实例自动运行. Detect errors as early as possible 尽可能早的检出 错误? 如果在模拟过程中产生一系列输出结果, 随后能和参考值进行比 较, 效率可以高得多。 ? 输出结果可以在模拟过程之外进行进一步处理, 以确定模拟成功 与否 ? 及早发现错误可以提高效率。如果响应能在模拟过程中进行检测, 就能在出错时及时发现错误, 改正起来要容易得多. 3.3.2 Random Verification随机测试Random verification still provides valid stimulus 随机测试提供有效的模拟 ? 随机测试中, 输入是由合法的单个操作来控制, 如读 周期和以太网数据包 ? 所谓随机指的是这些操作的顺序和传送的数据 Random verification will create conditions you did not think of. 可产生预料之外的条件 ? 随机模拟可以产生你在编写测试计划时没有考虑到的 情况 ? 用途：产生意外情况和边缘条件, 能校正测试人员在编 写测试平台时的偏差 ? 它产生的激发信号更接近实际情况, ? 当正在建立一两个接口的测试实例, 随机激发还可以用 来产生其它接口上的后台运行. They are complex to specify and code.随机模拟说 明和编码复杂? 数据和操作的顺序必须和测试对象在实际中一致 ? 随机模拟要说明数据和操作的范围和分布. ? 更为复杂的是预测预期输出－既然不知道要产生什么 样的激发信号, 又怎么知道其响应? ? 随机测试必须找到一种方法, 能检测到非法响应 Random simulations are usually used at the system level 随机模拟常用于系统级? 因为实现起来比较复杂, 所以随机测试通常用于粒度较 大的情况 ? 很多设计单元和较小的模块都能有单独的模拟环境. 一 种可行的方法是进行随机测试, 以测试计划, 源代码和 功能覆盖为依据, 随机模拟完全可以包含进单个的测试 实例里面. 3.4 FROM SPECIFICATION TO FEATURES 从说明到特性? 编写测试计划的第一步是从说明文件中统计出要测试的 特性 ? 系统工程师和RTL编码人员, 要继续提出所要测试的附 加特性 ? 附加特性在要求说明中必须一目了然, 对设计的目的和 特点不了解的人也能看懂 Label each feature 标记每一个特性? 所有的特性都应该有标记并附加简短的说明 ? 在说明这些特性时还要说明哪些需要测试, 以及如何 在设计中实现该特性 ? 每个特性都应该有索引, 可以在要求说明文件中找到 详加说明的章节或段落, ? 最好是在要求说明文件中也有索引, 可以在测试计划 中检测到该特性, 例 ：UART设计中的某些特征 ①当UART能够接收一个字并通过CPU接口发送时, 必 须 使清除发送端(CTS)有效, 见UART要求说明文件的 4.2节. ②状态寄存器中的CTS位必须反映CTS端的状态, 见表 A.2. ③当CPU接口可以读取接收数据时, 必须使数据就绪端 (DTR)有效, 见UART要求说明文件的4.1节. ④状态寄存器的DTR端必须反映DTR端的状态, 见表A.2. ⑤数据位串行发送和接收, 先送最低有效位, 见UART要 求说明文件的5.2节. 3.4.1 Component-Level Features组件级特征这里所说的组件, 可以是一个单元, 一个可再用组件, 或者整个的ASIC, 组件级特征完全包含在所要测试的组件中, 其中并不 包括和其它组件的系统级接口, 在测试其正确性时不 需要依赖于更高级别组合的正确性. 大部分的特征都是组件级特征, 在进行系统级测试时 必须假定这些特征都是正确的 3.4.2 System-Level Features系统级特征一个系统可以是一个ASIC, 来自不同电路板的几个ASIC, 整个电路板, 或是整件产品. 系统级模拟结构较大, 运行时间较长, 所以要尽量减少系 统级特征 对于所有的系统级特征, 都要考虑一下能否用组件级特 征来代替 MX ASIC在软件控制的条件下, 可以在ASIC ID0和ID1的数据之间进 行选择，这种选择特征是系统级特征吗?答案是否定的. 该特征完全包含在MX ASIC中, 因此是一个组件级特征 ? 系统级特征通常仅限于连接性, 流控和互操作性, ? 例如, 输入接口和输出接口的连接就是一个系统级特征, 在测试连 接时, 有必要把输入从ID0切换到ID1, 这种切换不是测试的目的, 我 们假定它能实现. ? 另一个系统级测试实例是MX ASIC中的FIFO, 它能通过ID0和ID1 产生反压, 并中止数据传送, 直到清除阻塞 3.4.3 Error Types to Look For查找错误类型Assume design tools do not introduce functional errors 假定设计工具不会引起功能错? 在列举所要测试的特征时, 我们都在无意中假设了一定会出错并且 一定能被找出来, ? 功能测试能够找出设计的功能错误, 但设计工具如果有问题它就无 能为力了 ? 功能模拟能够保证测试对象能按要求实现功能, 但前提是设计者自 己不出错 ? 比如, 在门级线网表运行所有的功能测试平台只能证明合成工具没 错, 要做到这一点, 采用正规测试或静态定时工具其实更好些. Likely errors are different based on the capture tool used. 相似的错，使用不同工具检出是有名同的? 用不同的检测工具, 所检测出来的错误类型也就不一样, ? 如果用的是原理图检错工具, 检测出来的就会是连接错误, ? 总线中数据位倒序, 和总线中单个位没连接之类的错误, 在RTL编码 和逻辑合成环境中, 就不易检测到这类错误, ? 如果总线连接正确, 要么所有的位都正确, 要么都不行. ? 检错工具能检测到一些连接上的问题, 如一条线上的多路驱动器, 或 者输出结果丢失, 对于这类错误, 它更为实用些 Look for functional errors.查找功能错误? 在基于合成的设计中常见的错误包括极性错误, 违反协议和计算错 误 ? 在原理图检测过程中证明有用的激发信号在RTL检测中就不一定 管用, 一对0和1的转换, 如”0xAAAA”后接”0x5555”, 就可以实现检测. ? 在数据流中使用签名是另外一种检测功能错误的好方法, 签名可以 是一个序列号, 用以检测数据丢失和数据重复, 签名还可以鉴别数 据的源址和目的址. 例如, 和写周期的地址相关的数据可以包括一 部分地址并能鉴别发送该周期的总线 3.5 From Features to Testcases 从特征到测试实例3.5.1 Prioritize 优先级别? 并非所有的特征都是同等的重要, 对所有的特征统计完后, 就必须对 它们排列优先级别, ? 在实现功能或满足客户需要方面, 有些特征是”必不可少”的, 决定了 是否能首次测试成功, 这些特征的测试决定了项目是否能如期完成 ? 测试”必不可少”特征的测试平台处于关键路径, 这些”必不可少”的特 征必须在所有可能的配置和用法选项中进行测试 Less important features receive less attention? 有些特征是”应该有的”, 但它们在设计时并不是优先考虑的, 它们只 是用来扩展功能或为了在竞争中获得有利地位, ? 保证基本功能的实现前题, 在时间和资源允许的情况下, 可以对这 类特征进行仔细的测试, ? 但如果时间不允许或是有更重要的特征等着测试, 也可以不必测试.Some features are verified only as time allows? 还有一类”最好有的”特征, 它们完全是可选的, 而且只是在时间允许 的情况下才测试, 并也只是粗略的测试一下 ? 一般设计的进度安排都比较紧, 所以一般都没有测试 Make an informed decision when cutting back on the verification effort.? 对所要测试的特征排列优先级别, 这样项目经理在进度较紧的情况 下, 就可以酌情取消某些测试, ? 如果时间更为紧迫的话, 还可以取消某些”应该有的”特征的测试. ? 省却对某些 ”应该有的”特征的测试的话, 就要对项目的市场目标重 新进行评估 3.5.2 Group into Testcases 组合成测试实例特征分类? 特征可以进行分类, 某些特征在测试时用相似的配置, 粒度和测试 方法 ? 为了提高效率, 同一类特征可以分配给一个测试人员 ? 例, 所有和CPU接口有关的特征应该归为一类, UART的波特率, 数 据位和奇偶产生的测试应该归为一类。 ? 每一类特征的测试构成一个测试实例. 标注? 每个测试实例都应该进行标注, 并对其目的进行简短说明 ? 说明中应该列举所有在测试实例中测试的特征 ? 每个特征也应该给出注释, 说明在哪一个测试实例中测试, ? 如果特征没有注明相应的测试实例, 就不会得到测试. ? 测试实例的说明中要列举已经假定实现了的特征, 根据这些, 可以确 定测试的顺序, 确定哪些测试可以并行处理. ? 要说明测试实例的激发信号的顺序和特点, 例如, 要描述各种操作和 总线周期, 对于随机测试实例, 还要说明输入数据的范围和分布, 以 及操作的类型. ? 测试实例不仅要给出预期响应, 还要说明如何确定响应是合法的, 这 包括预期的数值, 定时和协议, ? 例： 数据包处理器的输出只有在目的地址和输出端口一致的情况下 才算是正确的, 或者, 还可以加上一个更严格的要求, 来自不同源址 的数据包以一定的顺序产生, 并服从一定的形态分布. ? 更为明确的方法是直接列出所要查找的错误, 例如, 看一个数据包的CRC校验值是否正确, 还可以检查互斥事件, 比如同时向FIFO写入full和empty值, 如果一个测试人员对设计不是很了解的话, 明确所要查找的错误可以 使他写出更为可靠的测试平台. ? 别相信一个测试平台没有产生任何出错信息, 每个测试实例都会插入 一些错误, 以便确认是否能被测试平台检测到, 如果没有检测到出错, 只能证明测试实例失败, 比如, 测试UART的奇偶位的测试实例会故意 弄错奇偶位, 来看测试平台是否能检测出 第四章 行为硬件描述语言BEHAVIORAL HARDWARE DESCRIPTION LANGUAGES 大部分的硬件设计人员都有一种“RTL思维模式”, 一 个合格的测试人员应该打破这种思维模式 要想有效的完成测试工作, 你必须精通行为(也就是 不可合成的和高度算法化的)描述方式 为了正确可靠的使用VHDL和Verilog的行为结构, 必 须了解其模拟算法的边缘作用和该种语言的局限性, 还要知道如何去避免, 而在建立RTL模型时就不用了 解这么多. 4.1BEHAVORAL VERSUS RTL THINKING 行为思维模式和RTL思维模式之比较建立RTL模型和建立行为描述模型的区别几乎所有的硬件设计人员在建立可综合的模型时都比较得心 应手, 因为这时仅局限于一个定义好的VHDL和Verilog集合, 只需 要遵循某一种编码风格即可。毕竟有很多的RTL编码指导书可供 借鉴, 这些书可以帮助设计人员有效的进行设计, 可以实现体积小, 高速和低功耗。 例4-1所示的指导规则就可以帮助设计人员中的新手避免不必要的硬件组件设 计, 如锁存器, 内部总线和三态缓存之类. 更重要的是, 这些指导规则可以在可综合 的模型和门级设计之间维持等价行为, 如例4-2所示.例4-1 避免不必要的硬件结构的 RTL编码指导规则 为了避免锁存, 组合模块所有 的 输出值设为缺省值. 为了避免内部总线, 不要从两 个不同的always模块给regs赋值 (只对Verilog而言). 为了避免三态缓冲, 不要 赋’Z’(VHDL) or 1’bz(Verilog)例4-2 保持模拟行为等价的RTL编 码指导规则 所有的输入都要列入组合成模 块的敏感量列表. 时钟和异步复位必须列入串 行时钟的敏感量列表. 在给reg赋值, 准备作为一个触 发器的情况下, 要采用非阻塞赋 值 是否遵从了可合成集合和正确的编码规则, 很容易就可以通过检错工具 进行检测 如果经过几个月的锻炼, 设计人员基本上就可以接受这种方式： 状态机 操作符 多路选择器 解码器 锁存器 时钟 Do not use RTL-like code when writing test-benches可合成子集在描述特定设计的实现时是足够的 VHDL和Verilog可合成子集是由合成方法来描述的, 用来说明硬 件结构和寄存器之间的逻辑转换, 符合逻辑合成规则. 如果只是建立测试平台, 而没有用硬件来实现, 这时可合成子集 就远远不够了. 两种硬件描述语言都有着丰富的结构和语句, 如果在建立测试平 台时还局限于RTL思维模式, 局限于设计底层硬件结构时的编码 方式, 将不能完全体现这种语言的作用, 测试工作也会变得单调 而复杂 4.1.1 Contrasting the Approaches 两种编码方式的比较例：一个简单的握手协议, 用VHDL或Verilog来实现? 检测到在产生一个请求信号(REQ)之后产生了一个应答信号(ACK) ? 检测到应答信号之后, 就清除请求信号, 随后应答信号也被清除 type STATE_TYP is (… , MAKE_REQ, RELEASE,…); signa1 STATE, NEXT_STATE: STATE_TYP; … COMB: process (STATE, ACK) begin NEXT_STATE &= STATE; case STATE is … when MAKE_REQ =& REQ &= ‘1’; if ACK ='1' then NEXT_STATE &= RELEASE; end if: when RELESE =& REQ &= ’0’ ; if ACK = '0' then NEXT_STATE &=...; … end process COMB;RTL思维模式举例硬件设计人员有着RTL 思维模式, 所写的对应的 VHDL代码需要用28行代码和两个过程 来实现, 如果状态机更为复杂的 话, 还需要两个额外的状态 SEQ: process (CLK) begin if CLK' event and CLK ='l' then if RESET = '1' then STATE &=...; else STATE &= NEXT_STATE; end process SEQ; 行为描述思维模式测试人员有着行为思维模式, 只会注重协议的行为, 而不会用状 态机来实现, 相应的代码如下, 其功能只是用简单的四条语句来 描述process begin … REQ &= ’l’; wait until ACK ='l'; REQ &= ’0’; wait until ACK ='0'; …? 检测到在产生一个请求信号(REQ) 之后产生了一个应答信号(ACK) ? 检测到应答信号之后, 就清除请求 信号, 随后应答信号也被清除 采用行为描述模型可以提高模拟性能假设在请求信号和对应的响应信号之间有较长的延时, 可合 成模型将在时钟的每个转换点执行SEQ过程(因为该过程对 时钟信号敏感), 而行为模型则一直在监测应答信号的状态, 只有在协议完全 满足时才恢复运行 如果应答信号有10个时钟周期的延时, 这意味着该过程的执 行次数从可合成模型中的40次减少到行为描述模型中的2次, 或者说模拟性能提高了1900%. 4.2 You Gotta Have Style !必须有自己的风格可合成子集对编码方式有所限制, 有些不太熟练的硬件设计人员 写出来的RTL代码既难懂, 又难维护, 行为描述模型有着完全的自由, 很多很熟练的设计人员写出来的 测试代码也是既不简练, 可维护性也不好 4.2.1 A Question of Discipline关于严谨的问题Write maintainable, robust code.写可维护的代码 Invest time now save support time later.在编码时多 投入一点时间，在维护时要省很多事 4.2.2 Optimize the Right Thing进行合理的优化注意设计的可维护性, 在编写可合成代码时也是如此 在对代码进行优化之前, 要确定它的确需要优化, 如果它已经符合 所有的要求, 就没有必要进行优化了 在编写代码时，可维护性是最重要的一个方面, 因为人们在代码的 理解和支持上投入最多. 压缩代码行数一般没有什么经济价值, 除非能提高代码 的可维护性, 例：如果按一行50个字符计算, 减少一行代码只能节省50个字节的存储 空间, 现在100G的硬盘价格还不到$200, 省一行也不过是省了 200*8*50/100G 。 节省的打印时间, 按每秒钟一字节算, 如果一个设计人员一年的劳动 价值是10万美元的话, 那么也只是省了0.69美元。 如果因此而降低了它的可理解性, 使得运行时间延长了5分钟, 那么 成本就要增加4.17美元。 综合节省和增加的成本, 总的成本增加了3.48美元, 并且这只是省一 行的代价。 对代码的性能进行优化会增加成本assign next_grant[0]= ~reset & (request[0] & 如果代码已经符合要求, 就不要进行 (~request[1]Olast_winner )); 优化, 可合成代码也是如此。 Sample Synthesizeable code for 2-bit assign next_grant[l] = round robin arbiter ~reset & (reguest[l] & modu1e rrarb(reguest, grant, reset, (~request[0]| ~last_winner)); clk); assign winner = input [l:0] ~reset & ~next_grant[0] & output [l:0] (last_winner O next_grant[l]); always @ (posedge clk) last_winner = reg last_winner grant = next_ reg [1:0] end wire [1:0] next_ endmodule优化会降低代码的可维护性, RTL code can be too close to schematic capture例中在某些方面还是注意了可维护性: 标识符示意明确, 也注 意了某些行的缩进问题. 然而, 它在实现可合成解码时用了一连串的赋值语句, 这表明 该设计人员是从布尔等式的角度考虑的, 甚至是从原理图的角 度考虑的, 而没有着眼于功能. 这种设计方法使得哪怕对设计作很小的改动都很困难, 如果 你想进一步确定到底难在何处, 不妨在没有请求信号时观察 last-winner寄存器的内容 另一个潜在的问题是在always模块中赋值时所产生的竞态条件 Specify function first. Optimize implementation second - and only if needed.Synthesizeable code for 2-bit round robin arbitermodule rrarb (reguest, grant, reset, clk); input [l:0] output [1:0] reg [l:0] reg last_ always @ (posedge clk)begin if (reset) begin grant &= 2'b00; last_winner &= 0; end. else begin grant &= 2'b00; if (reguest != 2'b00) begin: find_ case (reguest) 2' b01: winner = 0; 2' b10: winner =1; 2' b11: if (last_winner == 1'b0) winner = 1; else winner = 0; endcase grant[winner] &= 1'b1; last_winner &= end end end 可维护性 endmodule 4.2.3 Good Comments Improve Maintainability 适当的注释可以提高可维护性加上注释能减少投入 有人可能会说减少代码的行数能使程序语句较少, 更加清晰, 但是, 注释的首要目的是提高代码的可维护性, 没人能说代码行 数越少越好。 注释和代码一样, 也有好差之分, 过时的和没用的注释比没有注 释还要糟, 因为它会引起误解。 含义模糊的代码用处也不大, 在注释代码时最容易犯的毛病是直 接重复该行的作用, 如例所示。- -- Increment addrPoor comment：addr: = addr + 注释应该说明代码的目的, 它提供的信息是对设计本身不是 很了解的人所不知道的. Sample 4-8 Proper comments -- In burst mode, the bytes are written in -- Consecutive addresses. Need to access the -- next address to verify that tone next byte -- was properly saved. addr := acdr + l: 在注释代码时, 应该假设你的用户对该语言很精通, 但对设计本身 不是很了解。 最理想的状况是, 不看一个文件的源代码而只看其注释也能知道 它实现了什么功能。 4.3 STRUCTURE OF BEHAV1ORAL CODE 行为描述代码的结构如何对行为描述代码进行构造和封装, 以获得最好的可维护性 封装可以隐藏实现细节并对可再用的 代码打包. RTL models require a well-defined structure strategy RTL模型须要好的结构构造代码的过程把功能的各部分分配给各个模块和实体 模块和实体合起来实现整个设计的功能 在构造可合成代码时通常只考虑到合成工具的限制, 而没有 考虑功能. Testbenches are structured according to functional needs 根据功能构建Testbench用VHDL和Verilog行为描述代码实现的测试平台不存在类似的 工具方面的限制, 你可以随意的构造代码。 为了提高可维护性, 行为描述代码当然最好是根据功能或用途 来构造。 如果一个功能特别复杂, 可以把它分成较小的, 易于实现的子功 能。 如果一个功能要用到很多次, 最好单独进行构造和测试, 这样在 重复使用时就不用再投入时间。 表 Available constructs forVHDstructuring code VerilogModule Function Task ModuleEntity and architecture Function Procedure Package and package body 4.3.1 Encapsulation Hides Implementation Details 封装可以隐藏实现细节封装是构造方法的一个具体应用, 封装的主要思想是隐藏实 现细节并把其功能和实现过程分离。 目的：只要接口不变, 就可以对实现过程进行修改和优化而 不影响用户。 最简单的封装方法是尽可能的采用局部变量, 这样可以避免 和代码中其它用到该变量的部分产生冲突。 Sample ：Improper encapsulation of loc always begin for (i=0; i&32; i=i+l) begin … end end alwavs beqin for (i=l5; i&=0; i=i-l) begin. … end end例中所示的问题：两个always模块在循环语 句中都用寄存器 i 作为计 数器, 但 i 又是一个全局 变量 可能会引起相互冲突, 产 生不可预料的结果. In Verilog, put local declarations in named blocksbegin/end模块中声明 寄存器 对递增量进行封装, 最 好就是在每个always模 块中进行局部定义只要正确封装, 局部变量 就不会被其它的always或initial 模块访问, 也就不会产生不可 预料的结果。Sample. Proper encapsulation of local objects always begin: b1ock_1 for (i=0; i&32; i=i+1) begin ... end end always begin: b1ock_2 for (i=15; i&=0; i=i-1) begin ... end end Verilog中另一个可以定 义局部寄存器的场合 是任务和函数, 在VHDL中, 可以在任 何begin关键字之前进 行定义Sample. Local declarations in tasks and input [7:0] begin … end endtask function [3l:0] input [31:0] Val1; input [3l:0] val2; reg [32:0] begin sum=val1+val2; averaqe=sum/2; end end function 4.3.2 Encapsulating Useful Subprograms 封装有用的子程序有些函数和过程在整个项目甚至很多测试平台中都能用到, 如 果在每个用到的地方都进行拷贝, 无疑会增大维护的难度, 因 为它对所产生的信息也会进行拷贝 VHDL有一种程序包可以对在多个实体和结构中用到的定义 量进行封装 Verilog不能做到这一点, 但它有其它的方法可以实现这个目的. Example: error reporting routines错误报告程序如：在很多测试平台中用到的过程是出错报告例程, 为了获得一致 的出错报告格式，在模拟的过程中要用一系列标准的例程来产生 出错信息 在VHDL中, 它是用程序包中的过程来实现的。 在Verilog中, 它是用任务来实现的。 Verilog packages can be simple include filesSample. Using tasks packaged using ‘include file in Ver ‘ include. “syslog.vh.” initial begin ... if (...) error ('Unexpected response\n& ); ... end endmodule封装方法： 把任务放在一个文件 中, 通过一个编译器指 令把它包含进将要用 到它的模块中去。 Tasks can be packaged in a module and used using a hierarchical name. 封装方法：把任务 放进模块, 然后包 含在模拟过程中 能够独立编译Sample 4-13. syslog.vh: packaging tasks using ‘include file in Verilog input [80*8:1] begin $write ('WARNING at %t: %s&, $time, msg); end input [80*8:1] beqin $write(“-ERROR- at %t: %s', $time, msg); en input [80*8 l] begin $write (&*FATAn* ac %t: %s', $time, msg); End end
begin $write(&simulation completed\n&); $ end endtask Sample 4-14. Packaging tasks using a module in Verilog. Module sys initial begin warnings = 0; errors = 0; input [80*8:l] begin $write(&WARNING at %t: %s”, $time,'msg); warnings = warnings + 1; end endtask ... endmodule Sample 4- l5. Using tasks packaged using a module in Verilog M Intital begin ... if (. . . ) syslog error (“unexpected response”); ... end endmodule 4.3.3 Encapsulating Bus-Functional Models 封装总线功能模型总线功能模型：通过任务和过程用复杂的波形和协议把数据赋 给测试对象 总线功能模型被很多测试平台用到, 如果它所模拟的是一个标准 接口, 如一个PCI总线或是Utopia接口, 甚至可以在不同的项目中 用到。正确封装有利于重复利用.? 图：一个总线功能模型的模块图 ? 它按预定的协议驱动底层信号并 采样 ? 子程序可以用来对特定的数值进 行处理（过程接口）。 Sample 4_16 Encapsulating bus-functional models in VHDL use ieee.std_logic_1164. package cpu is subtype byte is std_logic_vector(7 downto 0); procedure write( variable wadd:) variable wdat: signal addr: signal data: signal rw: out std_ signal ale: out std_ signal vald: out std_logic); use ieee.numric_std. package body cpu is procedure write( variable wadd: variable wdat: signal addr: signal data: signal rw: out std_ signal ale: out std_ signal vald: in std_logic) is constant Tas: time=10VHDL总线功能模型是用程 序包中的过程来实现的begin if vald /='0' then wait until vald = '0'; addr &= std_logic_Vector(unsigned(wadd,8)); data &= std_logic_vector(unsigned(data,8)); rw &=’0’; wait for T ale &= ’l’; wait until vald =‘1'; Ale &= '0'; In VHDL, use procedures with signal arguments In Verilog Task arguments are passed by value only在Verilog中, 用任务来实现总线功能模型(底层信号直接传给 任务), 在任务的调用和返回的过程中, Verilog的自变量是通过value来 传递的, 在其它时间不能通过接口向任务赋值或是任务读值。 Sample 4-17. Task arguments in Verilog are passed by value Module arbiter task request output bus_ input bus_ begin //The new value does not “flow” out bus_rq &= 1’b1; end endtask endmodule例4-17所示的任务： 在任务返回之前给busrq赋值不会对外部造成 任何影响 任务在wait语句检测到 bus-gt信号置位之前不 会返回 调用任务时bus-gt的值 不会改变. Sample 4-18. Signal interface on Verilog package module arbiter ( bus_rq, bus_gt ); output bus_ input bus_ begin //The new value “flows” out through the pin bus_rq &= 1’ //And changes “flow” in as well wait bus_gt==1’b1; end endtask endmodule修改以解决问题： 不通过任务的接口传送 信号, 而通过实现包装的 模ku块接口进行传送 4.4DATA ABSTRACTION数据抽象Synthesizeable models are limited to bits and vectors.逻辑合成方法的局限性使得可合成子集仅限于处理数据格式：位, 位矢量和整数 行为描述代码则没有这种限制, 可以采用任意的数据表述形式Work at the same level as the design under verification.从”工作单元”这种粒度来考虑测试问题。不要让RTL思维模式束 缚，或者影响从更高的抽象级别进行考虑。 Abstracting date in Verilog requires creativity and discipline.VHDL能够很好的支持把数据抽象为更高级的形式 Verilog在这方面要差一点, 但只要采用合适的方法,很多功能能实现 的 Verilog的局限性较强, 将介绍如何用Verilog来实现各种数据抽象 VHDL中实现起来要容易的多, 只要参考相关的语法书即可. 4.4.1 Real Values实数值Use real when verifying DSP designs.测试数字信号处理器件, 实型将很有用处, 用浮点数更容易计算 出滤波器的预期输出值。 例：计算yn = a0 xn + a1xn-1 + a2xn-2 +b1yn-1 + b2yn-2 Constants could be defined using define symbols.最好用define宏定义符来定义在整个测试实例中保持不变 的 值，．如系数。 例：定义系数yn = a0 xn + a1xn-1 + a2xn-2 +b1yn-1 + b2yn-2Sample 4-19. Coefficients defined using define symbols Define Define define define define a0 a1 a2 b1 b2 0.....009672define定义符在编译中是全局 的, 这违反数据封装规则 占用了全局命名空间, 使得别 人不能使用相同的符号 Defining them as parameters is betterSample 4-20. Coefficients defined using parameters 解决方法： Parameter: a0 = 0.500000, a1 = 1.125987, a2 =-0.097743, b1 =-l.009373, b2 = 0.009672; 对于模块来说就是 局部的 定义为参数 Implement the filler equation as a functionVerilog中所有的寄存器都是静态的(也就是说它们在编译时间就分 配好了, 然后就一直保持不变), 所以滤波器的实数值保存在函数局 部定义的寄存器内. Verilog局限性: 实数值不能通过接口传送。解决办法： 在实数值和 64位矢量之间进行转换，分别用$realtobits和$bitstoreal。 VHDL中, 用实数组类型的常量来解决, 优点是能用for-loop语句进 行计算, 这种方法简单有效, 并且和滤波器的数目无关。在Verilog， 可以用一个由64位寄存器组成的存储器, 其中每个存储位置都有一 个系数转化为位矢量。 Sample 4-21. Function computing the next output va input (63:0) real xn_1,xn_2; real yn_1,yn_2; begin //Computer next output value yn = a0 *$bitstoreal(xn)+ a1 * xn_1 + a2 * xn_2 + b1 * yn_1 + b2 * yn_2 + ; //shift state of the filter xn_2 = xn_1; xn_1=$bitstoreal(xn); yn_2=yn_1; yn_1= end endfunction initial begin: test_ //Reset the filter yn.xn_1=0.0; yn.yn_1=0.0; y yn.xn_2=0.0; yn.yn_2=0.0;//compute the response to an impulse = yn($bitstoreal(1.0)); y end end = yn($bitstoreal(0.0)); repeat (99) begin Sample 4-22.Proper implementation in VHDL type real_array_typ is array( natural range&& ) constant a: real_array_typ(0 to 2):= (0=&0.=&1.=&-0.097743); constant b: real_array_typ (1 to 2) := (1=&-1.=&0.09672); Use a conversion function to translate into a fixed point representationSample 4-24. Converting a real function [15:0] to_ input [63:0] value to a fixed point value // fixed-point number format: s1.ffffffffffffff // sign(1=negative // integer portion 1 begin Co_fixpnt = 16'h0000; c = $bitstoreal(coeff); if (c & 0) begin to_fixpnt[15] = 1'b1; c = -c; end to_fixpnt[14:0] = c * 'h4000; end endfunction 有了这些实用函数, 测试平台就变得既容易实现, 又容易理解initial begin: test_ // Initialize prediction funnction yn.xn_1 = 0.0; yn.xn_2 = 0.0; yn.yn_1 = 0.0; yn.yn_2 = 0.0; // Reset the desiqn ... // program the coefficient cpu_write('A0_AdDR, to_fixpnt(a0)); cpu_write('A1_ADDR, to_fixpnt(a1)); cpu_Write('A2_ADDR, to_fixpnt(a2)); cpu_write('B1_ADDR, to_fixPnt(b1)); cpu_write('B2_ADDR, to_fixpnt(b2)); // Verify the response to an impulse inputSample 4-25. DSP testcasexn = 1.0; repeat (100) begin: test_one_ data_in = to_fiXPnt(xn); expect = yn($realtobits(xn)); @ (posedge clk); if (expect !== to_real(data_out))... xn = 0.0; end $ end 4.4.2 Records 记录记录中所描述的是各种各样的信息, 这一节将介绍如何在 Verilog中建立记录. 记录最理想的应用场合是数据包和数据帧, 因为这时控制和信 号信息是和用户信息组合在一起的 Sample 4-26. VHDL record for an ATM cell type atm_payload_type is array (0 to 47 ) of integer range 0 to 255; type atm_cell_typ is record vpi : integer range 0 to 4095; vci : integer range 0 to 65535; pt : bit--vector (2 downto 0); clp : hec : bit_vector (7 downto 0); payload: atm_ payload_ 例ATM信元记录的 VHDL定义 一个ATM信元的固定 长度是53字节, 其中48 个字节是用户数据. Verilog不直接支持 记录, 但可以建立伪 记录 模块中的任何定义 都可以用层名来访 问 一个模块可以只包 括寄存器定义, 以模 仿记录 在进行记录的时候, 每个模块实例模仿 记录的一个域。Sample 4-27. Verilog record for an ATM cell module atm_cell_ reg [11:0] vpi: reg [15:0] reg [ 2:0] reg [ 7:0] req [ 7:0] payload [0:47]; endmo atm_cell_typ cell(); initial begin: test_ cell.vci = 0; ... for (i=0; i&48; i=i+1) begin cell.payload[i]=8'hFF; end end endmodule 4.5 Files文件尽量避免在测试平台中采用内部输入文件测试平台和测试对象的配置管理是相当复杂的, 如果不是有着很 丰富的实践经验, 在测试中很难保证所测试的设计正确, 并且所 用的测试平台也正确。 如果要保证输入文件的正确性, 而这些输入文件通常是由另外一 些文件格式的下标所产生的, 会极大的增加配置管理的复杂程 度。 Verilog存储器进行初始化Sample 4-42. Initializing a Verilog memory using an external file. reg [7:0] pattern [0:55]; initial $readmemh(pattern, &pattern.memh& ); endmodule Sample 4-43.Explicitly initializing a Verilog me reg [7: 0] pattern [0: 55]; initial begin pattern[0] = 8'h00; pattern[1] = 8'hFF;例4-43中产生了Verilog代码 和例4-42中的文件数据等价pattern[55] = 8'hC0 end endmodule 4.5.1 Interfacing High-Level Data Types 高级数据类型接口一般很少对需要测试的设备直接采用高级数据类 复杂的数据结构必须在位级别对测试对象进行读写, 通常还包括 同步信号, 帧信号和握手信号. 第5章讲到如何用总线功能模型从复杂的数据结构对设计进行输 入 4.6 THE HDL PARALLEL ENGINE HDL并列引擎硬件模型设计所必须的三个要素: 连接性 时序性 并行性. 4.6.1 Connectivity Time, and Concurrency 连接性, 时序性和并行性连接性：用简单模块的连接在一起来实现设计。 作图工具就是支持连接性的. 时序性：表述设计的内部状态是如何随时间而变化的 与执行时间的概念不同, 执行时间只是用来计量程序运行 时间的. 并行性：描述相互独立操作并行运行。 4.6.2 Connectivity, Time, and Concurrency in HDLs HDL中的连接}
我要回帖
更多推荐
- ·一个单元格引用另一个单元格的数据查找引用多个数据并加在一起？
- ·怎么样登录云空间下载安装呢？
- ·数控车床简单图纸编程图纸编程（发那克系统），有谁会的帮帮谢谢
- ·张铭新李新亮教授的学术成果和荣誉果
- ·2023年春节新疆快递现在停运了吗2024年具体哪天停运？
- ·为什么我的三星Filpboard中国计量大学 board版切换不了中文
- ·耳机套开胶了，要鞋子开胶用什么胶水水粘
- ·格力空调柜机清洗视频T派柜机怎么清洗过滤网
- ·华为手机最好听的铃声铃声
- ·求助，各位大人能发一下诺基亚凤凰刷机教程
- ·AMD32核amd 霄龙 7601性能评测 AMDamd 霄龙 7601好用吗
- ·魅蓝note6相机扫题5的相机功能，大家良心说下，好不好
- ·临泉瓦店考全羊哪儿有手表店
- ·LED与液晶电视和松下等离子电视维修区别在哪
- ·新浪足球苹果曰报足球推介手机可以吗？ISO 7.1 行不行
- ·小区智能门禁系统一套多少钱统
- ·话说入手nexus5的人为什么还刷nexus 第三方库rom
- ·有哪位朋友知道在浙江湖州房价哪儿有正宗手机专卖店？谢谢了！
- ·ic integration和icenterprise architectt的区别
- ·儿童淘气堡设备价格多少钱一方
- ·老电脑怎么查看电脑硬盘接口连接SATS接口硬盘
- ·海信电视电源线背后线插孔图
- ·广告费惊人 二手车电商哪家强烧钱大战能持续多久
- ·谁能借我一万块钱 真心感谢 贪玩游戏真的能赚钱吗是没有办法了欠了好多钱
- ·甘肃陇南成县是山区吗有交通银行吗
- ·社保账户公司往个人账户打钱打钱进去不用预约可以取吗
- ·财务管理，工商管理类会计学，会计学，金融学哪个专业好
- ·工商银行和那几个装修公司合作协议在合作
- ·选的美签中信自取取，请问issued大概多久之后可以自取
- ·净头寸是什么意思思 有哪些交易策略
- ·银行卡被别人拿去办公积金银行卡补办流程有没有危害啊
- ·北丰台保安公司保安员上岗证查询网站保险的问题
- ·加盟特色餐饮饮加盟品牌：多少选择是从亲身体验
