Designing Using the AMBA (TM) 3 AXI (TM) Protocol -- Easing the Design Challenges and Putting the Verification Task on a Fast Track to Success

by Mick Posner, Darrin Mossor from Synopsys

Abstract

The need for higher performance applications is driving the requirement for a new age of on-chip communication infrastructure. Increasing the clock frequency no longer addresses this higher performance requirement, as the bottleneck is inherent in the existing bus infrastructure.

This paper examines the advantages of the new AMBA™ 3 Advanced eXtensible Interface (AXI™) protocol for on-chip bus infrastructure, and how it revolutionizes the future of high-performance system-on-chip (SoC) interconnect. It describes the AMBA 3 AXI protocol feature set that makes it suitable for the new high-performance, low-latency and low-power designs. It also examines the verification tools and intellectual property (IP) necessary to successfully complete design and verification in today’s reduced development design cycle.

The Ever Reducing Development Cycle

As design complexity continues to increase, time-to-market pressures force shorter and shorter design cycles. High-performance designs are technically complex and require vast amounts of verification to ensure correct operation. Interconnect topologies, with multiple address, data, handshaking buses and transaction cycles that complete out of order over many cycles, enable high performance and low latency, but can no longer be verified with the standard directed testing methodologies. These features on their own not only take the verification task to the next level of complexity, but also introduce corner cases that must be captured and tested. Unfortunately these corner cases are typically very hard to identify and, if missed, could mean failure of the resulting design.

Standards and Reuse

One way to reduce the risk and pressures of a new design is through the use of standards and reuse. Today, designers can also choose from a range of open specifications of on-chip interface protocols. Choosing this option facilitates use of proven, pre-designed, pre-verified IP and verification components. With more proven IP in the design and by the deployment of Verification IP (VIP), designers can focus on differentiating their designs rather than verification of the standard based protocol.

Use of existing standard protocol IP and VIP shortens subsystem creation time, as less effort and time is required to build and verify the SoC infrastructure. The use of these standards-based protocols also aids interoperability, as all components will have been designed to the same specification. This dramatically reduces the overall risk associated with the design.

The AMBA 3 protocol family defines a new set of on-chip interface protocols for SoC designs. These are the latest generation protocols, which are interoperable with existing bus technology defined in the AMBA 2 Specification.

The AMBA 3 AXI protocol is an advanced microprocessor system bus interface, which is part of this new protocol family.The AMBA 3 AXI protocol specification is openly available for download from ARM http://www.arm.com/products/solutions/axi_spec.html and is well supported and documented. This open access, coupled with the advanced features that AMBA 3 AXI provides, makes it a good candidate to be the de-facto standard for the next generation of on-chip bus interconnects.

Design Verification Considerations

According to a Collett International study, 70% of project effort for complex ICs is spent on verification. This is even worse when designing to a protocol that you have not implemented before. In addition to design application testing, significant effort is needed to learn the new protocol to make use of the features the protocol brings to the design. Anyone can sit in the driver’s seat of a car, but if you have never learned where the gas pedal is, you are going nowhere. The Collett study also analyzed the main causes of chip re-spins: 70% are due to logic or functional bugs, which mean the classic verification methodologies are not providing the bug finding capabilities required by today’s designs.

The huge set of complicated verification tasks is driving designers to become smarter about verification, which includes choosing the right tools and techniques. Directed testing no longer generates enough coverage in the time allotted, so other approaches are required.

Fig 1: More Re-spins Required Because of Verification Failure

AMBA 3 AXI Protocol: A Powerful Evolution

The new AMBA 3 AXI protocol builds on the many benefits of the AMBA 2 standard by greatly extending the performance and flexibility of the systems based on AMBA technology. Based on the industry’s needs, and created in collaboration with more than 30 companies, the AMBA 3 AXI protocol is available now and addresses the needs of the coming generation of designs.

The AMBA 3 AXI protocol defines a unidirectional channel architecture, which enables the efficient use of register slices to pipeline the connection for higher speeds, or to enable the use of multiple clock domains for low power. The support of multiple outstanding transactions and out-of-order transaction completion, together with the efficient use of the read, write and address/control channels enable systems to achieve levels of performance and efficiency limited only by the capabilities of the peripherals themselves.

One of the key goals of the AMBA 3 AXI protocol is interoperability with the existing AMBA technology. A clear advantage of this interoperability is that designers have access to a wide array of silicon-proven IP and VIP for AMBA protocols, increasing options for reuse and again increasing the time designers spend on design differentiation rather than general subsystem creation and validation.

AMBA 3 AXI Protocol and Features

The AMBA 3 AXI protocol is targeted at high-performance, high-frequency system designs and includes a number of features that make it suitable for a high-speed, submicron interconnect.The AMBA 3 AXI protocol objectives:The AMBA 3 AXI specification was created with the following objectives in mind to ensure it’s suitability for the next generation of designs.

• Suitability for high-bandwidth and low-latency designs
• To enable high-frequency operation without using complex bridges
• Meet the interface requirements of a wide range of components
• Suitability for memory controllers with high initial access latency
• Provide flexibility in the implementation of interconnect architectures
• Easily interface with existing AMBA technology
  

Features of the AMBA 3 AXI protocol include:

• Separate address/control and data phases
• Support for unaligned data transfers using byte strobes
• Burst-based transactions with only start address issued
• Separate read and write data channels to enable low-cost direct memory access (DMA)
• Ability to issue multiple outstanding addresses
• Out-of-order transaction completion
• Easy addition of register stages to provide timing closure
• Protocol includes optional extensions that cover signaling for low-power operation

Advantages of the AMBA 3 AXI protocol include:

• Independently acknowledged address and data channels
• Out-of-order completion of bursts
• Exclusive access (atomic transaction)
• System level cache support
• Access security support
• Unaligned address & byte strobe
• Static burst, which allows bursts to FIFO memory
• Low power mode
  

Feature Comparison: AMBA 2 AHB™ Protocol Versus AMBA 3 AXI Protocol

AMBA 2 AHB Protocol	AMBA 3 AXI Protocol
Fixed pipeline for address and data transfers	Five independent channels for addr/data and response
Bidirectional link with complex timing relationships	Each channel is unidirectional except for single handshake for return path
Hard to isolate timing	Register slices isolate timing
Limits frequency of operation	Frequency scales with pipelining
Inefficient asynchronous bridges	High performance asynch bridging
Separate address for every data item	Burst based—one address per burst
Only one transaction at a time	Multiple outstanding transactions
Fixed pipeline for address and data	Out of order data
Only one transaction at a time	Simultaneous reads and writes
Does not natively support the ARM v6 architecture	Native support for unaligned and exclusive accesses
No support for security	Native security support

AMBA 3 AXI Protocol: Channel Power

The AMBA 3 AXI architecture differs significantly from previous AMBA protocols by the introduction of channels.

Each of the five independent channels consists of a set of information signals and uses a two-way VALID and READY handshake mechanism. The information source uses the VALID signal to show when valid data or control information is available on the channel. The destination uses the READY signal to show when it can accept the data. Both the read data channel and the write data channel also include a LAST signal to indicate when the transfer of the final data item within a transaction takes place.


Read and write transactions each have their own address channel. The appropriate address channel carries all of the required address and control information for a transaction.

The Read data channel conveys both the read data and any read response information from the slave back to the master.

The Read data channel includes the data bus, which can be 8, 16, 32, 64, 128, 256, 512, or 1024 bits wide and a read response indicating the completion status of the read transaction. The Write data channel conveys the write data from the master to the slave.

The Write data channel includes the data bus, which can be 8, 16, 32, 64, 128, 256, 512, or 1024 bits wide, and one byte lane strobe for every eight data bits, which indicates which bytes of the data bus are valid.

Efficiency Comparison: AMBA 2 AHB Protocol Versus AMBA 3 AXI Protocol


Fig 2: Cycles for the AMBA 2 AHB Protocol


Fig 3: Cycles for the AMBA 3 AXI Protocol

AMBA 3 AXI Protocol: Interconnects and Interfaces

The specification provides a single protocol definition for describing interfaces:

• Between a master and the interconnect
• Between a slave and the interconnect
• Between a master and a slave

In most systems, the address channel bandwidth requirement is significantly less than for the data channel. Such systems can achieve a good balance between system performance and interconnect complexity by using a shared address bus with multiple data buses to enable parallel data transfers.

The AMBA 3 AXI protocol enables a variety of different interconnect implementations.

Most systems use one of three interconnect approaches:

• Shared Address and Single Data buses (SASD)
• Shared Address buses and Multiple data buses (SAMD)
• Multi-layer with Multiple Address buses and Multiple Data buses (MAMD)

With SASD, one master and slave can be active per channel. When one master sends an address to one slave, no other master can use the address bus. This is similar to the structure of the AMBA 2 specification.

With SAMD, one master and slave can be active per address channel. Multiple masters and slave pairs can be active on other channels (Read/Write Data and Response channel). For example, if master1 sends write data to slave1, master2 can send write data to slave2 at the same time and does not have to wait for the bus being freed. The number of active pairs is design dependent. Obviously the parallel nature of this operation significantly improves the performance of the subsystem.

With MAMD, multiple pairs can be active on the address channels. This provides the maximum of interconnect flexibility and yields the highest performance subsystem interconnect architecture. This topology is also the most complex scenario to verify as multiple masters and slaves can be active at any time. Verifying the interaction between all ports will be critical to the successful operation of the resulting system.

The details of the implementation of SASD, SAMD and MAMD are design-specific and outside the scope of this paper.

Deployment of a Layered Constrained Random Verification Methodology

Deployment of a layered verification methodology, combined with the use of constrained random verification
techniques, are required to meet the challenge of verifying a subsystem which uses the AMBA 3 AXI protocol. As discussed earlier, a directed testing methodology cannot create enough system stimuli to reach the required coverage goals in the shortened design cycle.

The Synopsys Reference Verification Methodology (RVM) is one example of a reusable layered verification methodology that employs constrained random techniques to achieve full coverage in the shortest possible time and effort. Reuse is another key consideration with verification as well as with IP. The verification methodology must support reuse such that tests at one hierarchical level can me reused at the next level up, as well as with the next project. The structure of RVM enables this.

With a layered verification approach, lower layers like protocol verification are reused at higher levels. Tests written for the lowest levels, protocol validation are reused at the higher levels where the verification focus shifts to generating and verifying transaction sequences that not only stress the bus interface logic but can also target the application-specific logic.

Leveraging Verification IP and Assertion IP

A new interface like the AMBA 3 AXI protocol requires additional verification to ensure that the protocol has been implemented correctly and to ensure that none of the included components violate the protocol standard.
This requires the generation of verified stimuli, responses and some sort of monitor to check that all transactions adhere to the protocol standard. One solution would be to create hand-crafted protocol transactors
to generate the desired stimuli. While this option seems “free” to the engineer, there are of course many frequently overlooked costs of taking this approach. Example costs that have to be considered include the time it takes to create this transactor, ensuring adherence to the protocol, supporting it throughout the design cycle, and designing it for reuse in subsequent projectsl. Of course, the actual transactor will require its own verification environment to ensure some level of accuracy. Finally, this hand-crafted verification block will need to support a layered methodology with the generation of constrained random transactions if it is really going to help with the verification task.

A better approach to take is to use VIP from a reliable vendor, like Synopsys, who has done the hard work to verify the accuracy of the generated protocol and implemented the required interfaces to enable the use of the layered methodology with constrained random transaction generation. The Synopsys DesignWare® master and slave VIP for the AMBA 3 AXI protocol can be used to generate and respond to transactions stressing the interconnection of design blocks. The Synopsys monitor for the AMBA 3 AXI protocol is used to verify the bus protocol, generate bus coverage and cross port coverage information and has the required hooks to support a self-checking scoreboard-based testbench.

Assertion IP should also be included at this stage to enable the use of formal and semi-formal verification tools, like the Synopsys Magellan™ tool, to further speed up the verification task. Both the VIP and the assertion IP should be included in the verification environment. The VIP provides the advanced simulation features like cross-port coverage and scoreboard notification. The assertion IP can be used as the golden reference and enables the use of formal tools and techniques.


Fig 4: Constrained Random Methodology Combined with VIP Addresses Time-to-Market Pressures

Explanation of Layered Verification

A layered approach to verification ensures that testbench code is structured in a reusable layered fashion. The layered approach is applied to individual block-level verification as well as at the subsystem and full system
level. Each layer of tests builds on top of each other, so moving from layer to layer requires minimal effort. Each layer of tests is portable so it can be reused at a subsequent layer or within a new verification project.

There are fundamentally three layers: The layer 1 tests target interface protocol verification while layers 2 and 3 target application-specific logic verification using realistic data traffic generation which stresses the subsystem more completely.



Fig 5: Verification Layers

Layer 1

The goal of layer 1 is to test the physical bus interface and ensure that it does not violate bus protocols. The interface must adhere to the defined interface, the AMBA 3 AXI protocol in this case. The layer 1 tests are a set of tasks that check to ensure that all of the busses’ different cycles can be correctly executed. Individual tests are created to exercise specific areas of the busses’ protocol. Once all basic transactions have been covered, layer 2 tests can begin. The Synopsys master and slave VIP can be used to generate the bus testing cycles while the monitor can be used to check the interface protocol while automatically collecting transaction coverage data.

Layer 2

The goal of layer 2 is to generate transaction sequence tests that not only stress the bus interface logic, but also target the application-specific logic. Layer 2 tests are structured to generate realistic design traffic. To fully achieve the layer 2 goals, constrained random techniques must be applied to the verification environment.

One of the benefits of using a constrained random approach to achieve the layer 2 goals is that it’s easy to achieve the first tests. With a couple of simple bus functional commands, you can generate correct bus cycles.
The Synopsys RVM provides the infrastructure to generate these constrained random transactions with ease and enable reuse at each subsequent layer and reuse across projects. High bus cycle and functional coverage are achieved very quickly and more corner cases will be found. The coverage statistics will be far more complete than what could be achieved using directed tests only. This constrained random environment is able to generate huge amounts of stimuli from a minimum of testbench code. As it is constrained to the design requirements, simulation cycles are not wasted by inadvertently activating unnecessary sections of the subsystem. The constrained random traffic will stress the design block under verification far more than directed tests can. The real representation of the traffic also thoroughly tests the blocks’ application-specific logic in a manner much closer to how the physical silicon will act.


A fully constrained random environment is defined as a set of transactions with a layer of sequences above that, then a layer of choices sitting above with the final layer being the transaction constraints. The payload is fed into the system, which creates an autonomous stimuli generator. Individual transactions are joined together to create a sequence. Sets of sequences are joined together to create a choice. Sets of choices will produce a wide variety of transaction cycles and responses.

Layer 3: Application Specific Tests

Tests at layer 3 are used to raise the overall confidence in the design’s stability. Full sign-off scenarios are run, which include system and application boot sequences. The software-to-software interfaces can be checked at this level. The final application API’s and drivers are tested and a more focused performance trial can be executed. Now, a full context validation can be achieved. The layer 3 tests target the higher-level functions of either the individual block or system. Testing at layer 3 typically uncovers bugs that traditionally have only been uncovered when the final product was already available in the lab.

At all levels constrained random transaction generation becomes critical, because with just a few bus functional commands, thousands of bus cycles can be generated and functional coverage can be achieved quickly. This enables more verification to be done in less time (and with less effort), freeing up the engineer to spend more time on application verification which is the differentiated portion of the design. Constrained random transaction generation also hits corner cases that may have been missed during the classic directed testing methodology.

The Synopsys RVM with Synopsys DesignWare VIP enables designs to use the layered approach and constrained random verification to generate a huge amount of stimuli from a minimum of testbench code. This simplifies the engineer’s verification task by making it as easy as possible to meet the defined coverage goals with the minimum of test code creation.

Leveraging Existing IP

One of the advantages of the AMBA 3 AXI protocol is that it can support existing subsystems which use AMBA 2 protocols. In the embedded core market, the most widely-adopted on-chip bus is the AMBA 2 AHB protocol.

Backward compatibility with AMBA 2 protocols is a major feature of the AMBA 3 AXI protocol, making a wide variety of IP available for reuse.

Bridges from the AMBA 3 AXI protocol to the AMBA 2 Protocols are available to enable reuse of existing IP.



Fig 6: Bridging from the AMBA 3 AXI Protocol to AMBA 2 Protocols to Enable Reuse


This simple bridging enables existing IP and subsystems to be reused, which will help shorten the design cycle even more as interface redesign is not required. Even whole subsystems can be reused by taking advantage of the efficient memory interface that the AMBA 3 AXI protocol enables.

There is an enormous existing base of IP components and tools available for the AMBA 2 protocols, such as the offering from Synopsys which is delivered as part of the DesignWare Library. Both Verification IP and Synthesizable IP are included in the royalty-free library.

Some of the existing Synopsys DesignWare IP based on AMBA 2 technology includes:

• DMA Controller
• Interrupt Controller
• Remap and Pause
• Memory Controller
• General Purpose I/O
• Real Time Clock
• UART, Timer
• Fabric for AMBA 2 protocols
• Watchdog Timers
• Protocol Bridges
• I2C, SSI, and many more

Verification IP that supports the RVM layered methodology and constrained random verification techniques is also available from Synopsys for the AMBA 2 protocols.

Reusing subsystems based on AMBA 2 technology and IP with AMBA 3 AXI protocol interfaces eases the transition to the new specification. As the legacy IP blocks have been pre-verified, more time can be spent on design and verification of the new subsystem components and application.

Summary

The AMBA 3 AXI protocol is a well supported interface with very powerful features to address the needs of next-generation designs. Coupling the power of this new protocol with the ability to utilize existing design and verification IP provides a wide ranging set of design options. Powerful verification IP, tools and methodologies
like RVM available from Synopsys and the Synopsys DesignWare Library further allow designers to focus on the portions of their designs that are unique and differentiated. These tools and methodologies add significant value and reduce the overall design cycle when designing the next generation of products using AMBA technology.