原创 学习SystemVerilog（二）——学习它的理由

    学习SystemVerilog的理由也很多，我在阅读SystemVerilog for Design 和 SystemVerilog for Verification两本书前言的过程中，总结出了SystemVerilog在以下几个方面对Verilog的增强：  riple

    更清晰、准确、简洁的硬件描述能力——Design。 在上一篇关于学习SystemVerilog的文章中，我不建议入门级的数字电路设计工程师学习SystemVerilog，原因是使用Verilog足以完成我们绝大多数工作。从提高代码的可读性和易维护性角度来看，使用SystemVerilog有助于提高工作效率。  riple

    编写受控随机的、分层的、可重用的测试平台的能力——Test。Verilog编写测试平台的能力就相当于采用最基本的C语言结构编程，而采用SystemVerilog编写测试平台则相当于采用C++按照面向对象的思想编程。  riple

    在设计描述和测试平台中添加断言的能力——Assertion。断言这个工具，在软件开发中早就广泛应用了。在单元测试、集成测试和功能覆盖率评估中，断言都是一个很强大的工具。  riple

    更高抽象层次的系统描述能力——Architectural Modeling。OOP、Dynamic Threads、Interprocess Communication、行为级和事物级的描述能力，从名称上看来确实高级。  riple

    使用SystemVerilog的最大好处是，上述所有特性都统一于同一种语言环境下。从系统架构设计者到底层实现设计者到验证工程师都采用同一种语言，设计过程中团队之间的交流更加准确和方便，提高了设计效率。  riple

    上述四个方面中的后三个，都是我这样的FPGA设计工程师不曾涉猎过的领域，对于大家是否应该学习SystemVerilog在这三个方面的特性，我没有发言权。需要说明的是，现在在这三个领域都有相应的较成熟的工具，尽管难以统一。大胆猜测一下，未来的发展趋势应该是SystemVerilog一统天下，因为它在这三个方面从已经成熟的工具中继承了很多，也得到了众多EDA厂商的大力支持。  riple

    对于我自己的工作来说，采用新的设计语言特性不是十分急迫，读懂示例还是需要学习新特性的；断言和系统建模两个方面是我感兴趣的领域，学到的东西也能更快地应用到我的工作中；编写简单的测试平台也是我的工作内容之一，也需要学习一下。 riple 

    学习语法和使用语言是两个不同的层次。只有把语言用起来，才能真正掌握这门语言；而语法的学习，只有在语言的使用过程中才能获得更加具体形象的认识，否则学到的只是只言片语，很难融会贯通。学习使用SystemVerilog语言的方法，也就是学习一种方法学，从SystemVerilog的两个主要组成部分看来，方法学可以分为以下两大类：  riple

    设计方法学：即使在SystemVerilog for Design这本书中也没有明确给出一种方法学，只是在倒数第二章给出了采用SystemVerilog语言特性进行设计描述的实例，从中应该可以总结出一套不甚完善的设计方法学。此外，《SVA使用指南》可以算作断言在设计过程中使用的方法学。  riple

    验证方法学：在验证方面的方法学相对成熟得多。SystemVerilog for Verification这本书给出了一套简单、实用的方法学，适合入门阅读，算是初级方法学；《VMM for SystemVerilog》和《高级验证方法学》则如名称所示，是高级方法学，不适合一上手就阅读。  riple

    以下文字节选自Stuart Sutherland发表在EEdesign, May 23, 2003上的一篇文章：An Overview of SystemVerilog 3.1。这篇文章可以说是SystemVerilog的入门必读文章。下面两段文字叙述了SystemVerilog产生的原因和发展过程。  riple

A problem that needed solving. For many years, the behavioral coding features of Verilog, plus a few extras such as display statements and simulation control, gave Verilog-based design engineers all they needed to both model hardware and to define a testbench to verify the model.

As design sizes have increased, however, the number of lines of RTL code required to represent the design have increased dramatically. Even more significant is the increase in the amount of verification code required to test these very large designs. While modeling large designs and verification routines in traditional RT-level HDLs is still possible, the amount of coding far exceeds what can be accomplished in a reasonable amount of time.

To address these problems, new design languages such as SystemC were created that could model full systems at a much higher level of abstraction, using fewer lines of code. Proprietary Hardware Verification Languages (HVLs) such as Verisity's e and Synopsys' Vera were created to more concisely describe complex verification routines (Note: company and product names are trademarked names of their respective companies). These proprietary languages solve a need, but at the cost of requiring engineering teams to work with multiple languages, and often at the expense of simulation performance.

The SystemVerilog standard currently being defined by Accellera takes a different approach to solving the design and verification needs of today's multi-million gate designs. Rather than re-invent the wheel with new languages, Accellera — the combined VHDL International and Open Verilog International organizations — has defined a set of high-level extensions to the IEEE 1364 Verilog-2001 language.

The definition of the SystemVerilog 3.1 standard has been completed and is expected to be released in June of this year. Accellera plans to donate the SystemVerilog extensions to the IEEE 1364 Verilog Standards Group, where it is anticipated that the extensions will become part of the next generation of the IEEE 1364 Verilog standard.

SystemVerilog's roots. Accellera chose not to concoct these SystemVerilog enhancements to Verilog from scratch. That would have required re-inventing the wheel and creating a standard based on unproven, untested syntax and semantics. Instead, Accellera relied on donations of technology from a number of companies. These donations include high-level modeling constructs from the Superlog language developed by Co-Design, testbench constructs from the Open Vera language and VCS DirectC interface technology donated by Synopsys, and assertions work from several companies, including, to name just a few, OVA from Verplex, ForSpec from Intel, Sugar (renamed PSL) from IBM, and OVA from Synopsys.

Over the past two years, the Accellera SystemVerilog committee and subcommittees have met two to four times each month to standardize these donations. Members of the SystemVerilog committee include experts in simulation engines, synthesis compilers, verification methodologies, members of the IEEE 1364 Verilog Standards Group, and senior design and verification engineers.

How to raise the RTL abstraction level and design conciseness with SystemVerilog - Part 1

How to raise the RTL abstraction level and design conciseness with SystemVerilog - Part 2