Paper on AXI

8/2/2019 Paper on AXI

http://slidepdf.com/reader/full/paper-on-axi 1/5

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

Volume 4, Number 1, 2005Information Quarterly [58]

Designing with the

AMBA™

3 AXI™

ProtocolT

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 verif ication in today’s reduced development design cycle.

he Re duc i ng De ve l opm e nt Cyc l e

As design complexity continues to

increase, time-to-market pressures force

shorter an d sh orter design cycles. High

performa nce designs a re techn ica lly com-

plex a nd requ ire va st am oun ts of verifica-

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

formance and low latency, but can no

longer be verified with the standa rd direct-

ed testing methodologies. These features

on th eir own not on ly 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 a nd, if missed, could m ean failure

of the resulting design.

Stan dar ds an d Re use

One way to reduce the risk and pressuresof a n ew design is through th e use of stan-

dards and reuse. Today, designers can also

choose from a ran ge 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), design ers can focus

on differentiating th eir design rath er tha n

verification of the standard based proto-

col.

Use of existing standard protocol IP and

VIP shortens subsystem creation time, as

less effort a nd time is required to build a nd

verify the SoC infrastructure. The use of

these standards-based protocols also aids

interoperability, as all components will

ha ve been designed to th e sam e specifica-

tion. This dra ma tically reduces the overall

risk associated with the design.

The AMBA 3 protocol fam ily defines a n ew

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 a vailable for download from ARM

and is well supported and documented.This open access, coupled with the

advanced features that AMBA 3 AXI pro-

vides, ma kes it a good can didate to be the

de-facto standard for the next generation

of on-chip bus interconnects.

Design Veri f icat ion Considerations

According to a Collett International study,

70% of pro ject effort for com plex ICs is

spent on verification. This is even worse

when designing to a protocol that you

ha ve not implemen ted before. In ad dition

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 th e

driver’s sea t of a ca r, bu t if you h a ve never

learned where the gas pedal is, you are

going nowhere. The Collett study also

an alyzed the ma in cau ses of chip re-spins

70% are due to logic or functional bugs,

which mean the classic verification

methodologies are not providing the bug

find ing ca pa bilities required by toda y’s

designs.

The huge set of complicated verification

tasks is driving designers to become

smarter about verification, including the

tools a n d techn iques th ey use. Directed

testing n o longer generates enou gh cover-

age in the time allotted, so other

approaches are required.

AMBA 3 AXI Protoco l : A Pow erful

Evolution

The new AMBA 3 AXI (Advanced

eXtensible Interface) protocol builds on

the many benefits of the AMBA 2 stan-



Feat ures of t he AMBA 3 AXI prot ocol

include:

• Separate a ddress/control and da ta

phases

• Support for una ligned data transfers

using byte strobes

• Burst-ba sed tran sactions with only start

a ddress issued

• Separate read an d write data cha nnels

to en a ble low-cost Direct Mem ory Access

(DMA)

• Ability to issue multiple outstan ding

addresses

• Out-of-order tran saction completion

• Ea sy addition of register stages to

provide timing closure

• Protocol includes optiona l extensions

that cover signaling for low-power

operation

Advantages of the AMBA 3 AXI proto-

col include:• Independently a cknowledged address &

data chan nels

• Out of order comp letion of bursts

• Exclusive access (atom ic tran saction)

• System level cache support

• Access security support

Fe atur e Com pa r ison:

AMBA 2 AHB™ Protocol Versus

AMBA 3 AXI Protocol

AMBA 3 AXI Protoco l : Cha nn el

P o w e r

The AMBA 3 AXI a rchitectu re differs sig-

nificantly from previous AMBA protocols

by the introduction of cha nn els.

Each of the five independent channels

consists of a set of informa tion signa ls an d

uses a two-wa y VALID an d READY h a n d-

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


dard by greatly extending the perform-

ance and flexibility of the systems based

on AMBA technology. Based on the indus-

try’s needs, and created in collaboration

with more than 30 companies, the AMBA

3 AXI protocol is available now and

a ddresses the n eeds of the coming gen era-

tion of designs.

The AMBA 3 AXI protocol defines a un idi-

rectional channel architecture, which

ena bles 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 an d address/control cha nn els ena ble

systems to achieve levels of performance

a nd efficiency lim ited only by the ca pa bil-

ities of the peripherals themselves.

One of the key goals of the AMBA 3 AXI

protocol is interoperability with the exist-

ing 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 Proto col a nd

Features

The AMBA 3 AXI protocol is targeted at

high-perform an ce, h igh-frequency system

designs an d includes a n um ber of featu res

that make it suitable for a high-speed,

subm icron interconn ect.

The AMBA 3 AXI prot ocol objectives:

The AMBA 3 AXI specificat ion wa s created

with the following objectives in mind to

ensure it’s suitability for the next genera-

tion of designs.

• Suita bility for high-ba ndwidth a nd low-

laten cy designs

• To en ab le high -frequency opera tion

without using comp lex bridges

• Meet the in terfa ce requiremen ts of a

wide range of components

• Suitability for memory controllers with

high initial a ccess latency

• Provide flexibility in the implem enta tion

of interconnect a rchitectures

• Ea sily in terface with existing AMBA

technology

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

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

AMBA 3 AXI Protocol

Five independent channels for R/W, addr/data

and responseEach 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





shake mechanism. The information

source u ses th e VALID sign a l to show

when valid data or control information is

available on the channel. The destination

uses the READY signa l to sh ow when it can

accept the data . Both the read data cha n-

nel 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 appropri-

ate address channel carries all of the

required address and control information

for a transaction.

The Read data channel conveys both the

read data an d an y read response informa -

tion from the slave ba ck to the ma ster.

The Read data chan nel includes the databus, which can be 8, 16, 32, 64, 128, 256,

512, or 1024 bits wide an d a read response

indicating the completion status of the

read tra nsaction.

The Write data cha nn el conveys the write

da ta from the ma ster to the slave. The

Write data chan nel 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 d a ta bits, which in di-

cates which b ytes of the da ta bus a re valid.

Eff i c i enc y Com pa r ison:AMBA 2 AHB Proto co l Versus

AMBA 3 AXI Protocol

AMBA 3 AXI Protocol:

Inte rc onn e c ts and Inte r fac e s

The specification provides a single proto-

col definition for describing in terfaces:

• Between a master and the interconnect

• Between a slave and the interconnect

• Between a m aster and a slave

In most systems, the address channel

bandwidth requirement is significantly

less than for the data channel. Such sys-

tems can achieve a good balance between

system performance and interconnect

complexity by using a shared address bus

with m ultiple data buses to enable para l-

lel data tran sfers.

The AMBA 3 AXI protocol enables a vari-

ety of different interconnect implementa-

tions.

Most systems use one of three intercon n ectapproaches:

• Sha red Address a nd Single Data buses

(SASD)

• Sha red Address buses an d Multiple data

buses (SAMD)

• Multi-layer with Multiple Address buses

a nd 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 m aster an d sla ve ca n be

active per address cha nn el. Multiple ma s-

ters an d slave pa irs can be active on oth er

channels (Read/Write Data and Response

cha nn el). For exa m ple, if m aster1 sends

write data to slave1, master2 can send

write data to slave2 at the sam e time a nd

does not h ave to wa it for bus being freed

The number of active pairs is design

dependent. Obviously the parallel nature

of this operation significantly improves

the performa nce of the subsystem.

With MAMD, mu ltiple pa irs can be a ctive

on the a ddress cha nn els. 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 a ny tim e. Verifying th e interac-

tion between a ll ports will be critical to th e

successful operation of the resulting sys-

tem.

The details of the implementation of

SASD, SAMD an d MAMD a re design -spe-

cific and outside the scope of this paper.

De pl oym e nt o f a Laye r e d

Cons tr a i ne d Random Ve r if i c at i on

M e t h o d o l o g y

Deployment of a layered verification

methodology combined with the use of

constrained random verification tech-

niques are required to meet the challenge

of verifying a subsystem which uses the

AMBA 3 AXI protocol. As discussed ea rlier,

a directed testing m ethodology ca nn ot cre-

ate enough system stimuli to reach the

required coverage goals in the shortened

design cycle.

The Synopsys Reference Verification

Metho dology (RVM) is on e exa m ple of a

reusable la yered verification m ethodology

that employs constrained random tech-

niques to achieve full coverage in the

shortest possible time and effort. Reuse is

another key consideration with verifica-

tion as well as with IP. The verification

methodology must support reuse such

that tests at one hierarchical level can mereused at th e nex t level up, a s well as with

the next project. The structure of RVM

ena bles this.

With a layered verification approach,

lower layers like protocol verification are

reused a t h igher levels. Tests written for th e

lowest levels, protocol validation are

reused at the higher levels where the veri-

fication focus shifts to generating and ver-

ifying tran saction sequences tha t not on ly

Figure 2: Cycles for the AMBA 2 AHB Protocol

Figure 3: Cycles for the AMBA 3 AXI Protocol





stress the bus interface logic but can also

target the application-specific logic.

Le ve r agi ng Ve r if i c at i on IP an d

Assertion IP

A new interface like the AMBA 3 AXI pro-

tocol requires additional verification to

ensure that the protocol has been imple-

men ted correctly and to ensure that n one

of the included components violate the

protocol stan da rd. This requires the gener-

ation of verified stimuli, responses and

some sort of monitor to check that all

transactions adhere to the protocol stan-

dard. One solution would be to create

hand-crafted protocol transactors to gen-

erate 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 ta kes to create this tran sac-

tor, 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 environm ent to ensure

some level of accuracy. Finally, this hand-

crafted verification block will need to sup-

port a layered methodology with the gen-

eration of constrained random transac-

tions if it is really going to help with the

verification task.

A better approach to take is to use

Verification IP from a reliable ven dor, likeSynopsys, who h as don e the h ard work to

verify the accuracy of the gen erated proto-

col and implemented the required inter-

faces to enable the use of the layered

methodology with constrained random

transaction generation. The Synopsys

DesignWare® m a ster a nd slave VIP for the

AMBA 3 AXI protocol can be u sed to gen -

erate a nd respond to tran sactions 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 a nd cross port cov-

erage information and has the requiredhooks to support self checking scoreboard

ba sed testbench.

Assertion IP shou ld also be included a t 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 includ-

ed in the verification environment. The

VIP provides the a dvan ced simu lation fea-

tures like cross-port coverage and score-

boa rd notification. The a ssertion IP can be

used as the golden reference and enable

the u se of forma l tools an d techniques.

Expl an at i on of Laye r e d

Veri f icat ion

A layered a pproa ch to verifica tion en sures

that the testbench is structured in a fash-

ion that simplifies the test code genera-

tion, ensures reuse and enables the use of

higher levels of verification abstraction.

The layered approach is applied to indi-

vidua l block-level verification a s well as a t

the subsystem and full system level. Each

layer of tests bu ilds on top of each oth er, so

m oving from layer to layer requires m ini-

m a l effort. Ea ch la yer of tests is porta ble so

it can be reused at a subsequent layer or

within a new verification project.

There a re fun da m enta lly three layers: The

layer 1 tests target

interface protocol veri-

fication while layers 2

and 3 target applica-tion-specific logic veri-

fication using realistic

data traffic generation

which stresses the sub-

system m ore complete-

ly.

Layer 1

The goa l of la yer 1 is to

test the physical bus

interface and ensure

that it does not violate bus protocols. The

interface m ust adh ere to the defined in ter-

face, th e AMBA 3 AXI protocol in th is ca se.

The layer 1 tests are a set of tasks that

check to ensure that all of the busses’ dif-

ferent cycles can be correctly executed.

Individua l tests a re created to ex ercise spe-

cific area s of the busses’ protocol. Once all

basic transactions have been covered,

layer 2 tests can begin. The Synopsys mas-

ter 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 goa l of layer 2 is to genera te tran sac-

tion sequence tests tha t n ot only stress the

bus interface logic, but also target the

a pp lica tion-specific logic. La yer 2 tests a re

structured to generate realistic design traf-

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

Figure 5: Verification Layers





fic. To fully ach ieve the la yer 2 goa ls, con -

strained random techniques must be

applied to the verification environment.

One of the benefits of using a constrain ed

random approach to achieve the layer 2

goals is that it’s easy to achieve the first

tests. With a couple of simple bus func-

tional commands, you can generate cor-

rect bus cycles. The Synopsys RVM pro-

vides 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 foun d. The covera ge statistics

will be fa r more complete tha n wha t could

be achieved using directed tests only. This

constrained random environment is able

to generate huge amounts of stimuli from

a m inimu m of testbench code. As it is con-strain ed to the design requirements, sim u-

lation cycles are not wasted by inadver-

tently 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’ applica-

tion-specific logic in a m a nn er m uch clos-

er to how the physical silicon will act.

A fully constrained random environment

is defined as a set of transactions with a

layer of sequen ces a bove tha t, then a layerof choices sitting a bove with th e fina l la yer

being the transaction constraints. The

pa yloa d is fed into th e system, wh ich cre-

ates an autonomous stimuli generator.

Individual transactions are joined togeth-

er to create a sequence. Sets of sequences

are joined together to create a choice. Sets

of choices will produce a wide variety of

tran saction cycles an d responses.

Laye r 3: Appl ica t ion Speci f ic Tests

Tests at layer 3 are used to raise the over-

all confidence in the design ’s stability. Full

sign-off scenarios are run, which includesystem 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 execut-

ed. Now, a full context validation can be

a chieved. The la yer 3 tests target the h igh-

er-level functions of either the individual

block or system. Testing a t layer 3 typ ical-

ly uncovers bugs that traditionally have

only been uncovered when the final prod-

uct was already available in the

lab.

At all levels constrained ran dom

transaction generation becomes

critical, because with just a few

bus functiona l comm an ds, thou-

sands of bus cycles can be gener-

ated 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 differen-

tiated portion of the design.

Constrained ran dom transaction

generation a lso h its corner cases

tha t ma y ha ve been m issed dur-

ing the classic directed testing

methodology.

The Synopsys RVM with

Synopsys DesignWare VIP

enables designs to use the lay-

ered approach and constrained

random verification to generate

a huge amount of stimuli from

minimum of testbench code. This simpli-

fies the engineer’s verification task by

making it as easy as possible to meet the

defined coverage goa ls with th e min imu m

of test code creation.

Leveraging Exist ing IP

On e of th e ad van ta ges of th e AMBA 3 AXIprotocol is tha t it can support existing sub-

systems which use AMBA 2 protocols. In

the em bedded core ma rket, the m ost wide-

ly-adopted on-chip bus is the AMBA 2

AHB protocol.

Ba ckward com pa tibility with AMBA 2 pro-

tocols is a major feature of the AMBA 3

AXI protocol, making a wide variety of

intellectual property (IP) available for

reuse.

Bridges from th e AMBA 3 AXI protocol to

the AMBA 2 Protocols are available toena ble reuse of existing IP. This sim ple

bridging enables existing IP and subsys-

tems to be reused, which will help shorten

the design cycle even more as interface

redesign is not required. Even whole sub-

systems can be reused by taking advan-

tage of the efficient m emory in terfa ce tha t

th e AMBA 3 AXI protocol en a bles.

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 an d Synth esizab le IP a re

included in the royalty-free library.

Reusing subsystems ba sed on AMBA 2

technology and IP with AMBA 3 AXI pro-tocol interfaces ea ses the tra nsition to the

new specification. As the legacy IP blocks

have been pre-verified more time again

can be spent on design a nd verifica tion of

the new subsystem compon ents an d app li-

cation.

S u m m a r y

The AMBA 3 AXI protocol is a well sup-

ported interface with very powerful fea-

tures to address the needs of next genera-

tion designs. Coup ling the power of th is

new protocol with the ability to utilize

existing design and verification IP pro-vides a wide ranging set of design options.

Powerful verification IP, tools an d m etho d-

ologies like RVM a vaila ble from Synop sys

and the Synopsys DesignWare Library fur-

ther allow designers to focus on the por-

tions of their design that are unique and

differentiated. These tools and m ethodolo-

gies add significant value and reduce the

overall design cycle when designing

the next generation of products using

AMBA technology.

Figure 6: Bridging from the AMBA 3 AXI protocol to AMBA 2protocols to enable reuse

Documents

Paper on AXI