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
      • Fault Campaign for Mixed-Signal - 5/4
      • 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 2014
  • Cache Coherent Interface Verification IP

Cache Coherent Interface Verification IP

Verification Horizons - Tom Fitzpatrick, Editor

Cache Coherent Interface Verification IP—How a Cache Controller and Generic APIs Can Make It Easier to Generate Stimulus. by Amit Kumar Jain, Questa VIP Product Team, Mentor Graphics

ABSTRACT

In a multi-processor system, a cache coherence protocol is vital to maintaining data consistency between local caches and the main memory. With the local processor cache, the bus stimulus must be compliant with the cacheline state in the local cache, and must follow predefined ordering rules between the read/write and cache snoop stimulus. These constraints can make it confusing to generate stimulus on a cache coherent interface. This article addresses such stimulus generation issues by providing easy to use generic APIs along with a cache controller.

INTRODUCTION

The advent of heterogeneous, multi-processor systems with multiple caches sharing the same data has made interconnect design more complex and prompted the development of cache coherent protocols such as ARM® AMBA® 4 ACE (AXI Coherency Extension) and ARM® AMBA® 5 CHI (Coherent Hub Interface).

As per the latest cache coherency protocol specifications from ARM®, the cached processor bus stimulus is compliant with the particular initial cacheline state in the local cache. Similarly, the processor needs to update the cacheline state and data in the local cache as needed at the end of a transaction. If a user is creating a testbench environment for verifying a cache coherent interface, the stimulus dependency on cache memory can complicate user sequences. The user needs to access cache memory at the start and end of each transaction. Beyond dependency on the local cache, there is dependency on setting the address region and domain (shareable or non-shareable) that is, in general, based on a system address map.

For example, here are the steps if a user wants to perform a cache maintenance operation (CMO):

  • Check system address map to make sure address lies correctly in one of the shareable regions
  • Access the master cache model to check initial cacheline state
  • Check ordering for the same ID and cacheline transactions in progress
  • Set a longer list of transaction attributes as per protocol legality
  • Perform the cache data/state update at end of transaction, as needed

AMBA® 4 ACE and AMBA® 5 CHI Questa Verification IP (VIP) introduces a single ACE/CHI QVIP agent with a generic API master sequence and master cache controller. This makes it easier for a user to generate stimulus on a cache coherent interface without worrying about accessing/ updating the cache and accessing the system address map; the cache controller takes care of this internally.

 Generic master sequence

Figure 1: Generic master sequence.

GENERIC MASTER SEQUENCE

This is a simple reusable sequence that provides a different set of APIs such as instruction-level and transactional read/write, and barrier and coherency. APIs in the generic sequence further make use of the cache controller APIs to execute the transaction and perform the required operation. The cache controller implements logic to execute the transaction on the bus after doing required operations such as accessing the cache memory and system address map. At the end of transaction, it performs the required cache memory update.

Generic read/write instruction-level APIs To verify a processor-based interface, a user needs to read or write a chunk of data in memory preferably without worrying about protocol intricacies and a huge list of attributes associated with the protocol-specific transaction items. So the first stimulus generation requirement is for a generic read/write instruction-level API. Figure 2 shows a generic transaction item for passing generic read/write transaction information to the read/write API. This sequence item encapsulates a request to read or write a selected number of bytes in the system/cache memory.

class rw_txn extends uvm_sequence_item;
typedef rw_txn this_t;
typedef enum bit[7:0] {READ, WRITE, BARRIER} cmd_e;
typedef enum bit[7:0] { OKAY, ERROR } status_e;
 
typedef longint unsigned addr_t;
 
// Input attributes
int id = -1;
rand cmd_e cmd;
rand addr_t addr;
rand int size;
// This is Write data input for WRITE cmd, output for
// READ cmd
rand byte unsigned data[];
rand bit strobes[];
 
// Output attributes – Set after execution is complete status_e status;

Figure 2: Generic read/write transaction class.

The read/write API is for conducting basic reads and writes as if from a program running on a processor. It provides a basic interface, letting the master cache controller choose the most appropriate bus protocol transaction based on current cache state and the type of memory being targeted (snoopable, non-snoopable, etc).

The API methods have only a handful of simple arguments (command, address and data) with no direct dependency on bus-specific attributes. Bus-specific attributes will be determined configurations that change less frequently such as the address map and attributes API, both of which are described later.

The generic master sequence provides the following instruction level read/write APIs, as well as a read/write transaction API (with minimal arguments and no protocol or cache dependencies). Figure 3 shows a basic block diagram and Figure 4 (on the next page) provides the code.

 Generic read/write instruction level API

Figure 3: Generic read/write instruction level API.

Generic Read-Write Instruction API Declaration Abstract Writes
// Write a single byte of data at addr
task write8 (longint unsigned addr, byte unsigned data,
		int id=-1);
 
// Write a single 16-bit half-word of data at addr
task write16 (longint unsigned addr, shortint data,
		int id=-1);
 
// Write a single 32-bit word of data at addr
task write32 (longint unsigned addr, int data,
		int id=-1);
 
// Write a single 64-bit long word of data at addr
task write64 (longint unsigned addr, longint data,
		int id=-1);
 
// Write a variable-length array of data at addr
task write (longint unsigned addr, ref byte unsigned
		data[], input int id=-1);

Abstract Reads
// Read a single byte of data at addr
task read8 (longint unsigned addr,
		output byte unsigned data,
		input int id=-1);
 
// Read a single 16-bit half-word of data at addr
task read16 (longint unsigned addr, output shortint data,
		input int id=-1);
 
// Read a single 32-bit word of data at addr
task read32 (longint unsigned addr, output int data,
		input int id=-1);
 
// Read a single 64-bit long word of data at addr
task read64 (longint unsigned addr, output longint data,
		input int id=-1);
 
// Read size number of bytes into data starting from addr
task read (longint unsigned addr, ref byte unsigned
		data[], input int unsigned size, int id=-1);

Barrier
// Execute a barrier transaction with the optional
transaction
// stream id
task barrier (int id = -1);

Transaction RW
// Execute a transaction whose attributes are specified in
// txn, of type rw_txn (generic read/write transaction class).
task execute_txn (rw_txn txn);

Figure 4: Generic read/write instruction API declarations.

Coherency APIs

The instruction-level and transactional read/write APIs mentioned above are declared within a generic reusable master sequence. Along with these APIs, a user would also want to run protocol specific coherency transactions. Coherency APIs provide flexibility to the user to run coherency transactions such as cache-maintenance operations (CMO), copy-back (CB), DVM and barrier transaction.

If a user wants to run a CMO, then generally he wants to run specific cache maintenance operations on a selected cacheline instead of worrying about lots of other protocolrelated transaction attributes. This coherency API takes the CMO transaction type and cacheline address information from the user (with an optional transaction stream-ID) as input. The coherency API for copy-back operations behaves similarly.

Along with generic coherency APIs is an API to run a busspecific transaction/sequence-item directly, so that the user has the flexibility to specify transaction item attributes. Figure 5 gives the list of coherency APIs in the generic master sequence; Figure 6, the coherency API declarations.

 Coherency APIs

Figure 5: Coherency APIs.

 

Coherency API Declarations
// Execute a specific cache maintenance transaction
// on particular cacheline
task execute_cmo_txn (txn_type_e txn_type,
	longint unsigned addr,
	int		id = -1);
// Execute a copy back transaction on particular
// cacheline (CB transaction is chosen based on
// initial cacheline state)
task execute_cb_txn (longint unsigned addr,
	int		id = -1,
	bit		invalidate);
// Initiate a DVM transaction
task execute_dvm_txn (dvm_info_s dvm_msg[],
	int		id = -1);
// This API is meant for the user to start a desired
// protocol specific transaction/sequence-item
task execute_ace_txn (ace_rw_txn txn); // For ACE
task execute_chi_txn (chi_rw_txn txn); // For CHI

Figure 6: Coherency API declarations.

MASTER CACHE CONTROLLER

The cache controller is a background process that runs continuously on the VIP master components. It receives and executes read/write requests from user sequences and automatically performs protocol compliance/legality checks (such that ordering rules are followed to generate legal stimulus as per protocol specification) and cache updates. This is the base class for driving stimulus and controlling behavior on a cached master VIP. It contains handles to the cache memory model and VIP configuration class object. The controller basically starts transactions on both read and write channels depending on the cacheline state, as illustrated in figure 7.

Transaction ordering rules and related protocol compliance/ legality are automatically taken care by controller logic. An example: an ordering rule requires that while generating stimulus a CMO transaction should be issued only after the previous CMO transaction is completed inside the controller.

 Master cache controller

Figure 7: Master cache controller.

The master cache controller generates a transaction stimulus on the read/write request channel and handles snoop requests on the snoop virtual channel. As a cache processor is also responsible for responding to snoop requests on its respective channel, the controller implements respective snoop handling logic.

The snoop sequence logic in controller receives snoop requests via the snoop request virtual channel, processes the request, possibly modifies the cacheline state in its local cache (whenever needed) and then sends the appropriate response on the response virtual channel. If data transfer must occur, it is sent via the data virtual channel.

CACHE MODEL, SYSTEM ADDRESS MAP AND ATTRIBUTES API

As described above, a generic master sequence consists of the following set of APIs:

  • Generic read/write instructions
  • Transactional read/write
  • Coherency API

The top level transaction includes many attributes to allow precise control over bus activity, but remains simple to use as the API is abstracted so that only minimal inputs are required.

The Master controller implements execution of these generic APIs and finally starts at the top abstraction level bus sequence item on the VIP BFM. In order to do this, the master controller needs to obtain and set values of all other transaction attributes that are not provided as input to generic instruction read/write or coherency APIs.

These attributes come through the following means:

  • Master local cache
    This is accessed at the start of a transaction to determine if the transaction to be executed is legal or not as per the initial cacheline state. It extracts the following information from the cache model for executing transactions on the bus:
    • Cacheline state
    • Cacheline data
  • System address map
    This defines the address map for a master and consists of multiple address region entries. Each address map entry defines the range of addresses and attributes for addresses in this entry. These attributes are:
    • Target : The slave (target) that services requests to this region of memory
    • Domain: Shareable (inner/outer) or non-shareable
    • Region: The optional region in which this memory belongs
    • Prot: Protection mechanism attributes mapped to by the address map
    • Memory type: Normal or device memory
  • Attributes API
    There are a few other transaction attributes that are not extracted from the cache model and system address map. A separate attributes API (set/get methods for each attribute) is provided in the generic master sequence that can be set once and used by multiple transactions until changed again. If not set, then the default value is used for the attribute.

VIP AGENT

The Verification IP agent (shown below) automatically does the following:

  • Creates and maintains the cache memory model
  • Automatically starts the cache controller
 VIP UVM agent.

Figure 8: VIP UVM agent.

CONCLUSION

This article lists and describes VIP master APIs that could be reused to generate stimulus on a cache coherent interface without worrying about accessing the cache model and other testbench objects that are typically needed to know about transaction attributes. Instruction level read/ write and coherency APIs make it easy to write stimulus sequences on a cache coherent interface such as ARM® AMBA® 4 ACE and AMBA® 5 CHI.

REFERENCES

  1. ARM® AMBA®4 AXI and ACE Protocol Specification – IHI0022E by ARM®
  2. UVM – Universal Verification Methodology Cookbook

Back to Top

Table of Contents

Verification Horizons Articles:

  • Whether for a Community Play or a Coverage Plan, Reuse Makes a Lot of Sense.

  • Integrate Ethernet QVIP in a Few Hours: an A-to-Z Guide

  • Fast Track to Productivity Using Questa® Verification IP

  • Cache Coherent Interface Verification IP

  • Hey You Design Engineer!

  • Please! Can Someone Make UVM Easier to Use?

  • Controlling On-the-Fly-Resets in a UVM-Based AXI Testbench

  • Increase Verification Productivity with Questa® UVM Debug

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