• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer

Microcontroller Tips

Microcontroller engineering resources, new microcontroller products and electronics engineering news

  • Products
    • 8-bit
    • 16-bit
    • 32-bit
    • 64-bit
  • Applications
    • 5G
    • Automotive
    • Connectivity
    • Consumer Electronics
    • EV Engineering
    • Industrial
    • IoT
    • Medical
    • Security
    • Telecommunications
    • Wearables
    • Wireless
  • Learn
    • eBooks / Tech Tips
    • EE Training Days
    • FAQs
    • Learning Center
    • Tech Toolboxes
    • Webinars/Digital Events
  • Resources
    • Design Guide Library
    • DesignFast
    • LEAP Awards
    • Podcasts
    • White Papers
  • Videos
    • EE Videos & Interviews
    • Teardown Videos
  • EE Forums
    • EDABoard.com
    • Electro-Tech-Online.com
  • Engineering Training Days
  • Advertise
  • Subscribe

Retargeting existing tests in an integrated SoC verification flow

March 6, 2019 By Aimee Kalnoskas Leave a Comment

by Matthew Ballance, Mentor, a Siemens Business

The raison d’etre for portable stimulus is reuse. The Accellera Portable Stimulus Standard (PSS) promotes test intent reuse throughout the verification process and across the multiple engines on which those verification runs are performed. Test intent captured as portable stimulus models enables test reuse from the IP to SoC levels and boosts test-creation productivity.

As users consider applying portable stimulus, one immediate realization is the limited amount of portable stimulus content currently available within their organizations. Fortunately, there are many existing descriptions and formats within an organization that can be reused to create portable stimulus descriptions.

UVM register models and SystemVerilog classes and constraints are examples of existing descriptions that can be productively reused with portable stimulus.

In this four-part series, we will show you how to use UVM and SystemVerilog descriptions that you may already have, so you can jump-start the creation of portable stimulus models. We will begin with UVM register models.

UVM register models are heavily used at the block and subsystem levels to simplify interacting with device registers. The information captured within a register model description – register addresses, which fields can be written, etc. – is very helpful in creating SoC integration tests. In addition, this information is captured in a machine-readable way which makes it easy to automate reuse of this key portable stimulus information.

The UVM library provides built-in, directed sequence tests that iterate through a UVM register model to check the reset value of registers and confirm that registers are accessible. These sequence tests are incredibly useful at the IP level, but reusing them at the subsystem and system levels remains difficult.

This is where the PSS comes in. Capturing register-test intent in a portable stimulus model makes register-test functionality portable from the IP to the SoC level and provides more flexibility in controlling which registers are checked in a given test run.

Splitting the atom: Test intent and realization

Separating test intent and test realization, which are typically merged in a directed test, is a core element of portable stimulus, and this division is key to enabling test intent to be easily retargeted across environments. Test intent is the high-level design of what to test. Test realization is the mechanism by which that test is carried out.

In the case of testing a register model, test intent looks something like this: select a register from the register block; select a read/write field from the register, and select a bit within that field to test.

The test intent described above is independent of whether we are verifying a block, subsystem, or SoC level design. It is also independent of whether a SystemVerilog environment or an embedded-software environment is targeted. The test intent for testing a single register is captured by the PSS code below, where: reg_id captures the register being tested, flip_bit captures the bit within the register to be tested, and reg_addr captures the address of the field in the memory maps.


Designing the test realization with portable stimulus in mind allows us to design a common API that will be available in all environments. For example, we might specify that a method named testbit will be available in all environments, and that this method will test the ability to modify the specified bit. The function prototype for such a function is shown below.

In a SystemVerilog IP or subsystem level environment, we could implement this method as a task within a UVM sequence. The SystemVerilog task shown below uses a memory-access API to read and write memory and implements the register bit-test operation by reading the current value of the register, negating the target bit of the register and writing the new register value, and reading back the register address and checking whether the bit retains its value.


Birth of a subsystem register model

In this case, the test will continue to run if an error is encountered. This is pretty typical of UVM tests. However, an embedded software environment has different constraints. The example below shows an implementation of the testbit function for an embedded processor. This approach is very similar to the SystemVerilog version, though the specifics are different. One of the biggest differences is that, in this case, we assume if a register bit test fails, we will end the entire test.

Now we will create a subsystem UVM register model. The example subsystem in figure 1 has a processor, two Ethernet controllers, and two DMA engines.

SoC verification flow
Figure 1 – Simple Subsystem

A UVM register model was created at the block level, most likely using a register-creation tool (see figure 2), for the Ethernet and DMA controllers during verification.

Figure 2 – Register Creation Tool

At the subsystem level, a register-creation tool may help us to assemble a register model for the entire subsystem. Or we may simply take the individual block-level register models and assemble the subsystem-level register model manually. The code below assembles a subsystem-level register model from the Ethernet and DMA controller register models. Not much code is required: only the available registers in the design, and their addresses, and the fields within those registers and any access restrictions.

What might be surprising is just how quickly the number of registers accumulates. By the time we’ve created a register model for just two Ethernet controllers and two DMA controllers, we have 989 registers with testable fields. Imagine how many registers a full SoC contains!

Now that we’ve seen how to capture a subsystem or SoC level register model, how do we proceed to create register-access tests? First, we need to create a PSS model of the register-access test intent. Then, we need to connect that test intent to specific verification environments with test realization.

The next article in this series will show you just how to do that.

 

Additional Resources:

https://accellera.org/activities/working-groups/portable-stimulus

https://verificationacademy.com/topics/portable-test-stimulus

https://www.mentor.com/products/fv/infact/

 

Matthew Ballance is a Product Engineer and Portable Stimulus Technologist at Mentor Graphics, working with the Questa inFact Portable Stimulus product. Over the past 20 years in the EDA industry, he has worked in product development, marketing, and management roles in the areas of HW/SW co-verification, transaction-level modeling, and IP encapsulation and reuse. Matthew is a graduate of Oregon State University.

 

 

You may also like:

  • SystemVerilog
    How to structure SystemVerilog for reuse as Portable Stimulus
  • Portable Stimulus
    The nuts and bolts of verification: Recasting SystemVerilog for Portable…
  • reusable register-test models
    How to create and run reusable register-test models

Filed Under: FAQ, Featured, PCB Design, Tools Tagged With: FAQ, mentor, siemens

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

Featured Contributions

Five challenges for developing next-generation ADAS and autonomous vehicles

Securing IoT devices against quantum computing risks

RISC-V implementation strategies for certification of safety-critical systems

What’s new with Matter: how Matter 1.4 is reshaping interoperability and energy management

Edge AI: Revolutionizing real-time data processing and automation

More Featured Contributions

EE TECH TOOLBOX

“ee
Tech Toolbox: Internet of Things
Explore practical strategies for minimizing attack surfaces, managing memory efficiently, and securing firmware. Download now to ensure your IoT implementations remain secure, efficient, and future-ready.

EE Learning Center

EE Learning Center

EE ENGINEERING TRAINING DAYS

engineering
“bills
“microcontroller
EXPAND YOUR KNOWLEDGE AND STAY CONNECTED
Get the latest info on technologies, tools and strategies for EE professionals.

RSS Current EDABoard.com discussions

  • ADS optimization error
  • How to get started with RTL design?
  • RFsoc4x2 fpga diagram request
  • What is the purpose of the diode from gate to GND in normal Colpitts oscillator Circuits?
  • OFweek Mall Online Wholesale Sensors

RSS Current Electro-Tech-Online.com Discussions

  • 100uF bypass Caps?
  • Fuel Auto Shutoff
  • Actin group needed for effective PCB software tutorials
  • how to work on pcbs that are thick
  • compatible eth ports for laptop

DesignFast

Design Fast Logo
Component Selection Made Simple.

Try it Today
design fast globle

Footer

Microcontroller Tips

EE World Online Network

  • 5G Technology World
  • EE World Online
  • Engineers Garage
  • Analog IC Tips
  • Battery Power Tips
  • Connector Tips
  • DesignFast
  • EDA Board Forums
  • Electro Tech Online Forums
  • EV Engineering
  • Power Electronic Tips
  • Sensor Tips
  • Test and Measurement Tips

Microcontroller Tips

  • Subscribe to our newsletter
  • Advertise with us
  • Contact us
  • About us

Copyright © 2025 · WTWH Media LLC and its licensors. All rights reserved.
The material on this site may not be reproduced, distributed, transmitted, cached or otherwise used, except with the prior written permission of WTWH Media.

Privacy Policy