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
  • November 2015
  • Memories Are Made Like This

Memories Are Made Like This

Verification Horizons - Tom Fitzpatrick, Editor

Memories Are Made Like This by Mark Peryer, Verification IP Architect, Mentor Graphics

INTRODUCTION

One of the most common requirements for the verification of a chip, board or system is to be able to model the behaviour of memory components, and this is why memory models are one of the most prevalent types of Verification IP (VIP).

Figure 1. Memory model functionality
Figure 1. Memory model functionality

Memory models have two main functions. The first is to store information in a data structure so that it can be written, retrieved and updated. The second is to provide a signal level interface which allows access to the storage array using a pre-defined protocol (see figure 1 for a representative functional block diagram). For effective verification the model should also check that the signal level protocol from the host interface is behaving correctly, provide a backdoor access to the storage array and provide a means of collecting functional coverage.

Over the years, memory devices such as Dynamic RAMs (DRAM) have driven semiconductor process development as manufacturers have sought to create faster memories with a greater storage capacity through the use of smaller feature sizes. Over time, several different memory protocols have been developed to optimise the various trade-offs between device access speed and packaging costs, and today, one of the most widely used protocols is the Double Data Rate (DDR) memory protocol, and its low power variant, LPDDR. The DDR protocol is designed for high speed access, with data being transferred on both edges of the clock. However, in practice, this high level of throughput can only be achieved by managing the DDR accesses so that the time and power expensive operations such as activate and pre-charge can be taking place in one part of the memory whilst a data transfer takes place with another part of the memory. It is the task of a DDR controller to order the operations taking place in the DDR device to maximise throughput, and in order to verify the complex trade-offs a sophisticated memory model is needed.

In order to address the need for accurate DDR models, the Model Generator utility was introduced in the 10.4b release of Mentor’s Questa VIP (QVIP) library. The function of the Model Generator is to generate DDR and LPDDR models that match the behaviour of commercially available memory parts.

MODEL GENERATOR

QVIP Model Generator is an easy to use graphical utility that allows a user to specify and create a DDR or LPDDR model that will match the behaviour of over 750 commercially available devices. Underlying Model Generator is a code generator that supports all types of DDR and LPDDR models as defined in the JEDEC JESD79 and JESD209 specifications, with all possible configurations of device width, density and speed. The models are generated based on a memory manufacturer’s part number that represents an entry in a database that contains the details of each target memory device. The generated model is implemented as a Verilog module that is wrapped around the Mentor DDR QVIP.

To create a part in Model Generator GUI, the user first has to choose the DDR type and the manufacturer, this narrows their search down to a list of available devices. Then the user selects the required device from those part numbers available in the reduced list and then they press the generate button to write out the code for the device model. Figure 2, shows a screen shot of the part number selection pane for Micron DDR3 memories, the table entry row in blue is the one that has been selected. Table 1 lists the memory devices available from the various memory vendors that are supported by Model Generator.

The Model Generator software allows the user to create several models in a session, and also to specify the name of the generated model.

GENERATED MEMORY MODELS

The DDR/LPDDR models generated by Model Generator are intended to be instantiated in a VHDL, Verilog or SystemVerilog/UVM testbench module as a component module. The models are reactive, in other words, they respond to the signalling on the protocol wires in order to determine how to behave and do not require any user stimulus in order to provide their functionality.

The models have a port map that corresponds to the memory device selected, and in some cases the models have several DDR/LPDDR interfaces since the selected memory device package contains several die. Each type of DDR and LPDDR has a different pin interface, and depending on the protocol there are several data bus width options per device, some of which have a further influence over the pin out. The generator has built-in rules that ensure that the right pin out is used. Most of the signal pins are simple inputs or outputs, but the data pins and their strobes are bidirectional, and the model switches between driving or receiving on these pins according to the current mode of operation.

Table 1. Available memory device types by manufacturer

DDR Manufacturer DDR2 DDR3 DDR4 LPDDR2 LPDDR3 LPDDR4
Micron Available Available Available Available Available Available
Samsung NA Available Available Available Available NA
SK-Hynix NA Available Available Available Available NA
ESMT Available Available NA NA NA NA
ETRON Available Available NA NA NA NA

 

Figure 2. Screen shot of the Model Generator GUI
Figure 2. Screen shot of the Model Generator GUI
Figure 3. Model Generator memory model functional diagram
Figure 3. Model Generator memory model functional diagram

The models are wrapped around the DDR QVIP BFM – see figure 3 for a functional block diagram of the features of the Model Generator memory model. The DDR QVIP BFM is configured by code inside the module to provide the correct functionality for the part selected in the generator. In addition to modelling the behaviour of the DDR memory, the QVIP BFM also has built-in assertions for protocol violations and will report any errors that occur.

TRANSACTIONAL FEATURES

The generated models support two additional features that are normally only available in the context of UVM testbenches – functional coverage and transaction reporting. The functional coverage monitor is enabled by setting the models ENABLE_FUNC_COV parameter to a ‘1’. The functional coverage is collected by taking advantage of the transaction recognition features of the DDR QVIP BFM. Enabling the functional coverage monitor gives users of VHDL and Verilog testbenches the opportunity to take advantage of the built-in functional coverage to check which aspects of DDR or LPDDR functionality they have tested with their stimulus. The transaction reporting function is enabled by setting the models ENABLE_TXN_LISTENER parameter to a ‘1’. The transaction reporter prints a record to the transcript every time a transfer takes place over the DDR interface. Both of these features need to be enabled by the user, since they are disabled by default to optimise simulation performance.

The default behaviour of the models is that they are configured to work in the absence of a UVM testbench. If the NO_UVM parameter is set to ‘0’, then the functional coverage monitor and the transaction logger participate in the UVM phases. There is no support for creating a DDR memory agent in a UVM env since the DDR BFM needs no active stimulus.

Another transactional feature built into the models is the ability to use the hierarchical transaction viewing feature of the DDR QVIP to debug DDR activity via the Questa waveform view – see figure 4 for an example. This feature takes advantage of the built-in transactional objects that are available across the QVIP library.

Figure 4. Screen shot of DDR QVIP transactions
Figure 4. Screen shot of DDR QVIP transactions

BACKDOOR API

The models also support a backdoor API which enables the memory data storage array to be accessed directly without using the DDR signal interface. The backdoor API is intended to allow the user to either pre-load areas of memory with data, or to examine stored data content. The available API calls are summarised in table 2, and can be called using a hierarchical reference to the memory model. There are several applications for this back door access functionality. If the design under test (DUT) contains one or more processors, then the DDR would provide the storage for the software binaries and the backdoor write API would be used to transfer a copy into the memory model. If the design contains a DMA function, then an area of memory would be initialised through the back door write API with a block of data containing a signature that would be copied to other places in memory during the course of the test case. Another possibility could be that the DUT has a data processing function, in which case the DDR memory would be initialised with the starting data on which the design would perform a transform and then write the result to another area of memory. The backdoor write APIs take an address and an array of bytes as their arguments. The data array content is written to consecutive locations starting at the given address.

Table 2. Model Generator backdoor API summary

Backdoor API Call Summary
backdoor_wr_by_address(address, data[]);
backdoor_wr_by_brc(bank, row, column, data[]);
backdoor_rd_by_address(address, length, data[]);
backdoor_rd_by_brc(bank, row, column, length, data[]);
dump_memory_content(mem_data_content[]);

 

Working in the opposite direction, the backdoor read APIs allow the content of the memory to be read back which can be useful for checking whether a data processing application has worked correctly, or that a known sequence of data transfers has completed successfully. The backdoor read APIs use a length argument to determine how many bytes are read back, starting from the location addressed by the address argument.

Finally, the dump_memory_content() API allows the DDR model to report on all locations accessed during the course of the simulation, listing bank, row and column addresses together with data content.

CONCLUSION

The Model Generator utility, released as part of the QVIP 10.4b library, supports models for more than 750 DDR and LPDDR commercial memory devices. The generated models provide comprehensive verification support for DDR and LPDDR memory interfaces, with a pin level interface, a complete set of protocol checking assertions, a functional coverage monitor and transaction reporting.

Model Generator proves an easy (EZ) way to generate an accurate and sophisticated simulation model for a standard part that can quickly be integrated into any Verilog or VHDL testbench.

Back to Top

Table of Contents

Verification Horizons Articles:

  • Welcome to the 10th Anniversary edition of Verification Horizons!

  • Memories Are Made Like This

  • A New Stimulus Model for CPU Instruction Sets

  • On-Chip Debug – Reducing Overall ASIC Development Schedule Risk

  • Hardware Emulation: Three Decades of Evolution—Part III

  • QVIP Provides Thoroughness in Verification

  • Minimizing Constraints to Debug Vacuous Proofs

  • A Generic UVM Scoreboard

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