Verification Academy

Search form

My Account Menu

  • Register
  • Log In
  • Topics
  • Courses
  • Forums
  • Patterns Library
  • Cookbooks
  • Events
  • More
  • All Topics
    The Verification Academy offers users multiple entry points to find the information they need. One of these entry points is through Topic collections. These topics are industry standards that all design and verification engineers should recognize. While we continue to add new topics, users are encourage to further refine collection information to meet their specific interests.
    • Languages & Standards

      • Portable Test and Stimulus
      • Functional Safety
      • Design & Verification Languages
    • Methodologies

      • UVM - Universal Verification Methodology
      • UVM Framework
      • UVM Connect
      • FPGA Verification
      • Coverage
    • Techniques & Tools

      • Verification IP
      • Simulation-Based Techniques
      • Planning, Measurement, and Analysis
      • Formal-Based Techniques
      • Debug
      • Clock-Domain Crossing
      • Acceleration
  • All Courses
    The Verification Academy is organized into a collection of free online courses, focusing on various key aspects of advanced functional verification. Each course consists of multiple sessions—allowing the participant to pick and choose specific topics of interest, as well as revisit any specific topics for future reference. After completing a specific course, the participant should be armed with enough knowledge to then understand the necessary steps required for maturing their own organization’s skills and infrastructure on the specific topic of interest. The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization’s processes so that you can then reap the benefits that advanced functional verification offers.
    • Universal Verification Methodology (UVM)

      • Advanced UVM
      • Basic UVM
      • Introduction to UVM
      • UVM Connect
      • UVM Debug
      • UVMF - One Bite at a Time
    • Featured Courses

      • Introduction to ISO 26262
      • Introduction to DO-254
      • Clock-Domain Crossing Verification
      • Portable Stimulus Basics
      • Power Aware CDC Verification
      • Power Aware Verification
      • SystemVerilog OOP for UVM Verification
    • Additional Courses

      • Assertion-Based Verification
      • An Introduction to Unit Testing with SVUnit
      • Evolving FPGA Verification Capabilities
      • Metrics in SoC Verification
      • SystemVerilog Testbench Acceleration
      • Testbench Co-Emulation: SystemC & TLM-2.0
      • Verification Planning and Management
      • VHDL-2008 Why It Matters
    • Formal-Based Techniques

      • Formal Assertion-Based Verification
      • Formal-Based Technology: Automatic Formal Solutions
      • Formal Coverage
      • Getting Started with Formal-Based Technology
      • Handling Inconclusive Assertions in Formal Verification
      • Sequential Logic Equivalence Checking
    • Analog/Mixed Signal

      • AMS Design Configuration Schemes
      • Improve AMS Verification Performance
      • Improve AMS Verification Quality
  • All Forum Topics
    The Verification Community is eager to answer your UVM, SystemVerilog and Coverage related questions. We encourage you to take an active role in the Forums by answering and commenting to any questions that you are able to.
    • UVM Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • UVM Forum
    • SystemVerilog Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • SystemVerilog Forum
    • Coverage Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • Coverage Forum
    • Additional Forums

      • Announcements
      • Downloads
      • OVM Forum
  • Patterns Library
    The Verification Academy Patterns Library contains a collection of solutions to many of today's verification problems. The patterns contained in the library span across the entire domain of verification (i.e., from specification to methodology to implementation—and across multiple verification engines such as formal, simulation, and emulation).
    • Implementation Patterns

      • Environment Patterns
      • Stimulus Patterns
      • Analysis Patterns
      • All Implementation Patterns
    • Specification Patterns

      • Occurrence Property Patterns
      • Order Property Patterns
      • All Specification Patterns
    • Pattern Resources

      • Start Here - Patterns Library Overview
      • Whitepaper - Taking Reuse to the Next Level
      • Verification Horizons - The Verification Academy Patterns Library
      • Contribute a Pattern to the Library
  • All Cookbooks
    Find all the methodology you need in this comprehensive and vast collection. The UVM and Coverage Cookbooks contain dozens of informative, executable articles covering all aspects of UVM and Coverage.
    • UVM Cookbook

      • UVM Basics
      • Testbench Architecture
      • DUT-Testbench Connections
      • Configuring a Test Environment
      • Analysis Components & Techniques
      • End Of Test Mechanisms
      • Sequences
      • The UVM Messaging System
      • Other Stimulus Techniques
      • Register Abstraction Layer
      • Testbench Acceleration through Co-Emulation
      • Debug of SV and UVM
      • UVM Connect - SV-SystemC interoperability
      • UVM Versions and Compatibility
      • UVM Cookbook
    • Coding Guidelines & Deployment

      • Code Examples
      • UVM Verification Component
      • Package/Organization
      • Questa/Compiling UVM
      • SystemVerilog Guidelines
      • SystemVerilog Performance Guidelines
      • UVM Guidelines
      • UVM Performance Guidelines
    • Coverage Cookbook

      • Introduction
      • What is Coverage?
      • Kinds of Coverage
      • Specification to Testplan
      • Testplan to Functional Coverage
      • Bus Protocol Coverage
      • Block Level Coverage
      • Datapath Coverage
      • SoC Coverage Example
      • Requirements Writing Guidelines
      • Coverage Cookbook
  • All Events
    No one argues that the challenges of verification are growing exponentially. What is needed to meet these challenges are tools, methodologies and processes that can help you transform your verification environment. These recorded seminars from Verification Academy trainers and users provide examples for adoption of new technologies and how to evolve your verification process.
    • Upcoming & Featured Events

      • CDC+RDC Analysis - 4/20
      • Low Power Verification - 4/29
      • User2User - 5/26
      • Webinar Calendar
    • On-Demand Webinars

      • Basic Abstraction Techniques
      • Safety Analysis Techniques
      • QVIP Workflow and Debug for PCIe
      • Writing a Proxy-driven Testbench
      • Achieving High Defect Coverage
      • Visualizer Features
      • Questa Static and Formal Apps
      • All On-Demand Webinars
    • Recording Archive

      • Siemens EDA 2021 Functional Verification Webinar Series
      • Improving Your SystemVerilog & UVM Skills
      • Should I Kill My Formal Run?
      • Visualizer Debug Environment
      • Industry Data & Surveys
      • All Recordings
    • Conferences

      • DVCon 2021
      • DVCon 2020
      • DAC 2019
      • All Conferences
    • Mentor Learning Center

      • SystemVerilog Fundamentals
      • SystemVerilog UVM
      • View all Learning Paths
  • About Verification Academy
    The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization's processes so that you can then reap the benefits that advanced functional verification offers.
    • Blog & News

      • Verification Horizons Blog
      • Academy News
      • Academy Newsletter
      • Technical Resources
    • Verification Horizons Publication

      • Verification Horizons - March 2021
      • Verification Horizons - November 2020
      • Verification Horizons - July 2020
      • Issue Archive
    • About Us

      • Verification Academy Overview
      • Subject Matter Experts
      • Contact Us
    • Training

      • Questa Basic
      • Questa Advanced
      • Mastering Questa
  • Home
  • Verification Horizons
  • March 2014
  • Don't Forget the Little Things That Can Make Verification Easier

Don't Forget the Little Things That Can Make Verification Easier

Verification Horizons - Tom Fitzpatrick, Editor

Don't Forget the Little Things That Can Make Verification Easier by Stuart Sutherland, Sutherland HDL, Inc.

The little things engineers can do when coding RTL models can add up to a significant boost in verification productivity. A significant portion of SystemVerilog is synthesizable. Taken individually, these synthesizable RTL modeling constructs might seem insignificant, and, therefore, easy to overlook when developing RTL models. These "little things", however, are like getting free assertions embedded directly in the RTL code, some of which would be quite complex to write by hand. Using these SystemVerilog constructs in RTL modeling can reduce verification and debug time. This article presents several features that SystemVerilog adds to traditional Verilog RTL modeling that can help catch subtle RTL coding errors, and make verification easier and more efficient.

There is a common misconception that Verilog is a hardware modeling language, and SystemVerilog is a verification language. This is not true! Much of SystemVerilog is synthesizable with today's ASIC and FPGA synthesis compilers. This article focuses on a few of the SystemVerilog RTL modeling constructs that help make verification easier. Only a brief summary of these constructs is presented, with an emphasis on how these constructs benefit verification productivity. There are a number of resources for more information on these and other synthesizable SystemVerilog constructs, including the DVCon-2014 conference paper, Can My Synthesis Compiler Do That? by Sutherland and Mills.

ENFORCED SINGLE-DRIVER FUNCTIONALITY

Traditional Verilog has two primary types of data, nets and variables. The types used almost exclusively for RTL modeling are the wire net type and reg variable type. Traditional Verilog has strict rules on where the wire type (or another net type), must be used, and where it may be used. This mandatory usage of a net type places a burden on verification. Net types permit multiple-driver functionality, even where multiple drivers are not intended. The verification process must detect unintentional multiple drivers.

SystemVerilog significantly reduces this risk with two additional types: logic and uwire. The full meaning of these types is beyond the scope of this paper. Their effect on verification is what is important. In most contexts, the logic type makes it a syntax error to have multiple drivers. The uwire type also enforces single drivers. No special verification is needed to ensure single-driver functionality — these data types automatically prevent potential multi-driver functional errors.

SELF-VERIFYING RTL-SPECIFIC PROCEDURAL BLOCKS

In traditional Verilog, procedural always blocks are used to model combinational, latch, and sequential logic. Synthesis and simulations tools have no way to know what type of logic an engineer intended to represent with the always keyword. Instead, these tools can only interpret the code within the procedural block, and then "infer" — which is just a nice way to say "guess" — the engineer's intention. This guessing by synthesis compilers places a burden on verification engineers to develop testbenches, stimulus, and response scoreboarding to verify that RTL and postsynthesis gate functionality correctly represent intended design functionality. This is a significant verification effort! Should RTL and/or gate-level verification fail to detect and isolate incorrect combinational or sequential behavior, faulty functionality could potentially find its way into an end product.

SystemVerilog adds three RTL-specific procedural always blocks: always_comb, always_latch, and always_ff. These RTL-specific procedural blocks document design intent for the procedure. Software tools can now automatically verify that this intent is being met. Functional bugs in the traditional Verilog model become compilation errors or warnings that pinpoint the location of bugs. These built-in assertion-like checks free the verification engineer from having to write code to verify correct combinatorial, latched, or sequential behavior.

SELF-CHECKING ENUMERATED DATA TYPES

Traditional Verilog nets and variables are loosely typed. There is little or no checking of the value being assigned to the net or variable. The DVCon-2014 conference paper Can My Synthesis Compiler Do That? by Sutherland and Mills shows an example of a finite state machine RTL model that is syntactically correct, but has six functional bugs. Verification engineers are burdened with the task of designing stimulus that will bring out the functional problems, and scoreboard checking that will detect the problems. Time must be spent debugging the cause of the problems, modifying the RTL models, and then reverifying the design to ensure all functional bugs have been corrected.

SystemVerilog adds enumerated type nets and variables that are more strongly typed. Enumerated types allow nets and variables to be defined with a specific set of legal values. Each legal value is referenced using a label. The stronger built-in checking of enumerated types provides a significant advantage over traditional Verilog. With enumerated types, all six bugs in the model described in the preceding paragraph become syntax errors. Simulators will not compile the faulty code, and synthesis compilers will not allow the faulty code to be implemented in gates, until the bugs are fixed.

CORRECT BY CONSTRUCTION ARRAY COPYING AND ARRAY ASSIGNMENTS

Traditional Verilog supports one-dimensional and multidimensional arrays, which, in RTL models, can be used to represent look-up tables and register files. However, traditional Verilog only permits access to a single element of an array at a time. To copy data from one array to another array requires writing loops that index through each element of each array. Manipulating the data in an array can also require the use of loops. Passing an array to a function, or through module ports to another module, also requires working with one element at a time, typically using loops in generate blocks or procedural code. The extra coding required in traditional Verilog to work with arrays is both tedious and prone to subtle coding errors. Verification engineers must verify that the RTL code has implemented array handling correctly.

SystemVerilog allows entire arrays to be copied as a single assignment statement, and assigning to entire arrays with a single statement. Complete arrays can be passed to functions and through module ports. Array copying, assignments and passing have syntactic and semantic rules that help ensure array handling is correct by construction.

By eliminating the complexity of array copying and assignments, SystemVerilog reduces the risks of coding errors and simplifies the task of verifying that arrays are being referenced correctly in RTL code.

CORRECT BY CONSTRUCTION COPYING AND ASSIGNMENTS TO GROUPS OF SIGNALS

Traditional Verilog represents functionality at the discrete signal level. While this accurately models how signals are represented in the silicon, it can require many lines of code, in order to work with each individual signal. In a module with dozens or hundreds of separate signals, coding mistakes can easily occur, such as a missing assignment to any one of the many signals.

SystemVerilog adds a structure construct that provides a more abstract and powerful way of working with large numbers of signals. Structures are used to bundle related signals together under a common name, and are analogous to records in VHDL.

The following example shows how the 54 signals (including the Payload array) that make up a UNI ATM cell can be bundled together as a SystemVerilog structure:

typedef struct {
 logic [ 3:0] GFC; // Generic Flow Control
 logic [ 7:0] VPI; // Virtual Path ID
 logic [15:0] VCI; // Virtual Channel ID
 logic [ 2:0] PTI; // Payload Type Indication
 logic CLP; // Cell Loss Priority
 logic [ 7:0] HEC; // Header Error Control
 logic [ 7:0] Payload [48]; // Payload
} uni_t;   

This structure definition uses the typedef keyword, another important SystemVerilog extension to traditional Verilog. By defining the UNI structure as a user-defined type, it can be used for multiple declarations in the same module, and used in multiple modules.

A powerful aspect of structures is that they can be read or written as a whole. An entire structure can be copied to another structure, and all members of a structure can be assigned values in a single statement. Entire structures can be passed through module ports or to functions. Where traditional Verilog works with separate signals, leaving the door open for a plethora of potential coding mistakes, copying, assigning, and passing structures have syntax and semantic rules that help ensure that these operations are complete and correct by construction. These rules simplify verification, and reduce the time and effort required to verify operations on large numbers of separate signals.

ELIMINATION OF REDUNDANT DECLARATIONS

The original Verilog language does not have a shared declaration space. Each module must contain all declarations used within that module. There is a risk of differences in the declarations in different modules, which can result in subtle functional bugs. The burden is on the verification team to generate stimulus that will detect any functional bugs that result from those declaration differences.

SystemVerilog addresses this Verilog shortcoming with the addition of declaration packages. Packages provide a declaration space that can be referenced from any design module, as well as from verification code. Packages can eliminate duplicate code, the risk of mismatches in different blocks of a design, and the difficulties of having to verify declaration mismatches.

ACCURATE AND SELF-CHECKING DECISION STATEMENTS

One of the ugliest gotchas of traditional Verilog is the subtle and undesired behavior of the wildcard casex/casez statements. Many conference papers have focused on the problems caused by these Verilog constructs. Verification engineers must be diligent in verifying that the gotchas of casex/casez statements have been avoided in the RTL models. SystemVerilog adds a case...inside decision statement that does not have the problems of casex/casez statements. The effort and time needed to verify casex/ casez statements is eliminated.

From the earliest days of RTL synthesis, synthesis compilers have used full_case and parallel_case directives (also called "pragmas") to guide the gate-level optimization of Verilog case statements. These directives cause synthesis to perform specific optimizations in the gate-level implementation of the case decisions. A major flaw with the full_case and parallel_case synthesis directives is that the commands are hidden in comments. Simulation is not affected by the directives, and therefore RTL simulation does not verify that the optimization effects of these directives are appropriate in the design.

SystemVerilog solves this problem by bringing the functionality of full_case and parallel_case into the RTL modeling world, using the keywords unique, unique0, and priority as decision modifiers. In simulation, these decision modifiers add built-in verification checking to help detect when the full_case or parallel_case optimizations would not be desirable. For synthesis, these modifiers enable the appropriate full_case and/or parallel_case synthesis optimizations.

CORRECT BY CONSTRUCTION BUS PROTOCOLS WITH SELF-CHECKING

Communication between design blocks often involves a set of signals and handshaking protocols. With traditional Verilog, these signal declarations must be duplicated in each design block, and at the higher level of hierarchy that connects the blocks together. The verification of the handshaking protocols is done at the testbench level, and cannot be done until late in the design cycle, after each block has been modeled.

SystemVerilog provides interface ports as a more abstract way for communication between design blocks. An interface definition encapsulates the several bus signals under single name. Modules use a single interface port with the encapsulated set of signals, instead of needing several separate ports for the bus signals. In addition to encapsulating the signals of a bus protocol, interfaces can encapsulate built-in verification code, such as assertions, so that all communications over the bus are automatically verified. Interfaces simplify RTL modeling, and significantly reduce the time and effort of verifying communication between design blocks.

EMBEDDED SELF-CHECKING FOR UNEXPECTED OR UNDESIRED VALUES OR CONDITIONS

Traditional Verilog RTL models are typically written with an assumption that the data on which the models operate is valid. State decoding assumes the state variable has legal values. Decision statements assume that the expression being tested does not X, Z or other unanticipated values. Verification engineers are expected to verify that these assumptions in the RTL models are correct. Writing the tests that detect invalid values within design blocks is nontrivial and time consuming. It can require using hierarchical paths in the verification code to examine signals internal to modules deep within the design hierarchy.

SystemVerilog adds assertions to the original Verilog language. Assertions can — and should — be written by design engineers anytime the RTL code makes an assumption regarding a logic condition or value. The following example illustrates how simple it is to add assertions in RTL code as the code is being written. This simple one line of code will trap any problems with the sel input to the module at the time and place the problem occurs, rather than hoping that verification will detect a functional problem downstream in both logic and time.

always_comb begin
  assert (!$isunknown(sel)) else $error
         ("%m : case sel = X");
  case (sel)
   2'b00 : out = a;
   2'b01 : out = b;
   2'b10 : out = c;
   2'b11 : out = d;
  endcase
 end    

SUMMARY

SystemVerilog adds many RTL modeling constructs to traditional Verilog that can make verification easier and more accurate! Major simulators and most ASIC and FPGA synthesis compilers support these constructs. The "little things" design engineers do in RTL models can have a significant impact on verification productivity. The SystemVerilog RTL modeling constructs were added to traditional Verilog for good reasons — be sure to take advantage of them in your design and verification projects!

Back to Top

Table of Contents

Verification Horizons Articles:

  • Whether It's Fixing a Boiler, or Getting to Tapeout, It's Productivity that Matters

  • Don't Forget the Little Things That Can Make Verification Easier

  • Taming Power Aware Bugs with Questa®

  • Using Mentor Questa® for Pre-silicon Validation of IEEE 1149.1-2013 based Silicon Instruments

  • Dealing With UVM and OVM Sequences

  • Stories of an AMS Verification Dude: Putting Stuff Together

  • Portable VHDL Testbench Automation with Intelligent Testbench Automation

Siemens Digital Industries Software

Siemens Digital Industries Software

##TodayMeetsTomorrow

Solutions

  • Cloud
  • Mendix
  • Siemens EDA
  • MindSphere
  • Siemens PLM
  • View all portfolio

Explore

  • Digital Journeys
  • Community
  • Blog
  • Online Store

Siemens

  • About Us
  • Careers
  • Events
  • News and Press
  • Newsletter
  • Customer Stories

Contact Us

USA:

phone-office +1 800 547 3000

See our Worldwide Directory

  • Contact Us
  • Support Center
  • Give us Feedback
©2021 Siemens Digital Industries Software. All Rights Reserved.
Terms of Use Privacy Cookie Policy