Altera Home Page
Literature Licensing
Buy On-Line Download

  Home   |   Products   |   Support   |   End Markets   |   Technology Center   |   Education & Events   |   Corporate   |   Buy On-Line  
  Knowledge Database   |   Devices   |   Design Software   |   Intellectual Property   |   Reference Designs   |   Design Examples   |   mySupport  

 Products
      MAX/MAX II
      Stratix/Stratix GX
      Nios II
  
 Functionality
      Arithmetic
      Memory
      Bus & I/O
      Logic
      Interfaces & Peripherals
      DSP
      Communications
      PLL & Clocking
  
 Design Entry
      Quartus II Project
      Tcl
      VHDL
      Verilog HDL
      C Code Examples
      DSP Builder
      TimeQuest
   On-Chip Debugging
  
 Simulation Tools
      Mentor Graphics ModelSim
      Cadence NCsim
      Synopsys VCS
  
 Legacy Examples
      Graphic Editor
      AHDL
  

Upgrading an Atlantic Interface Design to an Avalon Streaming Interface Design

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

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.

 
Recommended HDL Coding Styles chapter of the Quartus II Handbook

How to Use Verilog HDL Examples

  Please Give Us Feedback