Forum Discussion

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

IP with avalon ST >-|-< SOPC builder

the missing link between ip's with avalon st interface and sopc builder

We have:

A) ip cores such as FFT and FIR that have Avalon ST (streaming) interfaces.

B) blocks for maniplating avalon st In SOPC builder, such as Channel adapter, data format adapter, mux/demux and timing adapter.

But despite shaing a common standard (avalon ST) - A and B seem to live in separate design domains:

I) ip cores (FFT, FIR) can be put as blocks on their own in the design, but not into SOPC.

II) avalon manipulation block can be put into SOPC, but not as a separate block in the design.

I am missing a piece here. There is, as far as I can see, no ready-made solution joining these two design domains!

As a simple examples:

1) If I want to bring FFT data into SOPC, I will have to develop an avalon ST port.

2) If I want to send a stream of FIR data from several channels (filters) between two chips, I will have to develop my own channel adapter mux/demux. I cant use the ones from SOPC builder, as they only "live" inside SOPC.

Can someone tell me if I have overlooked something here?

If this is not the case, what are the plans from Altera to bring the pieces together?

4 Replies

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

    I'm using SGDMA (Scatter-Gather DMA) component to do that, works fine.

    The only problem I have with SGDMA is that it forces you to use 64-bit registers for all the other native addressing peripherals in your system because Altera has been lazy and has not put in an option to reduce the descriptor memory data width.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    sorry, could you be more specific how you use SGDMA to join the domains I and II described in my post?

    If you instantiate SGDMA in SOPC, it can not connect to say an FFT module outside of the SOPC using Avalon Streaming, unless you make a custom module to make this happen as far as I can see. Is that the way you bridge the two domains - with a custom module?

    Clearly that would be an option, but why should every user reinvent such an essential module?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    Yes, basically I had to create a SOPC Builder component/wrapper for the DSP function. This is just a tcl/ptf description file to map the DSP block's Avalon-ST signals to SOPC Builder. There is a bit of work involved to manually edit the tcl/ptf file if I make changes to the Avalon-ST interface (like change the number of channels for example), but usually this doesn't happen often.

    I agree that Altera should've released a component wizard to handle this automatically, it's a pretty straightforward process.

    Edit: just to be clear, I don't instantiate the DSP function outside SOPC, I've just created a folder for it and made it a SOPC Builder component using the method above.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    You mention that the FFT core already has an Avalon-ST interface, this component can be easily added into SOPC Builder (without any code changes) by adding a custom component using the Component Editor Wizard.

    I think the benefit of adding components into SOPC Builder is that it does the connections and module instantiations for you.