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

      • Creating an Optimal Safety Architecture  - February 9th
      • The ABC of Formal Verification - February 11th
      • Events Calendar
    • On Demand Seminars

      • I'm Excited About Formal...
      • Visualizer Coverage
      • Formal-based ‘X’ Verification
      • 2020 Functional Verification Study
      • All On-Demand Seminars
    • Recording Archive

      • Improving Your SystemVerilog & UVM Skills
      • Should I Kill My Formal Run?
      • Visualizer Debug Environment
      • All Recordings
    • Mentor Training Center

      • SystemVerilog for Verification
      • SystemVerilog UVM
      • UVM Framework
      • Instructor-led Training
    • Mentor Learning Center

      • SystemVerilog Fundamentals
      • SystemVerilog UVM
      • Questa Simulation Coverage Acceleration Apps with inFact
      • 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 - November 2020
      • Verification Horizons - July 2020
      • Verification Horizons - March 2020
      • Issue Archive
    • About Us

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

      • Questa® & ModelSim®
      • Questa® inFact
      • Functional Verification Library
  • Home /
  • Verification Horizons /
  • June 2015 /
  • Reuse MATLAB® Functions and Simulink® Models in UVM Environments with Automatic SystemVerilog DPI Component Generation

Reuse MATLAB® Functions and Simulink® Models in UVM Environments with Automatic SystemVerilog DPI Component Generation

Verification Horizons - Tom Fitzpatrick, Editor

Reuse MATLAB® Functions and Simulink® Models in UVM Environments with Automatic SystemVerilog DPI Component Generation by Tao Jia, HDL Verifier Development Lead, and Jack Erickson, HDL Product Marketing Manager, MathWorks

BACKGROUND

The growing sophistication of verification environments has increased the amount of infrastructure that verification teams must develop. For instance, UVM environments offer scalability and flexibility at the cost of upfront efforts to create the UVM infrastructure, bus-functional models, coverage models, scoreboard, and test sequences.

Engineers everywhere use MATLAB and Simulink to design systems and algorithms. Math-intensive algorithms, such as signal and image processing, typically begin with MATLAB language-based design. Complex systems, such as control and communications, typically begin with Simulink and Model-Based Design. At this early stage, engineers create behavioral models of the algorithms and subsystems along with system environment models and test sequences to validate the design given the requirements. The rest of this article will refer to this stage as “system design and verification.” At the end of this stage, the detailed requirements are captured in a paper specification for the hardware and software teams.

The verification team has to read and interpret this specification in order to create the verification plan, infrastructure, bus-functional models, coverage models, scoreboard, and test sequences. This is a large undertaking, one that is often complicated by vagaries in or misinterpretation of the spec. This specification gap creates a gulf between system design and hardware verification. For instance, when a late change is required, the hardware team typically just patches it into the design and verification collateral without going back to update the algorithm where it can be validated.

HDL Verifier TM bridges the specification gap by using cosim- ulation with HDL simulators such as the Mentor Graphics® Questa® Advanced Simulator. This enables the system models and tests to run in their native MATLAB or Simulink environment, while verifying the design-under-test (DUT) in its native HDL simulator environment. This allows for debugging visibility into both. However, as the project progresses to the stage where more automated regression testing is done, cosimulation has its drawbacks. The handshaking interface adds runtime overhead, especially in cross-platform situations. And managing many parallel HDL simulator sessions that communicate with corresponding MATLAB and Simulink sessions can add an extra layer of complexity.

MATLAB and Simulink have mature and robust C code generation capabilities for production embedded software for automobiles, aircraft, spacecraft, robotics, medical devices, and a host of other applications. Some of our more innovative customers began to use this code generation to re-use some of their system-level models and tests in their verification environments. However, integrating the code into hardware using SystemVerilog’s Direct Programming Interface (DPI) still requires lots of work. Could there be a way to automatically connect the system intent with hardware verification?

GENERATE DPI COMPONENTS AUTOMATICALLY

HDL Verifier now has the ability to generate SystemVerilog DPI components from MATLAB and Simulink. With this capability, hardware verification teams can run the algorithmic models, system components, and test sequences used by their system design teams directly in their SystemVerilog simulator. This not only saves the team the effort of reading the specifications and writing the tests and models, it also reduces the risk of misinterpreting the specifications. This is because the tests and models are essentially executable specifications generated directly from the MATLAB functions and the Simulink models.

Moreover, since the SystemVerilog DPI generation process is automatic, the verification components are available to verification engineers early in the development process. When the team needs to make changes to the specification in the middle of development, the verification components can be automatically regenerated from the changed models. At a high level, generating a SystemVerilog DPI component is as straightforward as deciding from where you will be generating the model, issuing the command to generate it, and integrating the component into your simulation.

The exported DPI component will be in the form of a thin SystemVerilog wrapper file and a shared library built automatically as part of the generation step. If your simulation runs on a different platform than from where it’s generated, you can use the generated makefile to build the shared library on that platform.

These components run quickly in simulation, as they are behavioral-level C code without the bit-level implementation details. Using C as the description language allows you to export a wide variety of model types. Some example applications include:

  • Bus-functional checker algorithm for UVM scoreboard
  • UVM sequence item
  • Analog model representation in SoC UVM environment
  • Digital model in an analog circuit simulator

This article uses an example FFT design to demonstrate how to generate a bus-functional checker algorithm written in MATLAB, and it outlines how to integrate it into a UVM scoreboard.

Image 1: Generating a SystemVerilog DPI component from a MATLAB algorithm for use in a UVM scoreboard.
©2015 The MathWorks, Inc.
 Generating a SystemVerilog DPI component from a MATLAB algorithm for use in a UVM scoreboard. ©2015 The MathWorks, Inc.


SETTING UP AND GENERATING THE DPI COMPONENT

The first step is to identify what you will need the component to do in your verification environment. In other words, how will it be used? What will the primary inputs and outputs be? What other signals will you need access to? In our example, we will generate a checker function that will calculate the floating point result of a 64-point radix-2 FFT and compare this to the outputs of a fixed- point RTL implementation.

Image 2: MATLAB code for the checker function.
©2015 The MathWorks, Inc .
 MATLAB code for the checker function. ©2015 The MathWorks, Inc .


This function returns a ratio of the root-mean-square error of the fixed-point implementation versus floating-point reference outputs, divided by the root-mean-square of the fixed-point implementation outputs.

This is a good time to check whether your model is compatible with code generation. SystemVerilog DPI component generation relies on underlying C code generation technology from MATLAB Coder or Simulink Coder, and there are certain requirements models need to comply with for code generation. Running one of the code generation checking utilities helps to identify and remedy many potential issues before you try to generate a DPI component:

  • MATLAB: Add the %#codegen directive (or pragma) to your function after the function signature to indicate that you intend to generate code for the MATLAB algorithm. Adding this directive instructs the MATLAB code analyzer to help you diagnose and fix violations that would result in errors during code generation, such as blocks, functions, or features not supported for C code generation.
  • MATLAB: Select your file in the current folder and right click Check Code Generation Readiness.
  • Simulink: Select your subsystem, right click C/C+ Code
  •     > Code Generation Advisor

At this point, you can generate the model using the default settings or customizing the output. This example generates the DPI component from MATLAB, which uses the dpigen command:

dpigen -args {int16(ones(1,64)),int16(ones(1,64)),int16(ones(1,64)),int16(ones(1,64))} fft_checker

We specify the function’s input types and size (the –args argument), and the name of the MATLAB function from which we’re generating (fft_checker). The generated testbench is a SystemVerilog file that reads input vectors and expected output vectors from the MATLAB testbench to verify that the DPI component is functionally equivalent to the original MATLAB function.

To generate the DPI component from Simulink, use a parallel workflow, but with the Simulink UI infrastructure. Set up by selecting the Code > C/C++ Code > Code Generation Options pull down menu. On this form, you first need to specify that it will be a DPI component by browsing in System target file and selecting systemverilog_dpi_grt.tlc.

Once you are satisfied with your settings, click OK to close the form. Then select the subsystem for which you want to generate the DPI component by right clicking C/C++ Code > Build This Subsystem.

Building the subsystem in Simulink, or running dpigen in MATLAB, will generate the collateral necessary to build your DPI component including the C files for the core function and its DPI interface, the necessary header files, a SystemVerilog wrapper, and a makefile. By default, it will even build the shared library to load into the simulator. Of course, if your simulation runs on a different platform, you will want to use the generated makefile to build the shared library on that platform.

INTEGRATING THE DPI COMPONENT INTO SIMULATION

The shared library encapsulates everything you need for the component to execute; you just need to point your simulator to it at runtime (more on that later). First, you need to make the SystemVerilog side aware of it. This SystemVerilog file was generated as part of the build process:

Image 3: Setting Code Generation Options to generate aSystemVerilog DPI component from Simulink.
© 2015 The MathWorks, Inc.
 Setting Code Generation Options to generate aSystemVerilog DPI component from Simulink. © 2015 The MathWorks, Inc.

Image 4: Auto-generated SystemVerilog wrapper for the checker DPI component.
© 2015 The MathWorks, Inc.
 Auto-generated SystemVerilog wrapper for the checker DPI component. © 2015 The MathWorks, Inc.


You can see that it created two functions in the component: an initialization function called at reset (DPI_fft_checker_initialize), and the main operation function
(DPI_fft_checker). These are the functions that will be used in SystemVerilog. We could just instantiate this fft_checker_dpi module in a testbench and feed it the inputs. However, since this example uses a UVM environment, we need to work these functions into its phasing. In this case, we will just take the two import “DPI” function statements over to our UVM testbench code and declare them there. These will be used in the scoreboard. First, the initialization function will return a handle to this instance during the build phase:

Image 5: Initializing the DPI function by returning a handle to it.
© 2015 The MathWorks, Inc.
 Initializing the DPI function by returning a handle to it.<br />
 ©2015 The MathWorks, Inc.


When a transaction comes through the analysis port from the monitor on the DUT’s output, we need to run the checker function. The original stimulus transactions have been stored in a FIFO, so the checker function will pop the next input from this FIFO and send its real and imaginary components to the checker along with the real and imaginary components of the DUT output.

Image 6: Sending the stimulus transaction and implementation output data into the checker, and comparing the result against the defined threshold.
© 2015 The MathWorks, Inc.
 Sending the stimulus transaction and implementation output data into the checker, and comparing the result against the defined threshold. © 2015 The MathWorks, Inc.


The return value, nmrs, is the return value from the MATLAB function. HDL Verifier created an output port for it when it created the SystemVerilog wrapper. This is compared against a threshold of error tolerance that we defined in our UVM testbench.

So now our verification environment looks something like this, with the scoreboard receiving transactions from the driver and monitor via analysis ports:

Image 7: High-level block diagram of the UVM environ- ment and where the generated SystemVerilog DPI component is used.
© 2015 The MathWorks, Inc.
 High-level block diagram of the UVM environment and where the generated SystemVerilog DPI component is used. © 2015 The MathWorks, Inc.


At this point, we can run simulation. Remember, we need to point the simulator to our shared library. Here’s how we do it with the Questa simulator:

Image 8: Questa Advanced Simulator run script, pointing to the generated shared library.
© 2015 The MathWorks, Inc.
 Questa Advanced Simulator run script, pointing to the generated shared library. © 2015 The MathWorks, Inc.


In the above script, libfft_checker_dpi is the name of the shared library automatically generated by HDL Verifier from the MATLAB function fft_checker.

RESULTS

This simple example shows how to generate SystemVerilog DPI components using HDL Verifier, and it illustrates how to integrate the generated components into a UVM environment. The simulation passes its simple test sequence (see image 9):

What effect did this have on our verification efforts? The high-level phases of a verification project typically include developing the verification plan, implementing the verification environment, and executing verification. The plan and implementation are driven primarily through reading and interpreting the specification, and that spec is written as a result of the design and verification efforts of the system team.

Image 9: Results from the simulation run.
© 2015 The MathWorks, Inc.
 Results from the simulation run.<br />
© 2015 The MathWorks, Inc.


In this approach, the spec is the primary – and sometimes the only – means of communication between system design and hardware verification teams. Building the environment, models, and tests by reading and interpreting the spec is labor intensive and error prone. If there is a spec change, it usually just gets addressed in the hardware design and verification environment. It rarely gets propagated back to the system design and verified there – why bother when there is a deadline to meet?

The ability to automatically generate SystemVerilog DPI components directly from the system design and verification environment is akin to directly passing the specification into the hardware verification environment.

Rather than having the verification team spend weeks reading the spec, writing and debugging a floating point reference model for an FFT, and checking functionality in SystemVerilog, we can automatically generate the DPI components from the system-level models. They are immediately available to the hardware verification team.

Image 10: When the specification is the primary method of communication between teams, implementation of the verification environment is a more manual process with more risk of misinterpretation of the specification.
© 2015 The MathWorks, Inc.
 When the specification is the primary method of communication between teams, implementation of the verification environment is a more manual process with more risk of misinterpretation of the specification. © 20155 The MathWorks, Inc.


Image 11: HDL Verifier SystemVerilog DPI component generation automatically generates system-level intent in a format that is consumable by the verification environment.
This reduces manual efforts and possible specification misinterpretations.
© 2015 The MathWorks, Inc.
 HDL Verifier SystemVerilog DPI component generation automatically generates system-level intent in a format that is consumable by the verification environment. This reduces manual efforts and possible specification misinterpretations. © 2015 The MathWorks, Inc.


If the spec changes, that change can be updated and verified in the system-level model, and the DPI component can be automatically regenerated.

This approach can be used for any project the verification team needs a model for, whether the model is digital, analog, or a mixture of the two. This saves the verification team weeks of implementation time and lets them focus on the core task at hand – verifying the design.

Back to Top

Table of Contents

Verification Horizons Articles:

  • Welcome to our once-again-super-sized DAC summer edition!

  • Verifying Airborne Electronics Hardware: Automating the Capture of Assertion Verification Results for DO-254

  • DO-254 Testing of High Speed FPGA Interfaces

  • Formal and Assertion-Based Verification of MBIST MCPs

  • Starting Formal Right from Formal Test Planning

  • Reuse MATLAB® Functions and Simulink® Models in UVM Environments with Automatic SystemVerilog DPI Component Generation

  • Intelligent Testbench Automation with UVM and Questa®

  • Unit Testing Your Way to a Reliable Testbench

  • Hardware Emulation: Three Decades of Evolution – Part II

  • Accelerating RTL Simulation Techniques

  • Emulation Based Approach to ISO 26262 Compliant Processors Design

  • Resolving the Limitations of a Traditional VIP for PHY Verification

© Mentor, a Siemens Business, All rights reserved www.mentor.com

Footer Menu

  • Sitemap
  • Terms & Conditions
  • Verification Horizons Blog
  • LinkedIn Group
SiteLock