Get control of ARM system cache coherency with ACE verification

Mirit Fromovich, Pete Heller, and Yoav Lurie, Cadence

August 9, 2011

Mirit Fromovich, Pete Heller, and Yoav Lurie, Cadence

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.