This design example describes how to upgrade an AtlanticTM interface to an Avalon® Streaming (ST) interface in Verilog HDL. You can use the described method to replace the Altera® Atlantic interface-based MegaCore® functions with the more recent Avalon-ST interface-based MegaCore functions. This design example allows you to upgrade a MegaCore function without modifying connecting logics to the old MegaCore function. This design example uses the Altera FFT v2.2.1 and FFT v8.0 MegaCore functions to demonstrate the conversion between the Atlantic and Avalon-ST interfaces.
Description
When upgrading an old module with the Atlantic interface to a design with the Avalon-ST interface, pay special attention to the interface flow control signals. This example shows a typical upgrade scenario and shows you how to effectively implement the flow control adaptation.
In a design using Altera FFT MegaCore v2.2.1 with the Atlantic interface, Atlantic source and sink blocks are built around the FFT core to supply data and record FFT data output, respectively. The goal when updating the design to use the FFT v8.0 MegaCore function, which uses the new, more effective Avalon-ST interface flow control, is to keep Atlantic source and sink blocks unchanged, and to build minimum control logic around the new FFT core so that it can be used with the Atlantic source and sink modules. Figure 1 shows the block diagram.
Figure 1. Atlantic Interface to Avalon Streaming Interface Design Top-level Block Diagram
Signal Mapping
The main differences between the two interface specifications are the valid and ready signals. Table 1 shows the signal name changes. This mapping only means that the signals in the right column have a similar function as their counterparts in the left column. You cannot directly use the Atlantic signals in place of Avalon-ST signals, as their timing behaviors are different.
| Table 1. Interface Control Signal Names | |
| Avalon-ST Interface Signal Name | Atlantic Interface Signal Name |
|---|---|
| sink_ready | master_sink_ena |
| sink_valid | master_sink_dav |
| source_ready | master_source_dav |
| source_valid | master_source_ena |
To illustrate their differences, the FFT core in this example is configured to the burst mode to show the behavior of backpressure signals, that is, the valid and ready signals. The design example uses the FFT v2.2.1 core's automatically generated testbench as the frame work of the design and demonstrates how to replace the FFT v2.2.1 core in the testbench with a v8.0 FFT core without changing the logic of the Atlantic-interfaced testbench.
Operation of the FFT Avalon Streaming Signals
The FFT core in burst mode accepts a frame of input data, and then halts the data source by de-asserting sink_ready so that the core can process the current frame. After the entire frame is processed and sent out from the core, sink_ready is re-enabled. The sink_valid signal indicates if the current data is valid.
Since the FFT Avalon-ST interface (v6.1 and later) uses ready-latency-0 signals, the upstream data source must halt at the same cycle when sink_ready is de-asserted. The sink_valid signal can be kept high. However, to decide if current input data is valid, both sink_valid and sink_ready are used.
Operation of Atlantic Interface Signals
FFT v2.2.1 asserts master_sink_ena to notify the slave source it can take a frame of data. The slave source supplies valid data with one cycle delay. After the entire frame is read in (plus a few more samples), the master sink de-asserts master_sink_ena to halt input data. The slave source responds with one cycle delay. Similarly, the downstream slave sink responds to master_source_dav with a predictable one cycle delay. This behavior is somewhat similar to an Avalon-ST interface with ready latency 1. The key difference is that a ready-latency-1 sink_valid signal must de-assert one cycle after sink_ready de-asserts, whereas master_sink_dav can stay high. This is because master_sink_dav indicates whether the slave source has data to supply. It is not an indication whether the current sample is valid.
Atlantic Interface and Avalon Streaming Interface Conversion
In this example, to use the same Atlantic source and sink, convert the Atlantic signals to ready-latency-1 Avalon-ST signals first, and then use a ready latency adaptor to convert the latency-1 signals to latency-0 signals.
The following summarizes the key functions of the adapting logic:
-
Generating input sop and eop signals for FFT v8.0
- Generating an intermediate ready-latency-1 in_valid signal based on master_sink_ena and master_sink_dav
-
Generating sink_valid signal (ready-latency-0) from in_valid signal (ready-latency-1)
-
Keeping the sink_valid signal high after reading the last frame of input data, in order to extract this frame of data from the FFT core
Download the design:
The use of this design is governed by, and subject to, the terms and conditions of the Altera Hardware Reference Design License Agreement.
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.
