Forum Discussion

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

No output in simulation after connecting FIR and FFT using SOPC Builder

Hi, all,

Sorry if I have posted in a wrong place. But I am really desperate now. Here is my problem:

I am using Quartus II 9.0sp2. Now I am trying to connect FIR compiler to FFT using SOPC builder with FIR being the master and FFT being the slave. I suppose the SOPC builder could automatically generate the interconnection fabric for me. After simulation, I found that there is simply no output from the FFT side no matter how I put these two signals. In addition, after a while, the source_error signals from FFT will have the value "01" which indicates missing sop signal.

Now I realize it might be the problem of the Avalon ST interface I used. I have to assert startofpacket and endofpacket signals to FFT manually in the simulation file since the FIR cannot generate them. However, the problem is that I don't know when will the sink_ready and sink_valid signal to the FFT will be asserted. According to the user guide of FFT, sink_read and sink_valid should be asserted at the same time for a successful data transfer, hence I guess my sink_sop should also be asserted when those two signals are both high. Am I right?

Anyone have such experience to deal with the sink_sop and sink_eop signals in system generated using the Avalon ST interface in SOPC builder??

p.s. I have attached the screen shot of my simulation results, connection inside SOPC as well as the Avalon ST interface settings when I created the FIR and FFT components. I will really be grateful if anyone can take a look and give some advice. I have been trying for a long time but no progress so far on this matter. All I need is to see some output from the FFT.

8 Replies

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

    I just had another idea... the FIR filter doesn't know anything about packets, as it works with bytes. Instead of generating the SOP and EOP signals yourself, which would require to work with the control signals between the two cores, you should use a avalon-st bytes to packets converter core (http://www.altera.com/literature/hb/nios2/qts_qii55012.pdf). Be sure you configure it with a packet size that the FFT will like.

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

    --- Quote Start ---

    I just had another idea... the FIR filter doesn't know anything about packets, as it works with bytes. Instead of generating the SOP and EOP signals yourself, which would require to work with the control signals between the two cores, you should use a avalon-st bytes to packets converter core (http://www.altera.com/literature/hb/nios2/qts_qii55012.pdf). Be sure you configure it with a packet size that the FFT will like.

    --- Quote End ---

    Thank you so much.

    I am going to try it now
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Hello! Daixiwen, Happy new year!

    Sorry that I have to trouble you in the first day of 2010...

    I have built a new system which contains FFT, FIR, DC-FIFO and the Avalon-ST Bytes to Packets Converter Core as you suggested. In addition, I also had to inserted a Avalon ST Channel Adapter (suggested by an error message in SOPC builder).

    Indeed it seems that I don't have to manually assert the sop and eop signals since the the Bytes to Packets Converter has taken care of them; however, the simulation result was the same: there still existed the error signals "01" indicating the miss of source_sop signal (Please have a look at the simulation result in the attachment). I have also attached the look of my system inside SOPC builder.

    I will appreciate for any advice from you. Thank you so much for your patience!

    Best regards
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    The SOPC system looks good... It would be interesting to see the signals between the channel adapter and the fft to see what's really happening. They are more difficult to catch, as you must go a bit deeper in the SOPC system to look for them.

    Shouldn't the clk_ena_to_the_my_fft_0 be 1?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    --- Quote Start ---

    The SOPC system looks good... It would be interesting to see the signals between the channel adapter and the fft to see what's really happening. They are more difficult to catch, as you must go a bit deeper in the SOPC system to look for them.

    Shouldn't the clk_ena_to_the_my_fft_0 be 1?

    --- Quote End ---

    Thanks for pointing out the "clk_ena_to_the_my_fft_0" mistake. I have just changed that, but the result is the same: "source_eop' still raises without the rising of "source_sop", hence the error signal still has the value "01"...

    Exactly, I am going to debug by looking at those signals between the components. I am going to try to use the Modelsim. can you take a look at my post over here: http://www.alteraforum.com/forum/showthread.php?p=79930#post79930 I am having problems for using the testbench I exported from Quartus II.

    I really appreciate for your precious time!

    Best regards
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Hello, Daixiwen,

    I have been trying to look for those signals between the FIR and FFT compiler, and I think I have identified some signals to look at, however, it seems that every time those signals were synthesized away hence I can't see them! How could that happen? Any suggestion? I have to use Modelsim instead of Quartus II simulator, right?

    Thank you so much
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Have a look at the RTL viewer and see how your two components are interconnected. You should be able to access those signals from both Modelsim and the Quartus simulator.

    Learning to use Modelsim could be a good idea though, as the Quartus simulator will soon become obsolete.

    If those interconnection signals were indeed synthesized away, it means that Quartus detected that they were never changing. There may be a configuration problem one one of the two cores...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    --- Quote Start ---

    Have a look at the RTL viewer and see how your two components are interconnected. You should be able to access those signals from both Modelsim and the Quartus simulator.

    Learning to use Modelsim could be a good idea though, as the Quartus simulator will soon become obsolete.

    If those interconnection signals were indeed synthesized away, it means that Quartus detected that they were never changing. There may be a configuration problem one one of the two cores...

    --- Quote End ---

    Hi,

    I have some problems with the simulator of the FFT_core_V90 .I have got the data and I am sure they are right.But the source_valid is always keep low. I am using the Quartus II 9.0. I hope you can help me to find what cause the result.