AMBA: Stitch it all up to ACE your Test
The ARM® AMBA4® specification for the connection and management of functional blocks in a system-on-chip (SoC) now features Advanced eXtensible Interface (AXI)™ coherency extensions (ACE)™ in support of multi-core computing. The ACE specification enables system-level cache coherency across clusters of multi-core processors. When planning the functional verification of such a system, these coherency extensions bring their own complex challenges, such as system-level cache coherency validation and cache state transition validation. At any given time, it’s important to verify that the ACE interconnect can maintain cache coherency across the different ACE masters in the system. With coherency support now in the hardware, together with an associated support protocol, the complexity of the system and the underlying components has increased substantially. The verification of such systems thus faces several challenges. Let’s get a grasp of the requirements on the stimulus generation infrastructure for validating a cache coherent system.
Here’s where you can find more information on our Verification IP.
An AMBA ACE interconnect-based system can have a variety of masters and slaves connected by a coherent interconnect. Individually, each master and slave component can support a complete ACE, ACE-Lite™, AXI4™ or AXI3™ protocol and can work with a different bus widths or clock frequencies. The different permutations involve the following parameters: cache states, transaction types, burst lengths and sizes, snoop mechanisms, snooped cache states, snoop responses, support for speculative fetches, support for snoop filtering, and user-specified scheduling of interconnect.
All these cross combinations lead to a very large verification space, creating four key challenges:
- Generating stimulus mapped to all of these include, ensuring each individual master, slave or interconnect is fully compatible with the protocol it supports;
- Ensuring all possible combinations of concurrent access among initiating masters, snooped masters and slave main memory are verified and are in compliance with the ACE specification;
- Ensuring all user-specific features are covered and working as expected; and
- Ensuring the completeness of verification
How do you go about creating a stimulus generation infrastructure that can handle all these?
Here we try to show you how it can be done? The idea is to ensure you have all the right building blocks to start with and progressively organize them and stitch them together to get to what you need.
Credits: http://www.geekalerts.com/lego-tonka-heavy-assault-truck/
What we do in our VC Verification IP (VIP) is something very similar: we start with some tried and tested native SystemVerilog UVM atomic sequences and progressively move toward creating complicated ones. Given the functionality that UVM provides, it is much more convenient to stitch together low-level, proven or validated scenarios to create more complex ones. Instead of creating a flattened implementation in the sequence body, hierarchical or nested sequences can be created to leverage the basic sequences which have been created earlier. This can go up to multiple levels of hierarchy and thus it becomes possible to converge towards meeting the requirements of the most complex scenarios.
As the complexity increases across multiple ACE components, there might be a requirement to coordinate the sequences across multiple sequencers and drivers. These are achieved through virtual sequences and sequencers. The other important functionality from a stimulus generation perspective is the grouping of sequences and the creation of hierarchical sequences. In UVM, similar sequences can be grouped together into a sequence library. Using the UVM base classes, you can create the library infrastructure which would allow any sequence to be registered to the sequence library through the library APIs. Once the library is picked in the simulation, the default functionality causes a random number of sequences to be picked up and executed. Thus, the sequence library which ships with the AXI VIP can be used can be used as a starting point for meeting the user’s requirements.
The default mode of sequence library can be modified by changing the parameters of the associated configuration class. Thus, one can enable a specific number of sequences to be picked up, enable random cyclic sequences, as well as program a user-defined sequence execution.
Creating custom rules for the sequence library would help not only to streamline multiple sequences in different simulations but also to avoid redundancy and move progressively toward convergence of all interesting system-level scenarios. Hence, without having to write multiple tests, I can create custom-defined sequence execution across multiple sequence libraries, across different interfaces, through a virtual sequencer, resulting in a stimulus management setup that helps meet all the stimulus generation requirements much faster. In some of the scenarios, the sequences have to be aware of the functional configuration to enable reconfiguration based on the system-level requirements. VC VIP leverages most of the functionality provided by the UVM Resource Mechanism to provide the configurability and the sophisticated stimulus generation requirements in the ACE context. The configurability enabled through the Resource Mechanism is a very interesting topic in itself, and I can talk about it in a subsequent post.
Here I have an example which shows how to create custom sequence generation requirement using the sequence collection. Let us take the case where we need to verify all the cacheline states associated with a Readclean transaction. (“ReadClean is a read transaction which is used in a region of memory that is shareable with other masters. A ReadClean transaction is guaranteed not to pass responsibility for updating main memory to the initiating master. Typically a ReadClean transaction is used by a master that wants to obtain a clean copy of a cache line, such as a master with a write-through cache.”) So, what how do you initiate such a transaction?
A ReadClean transaction would require a cache line initialization followed by cache line invalidation, then a basic Readclean. Lets see what you have as building blocks. First, you take the ‘cache line initialization’ sequence which initializes the cache line states of a master’s cache and its peer’s caches to a set of random but valid states. This ensures that all the different cache line state transitions for a coherent transaction initiated by a master are verified. This would require a sequence which would write into the initiating masters local cache. Data is now dirty in local cache. This would be followed by another master initiating a ‘write’ into memory. Data is now clean in local cache and the data in cache matches the data in memory. This is followed by a ‘BasicReadShared’ which will read data into per master’s local cache by getting clean data from the initiating Master. Then you would need a sequence that invalidates cache lines of a master. This would be your cache line invalidation sequence. This may be required for non-speculative load transactions. Finally , you need to have a basic Readclean sequence:
A complete verification scenario can be mimicked using the nested sequences and virtual sequences. With the hierarchical approach, it becomes relatively easy to model any scenario generation requirements regardless of how complicated they are. This approach when combined with the virtual sequences helps to leverage this functionality across multiple interfaces and is highly relevant in the system context as shown above. Thus, multiple virtual sequences that are part of the library can perform a combination of different sequential coherent transactions from different masters to the same slave or different slaves.
As the complexity of protocols continues to increase and evolve, the infrastructure required for their verification needs to scale up in sophistication as well. Advanced Methodologies such as UVM have been continually evolving to keep up with the many complex requirements. Verification of basic cache coherent systems is in itself challenging. The additional complexity that the ACE protocol brings demands a lot from the verification methodology used. The functionality provided with the UVM library with respect to sequence generation, distributed phasing and configuration management as well as the recent updates (available through the UVM-1.2 library) can enables VIP implementations to leverage these to meet the verification requirements in different systems.
Authored by Amit Sharma
Here’s where you can find more information on our Verification IP.
