The Atlantic® interface is a simple, standardized, on-chip data path interface that enables the rapid integration of IP MegaCore® functions. This register transfer level (RTL) design example shows how to connect one MegaCore function with an Atlantic interface to another MegaCore function that has an Atlantic interface of double the width. Figures 1 and 2 show typical applications.
The 1-to-2 converter block presented in this design example applies to both source-master and sink-master interfaces, and performs essentially the same function in both, provided it is connected appropriately.
Figure 1 shows the connections for the source-master interface, and Figure 2 shows the connections for the sink-master interface; the clock and reset signals are not shown. In both cases, the source on the left passes data to the sink on the right. To perform 1-to-2 conversion, the converter pushes data to the sink only once for every two data pushes by the data source (except for a few unusual cases). Table 1 shows the control signals used by the converter, and briefly describes the purpose of each signal in a source-master and sink-master interface.
Figure 1. Atlantic 1-to-2 Interface Width Converter Design Example Top-Level Diagram for Source-Master Interfaces
Figure 2. Atlantic 1-to-2 Interface Width Converter Design Example Top-Level Diagram for Sink-Master Interfaces
Download the files used in this example:
The use of this design is governed by, and subject to, the terms and conditions of the Altera Hardware Reference Design License Agreement.
Table 1 lists and describes the signals.
| Table 1. Atlantic 1-to-2 Interface Width Converter Design Example Signals | |||
| Signal | Type | Description | |
clk |
Input | Reference clock | |
reset_n |
Input | Active-low, synchronous reset | |
ai_rddav |
Input | Read data available | Atlantic Input Interface (Sink Master) |
ai_wrdav |
Output | Write data available | |
ai_rdena |
Output | Read enable | |
ai_wrena |
Input | Write enable | |
ai_sop |
Input | Start of packet | |
ai_eop |
Input | End of packet | |
ai_err |
Input | Errored packet | |
ai_dat[63:0] |
Input | Data | |
ai_mty[2:0] |
Input | Empty bytes | |
ai_adr[7:0] |
Input | Address | |
ao_rddav |
Output | Read data available | Atlantic Output Interface (Source Slave) |
ao_wrdav |
Input | Write data available | |
ao_rdena |
Input | Read enable | |
ao_wrena |
Output | Write enable | |
ao_sop |
Output | Start of packet | |
ao_eop |
Output | End of packet | |
ao_err |
Output | Errored packet | |
ao_dat[127:0] |
Output | Data | |
ao_mty[3:0] |
Output | Empty bytes | |
ao_adr[7:0] |
Output | Address | |
Atlantic Interface Signals
There are two variations of the Atlantic interface (see Figure 3), and these variations differ only in how the control signals are used.
On the left, you can see a source-master interface, and a receive MegaCore function that receives and pushes data into an Atlantic buffer. In this case, the receive MegaCore function is the source of the Atlantic data, and is the master controlling when data is pushed across the interface with the enable (ena) signal. To indicate that it is getting full, the Atlantic buffer deasserts the dav signal. For source-master interfaces, the ena signal can be considered as a 'push' signal that is asserted as the data is pushed across the interface.
On the right, you can see a sink-master interface. The Atlantic buffer sources the data going across the interface, but the transmit MegaCore function (Atlantic sink) decides when to pop data from the buffer using the enable signal. In this case, the sink controls the flow of data with the enable signal, and is the interface master. For sink-master interfaces, the ena signal can be considered as a 'pop' signal. When the source sees the enable signal, it responds on the next cycle with valid data and asserts the val signal back to the sink. If the source is unable to respond with valid data, the val signal is deasserted. For cycles where the sink does not assert the ena signal to the source, the outputs from the source, including val, remain unchanged.
Figure 3. Source-Master & Sink-Master Interfaces
Table 2 lists the control signals relevant to the Atlantic interface for both source-master and sink-master interfaces. Note that the ena signal for the source-master interface serves exactly the same function as the val signal for the sink-master interface, and corresponds to the source pushing data to the sink. The ena signal for the sink-master interface allows the sink to tell the source when to send data. For a source-master interface, it is as though the enable signal from the sink is always asserted, and the source can always send. The slave uses the dav signals in both interfaces to tell the master that there is data or space available, and that it can perform a read or write.
| Table 2. Source-Master & Sink-Master Interface Control Signals | ||||||
| Source-Master Interface Control Signals | Slave-Master Interface Control Signals | |||||
| Name | Direction | Description | Name | Direction | Description | |
ena |
Source -> Sink | Asserted when data from the source is valid. | ena |
Sink -> Source | The sink pops data from the source. | |
dav |
Sink -> Source | The sink is ready to receive data. | dav |
Source -> Sink | The source is ready to receive data. | |
val |
Source -> Sink | Asserted when data from the source is valid. | ||||
This design example presents a single block that can be used to convert source-master and source-slave interfaces. Table 3 describes the purpose of each of the control signals used by the converter. Figures 1 and 2 show how the converter would be connected to the source and sink control signals in order to support both source-master and sink-master interfaces.
| Table 3. Source-Master & Sink-Master Converter Control Signals | |||
| Signal | Description | Source master usage | Sink master usage |
ai_rddav, ao_rddav |
Read dav: The source tells the sink that it can read data. |
Unused. | Passed directly from the source to the sink. |
ai_wrdav, ao_wrdav |
Write dav: The sink tells the source that it can write data. |
Passed directly from the sink to the source. | Unused. |
ai_rdena, ao_rdena |
Read enable: The sink uses this signal to pop data from the source. | Tie to logic 1, telling the source that it can always send data. | Connect to the source and sink ena pins, asserted whenever data is to be read from the source. |
ai_wrena, ao_wrena |
Write enable: The source asserts this signal when pushing data to the sink. | Connect to the source and sink ena pins, asserted as data is being pushed. |
Connect to the source and sink val pins, asserted as data is being read. |
Atlantic Interface Signals
The following sections briefly discuss the implementation of the 1-to-2 Atlantic interface width converter design example.
Data Available (dav) Signals
In both directions, the dav signals are simply wired straight through the converter block to the other side, and are not used by the converter logic.
Read Enable (rdena) Signal
The read enable signal is used internally as an enable signal, therefore the output of the converter only changes when read enable is asserted. The read enable signal is also passed directly through to the source so that the source only updates its output, the input to the converter, when the sink is reading. For source/master interfaces, the read enable signal should be tied to a logic1 external to the converter block to allow the source to always send data.
Conversion Algorithm
Figure 4 shows the conversion algorithm flowchart. Every time the sink has ao_rdena asserted and the source has the ai_wren asserted, the converter block loads the top half of the output bus, if it has not already been loaded, or loads the bottom half of output bus and asserts the ao_wren signal to the sink. Whenever the top half of the output bus has not already been loaded, and the input data contains an EOP, the converter block asserts the ao_wren signal to the sink.
The error checking performed in this design example consists of an address comparison when data is received for the bottom half of the bus and after the top half of the bus has already been loaded. If the address arriving with the data for the bottom half of the bus does not match the address of the data already received for the top half of the bus, the ao_err and ao_eop signals are asserted. In this case, packets for both the old address and the new address are corrupted, but the Atlantic error is only asserted for the new address. For safety, an internal 'Error Found' signal could be used to remember that there was an error for the new address, and assert the Atlantic error signal again on the next clock cycle.
Figure 4. Atlantic 1-to-2 Bus Width Converter Decision-Making Flowchart
Half-Empty Issue
When converting from a narrow Atlantic interface to a wider Atlantic interface, it is possible that a burst on the narrow interface corresponds to an odd number of clock cycles. Consider, for example, a three-cycle burst (without an EOP) for port A, followed by a four-cycle burst for port B. The first two cycles of data for port A become a single cycle output for port A. The third input cycle for port A is stored in the top half of the output bus, and the first cycle for port B is written into the bottom half. The converter detects that the port for the top and bottom half do not match, and it asserts an Atlantic error on port B. The result is that even though the source is providing Atlantic data that is valid for the narrow bus, it is invalid for the wider bus.
The following are three possible solutions to the 'half-empty' issue:
- Never allow the source to send bursts that are an odd number of narrow cycles. For example, the Altera® POS-PHY Level 4 receiver MegaCore function can be configured to never assert its dav signal, indicating that there is data available in the buffer, until an even number of Atlantic cycles’ worth of data is available. This solution simply avoids the problem, and this design example can be used without any changes. The Atlantic error signal is only asserted to the sink if the source asserts it first.
- If the sink can accept cycles when its bus is half empty, the mty signal has a value of half the bus width even when the
eopsignal is not asserted. In this case, this design example can be changed to write data to the sink with themtyvalue set to half the bus width when the addresses do not match. This would require a storage register to hold the data for the new address while the converter pushes the data for the old address to the sink.
- If the sink cannot accept cycles when its bus is half-empty, and there is no way to guarantee that the source will never send any, then the safest solution is to include a mechanism inside the converter to store the half-empty data for each port until more data for that port is available. You could implement this solution by using a small memory to store the top half of the output bus for each port as it arrives. As the bottom half of each port’s output bus arrives, the top half is fetched from memory, and the two halves are presented to the sink together.
Related Links
For more information about using this example in your project, go to:
- Atlantic Interface Web Page
- Atlantic Interface Specification
- Atlantic 2-to-1 Bus Width Converter Design Example
- List of MegaCore functions using the Atlantic Interface
- How to Use Verilog HDL Examples
Design Examples Disclaimer
These design examples may only be used within Altera Corporation devices and remain the property of Altera. They are being provided on an “as-is” basis and as an accommodation; therefore, all warranties, representations, or guarantees of any kind (whether express, implied, or statutory) including, without limitation, warranties of merchantability, non-infringement, or fitness for a particular purpose, are specifically disclaimed. Altera expressly does not recommend, suggest, or require that these examples be used in combination with any other product not provided by Altera.
