The ordering of memory transactions in Arm® AMBA® protocol is a significant requirement, i.e. the sequence of memory updates/accesses must follow a defined ordering as per the specification. Ordering is important for synchronization events by a processor with respect to retiring load/store instructions. AMBA ACE barrier transactions are used for maintaining the memory ordering across a system. The learning curve to understand barrier transactions may become a barrier to verify your design thoroughly. This blog provides insight, making it easier to understand and verify the barrier transactions. The blog will cover different types of barrier transactions, usage, and domain boundaries.
Barrier transactions provides a range of functionality that helps to resolve ordering requirements, including:
— Ordering of load/store instructions
— Completion of load/store instructions across applicable domain
— Context synchronization
Types of Barrier Transactions
There are two type of barrier transactions, memory, and synchronization barriers. As per AMBA ACE specification, the difference between memory and synchronization barriers is best understood by looking at their definitions and their intended usage in terms of inter-processor communication.
Definition of Memory barriers – *If* another master in the appropriate domain observes a transaction issued after the barrier, *then* that master must be able to observe every transaction issued before the barrier.
Definition of Synchronization barriers – When the barrier completes, *every* master in the appropriate domain must be able to observe all transactions issued before the barrier.
The two definitions differ for the fact that, with sync barriers, the completion of the barrier transaction itself guarantees, for the originating master, that *any* other agent in the domain will have observed all transactions issued before. This difference has an impact on the intended usage of the two types of barriers for communication, and the ACE specification clarifies this in Sect. C8.1.
Memory barriers – are used for memory-based communication. In detail, the producer produces the data in memory, issues a memory barrier and then writes to a flag in memory. Any consumer that is constantly polling on the flag, once it observes the modified flag, will also be able to observe the produced data.
Sync barriers – are used for event-based sideband communication. Because the completion of the barrier transaction implies that *every* master in the appropriate domain must be able to observe every transaction issued before the barrier. Once the sync. barrier has completed, the producer can explicitly pinpoint any master in the domain with a sideband signaling mechanism (e.g. event, interrupt) to signal the availability of the produced data.
Verification challenges and solution:
Creating scenarios for verification of barrier transactions accurately is extremely time-consuming and challenging, requiring deep protocol and methodology expertise. Verifying these scenarios is a challenge as the ACE protocol put forward lot of considerations for barrier transactions especially proper ordering of memory updates and its observability. Observation of ordering of Barrier responses and providing flag to observer enhances the complexity.
As depicted in the diagram below, sequence sends a number of pre barrier store transactions based on num_pre_barrier_stores, followed by a barrier pair and a post barrier flag transaction. Considerations and transaction flows on barrier transactions with more in depth focus will be covered in upcoming blogs.
Synopsys VC VIP for ARM® AMBA® ACE™ can be leveraged to overcome the verification challenges, with built-in features to verify barrier transactions including sequences, checks, coverage, and assertions; thoroughly covering well defined corner cases of barrier transactions. In addition, Synopsys VIP for AMBA protocols provide system level checks, and system level coverage.
To learn more about Synopsys VIP and Test Suites, visit http://synopsys.com/vip.
Authored by Aadil Trikha.