D E S I G N S T R AT E G I E S A N D M E T H O D O L O G I E S

Designing with the AMBA 3 AXI Protocol

Author: Mick Posner, Product Marketing Manager and Darrin Mossor, Corporate Applications Engineer, Synopsys Inc. Synopsis: 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 AXI protocol for on-chip bus infrastructure, and how it revolutionizes the future of high performance 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 IP necessary to successfully complete design and verification in todays reduced development design cycle.

he 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, predesigned, 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 design 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 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 drivers 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 todays designs. The huge set of complicated verification tasks is driving designers to become smarter about verification, including the tools and techniques they use. Directed testing no longer generates enough coverage in the time allotted, so other approaches are required. AMBA 3 AXI Protocol: A Powerful Evolution The new AMBA 3 AXI (Advanced eXtensible Interface) protocol builds on the many benefits of the AMBA 2 stan-

Information Quarterly

[58]

Volume 4, Number 1, 2005

D E S I G N S T R AT E G I E S A N D M E T H O D O L O G I E S

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
Figure 1: More Re-spins Required Because of Verification Failure

dard by greatly extending the performance and flexibility of the systems based on AMBA technology. Based on the industrys 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 siliconproven 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 its suitability for the next generation of designs. Suitability for high-bandwidth and lowlatency designs

Advantages of the AMBA 3 AXI protocol include: Independently acknowledged address & data channels Out of order completion of bursts Exclusive access (atomic transaction) System level cache support Access security support Feature Comparison: AMBA 2 AHB Protocol Versus AMBA 3 AXI Protocol

AMBA 2 AHB Protocol

Fixed pipeline for address and data transfers Bidirectional link with complex timing relationships Hard to isolate timing Limits frequency of operation Inefficient asynchronous bridges Separate address for every data item Only one transaction at a time Fixed pipeline for address and data Only one transaction at a time Does not natively support the ARM v6 architecture No support for security 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

AMBA 3 AXI Protocol

Five independent channels for R/W, addr/data and response Each channel is unidirectional except for single handshake for return path Register Slices isolate timing Frequency scales with pipelining High performance asynch bridging Burst based one address per burst Multiple outstanding transactions Out of order data Simultaneous reads and writes Native support for Unaligned and exclusive accesses 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 hand-

Information Quarterly

[59]

Volume 4, Number 1, 2005

D E S I G N S T R AT E G I E S A N D M E T H O D O L O G I E S

shake 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

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 mas-

ters 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 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

Figure 2: Cycles for the AMBA 2 AHB Protocol

Figure 3: Cycles for the AMBA 3 AXI Protocol

Information Quarterly

[60]

Volume 4, Number 1, 2005

D E S I G N S T R AT E G I E S A N D M E T H O D O L O G I E S

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 include 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 projects all have to be considered. Of course, the actual transactor will require its own verification environment to ensure some level of accuracy. Finally, this handcrafted 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 Verification IP 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 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 fea-

tures like cross-port coverage and scoreboard notification. The assertion IP can be used as the golden reference and enable the use of formal tools and techniques. Explanation of Layered Verification A layered approach to verification ensures that the testbench is structured in a fashion that simplifies the test code generation, ensures reuse and enables the use of higher levels of verification abstraction. 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

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 transac-

Figure 4: Constrained Random Methodology combined with VIP addresses Time-to-Market Pressures

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.

tion 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 traf-

Layer 1 The goal of layer 1 is to test the physical bus interface and ensure Figure 5: Verification Layers

Information Quarterly

[61]

Volume 4, Number 1, 2005

D E S I G N S T R AT E G I E S A N D M E T H O D O L O G I E S

fic. 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 its 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 designs 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 APIs 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 prod-

uct 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 Figure 6: Bridging from the AMBA 3 AXI protocol to AMBA 2 random verification to generate protocols to enable reuse a huge amount of stimuli from AMBA 2 protocols, such as the offering minimum of testbench code. This simplifrom Synopsys which is delivered as part fies the engineers verification task by of the DesignWare Library. Both making it as easy as possible to meet the Verification IP and Synthesizable IP are defined coverage goals with the minimum included in the royalty-free library. 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 intellectual property (IP) available for reuse. Bridges from the AMBA 3 AXI protocol to the AMBA 2 Protocols are available to enable reuse of existing IP. 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 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 again 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 design 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.

Information Quarterly

[62]

Volume 4, Number 1, 2005