Atlantic: a high-performance datapath interface for SOPC Designs

by Robert Cottrell, Altera
High Wycombe UK

Abstract

Atlantic is a point-to-point interface protocol for IP cores, to make it easy to assemble System On A Programmable chip (SOPC) designs. It is primarily intended for high performance data path designs, and supports the transfer of a word of data on every clock cycle. The fundamental symbol size can be a byte or any arbitrary number of bits. Where the performance requires it, a number of symbols can be combined into a larger word. It supports continuous streams of data, typical of signal processing applications, and also streams of cells or packets. There is a standard handshake mechanism to enable flow control between cores. The interface is also suitable for connection to a DMA controller to transfer data to and from a host processor. Atlantic has a number of options to cover a wide variety of cores. Ancillary functions can be created to enable different flavours of Atlantic interface to be connected. Atlantic is being used by Altera on a wide variety of cores, and support for it will be included on tools for building SOPC designs.

Introduction

Atlantic provides a consistent interface for the transfer of data between IP cores in an SOPC solution. It is suitable for a wide range of cores, including digital signal processing (DSP) and telecommunications functions. It supports streams of data, and also data in blocks, cells and packets. Atlantic is a unidirectional, point-to-point interface; if bi-directional transfer is required, two separate Atlantic interfaces are used. The Atlantic interface can also be used between a core and a DMA Controller, to facilitate the transfer of data between a processor and an IP core.

The use of a consistent interface protocol makes it much easier to assemble SOPC solutions without the incorporation of a lot of unnecessary “glue” logic. This becomes even more important when creating tools for the automatic building of such systems. While it is true that Atlantic has many options, a number of parameterized functions can be developed to go between cores with non-compatible Atlantic interfaces.

Relationship to Other On-Chip Interfaces

Atlantic is not intended to be as a point-to-multipoint or multipoint-to-multipoint interface. This area has already been widely addressed by IP providers such as ARM in their AMBA bus family [1], and by industry bodies such as the Virtual Socket Interface Alliance in their Virtual Component Interconnect specification [2]. Such interfaces are often referred to as on-chip buses, although they are not implemented as 3-state buses on chip. Many existing implementations resemble buses in that only one master can communicate with one slave at a time, but in fact the interfaces are independent of the underlying interconnect technology, which could be a crossbar switch allowing multiple concurrent transfers.

Atlantic differs from these interfaces in that it does not use the concept of addressing to enable a master to select with which slave to communicate. It is concerned with high bandwidth data communication between two blocks.

History

Atlantic began life as an interface between telecommunications IP cores processing cells and packets, such as SDH/Sonet framers, and Utopia [3] interfaces. Indeed, Atlantic can be considered as an on-chip equivalent to POSPHY [4] and Utopia, which address the transfer of cells and packets between chips.

More recently, it has been recognized that the protocol can be extended to make it usable in a wider range of applications, including digital signal processing. Some digital signal processing functions, such as Reed-Solomon error correction, and based on blocks of data that can be treated in a very similar manner to the cells and packets used in telecommunications; other functions simply operate on unstructured streams of data.

Atlantic Applications

Data Flow Designs

Atlantic is primarily intended to transfer data between processing blocks in a data flow pipe. Figure 1 shows an example of such a pipeline in a telecommunications system

Figure 1 Telecom Data Flow Using Atlantic

Bridges 

The use of a standard interface such as Atlantic greatly simplifies the creation of bridges between different, non-compatible interfaces. Figure 2 shows an example of such a system. A company has designed a network layer function such as a switch to communicate over four Sonet lines running at 622 Mbps, each of which uses a single framer device which has a POSPHY Level 2 interface. They want to replace these four chips with a chip that supports four 622 Mbps channels and has a POSPHY Level 3 multi-phy interface. This bridge can easily be implemented in a programmable logic device using a POSPHY level 3 link interface core and four POSPHY level 2 phy interface cores. POSPHY Level 2 PhyCore POSPHY Level 2 PhyCore POSPHY Level 2 PhyCore POSPHY Level 2 PhyCore POSPHY Level 3 LinkCore Atlantic 4-channel SONET Framer Network Layer Function

Figure 2 Using Atlantic to create bridges between non-compatible interfaces

DMA Controller

Although Atlantic is intended for use as a point-to-point interface between cores, it will from time to time be required to transfer data between a processor-based system and a core. This can be done either by creating a bridge between an on-chip interface such as VCI and Atlantic, or by creating a DMA controller with an Atlantic interface. Since there is likely to be a large quantity of data transferred, DMA will often be the preferred option. A parameterized DMA controller with an Atlantic interface, or a multi-channel DMA controller with several Atlantic interfaces, can be used with a variety of different cores. Figure 3 shows a processor-based system with a Viterbi decoder core connected using Atlantic DMA controllers.

Figure 3 Using a Core in a Processor System with an Atlantic DMA Controller

Atlantic Requirements

High Throughput

Atlantic is designed for the transfer of data between IP cores that process that data. Some applications, such as Sonet, have extremely high throughput that is increasing with each generation. Today’s systems require up to 10 Gbps, and 40 Gbps will be in general use in the near future. This makes high throughput a top priority for Atlantic.

The protocol needs to be synchronous, controlled by one edge of a single clock. It must be capable of transferring one word of data on each clock cycle, and must be able to operate on an arbitrarily wide word. The fundamental data symbol in Sonet systems is an octet or byte; typical 10 Gbps data streams will be handled with 128-bit words at a clock rate of 80 to 100 MHz.

The interface protocol needs to be pipelined to ensure that it does not become the critical path in the design. That means that neither side of the interface should have a combinational path from input to output. Deeper pipelining, for example requiring each input and output signal to be directly connected to a flip-flop, is not considered necessary for an on-chip interface such as Atlantic.

Local Control

It is highly desirable that the synchronization of data between two blocks in a data flow is handled by local signaling between the two blocks concerned, rather than by a master controller. The design of such a master controller is error-prone, and it must be re-designed if the pipeline delay through any block in the system changes. The Atlantic interface needs to be capable of handling this control function, including the identification of the boundaries between packets or blocks of data, and handshake for flow control purposes.

Data Packets

Whereas some systems process data as simple streams of fundamental data symbols, many systems are based on data in blocks. Block-based systems include ATM, where data are contained in fixed-sized cells, and Internet Protocol (IP), where data are contained in variable-sized packets. Other example of block-based systems include Reed-Solomon based forward error correction, where data symbols (typically 8-bit bytes) are combined with parity symbols to form codewords, which are blocks typically containing 255 symbols. Atlantic interfaces need to be able to delineate blocks, in order to meet the requirement for local control.

Burst Support

In some cases, it is desirable to transfer data in bursts. For example, a Utopia or POSPHY interface is required to provide its data off-chip in bursts. It is therefore useful if the Atlantic interface on a Utopia or POSPHY interface core can also provide the data in bursts. The Atlantic protocol should therefore also allow a core to indicate that a burst transfer is possible.

Multiple Channels

Some systems allow multiple virtual data channels to be multiplexed together. This includes interfaces such as POSPHY and Utopia, but also covers digital signal processing functions such as FIR filters. The Atlantic protocol must allow the identification of channels in such systems.

Atlantic Fundamentals

In order to meet the wide variety of requirements for Atlantic interfaces, a fundamental interface is defined with many options. It is clear that not all Atlantic interfaces can be connected together. It is the intention that cores with compatible Atlantic interfaces can be directly connected, while other connections are facilitated through the design of a number of parameterized ancillary functions.

A minimal Atlantic interface has shared clock (clk) and reset (reset_n) lines, and a data bus (dat) connected from the data source to the data sink. The clock is rising edge active; the reset line is asynchronous and active low and intended for

system initialization only. The data bus is mn× bits wide, where n is the number of bits in a symbol and m is the number of symbols in a word. These can both have arbitrary values, but in some systems it is preferred to use 8-bit symbols (bytes or octets) and restrict m to a power of 2. This results in words of 8, 16, 32, 64, 128, etc. bits.

Such a minimal Atlantic interface is not likely to be very useful, since it requires the transfer of a data word every clock cycle. In most cases, one or other of the handshake options will also be required.

It should be noted that Atlantic is not concerned with the semantics of the data. The cores themselves define the content of each data symbol. For example, in Sonet systems it is simply an octet of data. In DSP systems, it may be a fixed-point or floating-point number. It is up to the user to ensure that cores have the same view of the semantics of the data, or to use or create an ancillary function to convert between two different semantics.

Atlantic Options

Data Symbol Size

As already indicated, a data symbol can contain any number of bits. A symbol is defined as the fundamental unit of data being transferred across the interface. The logically first symbol is always placed in the most significant position within the word.

Multiple Symbol Transfer

In order to achieve high performance, the Atlantic interface can transfer one word on each active edge of clock, and that data word can contain an arbitrary number of symbols. However, there may be occasions, such as at the end of the transfer of a packet of data, when it is necessary to transfer fewer symbols then normal. If this is required, an optional empty bus (mty) is provided from source to sink, which indicates the number of invalid or empty signals on the bus. When combined with block delineation, this bus is only considered valid when end of packet (eop) is asserted. The empty symbols are always at the least significant positions within the word.

Addressing

In order to support multiple channel applications, and optional address bus (adr) can be implemented from source to sink. The address bus must be valid whenever the data bus itself is valid.

It must be noted that this is a channel address. It is not an address bus that is used to select which slave device is selected, such as in an on-chip bus protocol such as AMBA.

Parity

An optional parity signal (par) carries parity calculated across the entire data bus. Either odd or even parity is supported.

Block delineation

Block delineation is required for interfaces where blocks of data are transferred, as opposed to simple streams of data. A start of packet signal (sop) is asserted concurrently with the first element of block data, and the end of packet signal (eop) concurrently with the last element of block data. The optional empty signal mty may be used concurrently with eop to indicate that there are not enough data symbols to fill a word at the end of a block.

An optional error signal (err) is provided for block-based interfaces. This is used to indicate that the current block should be aborted. It can be asserted at any time during the transfer of a packet, but when asserted must remain asserted for the rest of the transfer of the packet.

All the block delineation signals are from source to sink.

Handshake

Optional handshake signals are provided to control the flow of data between cores. Without any handshake, the cores must transfer a data word on every rising edge of clock. There are two varieties of handshake supported: master to slave, and slave to master.

Transfers are always initiated by a master. The concept of master and slave relates to FIFOs and burst support. Conceptually, an Atlantic slave has a FIFO behind it, but a master has not. A slave is able to indicate to a master whether the master can complete a burst transfer if it starts one. In the case of master to slave protocol, the slave indicates whether it has space available in its FIFO for a burst; in the case of slave to master, it indicates whether it has data available. This indication is done via a data available (dav) signal, whose direction is slave to master, irrespective of the direction of data transfer. The size of a burst is not defined by the Atlantic protocol; the user must ensure that the two cores agree on the size of the burst. Typically this burst size will be a parameter of the cores concerned.

The slave to master protocol is suitable for interfaces without FIFOs, requiring only simple flow control on a word level.

Master to Slave Data Transfer

In the case of master to slave, data transfer is controlled by an enable signal (ena) that behaves like a memory write enable. Data transfer takes place on any rising edge of clock when ena is asserted. There is no way for a slave to reject any data that is written; it should already have indicated to the master by asserting dav that it has space available. Figure 4 shows a block diagram of an Atlantic interface in master to slave mode. Figure 5 shows a timing diagram for Atlantic in this mode.

Figure 4 Block diagram of master to slave interface including optional signals

Slave to Master Data Transfer

In the case of slave to master, data transfer is controlled by an enable signal (ena) that behaves like a memory read enable. When a slave observes ena asserted on the rising edge of clock, it puts new data onto the Atlantic data signals and asserts its valid signal (val). If the slave is unable to provide new data, it de-asserts val for one or more cycles until it is prepared to drive valid data. Should the master de-assert ena while val is high, the slave must hold the values on its data signals and keep val asserted until the master once again asserts ena. Figure 6 shows a block diagram of an Atlantic interface in slave to master mode. Figure 7 shows a timing diagram for an Atlantic interface in slave to master mode. In this case, there is no FIFO on either side, so the data available signal (dav) is not included.

Figure 5 Timing diagram of Atlantic interface in master to slave mode

Figure 6 Block diagram of slave to master interface including optional signals

Atlantic Ancillary Functions

Various ancillary functions are useful to put together systems based on Atlantic interfaces. Future generations of system design tools will be able to insert these automatically.

DMA Controller

Atlantic is suitable as the hardware interface between a DMA controller and an IP core. Such a DMA controller can be used by a variety of different cores, while ensuring that the software view of these cores, in terms of their use of DMA descriptors, is as similar as possible. A multi-channel DMA controller with a number of Atlantic interfaces is also possible. clkreset_ndat[7:0]sopeopenavalThe Atlantic interface on the DMA controller needs to be as configurable as possible, in order to connect to as many different cores as possible. The DMA controller will need to incorporate memory to cope with burst transfers over the Atlantic interface as well as the processor bus. The DMA controller may need to pack data from the Atlantic interface into suitable sized words for the processor system, or such packing and unpacking functions must be available as other Atlantic ancillary functions.

FIFO

Atlantic FIFOs may be required between cores with Atlantic interfaces that have a fundamentally bursty operation, but which do not have their own internal FIFOs. Atlantic FIFOs can also be used to connect cores that are in different clock domains.

Multiplexors and De-multiplexors

Atlantic multiplexors can be used to merge multiple data streams into a single multi-channel stream, and de-multiplexors used to separate out a multi-channel stream into single streams.

Protocol and Semantic Converters

Figure 7 Timing diagram of Atlantic interface without FIFOs (Slave to Master)

The Atlantic interface has a wide range of options. Protocol converters can be built to sit between non-compatible Atlantic interfaces. In a similar way, semantic converters could take data in one format and present it in another format. An example of this would be converting between floating point and fixed point representations of a number.

References

[1] ARM Limited, AMBA Specification (Rev. 2.0), May 1999
[2] VSI Alliance Virtual Component Interface Standard Version 2 (OCB 2 2.0), April 2001
[3] The ATM Forum Technical Committee, UTOPIA 3 Physical Layer Interface, af-phy-0136.000, November, 1999
[4] PMC Sierra Inc., POS-PHY Level 3 SATURN-COMPATIBLE PACKET OVER SONET INTERFACE SPECIFICATION FOR PHYSICAL AND LINK LAYER DEVICES, Issue 4, June 2000