验证基础

• 1: 芯片验证
• 2: 数字电路
• 3: 创建DUT
• 4: DUT验证
• 5: 验证报告

1 - 芯片验证

什么是芯片验证

芯片从设计到成品的过程主要包括芯片设计、芯片制造、芯片封测试三大阶段。在芯片设计中，又分前端设计和后端设计，前端设计也称之为逻辑设计，目标是让电路逻辑达到预期功能要求。后端设计也称为物理设计，主要工作是优化布局布线，减小芯片面积，降低功耗，提高频率等。芯片验证（Chip Verification）是芯片设计流程中的一个重要环节。它的目标是确保设计的芯片在功能、性能和功耗等方面都满足预定的规格。验证过程通常包括功能验证、时序验证和功耗验证等多个步骤，使用的方法和工具包括仿真、形式验证、硬件加速和原型制作等。针对本文，芯片验证仅包含对芯片前端设计的验证，验证设计的电路逻辑是否满足既定需求（“Does this proposed design do what is intended?"），通常也称为功能验证（Functional verification），不包含功耗、频率等后端设计。

对于芯片产品，一旦设计错误被制造出来修改成本将会非常高昂，因为可能需要召回产品，并重新制造芯片，无论是经济成本还是时间成本都十分昂贵。经典由于芯片验证不足导致失败的典型案例如下：

Intel Pentium FDIV Bug：在1994年，Intel的Pentium处理器被发现存在一个严重的除法错误，这个错误被称为FDIV bug。这个错误是由于在芯片的浮点单元中，一个查找表中的几个条目错误导致的。这个错误在大多数应用中不会出现，但在一些特定的计算中会导致结果错误。由于这个错误，Intel不得不召回了大量的处理器，造成了巨大的经济损失。

Ariane 5 Rocket Failure：虽然这不是一个芯片的例子，但它展示了硬件验证的重要性。在1996年，欧洲空间局的Ariane 5火箭在发射后不久就爆炸了。原因是火箭的导航系统中的一个64位浮点数被转换为16位整数时溢出，导致系统崩溃。这个错误在设计阶段没有被发现，导致了火箭的失败。

AMD Barcelona Bug：在2007年，AMD的Barcelona处理器被发现存在一个严重的转译查找缓冲（TLB）错误。这个错误会导致系统崩溃或者重启。AMD不得不通过降低处理器的频率和发布BIOS更新来解决这个问题，这对AMD的声誉和财务状况造成了重大影响。

这些案例都强调了芯片验证的重要性。如果在设计阶段就能发现并修复这些错误，那么就可以避免这些昂贵的失败。验证不足的案例不仅发生在过去，也发生在现在，例如某新入局 ASIC 芯片市场的互联网企业打造一款 55 纳米芯片，极力追求面积缩减并跳过验证环节，最终导致算法失败，三次流片皆未通过测试，平均每次流片失败导致企业损失约 50 万美元。

芯片验证流程

芯片设计和验证的耦合关系如上图所示，设计和验证有同样的输入，即规范文档（specification）。参考规范，设计与验证人员双方按照各自的理解，以及各自的需求进行独立编码实现。设计方需要满足的前提是编码的RTL代码“可综合”，需要考虑电路特性，而验证方一般只要考虑功能是否满足要求，编码限制少。双方完成模块开发后，需要进行健全性对比测试（Sanity Test），判定功能是否表现一致，若不一致需要进行协同排查，确定问题所在并进行修复，再进行对比测试，直到所有功能点都满足预期。由于芯片设计和芯片验证耦合度很高，因此有些企业在研发队伍上也进行了直接耦合，为每个子模块的设计团队都配置了对应的验证团队（DV）。上图中的设计与验证的耦合流程为粗粒度的关系，具体到具体芯片（例如Soc、DDR）、具体企业等都有其适合自身的合作模式。

在上述对比测试中，设计方的产出的模块通常称为DUT（Design Under Test），验证方开发的模型通常称为RM（Reference Model）。针对图中的验证工作，按照流程可以有：编写验证计划、创建验证平台、整理功能点、构建测试用例、运行调试、收集Bug/覆盖率、回归测试、编写测试报告等多个阶段。

验证计划： 验证计划描述了如何进行验证，以及如何保证验证质量，达到功能验证要求。在文档结构上通常包含验证目标，验证策略、验证环境、验证项、验证过程、风险防范、资源及时间表、结果和报告等部分。验证目标明确需要验证的功能或性能指标，这些目标应该直接从芯片的规范文档中提取。验证策略描述如何进行验证，包括可能使用的验证方法，例如仿真、形式化、FPGA加速等，以及如何组织验证任务。验证环境用于描述具体的测试环境，例如验证工具类型，版本号等。验证项包含了需要验证的具体项以及预期结果。验证计划可以有总计划，也可以针对具体验证的子任务进行编写。

平台搭建： 验证平台是具体验证任务的执行环境，同一类验证任务可以使用相同的验证平台。验证平台的搭建是验证流程中的关键步骤、具体包含验证工具选择（例如是采用软件仿真，还是采用形式化验证，或者硬件加速）、环境配置（例如配置服务器环境，FPGA环境）、创建测试环境、基本测试案例等。创建好基本测试平台，跑通基本测试案例，也通常称为“冒烟测试”。后继具体的测试代码，都将基于该测试平台进行，因此测试平台需要具有可重用性。验证平台通常包含测试框架和被测试代码，以及对应的基本信号激励。

功能点整理： 根据规范手册（spec）列出DUT的基本功能，并对其进行明确的描述，以及如何对该功能点进行测试。功能点整理过程中，需要根据重要性、风险、复杂性等因数对其进行优先级排序。功能点整理还需要对各个功能点进行追踪和状态，如果发现原始功能点有更新需要及时进行对应计划的同步。

测试用例： 测试用例是指一组条件或变量，用于确定DUT是否满足特定需求并能正确运行。每个测试用例通常包含测试条件，输入数据，预期结果，实际结果和测试结果。通过运行测试用例并比较预期结果和实际结果，可以确定系统或应用是否正确实现了特定的功能或需求。在芯片验证中，测试用例是用来验证芯片设计是否满足规格要求的重要工具。

编码实现： 编码实现即测试用例的具体执行过程，包括测试数据生成、测试框架选择、编程语言选择、参考模型编写等。编码实现是对功能点和测试用例充分理解后工作，如果理解不到位，可能导致DUT无法驱动，不能发现潜在bug等问题。

收集bug/覆盖率： 验证的目标就是提前发现设计中存在的bug，因此需要对发现的bug进行收集和管理。每发现一个新缺陷，需要给定唯一标号，并同设计工程师进行bug定级，然后进行状态追踪。能发现bug最好，但在实际验证中不是每次测试都能发现bug，因此需要另外一个指标评价验证是否到位。该指标通常采用覆盖率，当覆盖率超过一点阈值（例如代码覆盖率大于90%）后方可任务进行了充分验证。

回归测试： 验证和设计是一个相互迭代的过程，因此当验证出bug后，需要设计进行修正，且需要保证修正后的DUT仍然能正常工作。这种测试的目的是捕获可能由于修改而引入的新错误，或者重新激活旧错误。回归测试可以是全面的，也就是说，它涵盖了所有的功能，或者可以是选择性的，只针对某些特定的功能或系统部分。

测试报告： 测试报告是对整个验证过程的总结，它提供了关于测试活动的全面视图，包括测试的目标、执行的测试用例、发现的问题和缺陷、测试覆盖率和测试效率等。

芯片验证层次

按照验证对象的大小，芯片验证通常包含UT、BT、IT、ST四个层次。

单元测试（Unit Testing， UT）： 这是最低的验证层次，主要针对单个模块或组件进行。目标是验证每个模块或组件的功能是否正确。

块测试（Block Testing，BT）： 很多时候，单个模块和其他模块存在紧耦合，如果进行单独UT测试，可能存在信号处理复杂，功能验证不准确等问题，这时候可以把多个有耦合关系的模块合并成一个DUT块进行测试。

集成测试（Integration Testing）： 在单元测试的基础上，将多个模块或组件组合在一起，验证它们能否正确地协同工作，通常用于测试子系统功能是否正常。

系统测试（System Testing）： ST通常也称为Top验证，在集成测试的基础上，将所有的模块或组件组合在一起，形成一个完整的系统，验证系统的功能是否正确，以及系统的性能是否满足要求。

理论上，这些层次的验证通常按照从低到高的顺序进行，每个层次的验证都建立在前一个层次的验证的基础上。但实际验证活动中，需要根据企业验证人员的规模、熟练度，功能需求等进行选择，不一定所有层次的验证都需要涉及。在每个层次，都需要编写相应的测试用例，运行测试，收集和分析结果，以确保芯片设计的正确性和质量。

芯片验证指标

芯片验证的指标，通常包含功能正确性、测试覆盖率、缺陷密度、验证效率、验证成本等多个方面。功能正确性是最基本的验证指标，即芯片是否能够正确地执行其设计的功能。这通常通过运行一系列的功能测试用例来验证，包括正常情况下的功能测试，以及异常情况下的鲁棒性测试。测试覆盖率是指测试用例覆盖了多少设计的功能点，以及覆盖的程度如何。高的测试覆盖率通常意味着更高的验证质量。测试覆盖率可以进一步细分为代码覆盖率、功能覆盖率、条件覆盖率等。缺陷密度是指在一定的设计规模或代码量中，发现的缺陷的数量。低的缺陷密度通常意味着更高的设计质量。验证效率是指在一定的时间和资源下，能够完成的验证工作量。高的验证效率通常意味着更高的验证生产力。验证成本是指进行验证所需要的总体资源，包括人力、设备、时间等。低的验证成本通常意味着更高的验证经济性。

功能正确性是验证的绝对指标，但在实践中，很多时候无法确定测试方案是否完备，所有测试空间是否全部测试到位，因此需要一个可量化的指标来指导验证是否足够充分，是否可以结束验证。该指标通常采用“测试覆盖率”。测试覆盖率通常有代码覆盖率（行，函数，分支）、功能覆盖率。

代码行覆盖率： 即在测试过程中，DUT的设计代码中有多少行被执行；

函数覆盖率： 即在测试过程中，DUT的设计代码中有多少函数被执行；

分支覆盖率： 即在测试过程中，DUT的设计代码中有多少分支被执行（if else）；

功能覆盖率： 即在测试过程中，有多少预定义功能被触发。

高的代码覆盖率可以提高验证的质量和可靠性，但并不能保证验证的完全正确性，因为它不能覆盖所有的输入和状态组合。因此，除了追求高的代码覆盖率，还需要结合其他测试方法和指标，如功能测试、性能测试、缺陷密度等。

芯片验证管理

芯片验证管理是一个涵盖了芯片验证过程中所有活动的管理过程，包括之前提到的验证策略的制定、验证环境的搭建、测试用例的编写和执行、结果的收集和分析、以及问题和缺陷的跟踪和修复等。芯片验证管理的目标是确保芯片设计满足所有的功能和性能要求，以及规格和标准。

在芯片验证管理中，首先需要制定一个详细的验证策略，包括验证的目标、范围、方法、时间表等。然后，需要搭建一个适合的验证环境，包括硬件设备、软件工具、测试数据等。接下来，需要编写一系列的测试用例，覆盖所有的功能和性能点，然后执行这些测试用例，收集和分析结果，找出问题和缺陷。最后，需要跟踪和修复这些问题和缺陷，直到所有的测试用例都能通过。

芯片验证管理是一个复杂的过程，需要多种技能和知识，包括芯片设计、测试方法、项目管理等。它需要与芯片设计、生产、销售等其他活动紧密协作，以确保芯片的质量和性能。芯片验证管理的效果直接影响到芯片的成功和公司的竞争力。因此，芯片验证管理是芯片开发过程中的一个重要环节。

芯片验证管理过程可以基于“项目管理平台”和“bug管理平台”进行，基于平台的管理效率通常情况下明显高于基于人工的管理模式。

芯片验证现状

当前，芯片验证通常是在芯片设计公司内部完成的，这一过程不仅技术上复杂，而且具有巨大的成本。从验收与设计的紧密关系来看，芯片验证不可避免地涉及芯片设计的源代码。然而，芯片设计公司通常将芯片设计源代码视为商业机密，这使得必须由公司内部人员来执行芯片验证，难以将验证工作外包。

芯片验证的重要性在于确保设计的芯片在各种条件下能够可靠运行。验证工作不仅仅是为了满足技术规格，还需要应对不断增长的复杂性和新兴技术的要求。随着半导体行业的发展，芯片验证的工作量不断增加，尤其是对于复杂的芯片而言，验证工作已经超过了设计工作，占比超过70%。这使得在工程师人员配比上，验证工程师人数通常是设计工程师人数的2倍或以上（例如zeku的三千人规模团队中，大约有一千人的设计工程师，两千人的验证工程师。其他大型芯片设计公司的验证人员占比类似或更高）。

由于验证工作的特殊性，需要对芯片设计源代码进行访问，这在很大程度上限制了芯片验证的外包可能性。芯片设计源代码被视为公司的核心商业机密，涉及到技术细节和创新，因此在安全和法律层面上不太可能与外部方共享。这也导致了公司内部人员必须承担验证工作的重任，增加了公司内部的工作负担和成本。

在当前情况下，芯片验证工程师的需求持续增加。他们需要具备深厚的技术背景，熟悉各种验证工具和方法，并且对新兴技术有敏锐的洞察力。由于验证工作的复杂性，验证团队通常需要庞大的规模，这与设计团队规模形成鲜明对比。

为了应对这一挑战，行业可能需要不断探索创新的验证方法和工具，以提高验证效率，降低成本。

小结：复杂芯片验证成本昂贵，表现在如下几个方面

验证工作量大： 对于复杂芯片，验证工作在整个芯片设计工作中，占比超过 70%。

人力成本高： 验证工程师人数是设计工程师人数的2倍，对于复杂业务，工程师数量在千人以上。

内部验证： 芯片设计公司为了保证商业秘密（芯片设计代码）不被泄露，只能选择招聘大量验证工程师，在公司内部进行验证工作。

芯片验证众包

相比与硬件，软件领域为了减少软件测试成本，测试外包（分包）已经成为常态，该领域的分包业务非常成熟，市场规模已经是千亿人民币级别，并朝万亿级别规模进发。从工作内容上看，软件测试和硬件验证，有非常大的共同特征（系统的目的不同的对象），如果以软件的方式对硬件验证进行分包是否可行？

把芯片验证工作进行外包（分包）面临诸多挑战，例如：

从业人员基数少： 相比软件领域，硬件开发者数量少了几个数量级。例如在github的统计上（https://madnight.github.io/githut/#/pull_requests/2023/2），传统软件编程语言占（Python、Java、C++，Go）比接近 50%， 而硬件描述语言，verilog占比仅 0.076%，这能从侧面反应出各自领域的开发者数量。

验证工具商业化： 企业中使用的验证工具（仿真器、形式化、数据分析）几乎都是商业工具，这类工具对于普通人来说几乎不可见，自学难度高。

开放学习资料少： 芯片验证涉及到访问芯片设计的源代码，而这些源代码通常被视为公司的商业机密和专有技术。芯片设计公司可能不愿意公开详细的验证过程和技术，限制了学习材料的可用性。

可行性分析

虽然芯片验证领域一直以来相对封闭，但从技术角度而言，采用分包的方式进行验证是一种可行的选择。这主要得益于以下几个因素：

首先，随着开源芯片项目的逐渐增多，验证过程中所涉及的源代码已经变得更加开放和透明。这些开源项目在设计和验证过程中没有商业机密的顾虑，为学习和研究提供了更多的可能性。即使某些项目涉及商业机密，也可以通过采用加密等方式来隐藏设计代码，从而在一定程度上解决了商业机密的问题，使验证更容易实现。

其次，芯片验证领域已经涌现出大量的基础验证工具，如verilator和systemc等。这些工具为验证工程师提供了强大的支持，帮助他们更高效地进行验证工作。通过这些工具，验证过程的复杂性和难度得到了一定程度的缓解，为采用分包的验证方法提供了更为可行的技术基础。

在开源软件领域，已经有一些成功的案例可供参考。例如，Linux内核的验证过程采用了分包的方式，不同的开发者和团队分别负责不同的模块验证，最终形成一个整体完备的系统。类似地，机器学习领域的ImageNet项目也采用了分包标注的策略，通过众包的方式完成大规模的图像标注任务。这些案例为芯片验证领域提供了成功的经验，证明了分包验证在提高效率、降低成本方面的潜力。

因此，尽管芯片验证领域相对于其他技术领域而言仍显得封闭，但技术的进步和开源项目的增多为采用分包验证提供了新的可能性。通过借鉴其他领域的成功经验和利用现有的验证工具，我们有望在芯片验证中推动更加开放、高效的验证方法的应用，进一步促进行业的发展。这种技术的开放性和灵活性将为验证工程师提供更多的选择，推动芯片验证领域迎来更为创新和多样化的发展。

技术路线

为了克服挑战，让更多的人参与到芯片验证，本项目从如下几个技术方向进行持续尝试

提供多语言验证工具： 传统芯片验证是基于System Verilog编程语言进行，但是该语言用户基数少，为了让其他软件开发/测试的技术人员参与到芯片验证，本项目提供多语言验证转换工具Picker，它可以让验证者使用自己熟悉的编程语言（例如C++/Python/Java/Go）基于开源验证工具参与验证工作。

提供验证学习材料： 芯片验证学习材料少，主要原因由于商业公司几乎不可能公开其内部资料，为此本项目会持续更新学习材料，让验证人员可在线，免费学习所需要的技能。

提供真实芯片验证案例： 为了让学习材料更具使用性，本项目以“香山昆明湖（工业级高性能risc-v处理器）IP核”作为基础，从中摘取模块持续更新验证案例。

组织芯片设计分包验证： 学以致用是每个人学习的期望目标，为此本项目定期组织芯片设计的验证分包，让所有人（无论你是大学生、验证专家、软件开发测试者、还是中学生）都可以参与到真实芯片的设计工作中去。

本项目的目标是达到如下愿景，“打开传统验证模式的黑盒，让所有感兴趣的人可以随时随地的，用自己擅长的编程语言参与芯片验证”。

2 - 数字电路

什么是数字电路

数字电路是一种利用两种不连续的电位来表示信息的电子电路。在数字电路中，通常使用两个电源电压，分别表示高电平（H）和低电平（L），分别代表数字1和0。这样的表示方式通过离散的电信号，以二进制形式传递和处理信息。

大多数数字电路的实现基于场效应管，其中最常用的是 MOSFET（Metal-Oxide-Semiconductor Field-Effect Transistor，金属氧化物半导体场效应管）。MOSFET 是一种半导体器件，可以在电场的控制下调控电流流动，从而实现数字信号的处理。

在数字电路中，MOSFET 被组合成各种逻辑电路，如与门、或门、非门等。这些逻辑门通过不同的组合方式，构建了数字电路中的各种功能和操作。以下是一些数字电路的基本特征：

(1) 电位表示信息： 数字电路使用两种电位，即高电平和低电平，来表示数字信息。通常，高电平代表数字1，低电平代表数字0。

(2) MOSFET 实现： MOSFET 是数字电路中最常用的元件之一。通过控制 MOSFET 的导通和截止状态，可以实现数字信号的处理和逻辑运算。

(3) 逻辑门的组合： 逻辑门是数字电路的基本构建块，由 MOSFET 组成。通过组合不同的逻辑门，可以构建复杂的数字电路，实现各种逻辑功能。

(4) 二进制表达： 数字电路中的信息通常使用二进制系统进行表示。每个数字都可以由一串二进制位组成，这些位可以在数字电路中被处理和操作。

(5) 电平转换和信号处理： 数字电路通过电平的变化和逻辑操作，实现信号的转换和处理。这种离散的处理方式使得数字电路非常适用于计算和信息处理任务。

为什么要学习数字电路

学习数字电路是芯片验证过程中的基础和必要前提，主要体现在以下多个方面：

(1) 理解设计原理： 数字电路是芯片设计的基础，了解数字电路的基本原理和设计方法是理解芯片结构和功能的关键。芯片验证的目的是确保设计的数字电路在实际硬件中按照规格正常工作，而理解数字电路原理是理解设计的关键。

(2) 设计规范： 芯片验证通常涉及验证设计是否符合特定的规范和功能要求。学习数字电路可以帮助理解这些规范，从而更好地构建测试用例和验证流程，确保验证的全面性和准确性。

(3) 时序和时钟： 时序问题是数字电路设计和验证中的常见挑战。学习数字电路可以帮助理解时序和时钟的概念，以确保验证过程中能够正确处理时序问题，避免电路中的时序迟滞和冲突。

(4) 逻辑分析： 芯片验证通常涉及对逻辑的分析，确保电路的逻辑正确性。学习数字电路可以培养对逻辑的深刻理解，从而更好地进行逻辑分析和故障排查。

(5) 测试用例编写： 在芯片验证中，需要编写各种测试用例来确保设计的正确性。对数字电路的理解可以帮助设计更全面、有针对性的测试用例，涵盖电路的各个方面。

(6) 信号完整性： 学习数字电路有助于理解信号在电路中的传播和完整性问题。在芯片验证中，确保信号在不同条件下的正常传递是至关重要的，特别是在高速设计中。

整体而言，学习数字电路为芯片验证提供了基础知识和工具，使验证工程师能够更好地理解设计，编写有效的测试用例，分析验证结果，并解决可能出现的问题。数字电路的理论和实践经验对于芯片验证工程师来说都是不可或缺的。

数字电路基础知识

可以通过以下在线资源进行数字电路学习：

• 清华大学数字电路基础
• 中科大数字电路实验
• 数字设计和计算机体系结构
• MIT 数字集成电路分析与设计

硬件描述语言Chisel

传统描述语言

硬件描述语言（Hardware Description Language，简称 HDL）是一种用于描述数字电路、系统和硬件的语言。它允许工程师通过编写文本文件来描述硬件的结构、功能和行为，从而实现对硬件设计的抽象和建模。

HDL 通常被用于设计和仿真数字电路，如处理器、存储器、控制器等。它提供了一种形式化的方法来描述硬件电路的行为和结构，使得设计工程师可以更方便地进行硬件设计、验证和仿真。

常见的硬件描述语言包括：

• Verilog：Verilog 是最常用的 HDL 之一，它是一种基于事件驱动的硬件描述语言，广泛应用于数字电路设计、验证和仿真。
• VHDL：VHDL 是另一种常用的 HDL，它是一种面向对象的硬件描述语言，提供了更丰富的抽象和模块化的设计方法。
• SystemVerilog：SystemVerilog 是 Verilog 的扩展，它引入了一些高级特性，如对象导向编程、随机化测试等，使得 Verilog 更适用于复杂系统的设计和验证。

Chisel

Chisel 是一种现代化高级的硬件描述语言，与传统的 Verilog 和 VHDL 不同，它是基于 Scala 编程语言的硬件构建语言。Chisel 提供了一种更加现代化和灵活的方法来描述硬件，通过利用 Scala 的特性，可以轻松地实现参数化、抽象化和复用，同时保持硬件级别的效率和性能。

Chisel 的特点包括：

• 现代化的语法：Chisel 的语法更加接近软件编程语言，如 Scala，使得硬件描述更加直观和简洁。
• 参数化和抽象化：Chisel 支持参数化和抽象化，可以轻松地创建可配置和可重用的硬件模块。
• 类型安全：Chisel 是基于 Scala 的，因此具有类型安全的特性，可以在编译时检测到许多错误。
• 生成性能优化的硬件：Chisel 代码可以被转换成 Verilog，然后由标准的 EDA 工具链进行综合、布局布线和仿真，生成性能优化的硬件。
• 强大的仿真支持：Chisel 提供了与 ScalaTest 和 Firrtl 集成的仿真支持，使得对硬件进行仿真和验证更加方便和灵活。

Chisel版的全加法器实例

电路设计如下图所示：

完整的Chisel代码如下：

package examples

import chisel3._

class FullAdder extends Module {
  // Define IO ports
  val io = IO(new Bundle {
    val a = Input(UInt(1.W))    // Input port 'a' of width 1 bit
    val b = Input(UInt(1.W))    // Input port 'b' of width 1 bit
    val cin = Input(UInt(1.W))  // Input port 'cin' (carry-in) of width 1 bit
    val sum = Output(UInt(1.W)) // Output port 'sum' of width 1 bit
    val cout = Output(UInt(1.W))// Output port 'cout' (carry-out) of width 1 bit
  })

  // Calculate sum bit (sum of a, b, and cin)
  val s1 = io.a ^ io.b               // XOR operation between 'a' and 'b'
  io.sum := s1 ^ io.cin              // XOR operation between 's1' and 'cin', result assigned to 'sum'

  // Calculate carry-out bit
  val s3 = io.a & io.b               // AND operation between 'a' and 'b', result assigned to 's3'
  val s2 = s1 & io.cin               // AND operation between 's1' and 'cin', result assigned to 's2'
  io.cout := s2 | s3                 // OR operation between 's2' and 's3', result assigned to 'cout'
}

Chisel 学习材料可以参考官方文档：https://www.chisel-lang.org/docs

3 - 创建DUT

在本文档中，DUT（Design Under Test）是指在芯片验证过程中，被验证的对象电路或系统。DUT是验证的主体，在基于picker工具创建DUT时，需要考虑被测对象的功能、性能要求和验证目标，例如是需要更快的执行速度，还是需要更详细的测试信息。通常情况下DUT，即RTL编写的源码，与外围环境一起构成验证环境（test_env），然后基于该验证环境编写测试用例。在本项目中，DUT是需要测试的Python模块，需要通过RTL进行转换。传统的RTL语言包括Verilog、System Verilog、VHDL等，然而作为新兴的RTL设计语言，Chisel（https://www.chisel-lang.org/）也以其面向对象的特征和便捷性，逐渐在RTL设计中扮演越来越重要的角色。本章以果壳处理器-NutShell中的cache源代码到Python模块的转换为例进行介绍如何创建DUT。

Chisel与果壳

准确来说，Chisel是基于Scala语言的高级硬件构造（HCL）语言。传统HDL是描述电路，而HCL则是生成电路，更加抽象和高级。同时Chisel中提供的Stage包则可以将HCL设计转化成Verilog、System Verilog等传统的HDL语言设计。配合上Mill、Sbt等Scala工具则可以实现自动化的开发。

果壳是使用 Chisel 语言模块化设计的、基于 RISC-V RV64 开放指令集的顺序单发射处理器实现。果壳更详细的介绍请参考链接：https://oscpu.github.io/NutShell-doc/

果壳 cache

果壳cache（Nutshell Cache）是果壳处理器中使用的缓存模块。其采用三级流水设计，当第三级流水检出当前请求为MMIO或者发生重填（refill）时，会阻塞流水线。同时，果壳cache采用可定制的模块化设计，通过改变参数可以生成存储空间大小不同的一级cache（L1 Cache）或者二级cache（L2 Cache）。此外，果壳cache留有一致性（coherence）接口，可以处理一致性相关的请求。

Chisel 转 Verilog

Chisel中的stage库可以帮助由Chisel代码生成Verilog、System Verilog等传统的HDL代码。以下将简单介绍如何由基于Chisel的cache实现转换成对应的Verilog电路描述。

初始化果壳环境

首先从源仓库下载整个果壳源代码，并进行初始化：

mkdir cache-ut
cd cache-ut
git clone https://github.com/OSCPU/NutShell.git
cd NutShell && git checkout 97a025d
make init

创建scala编译配置

在cache-ut目录下创建build.sc，其中内容如下：

import $file.NutShell.build
import mill._, scalalib._
import coursier.maven.MavenRepository
import mill.scalalib.TestModule._

// 指定Nutshell的依赖
object difftest extends NutShell.build.CommonNS {
  override def millSourcePath = os.pwd / "NutShell" / "difftest"
}

// Nutshell 配置
object NtShell extends NutShell.build.CommonNS with NutShell.build.HasChiselTests {
  override def millSourcePath = os.pwd / "NutShell"
  override def moduleDeps = super.moduleDeps ++ Seq(
        difftest,
  )
}

// UT环境配置
object ut extends NutShell.build.CommonNS with ScalaTest{
    override def millSourcePath = os.pwd
    override def moduleDeps = super.moduleDeps ++ Seq(
        NtShell
    )
}

实例化 cache

创建好配置信息后，按照scala规范，创建src/main/scala源代码目录。之后，就可以在源码目录中创建nut_cache.scala，利用如下代码实例化Cache并转换成Verilog代码：

package ut_nutshell

import chisel3._
import chisel3.util._
import nutcore._
import top._
import chisel3.stage._

object CacheMain extends App {
  (new ChiselStage).execute(args, Seq(
      ChiselGeneratorAnnotation(() => new Cache()(CacheConfig(ro = false, name = "tcache", userBits = 16)))
    ))
}

生成RTL

完成上述所有文件的创建后（build.sc，src/main/scala/nut_cache.scala），在cache-ut目录下执行如下命令：

mkdir build
mill --no-server -d ut.runMain ut_nutshell.CacheMain --target-dir build --output-file Cache

注：mill环境的配置请参考 https://mill-build.com/mill/Intro_to_Mill.html

上述命令成功执行完成后，会在build目录下生成verilog文件：Cache.v。之后就可以通过picker工具进行Cache.v到 Python模块的转换。除去chisel外，其他HCL语言几乎都能生成对应的 RTL代码，因此上述基本流程也适用于其他HCL。

DUT编译

一般情况下，如果需要DUT生成波形、覆盖率等会导致DUT的执行速度变慢，因此在通过picker工具生成python模块时会根据多种配置进行生成：（1）关闭所有debug信息；（2）开启波形；（3）开启代码行覆盖率。其中第一种配置的目标是快速构建环境，进行回归测试等；第二种配置用于分析具体错误，时序等；第三种用于提升覆盖率。

4 - DUT验证

开放验证平台的目标是功能性验证，其一般有以下步骤：

1. 确定验证对象和目标

通常来说，同时交付给验证工程师的还有DUT的设计文档。此时您需要阅读文档或者源代码，了解验证对象的基本功能、主体结构以及预期功能。

2. 构建基本验证环境

充分了解设计之后，您需要构建验证的基本环境。例如，除了由Picker生成的DUT外，您可能还需要搭建用于比对的参考模型，也可能需要为后续功能点的评测搭建信号的监听平台。

3. 功能点与测试点分解

在正式开始验证之前，您还需要提取功能点，并将其进一步分解成测试点。提取和分解方法可以参考：CSDN:芯片验证系列——Testpoints分解

4. 构造测试用例

有了测试点之后，您需要构造测试用例来覆盖相应的测试点。一个用例可能覆盖多个测试点。

5. 收集测试结果

运行完所有的测试用例之后，您需要汇总所有的测试结果。一般来说包括代码行覆盖率以及功能覆盖率。前者可以通过Picker工具提供的覆盖率功能获得，后者则需要您通过监听DUT的行为判断某功能是否被用例覆盖到。

6. 评估测试结果

最后您需要评估得到的结果，如是否存在错误的设计、某功能是否无法被触发、设计文档表述是否与DUT行为一致、设计文档是否表述清晰等。

接下来我们以果壳Cache的MMIO读写为例，介绍一般验证流程：

1 确定验证对象和目标：
果壳Cache的MMIO读写功能。MMIO是一类特殊的IO映射，其支持通过访问内存地址的方式访问IO设备寄存器。由于IO设备的寄存器状态是随时可能改变的，因此不适合将其缓存在cache中。当收到MMIO请求时，果壳cache不会在普通的cache行中查询命中/缺失情况，而是会直接访问MMIO的内存区域来读取或者写入数据。

2 构建基本验证环境：
我们可以将验证环境大致分为五个部分：

1. Testcase Driver：负责由用例产生相应的信号驱动
2. Monitor：监听信号，判断功能是否被覆盖以及功能是否正确
3. Ref Cache：一个简单的参考模型
4. Memory/MMIO Ram：外围设备的模拟，用于模拟相应cache的请求
5. Nutshell Cache Dut：由Picker生成的DUT

此外，您可能还需要对DUT的接口做进一步封装以实现更方便的读写请求操作，具体可以参考Nutshll cachewrapper。

3 功能点与测试点分解：
果壳cache可以响应MMIO请求，进一步分解可以得到一下测试点：

测试点1：MMIO请求会被转发到MMIO端口上
测试点2：cache响应MMIO请求时，不会发出突发传输（Burst Transfer）的请求
测试点3：cache响应MMIO请求时，会阻塞流水线

4 构造测试用例： 测试用例的构造是简单的，已知通过创建DUT得到的Nutshell cache的MMIO地址范围是0x30000000~0x7fffffff，则我们只需访问这段内存区间，应当就能获得MMIO的预期结果。需要注意的是，为了触发阻塞流水线的测试点，您可能需要连续地发起请求。
以下是一个简单的测试用例：

# import CacheWrapper here

def mmio_test(cache: CacheWrapper):
	mmio_lb	= 0x30000000
	mmio_rb	= 0x30001000
	
	print("\n[MMIO Test]: Start MMIO Serial Test")
	for addr in range(mmio_lb, mmio_rb, 16):
		addr &= ~(0xf)
		addr1 = addr
		addr2 = addr + 4
		addr3 = addr + 8

		cache.trigger_read_req(addr1)
		cache.trigger_read_req(addr2)
		cache.trigger_read_req(addr3)

		cache.recv()
		cache.recv()
		cache.recv()
		
	print("[MMIO Test]: Finish MMIO Serial Test")

5 收集测试结果：

'''
    In tb_cache.py
'''

# import packages here

class TestCache():
    def setup_class(self):
        color.print_blue("\nCache Test Start")

        self.dut = DUTCache("libDPICache.so")
        self.dut.init_clock("clock")

        # Init here
        # ...

        self.testlist = ["mmio_serial"]
    
    def teardown_class(self):
        self.dut.finalize()
        color.print_blue("\nCache Test End")

    def __reset(self):
        # Reset cache and devices
            
    # MMIO Test
    def test_mmio(self):
        if ("mmio_serial" in self.testlist):
            # Run test
            from ..test.test_mmio import mmio_test
            mmio_test(self.cache, self.ref_cache)
        else:
            print("\nmmio test is not included")

    def run(self):
        self.setup_class()
        
        # test
        self.test_mmio()

        self.teardown_class()
    pass

if __name__ == "__main__":
	tb = TestCache()
	tb.run()

运行：

    python3 tb_cache.py

以上仅为大致的运行流程，具体可以参考：Nutshell Cache Verify。

6 评估运行结果
运行结束之后可以得到以下数据：
行覆盖率：

功能覆盖率：

可以看到预设的MMIO功能均被覆盖且被正确触发。

5 - 验证报告

验证报告是对整个验证过程的回顾，是验证合理与否的重要支持文件。一般情况下，验证报告需要包含以下内容：

1. 文档基本信息（作者、日志、版本等）
2. 验证对象（验证目标）
3. 功能点介绍
4. 验证方案
5. 测试点分解
6. 测试用例
7. 测试环境
8. 结果分析
9. 缺陷分析
10. 测试结论

以下内容对列表进行进一步解释，具体示例可以参考nutshell_cache_report_demo.pdf

1. 基本信息

应当包括作者、日志、版本、日期等。

2. 验证对象（验证目标）

需要对您的验证对象做必要的介绍，可以包括其结构、基本功能、接口信息等。

3. 功能点介绍

通过阅读设计文档或者源码，您需要总结DUT的目标功能，并将其细化为各功能点。

4. 验证方案

应当包括您计划的验证流程以及验证框架。同时，您也应当接受您的框架各部分是如何协同工作的。

5. 测试点分解

针对功能点提出的测试方法。具体可以包括在怎样的信号输入下应当观测到怎样的信号输出。

6. 测试用例

测试点的具体实现。一个测试用例可以包括多个测试点。

7. 测试环境

包括硬件信息、软件版本信息等。

8. 结果分析

结果分析一般指覆盖率分析。通常来说应当考虑两类覆盖率：
1. 行覆盖率： 在测试用例中有多少RTL行代码被执行。一般来说我们要求行覆盖率在98%以上。
2. 功能覆盖率：根据相应的信号判断您提取的功能点是否被覆盖且被正确触发。一般我们要求测试用例覆盖每个功能点。

9. 缺陷分析

对DUT存在的缺陷进行分析。可以包括设计文档的规范性和详细性、DUT功能的正确性（是否存在bug）、DUT功能是否能被触发等方面。

10. 验证结论

验证结论是在完成芯片验证过程后得出的最终结论，是对以上内容的总结。