数字逻辑的可验证性是指，数字逻辑（RTL代码）中所具备的有助于验证工程师开展验证工作和加快验证收敛的设计属性。
数字逻辑设计工程师写代码时，通常要考虑逻辑
电路的延迟，面积，功耗等特性。如果这些特性不同，即使是相同的业务功能，设计出来的逻辑电路也千差万别。同样的道理，如果设计工程师也考虑了代码的可验证性，或多或少都会给设计逻辑电路带来一些变化。
这些变化在IC设计者看来或许是微不足道的，或许是可有可无的。但是对IC验证者来说，甘之如饴，意义非凡。
通常来说，交付一个模块，设计和验证的工作量比例是3:7。当然，此处的验证不仅仅是数字逻辑验证（EDA验证），还包括
FPGA验证，EMU验证等，但其中的大头一定是EDA验证。因此，加强数字逻辑的可验证性设计，对整个模块的交付，乃至整个项目的交付，都意义重大。
加强数字逻辑的可验证性设计，应从何做起？
窃以为，可从以下五个方面进行考虑。
第一，模块划分。
架构师或IC设计者首先面对的是业务的处理流程，包括数据流和控制流。需要对业务复杂的处理流程进行分析细化和分布处理。最终将处理流程分成多个步骤，每一步可对应一个模块。划分模块时，应遵循“高内聚，低耦合”。即，一个模块应该负责处理比较独立的业务功能，且该模块与上下游模块的交互具备一定的规范性。
模块业务功能的独立性，是从抽象程度更高的业务处理流程中划分的，这些通常都是经验丰富的架构师的活儿，小小验证不敢妄言。而模块之间进行交互的接口相对具体一些，相关的问题和痛点也比较直观，验证者或可班门弄斧，吐槽吐槽。
在验证者看来，模块间交互的接口的规范性主要体现在以下几点。
1.对于配置接口，若有大量的配置信息需要通过接口传递，应定义成配置总线，而不是通过port直接连线。飘逸随性的连线容易引发混乱。
2. 一个接口由一组信号组成，这组信号对应一种特定的业务数据流，负责传递一种特定的业务报文。
3. 通过抽象，可以把一个接口传递的业务数据流转换为一种业务报文。
4. 接口之间尽量不能复用信号。验证平台中，对每个接口会接BFM，如果涉及多接口之间信号复用，会出现driver多驱和monitor错误误报。
从这四点可以看出，接口信号的规范性主要是为了便于验证者将时序级信息抽象提取成事务级的报文。架构师或者设计者划分模块时，应该也把每级模块的各个接口对应的业务数据报文格式都定义好，如下图所示。
第二，数据采样。
架构师或设计者定义接口时，应考虑接口的下游模块如何采样有效数据。当前模块通过接口输出数据到下游模块，应该站在下游模块的角度考虑：如何能让下游模块简单便捷的采样到有效数据。这样做，不仅仅是对下游模块的设计者考虑，更是对本模块的验证者考虑。
接口采样数据时，采样时钟如何获取（系统时钟？输入时钟？），用时钟上升沿采，还是下降沿采？
如果没有明确说明接口的采样时钟，而让验证者使用DUT内部时钟采样接口数据，会降低模块整体的可验证性。因为使用的DUT内部时钟信号的正确性无法保证。此外，后仿时网表中的时钟信号很可能被改名了，找不到了，
仿真就会编译报错。
如果接口数据没有时钟信号，而让验证者通过判断端口数据的跳变来采样，也会降低模块整体的可验证性。因为，数据跳变不能准确反应新的数据的采样时刻，例如有毛刺的时候，例如随机到两个连续的相同的数据的时候。
数据有效性指示怎样实现？对与模块的输入数据，如何判断数据是有效的？对于输出数据，如何指示数据是有效的？举几个例子。
AXI接口有五路独立通道，每路通道通过特定的valid信号指示数据有效性。AW-valid/AR-valid/W-valid/B-valid/R-valid。
UFS物理层通过request-grant握手完成数据传输，通过request指示数据有效性。
PCIe物理层TX方向数据量通道通过特定的START-END码型标注有效数据流的起始和结尾，实现了对有效数据的指示。
如果没有数据有效性指示信号，验证很难从数据流中区分无效数据和有效数据，会严重影响采样的准确性，进而降低模块整体的可验证性。数据有效性指示对验证者来说，是不可或缺的，是必选项。如果架构师或设计者不提供，验证者只能自己通过辅助手段来添加。这样做会减少随机力度，增加验证复杂度，也增加了调试和定位的时间，进而降低了模块的可验证性。
第三，报文格式。
一个接口可以传输多种报文。架构师或设计者在定义一个接口的报文时，多种报文的格式应尽量统一。通常情况，报文的结构包括帧头，payload字段，控制字段，帧尾等。PCIe报文如下图所示。
建议通过一个帧的信息域段表示帧类型，不同类型的帧，对payload，控制字段等帧的信息进行修改，帧尾格式相对固定。
统一格式的帧结构对验证者开发BFM组件（driver， monitor）有益。通常，一个接口对应一组BFM组件。如果该接口的多种报文格式都是统一的，验证者就可以把BFM的代码也统一起来。在driver中，对报文进行解析和驱动可以封装成一个task，多种报文，多次调用即可。在monitor中，对接口信号进行采样和组包可以封装成一个task，多种报文，多次调用即可。这样可以使BFM的代码归一化，减少重复和冗余，缩短环境错误的debug时间，减少环境平台的错误数量。
如果一个接口的多种报文的帧结构不统一，在driver和monitor中都要针对不同的报文结构，专门开发相关的解包驱动task和采样task。这样代码量就多了。言多必失，代码写多了也容易出错。
第四，仿真加速。
相对于FPGA验证和EMU验证，EDA验证仿真速度非常满。因此，当DUT有传输大量数据的场景时，如果设计者能添加加速仿真模式，等比例缩小传输数据量以减少EDA仿真时间，可提升仿真效率。验证的目的是发现DUT中的bug，是通过激励覆盖全部的DUT逻辑分支。如果对同一个逻辑分支用大量的数据量反复覆盖，不会增加DUT整体的代码覆盖率，对功能覆盖率也贡献微薄，反而是白白浪费了宝贵的仿真时间。
加速仿真模式下，令DUT等比例缩小传输数据的前提是，数字逻辑对数据量的处理是归一的，是一致的。数据流经过的逻辑分支是唯一的，恒定的。
目前，在逻辑设计中使用加速仿真策略也比较流行。例如在PCIe物理层协议中，规定当软件配置了Turbo_Sim模式（加速仿真），本来连续传输1024个Training Sequence业务报文，减少到只传输2个即可。再例如，某显示驱动芯片的测试模式，正常情况下需要传输65536个Byte的测试码型，在加速仿真模式下，只需要传输256个即可。
加速仿真模式，可以通过定义特定的宏来实现，也可通过配置寄存器来实现。通过配置寄存器使能加速仿真模式，对验证者更加友好。其原因有二：
其一，通过配置寄存器的方式，不会改变DUT的代码。Merge覆盖率数据不受加速和非加速两种模式的影响。
其二，通过配置寄存器的方式，加速仿真模式的测试用例和非加速仿真的测试用例可直接放在一起回归，不用在命令行添加额外的控制字符。
第五，信号命名。
寄存器表单中的寄存器域名称字符与数字逻辑内部的Reg名称字符保持一致。验证者可根据表单字符串在RTL代码中搜索寄存器信号，而不用每次都麻烦设计同学。
设计者在集成多个模块，包数字逻辑的顶层模块TOP wrapper时，顶层端口信号要与内部模块的端口信号名称保持一致。验证者在IT验证平台中重用UT平台时，与DUT连接的interface文件可直接重用UT的代码。
以上五点赘述，仅是小小的IC验证者在窥视高深莫测的芯片微架构设计和数字逻辑设计时，嘴里嘟嘟囔囔发的几句牢骚意见而已。不当之处，架构师和设计者们还是要多多保函，一笑而过。
突然，有人问，数字逻辑的可验证性设计，用英语怎么说？毕竟有很多在外企工作的小伙伴。
大家苦苦思考。“有了！”经验丰富的IC设计者田同学一拍大腿，说到：“在设计领域，本来就有DFX技术一说。Design For X，面向产品生命周期的设计，X可以是生命周期的任一环节。例如DFT，design for test面向测试的设计。DFI，design for inspec
tion面向检验的设计。DFS，design for service面向维护的设计。这个数字逻辑的可验证性设计，就叫DFV吧，design for verification。”
原作者：一只特立独行的猪
