Get control of ARM system cache coherency with ACE verification - Embedded.com

Get control of ARM system cache coherency with ACE verification

In this Product How-To article, the Cadence authors describe how to use the company’s Verification IP solutions framework to implement ARM’s AMBA 4 Coherency Extensions (ACE) in embedded SoC designs.

The challenges facing designers of the next generation of devices such as multimedia smartphones, tablets, and other mobile devices are many. They have to deliver highly responsive systems yet must also consume the least power possible—certainly no more than their competitors.

To achieve these goals, designers have been employing multi-processor architectures for many years. However, the need for even greater performance has exceeded the capability of current multi-processor/multi-cluster architectures.

Squeezing every last drop of performance and power out of these compute clusters is more important now than ever. One of the largest areas of opportunity for performance gains in multi-processor systems is in moving software-based cache-coherency management into hardware.

Why cache coherency? The primary goal of cache coherency is to minimize cache misses, as this is beneficial for both performance and power consumption. Every off-chip main memory access consumes much greater power versus a cache hit. Even worse, process cycles are wasted while waiting for the off-chip data. Because the cache management scheme must be aware of the status of all data in the system, these schemes have become quite complex. In addition, the engineering effort involved to develop and debug a software-based cache-coherence scheme is high.

This is the driving force behind ARM AMBA 4 Coherency Extensions (ACE). By embedding the responsibility for coherency in the hardware and defining a protocol to support it, ARM has addressed a key performance-limiting and power-consuming aspect of multi-processor systems while also assuring cache coherency.

However, this changeover from software to hardware-based cache coherence creates its own set of verification challenges. Every component in an ACE-based system has become more complex, thereby significantly expanding the verification team’s scope and required knowledge.

Coherency schemes are high-risk areas
Coherency management is required because there are multiple copies of the same data in different caches throughout the system. Since data in each cache can be modified locally, the risk of using invalid data is high. Therefore, it is essential to provide a mechanism that manages when and how changes can be made. Most typically coherency management is implemented in software today. This consumes processor cycles and power that could better be applied to user applications.

Though the protocol mechanisms to achieve this are conceptually simple, the implementation (involving multiple finite state machines all operating concurrently) is surprisingly complex. Bottom line: cache-coherent systems are high-risk elements of the design—they are difficult to design and even more difficult to verify. And, at the end of the day, you need a way to confidently sign off that your system is cache coherent—this a key verification challenge.

Another major challenge in verifying an ACE-based system is the tremendous size of the verification space. The cross between ACE specification elements such as Domain, Transaction Types, Response Types, and Cache States is huge, and every combination and permutation must be completely verified. Yet the logical behavior is only part of describing activity on the bus. The sequencing and timing of accesses to shared cache lines must also be accurately modeled and verified.

The keys to verifying ACE-based, cache-coherent designs
.There are three major capabilities necessary to verify ACE-based designs. They are:

1 . Mimicing all possible scenarios to cover the full verification space
2 . Ensuring coherency and system compliance with the ACE specification
3. Measuring coverage and ensuring verification completeness

This article describes what to look for when considering ACE verification solutions and discusses in detail the three requirements for ACE Verification IP (VIP).

1) Stimulus generation: all possible scenarios for full verification space
The complexity of verifying ACE-based designs requires using VIP that can model the variety of ACE masters and slaves in the system. This offloads the user from having to know the protocol details in order to create legal (or illegal) transactions.

VIP that purports to mimic processor behavior must create stimulus that takes into account the protocol rules, cache line states, and any design-specific constraints when generating transactions. The VIP must also calculate timing correctly according to the bus state. Examples of specific modeling requirements for the VIP are shown in Table 1 below.


Table 1: ACE behavior examples and the VIP capabilities required to model them
For designs employing multiple processors, the VIP must be able to behave differently and appropriately per master being mimicked. The VIP must have the flexibility to:

* Initiate the cache with specific or random values at the beginning of a test and/or by providing back-door access to the cache during the simulation

* After a transaction is completed, randomize the final state of the cache

* Choose between using “allowed” or “expected” responses

* Mimic processor internal activities that affect the cache state and for those states that require it will generate a new transaction on the bus

Figure 1: ACE VIP must be able to model the full range of masters and slaves
While we’ve focused on the master, clearly your VIP will also need to provide a memory model for the system that correctly responds to read/write transactions.

2) Coherency checking: ensure ACE spec compliance & system coherence
Each master and slave must be verified individually to ensure it complies with the specification, but this is not enough. The VIP must be teamed with a monitor that watches all the traffic on the interconnect. This is necessary to ensure coherency of the full system. In other words, the ACE verification solution is needed to perform two key tasks:

Task #1. Ensure that each individual component (e.g, processors, memory) behaves correctly
Task #2. Monitor the interconnect to ensure that communication between all blocks is accurate and in compliance with the ACE specification.

Task #1 is enabled by the VIP’s master and slave agents. Once the user has integrated the block RTL with the interconnect the VIP will be used as a passive agent so it must monitor each individual bus interface to ensure protocol compliance.

Each master agent must also hold a cache model that will serve as a mirror image of the processor cache. It does so by monitoring transfers on the bus.However, the simple cache mirror image may not be sufficient for all design cases. The ACE specification supports “snoop filtering,” which reduces snooping activities.Therefore, if the design under test (DUT) doesn’t support snoop filtering, then the VIP’s cache mirror must be capable of capturing a list of possible states and check accordingly.

To enable Task #2 , a separate interconnect monitor is required. Without such an interconnect monitor it is impossible to ensure full system coherency. This monitor must check data integrity and correctness of the interconnect itself to be sure it is behaving in compliance with the ACE specification.

For example, only the interconnect monitor (which is aware of all the masters and domains in the design) can check whether a coherent transaction initiated by a master causes the interconnect to create snoop transactions in the correct domain/master.

Figure 2: ACE verification requires both ACE VIP and an interconnect monitor
Since interconnect behaviors are often design specific, verifying these additional rules or bypassing standard protocol rules, the interconnect monitor must provide user hooks to extend the checks.


Figure 3. Error state scenario.
For example, in some cases, interconnects will redirect items not only based on the address but on other attributes like user signals. In this case a user hook must be used to inform the interconnect monitor to expect a different behavior than the standard.

Coverage: definitions & measurement for verification completeness
As previously mentioned, the huge state space associated with ACE-based designs presents a key verification challenge. Simply defining all the complex scenarios requires major investment in and of itself. Yet, this is insufficient. The ACE verification solution must also enable you to measure and ensure completeness of the verification space.

Figure 4: Interpreting flat coverage results is challenging
Simple bus functional model (BFM)-style VIP isn’t sufficient to verify the ACE protocol. To attain the productivity necessary, ACE VIP must define all the required coverage points.

This relieves the verifcation team of the burden of creating the thousands of scenarios necessary. It dramatically reduces and focuses the test writing effort down to only filling the coverage holes.

Further reducing risk, in this model, coverage is used as the metric for determining verification completeness. Therefore, it is imperative that the VIP provide the complete coverage map based on the ACE specification.

Yet, VIP that simply provides the raw coverage in a flat printout leaves the challenging task of reading and analyzing coverage results to the engineering team.

What’s needed is an executable verification plan that hierarchically correlates to the ACE specification sections. It also must provide a way to easily differentiate between high and low importance coverage items.

Figure 5: ACE executable verification plan correlates to the ACE specification
While such an executable verification plan is essential, it is not sufficient. The complexity of creating and managing thousands of individual test cases is not feasible within realistic schedule constraints. There is a clear need for a wide range of pre-defined stimulus to ensure that you can achieve high coverage against your compliance goals.

Summary
The three major elements needed for an ACE verification solution are:

* Stimulus: Constrained random stimulus is required to mimic all possible scenarios
* Checks: Each interface requires complete protocol compliance checking; system coherency checks at the interconnect level are also necessary
* Coverage: Both a coverage map and verification plan (used to measure and ensure completeness) are required; pre-defined stimulus to achieve high coverage without test writing is essential.

To meet your ACE verification needs, Cadence now provides a complete verification solution for ACE-based designs. The Cadence solution comprises three products:

1. ACE Verification IP (VIP). This provides constrained random stimulus, coverage, and protocol compliance checks. It supports the leading simulators, all methodologies (UVM, VMM), and the leading verification languages (SystemVerilog, e )

2. Interconnect Monitor (ICM): This checks data integrity between all the ports on the interconnect. It’s extendable and customizable to enable design-specific checking such as support for all bus-oriented protocols (ACE, AXI, AHB, APB, OCP).

3. Compliance Management System (CMS): This provides two key functional capabilities.

The first is an ACE-specific verification plan (vPlan). The vPlan, an executable document, maps the necessary coverage and checks directly to the ACE specification. Second, it provides an extensive compliance test suite that yields a high level of functional coverage—typically in excess of 90% for an ACE master.

Both the vPlan and the compliance test suite are organized modularly. This enables parts of the specification not in use to be excluded, allowing you to focus on the greatest risk areas.

Based on best practices and experiences with leading ARM Cortex-A15 users, we recommend that all three elements of the ACE verification solution ACE verification solutionbe incorporated in order for ACE-based designs to achieve the highest verification productivity and design quality.

Mirit Fromovich, Verification IP Solutions Architect, leads the Cadence VIP product line for AMBA protocols. She is an expert in advanced verification techniques and technologies, having worked in the field for more than 10 years. Mirit holds a BSC in Software Engineering and Mathematics from the Bar-Ilan Institute of Technology.

Pete Heller is Senior Product Line Marketing Manager for VIP and Interconnect at Cadence. With more than 15 years of industry experience, he has played a key role in the growth of the Cadence VIP business. Pete holds both a BA in Computer Science as well as an MBA from Indiana University’s Kelley Graduate School of Business.

Yoav Lurie is a member of the Cadence VIP development team, where he works on the Interconnect Monitor and AMBA VIP. He is an expert in interconnect verification and advanced verification methodology. Yoav holds a BSC in Computer Science from the Hebrew University.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.