意图 vs. 阐释

为了补救此状况，SystemVerilog 加入数个硬件导向之建构元:
◆always_ff: 将序列逻辑模型化
◆always_comb: 将组合逻辑模型化
◆always_latch: 将闩锁式逻辑模型化

这些建构元可用来消除意图之含煳不轻，经由将浪费于不必要之阐释(和重新阐释)之生产时间週期最小化，使得设计和侦错较为直接， 其中使用之工具(例如：编译器或 linter) 可立即以旗标标示任何建构元之误用。以下图 3 系显示如何澄清图 2之使用情境。注意，此建构元亦可阐明主体中之遗漏所造成拴锁介面 (于always@* 建构元所註记之差异)。

同样的，其他常见误释为“full case”和“parallel case”使用情境，其中在模拟器和合成工具之行为中亦造成不符。为了因应此问题，SystemVerilog 加入了unique (单一的) 和 priority（优先权）修饰语。

行为 vs.通信

另一个主要的优点在于能改进抽象化。我们多半会以抽象的通讯应用开始，亦或一简单的机制，但是后来在设计效用上变为不足，例如不能达到频宽或潜伏要求。同时具有可经由改进或换成更精确、更有效之机制之分隔和抽象化，可使设计随着研发週期进行而可再使用并且可维持。此想法和支持它的方法和工具已经出现一阵子，肇始于Rowson和Sangiovanni，现在则是系统设计之最佳实施方式之一部分。以下例子为一简单的片断程式码，其执行了图 5之模式以显示通信政策之改变可于介面本身(而非其週遭之所有模组)产生影响。

interface chip_bus (input bit clk);
bit request, grant, ready;
bit [63:0] address;
bit [31:0] data;

// Protocol may change here

endinterface

module CPU (chip_bus io);
...
endmodule

module RAM(chip_bus pins);
...
endmodule

module top;
bit clk = 0;
//instantiate the interface

chip_bus a(clk);

//connect interface to module
//instance
RAM mem(a);
//connect interface to module
//instance
CPU cpu(a);

endmodule

此片段的程式码显示了介面chip_bus 是如何在设计中被举例说明，并且穿过一个埠而成为单一项目。如以上简单呈现之例子所示，SystemVerilog 介面为一捆线路收集。当一介面被用来作为一埠，其中网路被视作inout 埠。

通信抽象化和改进亦是组合式验证之中心概念，其中验证工作可分别针对行为和通信来进行，以致个别区块。使用介面使侦错註解方法可扩展，而且是相当强有力之追踪通信之方式。视觉化方法可加入抽象层，其中介面案例将数条线聚集成一将被更新或环绕各区块传递之单一物件。图 6 系显示这些概念如何显示于一侦错工具。

处理程序层级侦错

图 7系显示一用于侦错工具(例如：波形图)以显示处理程序，使得资料能以可理解并可管理之方式呈现之例子。

类别和物件

随着抽象化和执行层级之扩张、所理解之鸿沟变宽，设计者对于在一抽象层级和跨抽象阶层之各种关联和关系之概念化能力有显着之缩减。对于改进此一缺点，软件领域中有许多视觉呈现方式已证实极为有用：包括3种主要概念和图形：

1) 元件图：又可称作类别图或物件图(如显示于统一模式语言 (UML)中的)，其中属性可被显示为註解、一般化或规格化、聚集、从属或其他关联(以连结呈现)。以下图 10系显示一简化之以统一模式语言 (UML)标记Packet(封包) 类别例子之类别图。

2) 互动和活动图：一与元件互动之元件图正交垂直(或只是与其互补)的图。此图可以许多形式呈现，包括时序图或事件 (或transaction(处理程序))略图。这亦可被称作统一模式语言 (UML)之序列图.

3) 行为图：用来描述互动之语意。可以许多不同形式呈现。其于统一模式语言 (UML)即为状态图；系统操作之(阶层式) FSM(有限状态机) 描述。

上述这些图对于分析和侦错极为重要；虽然互所区隔，但是它们又以一整合方式共同分析系统和其行为。

在硬件侦错方面，亦有类似用于硬件领域之图形来分别记录结构和连结、随着时间之互动、及行为。最近图形通常埋藏于设计者之头脑中，如同一般软件侦错工具并不具有并行支援。这样的图形最近随着正规的侦错和合成推断之进步而浮出檯面，被称作“行为模式侦错”和“流程图”。这些图和原始码共同提供对系统之不同看法，并且藉由註解、拖放功能等相互连结。试想，由于SystemVerilog额外的抽象，这些图形需要改良，使得以下几种软件领域有所进展之模型化 (如统一模式语言 (UML))与硬件领域相似：

1) 概要图：目前是以模组(例如：元件) 互相连接之形式呈现。如上所述，介面亦须于此种图形上再现(参见图 6)。然而，此图目前最大的限制在于其主要针对设计。测试平台元件一般被标示为 “黑盒子”，其可经由原始码註记而加以侦错。註记是相当有用的，而且如果物件资料被保存下来(新物件注意用于互动模式，及后处理模式之压缩倾印)，则註记仍然会相当有用。然而，在此需理解的是，以着重于物件关系 (例如：类别案例)之元件图来延展测试平台之图示功能。列出所有类别之类别视觉化，将各元件连结原始码，经由清楚的显示类别继承之而可显示其可被(主动) 註解之宣告 [5]。此即是在元件图中包括类别 (静态图)和物件(物件值之类别註解)之最高价值和功用。当然，可合理的把其想成UML 变数 (即所谓名称 (profile))，尽管我们认为其更类似用于指定语意范畴之註解，而非适用于硬件设计者之一般表示方式。

2) 波形图：此为系统发展和互动之时间绪图。近年来我们可见就资料群集、封装、及呈现方面而言抽象化转向更高的层次。其概念即处理程序层级模型化 (Transaction Level Modeling, TLM)，其中元件互动被抽象化成一组抽象的描述，亦即撷取高层次之通信而非信号 (字元或位元) 层次。物件可被显示成具有使用时间之实体 (非常类似 assertions(断言，一种程式检验机制)被显示为波形图)，而活动领域可运用处理程序层次图来註记下互动或通信。

3) 行为 (流程) 图：经由阐明系统运作之时间性和逻辑性以显示资料流和度和对其之控制。其系系统功能运作之图示，能精鍊 (经由合成之过程)主动式 (和非主动式) 叙述和转换，并将其呈现给使用者。这需要2种形式之改进：

a) 今日之HDL呈现了RTL层级之资讯。可经由对运作图本身增进相关元件群集之形式，或藉由赋予此图示而和另一个别图示 (例如一(模拟) FSM2 图 )共同来呈现统一模式语言 (UML)之类似状态图。这是因为要顾及语言如SystemVerilog所增加之抽象性。

b) 测试平台叙述 通常被标记为黑盒子，其内部无法以流程图加以追踪或视觉化。由于流程图系以设计分析为其目的，因此这不是重大之限制。不过，应该对设计至测试平台之间的桥樑加以改良，以对设计运作环境(例如：测试平台限制)有较清楚之了解。

动态过程、通信、及同步化

由于处理过程会共用一些资源(例如：记忆体、资料等)，因此同步化 (和互斥)是必要的，这些可经由旗标和(或)事件而达成。邮箱系一种处理资料传输之工具。旗标和邮箱系内建类别，事件则是 Verilog 资料型态之延伸用法。

对于并行之侦错较具挑战，因为 “state” 资讯在各程序中必须被保存，因此资料储存的量增加。此外，并行会引发埋伏于其内部之潜在错误。它们包括：
接近违反；
死锁；
资料竞争错误；及同步误差

为了侦错上述违规，附名 fork 之前后文在互动式侦错中可呈现于使用者之眼前，而更多资讯可在纪录图形中被保存，此和assertion attempts (例如：附名 fork、创建时间、及另外的前后文相依关系有关联)之保存类似。由于共享资源仅能经由命名物件(例如：邮箱、旗标、及事件)来存取，因此在后处理过程中之互动式侦错或检验监测那些物件对于辨识资料竞争错误和同步误差即十分重要。运用 assertions(断言，一种程式检验机制) 藉由各通信通道监测共享资源之存取，可让死锁等之违规更容易被标上旗号(使用暂停)，并且经由使用assertion 资讯和提示能促进以后之设计侦错之实施。

以Assertion为基础之设计和侦错

有些建构元非常的简要。例如图 12所示之重复运算子(*) 隐藏许多内部的重复步骤。需对此建构元投以额外之注意。同样的，其他除了本文章已提过之原始码和波形显示之外之视觉方式，亦须加以适当的扩展以调和并影响assertions。