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 /
  • November 2020 /
  • Memory Softmodels - The Foundation of Validation Accuracy

Memory Softmodels - The Foundation of Validation Accuracy

Verification Horizons - Tom Fitzpatrick, Editor

 | Verification Horizons - November 2020 by Ridham Kothari - Mentor, A Siemens Business

As always, we must continue to reduce the time-to-market of SoCs and complex systems. An FPGA prototype implementation of these systems can be used as a basis for early software or firmware development, hardware-software co-verification and system validation, and all this can be achieved before actual silicon is available. As FPGA prototyping systems can also be used as a platform to validate system level functionality and are fast enough to develop application code running on top of an OS, the adoption of FPGA prototyping systems is increasing.

An important part of system level validation is to ensure that the performance meets expectations and that the system is capable of supporting anticipated workloads. In order to validate critical scenarios it is important to accurately model the clock-level timing of target memory types such as DDR4, DDR5, LPDDR4 and LPDDR5, so that the whole-system effects of running with different levels of memory subsystem loading can be observed, albeit at a scaled frequency. This article focuses on how Memory Softmodels are used in the validation process and how they provide the foundation for performance validation accuracy.

INTRODUCTION

The size of SoCs and complex systems is growing rapidly as more and more IP blocks and sub-systems are integrated to reduce overall system development cost. This trend demands increased efforts in both hardware and software validation. This has created the requirement to start validation of the system and its related software as soon as possible, in order to be able to meet the relentless drive to reduce time-to-market. As FPGA prototypes can represent a frequency-scaled replica of a design running at an actual speed, it can validate a comparatively mature RTL and provide a platform to start early development of the software to be executed on this RTL. Hence, FPGA prototyping systems provide a very effective solution in reducing time-to-market. Further it reduces costly design re-spins by validating and eliminating bugs in the design before the availability of actual silicon. The representation of a design on an FPGA prototyping system needs to be clock-cycle accurate to realistically determine its performance.

UNDERSTANDING THE VALIDATION PROCESS

In an SoC development cycle, Verification and Validation each play an important role in proving a design’s quality against its golden reference specification. Verification is a process in which a design is tested against its specification, with the main goal being to ensure the functional correctness of a design. On the other hand, validation is a process to make sure that the design fits its system level purpose and performs as it was intended to. Ultimately, validation is performed with the final silicon to qualify the design for all of its functionality within the required performance window.

Any form of validation, whether it is intended for system level validation or to run software stack on processor hardware, requires some form of memory. There are various ways in which the memory resources can be implemented in a FPGA prototype. It can be done using either resources internal to the FPGA, or by using on-board external memory devices connected to the FPGA. The applications that use a small amount of memory, i.e. up to few Kilobytes, can target internal FPGA resources. However applications which require memory resources of Gigabytes, would use on-board memory for bulk memory storage. A Memory Softmodel comes with a pre-packaged solution for interfacing to the bulk memory devices on the FPGA prototyping system.

Figure 1 - Subsystem-level Memory Abstraction Using a Softmodel


A Memory Softmodel can provide sub-system level memory abstraction as demonstrated in Figure 1. In this setup, the Memory Softmodel is implemented as an AXI slave and the DUT system accesses the on-board DDR memory by generating appropriate AXI traffic. This configuration is typically used to replace a memory controller sub-system in an SoC pending the arrival of the RTL. It provides access to bulk memory storage for the designers to start early development of the software, but this is an overly optimistic solution as the impact of DDR latency is completely ignored.

An important part of system level validation is to run the system under various traffic scenarios to determine if it is capable of supporting anticipated workloads under different system configurations. To be able to get a realistic idea of the system’s throughput it is important to have a setup that accurately models clock-level timings of various target memory accesses. Clock-level timing of a memory access is the memory’s configured latency at which read or write data is available from the point when the memory access is initiated. Using a clock timing accurate memory abstraction can help in determining key system characteristics such as the system’s throughput and its performance under different workloads.

Figure 2 - System-level Memory Abstraction Using a Softmodel


A DDRx or LPDDRx Memory Softmodel is a clock timing accurate model with a protocol compliant port list. When used with a target DDR controller, it provides memory abstraction and helps in creating accurate scenarios where the system’s throughput can be measured realistically. It supports all the protocol features required for system level validation, which can be useful in determining system’s performance under different memory configurations. For example, a Memory Softmodel can be used to determine the impact of different read and write latencies on system level throughput and to ensure that with each of the required configurations the system’s behavior aligns with expectations. Different performance characteristics can also be measured by trying different combinations of clock frequencies, different memory data widths, densities, and other functional configurations. This allows hardware implementers and software developers to optimize the system level design for the desired throughput. In the early parts of the development cycle it helps to make critical design-specific decisions by determining optimum configurations to achieve the required throughput.

The Memory Softmodel decodes the traffic from the memory controller, creates a logical address for each requested memory access and, based on the current configuration set by the controller, forwards or accesses this converted traffic so that it can be stored or read back from an on-board DDR resource. This eliminates the need for the FPGA prototype to provide on-board storage memory devices that match the memory type targeted by the DDR controller.

Many DDR controllers improve their throughput by changing how they map a logical address to a DDR physical address, made up of the bank, row and column registers. A Memory Softmodel has a built-in configuration feature that allows different physical mappings to be translated back to a logical address, making it easier to check memory content via the backdoor interface. By experimenting with various memory mapping schemes, developers of DDR controller hardware and software can also explore how different memory mapping schemes impact the system throughput and determine the best configuration to maximize throughput for the anticipated memory traffic.

FEATURES OF A MEMORY SOFTMODEL

The Memory Softmodel is encapsulated with features such as wrappers to provide backdoor accesses to the main memory, to protocol specific configuration registers, and to the Memory Softmodel specific place and route constraints within a single package. This can simplify integration of the Memory Softmodel with any DUT system, so the Memory Softmodel can be directly used as a plug-and-play solution. Support of backdoor accesses to the on-board memory can be a used to load/unload memory images to the on-board DDR, which can be very useful in providing bulk memory storage for important scenarios such as validation of the system boot process.

Backdoor accesses to the protocol-specific configuration register can be very helpful to understand the current status of the Memory Softmodel mode register configurations. This provides a quick way of debugging to eliminate issues such as differences in the Memory Softmodel configuration compared to the expected configuration set by the controller. A Memory Softmodel can also be configured to overwrite some configurations via backdoor accesses, which otherwise would require a whole recompile of the design.

Optionally, a Memory Softmodel can be configured to inject errors by modifying its configuration using backdoor access. Normally an error isn’t expected to happen, but it is important to determine the system’s behavior in case of such errors. It helps in ensuring that the system can withstand and recover from the error conditions as expected and still be able to provide necessary performance for the workload. This can be used to make the system more robust to qualify for various usage scenarios.

Figure 3 - Using a Softmodel in an example


To conclude, consider the validation of an example SoC aimed at a mobile application. The required Android boot image can be loaded on the FPGA prototype on-board memory via backdoor accesses to the LPDDRx Memory Softmodel and then the DUT can immediately initiate the process of booting via reading back the boot image from memory. After booting is completed, the system can be run under different traffic scenarios to determine if it can handle different workloads as expected and is able to meet its performance requirement under such workloads. If not, configuring the system with different memory latencies can be used to characterize the system’s throughput with each value of latency. This can be helpful in making decisions for any possible design change. Even in the case of the system’s meeting its throughput requirements, further optimization is possible to achieve the best possible throughput. In cases where different blocks of the system are still under development, software validation can still be started early by replacing the memory sub-system with an AXI-slave Softmodel. Software executables can be converted into hex which is fed to the system to generate required application-specific scenarios.

Mentor’s Veloce Prototyping System (VPS) provides an expansive library of Memory Softmodels with generic and protocol-specific solutions for these applications. Since these Memory Softmodels are in compliance with the protocol specification, they can also be retargeted to run on Mentor’s Veloce emulation platform.

Back to Top

Table of Contents

Verification Horizons Articles:

  • What Falling Leaves Can Teach Us About Greater Efficiency

  • Quantifying FPGA Verification Effectiveness

  • Arasan MIPI® CSI-2-RX IP Verification Using Questa® VIPs

  • Memory Softmodels - The Foundation of Validation Accuracy

  • Increasing Functional Coverage by Automation for Zetta-Hz High Speed CDMA Transceiver

  • Unified Approach to Verify Complex FSM

  • RISC-V Design Verification Strategy

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

Footer Menu

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