VIP Central

 

AMBA AXI Exclusive Access De-mystified

AMBA AXI exclusive access may look simple at first glance, but as we delve deeper into it, we find the different flavors of exclusive access. The possibility of these different scenarios and combinations poses a tough challenge in verifying the critical feature in AMBA-based designs. This blog primarily focusses on exclusive access in AMBA AXI3, the concept, its different flavors and how Synopsys VIP can be leveraged to overcome the corresponding verification challenges.

Exclusive Access – The Concept

Simply put Exclusive accesses are a sequence of read transactions followed by write transactions to the same address range. Successful exclusive accesses receive an EXOKAY response. All other accesses, including exclusive fail accesses, receive an OKAY response.

The exclusive access mechanism enables the implementation of semaphore type operations without requiring the bus to remain locked to a particular master for the duration of the operation. The advantage of exclusive access is that semaphore type operations do not impact either the critical bus access latency or the maximum achievable bandwidth.

The fact that the delay between the Exclusive read and write parts of the Exclusive sequence is undefined and a master may not complete the write portion of an exclusive operation gives different flavors to the Exclusive access operation. However, Exclusive sequences must always start with an exclusive read operation, and then assuming the read returns a successful EXOKAY response the master can then complete the exclusive sequence with the exclusive write.

The exclusive write access of the master is signaled as successful if no other master has written to that location between the read and write accesses, failed if another master has written to that location between the read and write accesses. In this case the address location is not updated.

AXI3 Exclusive Access
AXI3 Exclusive Access

 

System Level Perspective

Exclusive Access plays a critical role where more than one masters are trying to access the same memory in a system. In technical jargon, such type of memory is called a shared memory. A system designer will always try to ensure that at a given point of time one master does not overwrite the memory written by another master.

Let us assume that there are 2 AXI Masters in a system sharing the same memory of an AXI Slave (S1) which supports Exclusive access. AXI Master 1 (M1) initiates exclusive read transaction for address location 16’h1000 to 16’h100F. Slave will start monitoring these addresses for ARID given by M1 until either a write occurs to that location or until another exclusive read with the same ARID value resets the monitor to a different address.

In case master M2 writes to the same address location before M1 could complete its exclusive write, the slave will give indication of exclusive access failure during the exclusive write transaction by M1 and does not allow M1 to update the memory location.

In the above scenario, slave reserves some memory resource for M1 virtually as indicated by the Exclusive read request from M1. When M1 attempts a write to this memory location, slave will allow to write that memory resource only if another master device is not using that memory resource otherwise data is not written to memory resource. This way we can avoid memory overwrite problem for shared memory using Exclusive Access in AXI.

Different flavors of Exclusive Access

There can be different flavors of Exclusive access operation which poses a verification challenge for the AMBA-based designs. Some of these tricky scenarios are highlighted below:

  • An Exclusive Read can be followed by Normal Read or Write operation.
  • A master might not complete the write portion of an exclusive operation.
  • An Exclusive Read can follow an Exclusive Read with same ARID value as previous exclusive read and reset the monitor to a different address location.
  • There can be two Exclusive Reads monitoring the same address region.
  • An exclusive read/write to a slave which does not support Exclusive access.

Creating these scenarios accurately is extremely time-consuming and challenging, requiring deep protocol and methodology expertise. Verifying these scenarios is a challenge as the AXI protocol does not specifically goes into the details of the expected behavior in such cases. Synopsys VIP and Test suite for ARM AMBA AXI can be leveraged here to overcome the verification challenge.

Synopsys VC Verification IP (VIP) for ARM® AMBA® AXI™ provides complete protocol support, encapsulates System and Port level protocol checks, System Verilog source code test-suites, which include system-level coverage for accelerated verification closure.

To know more about our VIPs and test suites please visit http://synopsys.com/vip.

Authored by Viral Sharma.

Recent AMBA Blogs

Debug of AMBA AXI Outstanding Transactions

Synopsys AMBA 5 AHB5 Verification IP: What’s It All About?

ARM TechCon: Optimize SoC Performance with Synopsys Verification IP and Verdi Unified Debug

AMBA System Monitor, Scoreboarding and Beyond

AMBA: Stitch it all up to ACE your Test