In the last post of the series (http://www.vip-central.org/2012/08/a-strategy-to-verify-an-axi-ace-compliant-interconnect%E2%80%93-part-1-of-4/) I focused on the first level of testing required for verifying an AXI ACE Compliant Interconnect. In that post, I focused on Integration/Connectivity testing. In this post I will focus on basic ‘coherent transaction’ testing. I 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. I will first give an overview of the protocol before moving on to a testing strategy for these.
Overview of 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:
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.
I will try to 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 the 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’:
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:
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
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. I will take the example of ReadShared transaction to describe the verification requirements for these transaction types in general. Given 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 the 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 diagram below summarizes the key requirements for a sequence testing this:
Key Verification Points
At any given point of time all masters must have the same view of data.
If all cachelines are clean, then the contents of the cacheline must match that of memory
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
If a snoop transaction returns data, the same data must be returned to the master that requested the data through its read data channel.
Transactions that access the same location have specific sequencing requirements by the Interconnect. This is dealt with in detail in the next post.
In this post I have described the testing strategy and the key aspects of coherent transaction testing. In the next post I will focus on some of the details of the specification relative to accesses to overlapping addresses.
 AMBA AXI and ACE Protocol Specification (http://infocenter.arm.com/help/topic/com.arm.doc.ihi0022-/)
You must be logged in to post a comment.