A Strategy to Verify an AXI/ACE Compliant Interconnect (2 of 4)

In the last post of this series, we focused on the first level of testing required for verifying an AXI/ACE Compliant Interconnect — Integration/Connectivity testing. In this post, we will focus on basic coherent transaction testing. We use the term basic to signify something that is a prerequisite before we move on to more advanced testing. Coherent transactions are a set of transactions used in the AXI/ACE protocol to perform load and store operations. Each of these transactions have a different set of response requirements from the Interconnect. Further, each of these transactions can be used in multiple configurations. We need to verify that the Interconnect works correctly for each of these transaction types. We will first give an overview of the protocol before moving on to a testing strategy for these.

Here’s where you can find more information on Verification IP for AMBA 4 AXI.

Overview of the ACE Protocol

The ACE protocol provides a framework for system level coherency. It enables correctness to be maintained when sharing data across caches. It also enables maximum reuse of cached data. The protocol is designed to support different coherency protocols such as MESI, ESI, MEI and MOESI (where M stands for Modified, O for Owned, E for Exclusive, S for Shared and I for Invalid). The ACE protocol is realized using:

• A five state cache model to define the state of any cache line in the coherent system as shown in the diagram below:

The defined states are:

–        Valid, Invalid: When invalid, the cacheline does not exist. When valid, the cacheline is present in the cache.

–        Unique, Shared: When unique, the cache line exists only in one cache. When shared, the cacheline might exist in more than one cache.

–        Clean, Dirty: When clean, the cache does not have responsibility to update main memory. When dirty, the cache line has been modified with respect to main memory and this cache must ensure that main memory is eventually updated.

• Additional signaling on existing AXI4 channels that enables new transactions and information to be transmitted.
• Additional channels, know as snoop channels, that enables an Interconnect to access information that is stored in the cache of masters connected to it.

We will shed more light on the ACE protocol with an example of a load operation and a store operation from a shareable location.

Performing a Load Operation

Consider the system given below with two masters connected to an Interconnect. Both masters have a cache. The Interconnect is also connected to the main memory. Consider the scenario where Master 1 needs to read the value stored in a variable u. Also assume that this value is already stored in the cache of Master 2. The following sequence is used to retrieve the value of u:

• Master 1 issues a read transaction on the read address channel (1)
• Interconnect issues a snoop transaction on the snoop address channel of master 2 (2)
• Master 2 returns the snoop response and data information (3a)
• If master 2 did not return data, the Interconnect reads it from main memory (3b). Note that it is permissible for the Interconnect to read from main memory even before receiving a response to the snoop transaction
• Once the data is received it is returned to master 1 through its read data channel (4).

A ReadClean, ReadNotSharedDirty or ReadShared transaction is used for a load operation from a shareable location. A ReadClean transaction is used when an initiating master does not want to accept responsibility to update memory. A ReadNotSharedDirty transction is used when a master wants to load data and can accept the cacheline in any state except the SharedDirty state. A ReadShared transaction is used when a master wants to load data and can accept the cache line in any state. If no cached copy is required, a ReadOnce transaction is used. A ReadNoSnoop is used to read from a nonshareable location.

Performing a Store Operation

In the above system consider that Master 1 wants to write a new value to the variable u. The following sequence is used to store the new value into Master1’s cache:

• Master 1 issues a transaction indicating that it would like a unique copy of the cacheline storing u. This is done by sending a MakeUnique transaction (1).
• The Interconnect sends a snoop transaction to Master 2 to invalidate its cacheline. This is done by sending a MakeInvalid transaction (2).
• Once the invalidation is complete, Master 2 responds on its snoop response channel (3).
• The Interconnect now responds back to master 1 indicating that all other masters have invalidated the cacheline storing value of variable u (4).
• Master 1 now writes the new value of u in its cache. At this point the cacheline is in a unique state for master 1 and this cacheline does not exist in master 2.

Depending on whether a full cacheline store or a partial cacheline store is required, and whether the master already has a copy of the cacheline, a MakeUnique, CleanUnique or ReadUnique transaction is used for a store operation. If the master that is storing does not have a cache, but would like to write into a shareable memory location, a WriteUnique or WriteLineUnique transaction  is used. A WriteNoSnoop transaction is used to write into a nonshareable location.

Other transactions used in ACE

• Memory Update Transactions which are used to write a dirty line into memory. A WriteBack or WriteClean is used for this.
• The Evict transaction is issued by a master to indicate the address of the cacheline being evicted from its local cache.
• Cache maintenance transactions are used to access and maintain caches of other master components in a system. A CleanShared, CleanInvalid or MakeInvalid transaction is used for this.
• Barrier transactions are used to provide guarantees about the ordering and observation of transactions in a system. This is dealt with in detail in a subsequent post.
• Distributed Virtual Memory (DVM) transactions are used for virtual memory system maintenance.

Basic Coherent Transaction Testing

As described above, a number of different transactions are used in ACE to maintain coherency. Since each of these transaction types have different response and coherency requirements, it is good to test each of the transaction types individually to make sure that the Interconnect meets all the specification requirements. We will take the example of ReadShared transaction to describe the verification requirements for these transaction types in general.

Below is a table from the specification showing the cacheline state changes for ReadShared transaction:

In the above table, the Start State refers to the state of the cacheline in the master before the transaction was issued. RRESP refers to the response given by the Interconnect to the master that initiated the transaction. The Expected End State refers to the state of the cacheline after the transaction is complete. The last two columns refer to other possible end states based on whether a snoop filter is present or not, the details of which we will not get into in this post. The second table refers to speculative read. This represents a transaction that was issued even before the master could read the status of the cacheline. Basically, a Read transaction need not be sent out of the master if its cache already has an entry for that address. However, to improve performance, a master might choose to send out a transaction even before it gets information on the status of a cacheline. If the transaction was sent out in such a state, it is represented in the second table.

As seen from the tables above, there is a fairly large verification space for a single transaction. An important aspect to take note of is that the stimulus requires traffic from multiple masters. This is because the state space to be covered demands that all different response types and cache states are tested. The different response types can be created in the system only if the masters have cachelines in certain cacheline states relative to each other. For example, a response type (RRESP) of 10 indicating that the cacheline is shared by another master, requires that the cacheline is present in a master that is snooped by the Interconnect. The figure below summarizes the key requirements for testing this sequence:

• The sequence must initialize the system to a random, but valid state before a transaction of a certain type is initiated. This ensures that all different response types and cacheline states are exercised.
• Initialization must ensure that the rules of the states of cache are adhered too. For example a cacheline can be unique or dirty in only one cache. If a cacheline is present in two masters and both cachelines are clean, then their data should be the same. Similarly, if all the cachelines of a location are clean, then the contents of the cacheline must match that of the memory.
• A sequence must be configuration-aware: it must be aware of the number of masters in the system, the interface types of these masters and so on. Making sequences configuration-aware ensures that the sequences are portable across systems with varying topologies.

Key Verification Points

• Coherency across master caches: at any given point of time all masters must have the same view of data.

• Coherency across master cache and memory: if all cachelines are clean, then the contents of the cacheline must match that of memory.

• Snoop transactions: each transaction initiated by a master has a corresponding snoop transaction that will be initiated by the Interconnect. We need to ensure that the snoop transactions issued by the Interconnect are correct.

• Data integrity between snoop and coherent transactions: if a snoop transaction returns data, the same data must be returned to the master that requested the data through its read data channel.

• Sequencing transactions: transactions that access the same location have specific sequencing requirements by the Interconnect. This will be dealt with in detail in the next post in this series.

In this post, we have described the testing strategy and the key aspects of coherent transaction testing. In the next post, we will focus on some of the details of the specification relative to accesses to overlapping addresses.

Here’s where you can find more information on Verification IP for AMBA 4 AXI.

Authored by Ray Varghese