Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

help needed to switch from Avalon MM to Avalon ST interface

Hi,

I have designed SOPC based system using combination of soft IP core and custom logic. System has Avalon MM interface used to transfer data and control information between internal modules. Now I found problem with this implementation (like increased in area, data latency). So I want to make changes in current implementation. According to my understanding and knowledge, I found two ways to mitigate these problems. I need your help in finding out which one is the best and how to go about it or there is any another method to resolve this problem.

In soft IP core and custom logic, I have Avalon MM interface signals. If now I have to seperate out control and data pane in system by transferring data over Avalon ST interface and control operation will be done by Avalon MM interface.

1) Should I have to add Avalon ST source and sink interfaces in each and every modules of SOPC system for data transfer and Avalon MM slave is used only for control operation (like register configuration etc.) which will be controlled by single Avalon MM master.

2) Or should I convert Avalon MM signals to equivalent Avalon ST signals by developing some bridge module or ready made bridge module is available for use.

Please suggest me some way out of it. Thanks in advance.

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    It depends on the kind of data that you want to transfer. Avalon ST are well adapted for transfer of data that comes as a stream of elements that are always the same (such as a stream of bytes, or of words). A stream only goes from one source to a destination, but you can do more complex connections using channels and multi/demultiplexers.

    In a lot of systems it makes sense to use ST for data transfer and MM for control, but to give you more advice we would need more information on your system and what you need to achieve.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Hi,

    Thanks for your reply. My project is in video domain. I have to process different video formats coming from on board ADVs using IP core provided by Altera and transferred to Media processor (MP) or DAC depending on I2C interface configuration from MP.

    The switch from Avalon MM to Avalon ST interface is required for transferring Audio, Metadata, TSData and config data over VLYNQ interface to MP. Currently audio and metadata is transferred by Avalon MM interface, others are still need to implement. So due to Avalon MM interface, it generates arbitration logic which increases data propogation delay throughout the system. System became more complex and unable to scale the future requirements.

    We are using VLYNQ IP core from TES. It has built-in Avalon MM interface for exchange of information. And is it a good idea to modify third party IP core? Other modules like MetaDataCapture, I2S module and data_transfer has Avalon MM interface. So please suggest me some way out of it.

    Waiting for your reply......
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Audio and video formats can benefit from a stream interface. For metadata it depends on a few parameters. I don't know about the standards that you are using, but if you can transport the metadata in packets, you could use them in a stream too.

    I wouldn't advise modifying third party IPs though. It will make it harder to upgrade, and get support from the supplier. Another way of avoiding latency and arbitration is to separate the avalon MM busses. You don't need to connect all the masters to all the slaves, so if you are able to only connect the slaves to the masters they are supposed to talk to, it will reduce the arbitration.

    If you are implementing yourself the IP that does all the transfers, you could design it with multiple MM masters, and connect each one of them to only one slave, and have that slave only connected to your master. With 1-1 connections you would reduce the latency to the minimum and get rid of the arbitration logic.