SystemVerilog面临之挑战和机会

随着设计日益复杂、IC产能扩大、费用和风险升高、停滞 (甚至下降) 之工程生产力、及缩减之产品问世时间，IC相关产业目前环聚了各种高阶设计、验证、及侦错语言。这些语言建立在过去之经验和教训上，整合了近来之成功经验，并且为创新设计、验证、及侦错展开了大门。SystemVerilog即为一种建立在Verilog-2001基础上之语言，其系加入从前只有于测试平台语言如Vera和e发现之测试产生工具，而且因为包含来自OVA和PSL之assertion (断言，一种程式检验机制) 反应监测功能而又跃出一大步。PSL本身主要源自于Sugar，但也结合各种来自ForSpec、Temporal e、及CBV之概念和资讯。SystemVerilog之潜力不仅在于其令人深刻之有用元件，并且在于其具有可用于全面性设计、验证及侦错方法之统一一致架构。此语言增进设计抽象、资料封装、灵活性及再使用、修改之语意和语法、及各种促进生产力之功能。本篇文章系针对设计和侦错方面概述SystemVerilog 之几种关键要素，及其面临之挑战和机会。

在这篇文章中，我们使用SystemVerilog作为高阶语言之代表，该语言系受惠于数以千计之Verilog和VHDL设计和多年来供应商所给予之产品支援、累积之使用者经验和文件纪录之“希望清单"、及近来才注入但极为引人注意之物件导向验证建构元(constructs)。举例而言，SystemVerilog之抽象模型和改良之资料型态为系统层级行为设计提供了机会，因此容许以HDL为基础之设计由RTL 应用移向演绎。资料聚集概念 (例如struct等)使得侦错更有效。值得注意的是，我们将会见到抽象之增加转化为更高之生产率，对于合成效率仅具有极小甚至不具任何反效果。侦错需要对设计知识有充分和精确的分析、管理、及操作。改进之模型化，例如处理程序(transaction)层级，不仅考虑到由于资料群集和组织侦错工具会随着设计规模而有较高之扩展性，而且藉由更抽象之呈现和视觉化而对设计之理解有所开展。

SystemVerilog亦在程序区块加入许多建构元，使得意图推断较精确；这个对于所有设计工具都是一个好兆头，尤其是对于藉由自动化来减轻设计者之脑力负担的侦错工具。侦错工具都必须以好看而有效之方式呈现出设计资料，不管是原创或衍生而来的；呈现即如同工具的一部分一样包含了许多人类元素，亦如同任何其他演算法的态样。较多抽象使得资料组织、探索、及呈现对于侦错人员之侦错更经得起考验。SystemVerilo的另一个显着原理是将行为由通信分出，其对于在目前执行上之设计再使用有极大的益处，亦即为了供不同市场使用、不同交易而有不同的版本，及相同设计之未来世代产品。

SystemVerilog之物件导向增进了灵活性和再使用性。物件能让设计中之测试平台更加容易建立和维护；不过，却也对传统以硬体为中心之侦错产生新的挑战。必须以新的方法来改善侦错工具，由软体各领域(例如：阶层类别、物件序列图)引入概念以追踪设计之静态和动态特性。模型化和同步化之特性(例如：绪、旗标、及邮箱) 在于能改善测试平台之建立和描述。然而，这些亦对当今的源驱动硬件侦错工具带来一个特别的挑战，亦即不仅要考量到所有涉及之不同的绪 (IDs和时戳)，又必须发展创新之分析和视觉化技术以因应此一额外的并发层级。增加之设计生产力必须在侦错方面有相当程度之抵销；不然，在系统发展过程中，生产力之瓶颈只会由设计建立阶段移向分析和侦错阶段。

SystemVerilog assertions (断言，一种程式检验机制) 能产生组成的和限制的设计、合成、及验证。Assertions能改善以IP为基础之设计，其对教育性侦错之效用亦极高。Assertions 不仅可用来驱动侦错过程而将错误徵兆局部化，并且有助于诊断导致设计行为有缺陷之原因。本文章使用实例和图解来阐明上述几点，并且分享了对于设计和侦错近来之定位的看法。
改良之设计和侦错
工程师是有创造力的一群。我们自豪能够由很少创造出某些有用的事物 (撇开花费多少时间和精力不谈)；很多卡通会捕抓(甚至会夸大) 我们这个能力。然而，一个很少被公开的事实是，我们会一丝不苟的记下什么可行、什么不行。Verilog和 VHDL有很长的设计者“要做”、”不要做”、”要改进”、”希望有的”、及”要拿掉”之希望清单。设计社群有幸出现一群为数愈来愈多之志愿者，致力于将这些纳入最新版的Verilog: SystemVerilog。我们在此将着重于一些对于设计和侦错都有助益的项目。
SystemVerilog系较佳之Verilog
SystemVerilog可用来作为较佳之Verilog，因为其系建立于Verilog 2001之上。SystemVerilog可藉由加入几个源自software C之建构元而增进其生产力和可读性。这些建构元包括 typedef (自订资料型别)、enum (列举资料型别)、union(联合)、及 struct (结构)。Typedef容许使用者定义类型之建立和之后的使用。Enum 使得数值之解码变得简单，并且能让使用者使用简单的命名，而非直接使用资料值；无庸置疑的使侦错变得更加容易。Structs 能提供资料封装，并且让使用者轻易并且天衣无缝的移动大量资料。图 1 系显示一说明所述建构元如何改善设计中之操作和侦错之例子。
　

图1 structs 之操作和侦错
　

意图 vs. 阐释
写得较差的Verilog 程式码可能会遭受“模拟与合成不符”之批评，其系因为其本身叙述之模煳不清。没有什么比always 建构元来得更显着。Verilog中之Always 可用来将以下模型化：
◆组合逻辑,
◆闩锁逻辑,
◆序列逻辑及测试平台逻辑

软件工具接着必须依据程序内容和脉络来推断 (例如：猜测)工程师所要的是哪种硬件。图2即显示此一范例。一模拟器由于不完整的敏感、易触发资料列而会把always封锁(及输出 out) 当作一闩锁；然而一合成器却会将其当作组合逻辑 (如同该清单因其中具有信号sel而为完整的)。行为侦错工具可依据合成规范对其加以分析，而使用一 “使用者不 想之拴锁” 标示为输出以旗号来标示不符 (藉由质疑) 。然而，这些使用情境可能会造成相当程度之误解，而即使工具完全依据了阐释引导方针，它们也许只是以错误方式来阐释设计者之意思 (也许是由于在敏感、易触发资料列之遗漏信号、额外的posedge (正缘触发)、或甚至错序安排)。
　

图 2 语意含煳之例子
　

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

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

图 3 语意清楚之例子
　

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

行为 vs.通信
SystemVerilog语言之一主要特征在于加入介面。介面可用来将多条线路聚集在一起，因此能封装通信方块。介面包装和模组包装极为相似。它们可以包含各种宣告，例如可由所有介面使用者共用之变数、工作及功能。介面亦可包含用于模型化之程序，和用于验证适当用法之assertions (断言，一种程式检验机制)。因此问题在于：具有介面之背后道理为何？其答案为：藉由将行为由通信过程区分出来，设计者可以获得把区块功能之叙述由通信和资料传输区分出来的益处。举例而言，设计和侦错的一个直接优点在于能显着的减少不必要和易错之不同模组之埠的重复连接。以下图 4便说明介面如何有助于实现此点。
　

图 4 线路 vs.介面
　

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

图 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 系显示这些概念如何显示于一侦错工具。
　

图 6 侦错显示之介面
　

处理程序层级侦错
通信行为改进亦提供有用之资料抽象概念；亦即处理程序(transactions)。处理程序系一种用来描述资料如何在不同设计元件之中转移及到什么程度之形式。侦错工具可使用处理程序 来管理由设计所产生之资料，然后以使用者可理解之方式呈现出来。处理程序有各种形式；它们可以是简单之资料元件之标志，亦可为复杂和精细之通信或资料传输机制之封装。

为了将处理程序加以模型化，我们可由有关标记法和元件模型化语言(例如：统一模式语言 (UML))之大量研究中借用一些概念、专门术语、及註释。举例而言，我们可以把处理程序想成一种用于侦错视觉化(例如：波形)会被显示并且可在设计资料上操作之实际物件。处理程序可具有：
◆一标籤即一调处控制元，及一组属性。属性可具有各种数值和类型。
◆许多具有其他处理程序之关联。它们可具有各种不同的角色例如:父子、前者-后继者等。关联亦可具有多样性 (1 ~ 多)，并且可以组成或集合之形式呈现。

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

图 7 处理程序显示实例 - 改良之测试平台
　

类别和物件
为了支持有效而可再使用之测试平台之建立，SystemVerilog以类似C++ 或Java之方式把物件导向加入该语言中。物件被导入软体领域不仅是因为组织的目的，而是其主要目的在于以可以维持和扩展的方式来处理未来将其延伸到一特定系统。换言之，要知道的是一个系统是绝对不会被 “完成”，而只是发展的一个起点—是否以规格化来缓和对于某些考量之限制，或是藉由一般化(generalizations)来因应新的、未提及之考量点。的确，如果我们要再利用已经投入之时间和精力，测试平台即为一例：很多情况下，一设计元件也许有太多限制因此需要改良，或其被发现属于考量之较大范畴，而因此需要一般化。而且，随着复杂度的增加，也许要给予更多的抽象；这即是何以物件模型随着数年之经验而愈来愈优越，在软件领域能够提昇发展。物件和其关系包括将模型化概念呈现和执行：抽象、封装、群集(分群)、功能分解等。

在SystemVerilog，一个类别中之资料宣告被称作属性(properties)，工作/功能被称作方法。属性和方法所共同界定之一类别案例之内容和性能即称作物件。物件可经由动态建立并且藉由控制元来存取，其提供了指标(pointers)一安全的形式；SystemVerilog 亦收集垃圾以摆脱不再使用的物件，如此能防止记忆体遗漏。一般类别可经由参数化而建立，类似C++之样板类别。类别物件亦可继承来自其他类别之属性和方法 (如Java般为单一继承，即单一类别系源自单一父类别)。继承可衍生一延伸概念－测试平台可依据不同之利用或相同设计之不同变异而被再次使用和专门化。SystemVerilog又可容许多型化，即一种可让相似之方法依据情境在电脑运作时构成差异之功能。一基础类别中之方法可被扩充类别中之另一方法重新定义。这些概念亦呈现于显示Packet(封包) 类别例子之图 8 和和显示源自 Packet(封包)之ErrPkt类别之图 9。
　

图 8 Packet(封包) 类别定义
图 9 源自 Packet(封包)之ErrPkt类别
　

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

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

图 10 简化之统一模式语言类别图 – 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) 测试平台叙述 通常被标记为黑盒子，其内部无法以流程图加以追踪或视觉化。由于流程图系以设计分析为其目的，因此这不是重大之限制。不过，应该对设计至测试平台之间的桥樑加以改良，以对设计运作环境(例如：测试平台限制)有较清楚之了解。

动态过程、通信、及同步化
动态过程系用来将并行(concurrency)加入系统设计或测试平台模型。其目的在于经由较佳之资源利用而增进效能。SystemVerilog 以join_any 扩展 Verilog fork-join 叙述区块和join_none 修饰语。这些叙述之运用系以图形显示于以下之图 11。
　

图 11 Fork-join 衍生程序区块
　

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

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

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

以Assertion为基础之设计和侦错
Assertions(断言，一种程式检验机制) 系用来验证设计，为一种简要但是具表述性之工具，藉由一区块或多个共同使用之区块以描述(不)想要之动作。Assertions 通常是配合一验证方法而运用问题分割-结合而(分别击破)之方法使得确认局部化。此方法即是组合式验证。该想法即在验证设计中一或多个部份，然后整合所有验证结果以裁定全部之正确性。此外，将记分板用于验证活动以识别设计的哪一部分已经验证至何种程度，而哪些尚未达到标准。此即是所谓之coverage (涵盖)。coverage和assertion 叙述皆可使用相同之潜在的暂态语言；在SystemVerilog中，此语言即被称作 SystemVerilog Assertions (SVA)。 高阶指令分别为assert、或用以声明行为之cover，或聚集之涵盖资料。Assertions 亦可使用assume assertion 指令来限制验证工作(或作为测试之限制)。

尽管assertions (断言，一种程式检验机制) 主要系用于验证，它们亦可用于设计中，可被用于合成(如合成一区块)；其在介面合成方面相当成功。它们亦可被用来作为视觉元件，用以顾及分散式的设计活动和早期的高阶模拟。如此可促进对于设计之潜力、限制之了解并且增进设计团队之生产力。我们稍早在其他地方 [19] 详细描述 如果将assertions 放置于介面边界上即可找出和隔离错误。介面结合assertions，亦有助于检验是否设计之执行符合时间安排和协定之要求，及于[16]中描述之效能分析。的确，在SystemVerilog，assertions可被放置于介面之内(例如：通信或模组(行为))。

Assertions (断言，一种程式检验机制) 系一种进行设计侦错的理想工具。参考文献[20]已经详细论述如何使用assertions 来进行行为为主之设计侦错，其中叙述本身为对于错误之位置之时空提示及用于活动分析之动态assertion 资料。该方法尝试从问题癥兆开始以找出和隔绝错误 (以一种引导使用者之自动化方式))。

对于 of assertions (断言，一种程式检验机制)之侦错是值得留意的一个领域。随着对assertions 之信赖增加，assertions 之复杂度必然会提升，接着即会变成对assertion 本身侦错之需求。波形显示在过去已经有不少探讨 ([20])，而且愈来愈普遍。物件 (主动)源级註解用于设计相当的成功，其亦是能促进assertion 码之改进之主要范畴。由于以下两项因素，assertion 码之註解在视觉化和设计者之熟悉度方面呈现出一些挑战: Assertion 码是陈述式的。这和程序式的HDL 执行码有显着的不同。

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

图 12 重复之表示
　

结论
高阶语言如SystemVerilog 已经出现以回应市场需要甚至促进高阶和多产之设计、验证、及侦错。在此，我们已经略述对于SystemVerilog对设计社群之潜力，及其对于EDA 供应商社群之挑战和契机。此语言已经被业界认可为一种有价值、对于因应目前设计上困难的尝试。前景在此，但现在必须由使用者和供应商们来使其成真。本文译者李新基，思源科技股份有限公司thomas_li@springsoft.com）