Problems when I built my simple system

Altera_Forum · ‎12-18-2009

Hi, everyone,

I have Cyclone II board and Quartus II 9.0sp2. Now I am trying to build a system containing one FIR compiler and one FFT using SOPC Builder.

I am trying to build a system containing one FIR compiler and one FFT using SOPC Builder. FIR compiler is the master of FFT. The input to the FIR compiler is going to be input manually and I would like to obtain the output of FFT. Now I have several problems as stated below. Here is the process about how I generated the system:

(1) I converted FIR compiler and FFT into components which can be used in the SOPC builder. In the attachment, you may find the signals and interfaces that I assigned to them using Component Editor. (Since I want to manually input signals to FIR compiler and obtain the output of FFT during simulation, thus I have set the SINK ports of FIR compiler as well as SOURCE ports of FFT to Avalon Conduit interface)

(2) System-level design using SOPC. I am trying to put FIR compiler and FFT into different clock domains; hence I used a Dual clock FIFO component to connect them. The final connection in SOPC Builder GUI is also attached. One problem here is that there is a warming as you can see in the attachment. The number of data ports is not right, is there any walkaround to circumvent those warnings?

(3) I clicked the “generate” button and the system was generated successfully.

Now, I understand that I need to instantiate the system according to the fir_fft_sopc.vhd file (As attached). However, I am not quite sure how to get it done. Like the input and output port, do I only need to instantiate those conduit interface signals?

I am new to SOPC builder. I would highly appreciate if anyone could give me some hints. Thanks you so much! Now I get so frustrate that I cannot build this simple system after spending lots of time on it.

Best regards

Sincerely

Grit

Altera_Forum · ‎12-18-2009

As the warning says, you can have only one data vector. You should put together the real and imaginary parts of the sample in one single 36-bit data vector.

You need to instantiate your SOPC system in your top level file. If you use the graphical tools, SOPC builder generates a bdf file for you and you can integrate the symbol in your design. If you use vhdl you can have a look at the bottom of the fir_fft_sopc.vhd and look for the test bench. You can them copy-paste the code that declares and instantiate your SOPC component.

Altera_Forum · ‎12-18-2009

--- Quote Start ---

As the warning says, you can have only one data vector. You should put together the real and imaginary parts of the sample in one single 36-bit data vector.

You need to instantiate your SOPC system in your top level file. If you use the graphical tools, SOPC builder generates a bdf file for you and you can integrate the symbol in your design. If you use vhdl you can have a look at the bottom of the fir_fft_sopc.vhd and look for the test bench. You can them copy-paste the code that declares and instantiate your SOPC component.

--- Quote End ---

Hi, Daixiwen,

I really appreciate your reply.

Yes, I can find the testbench at the bottom of fir_fft_sopc.vhd. I am going to try to instantiate using that later.

However, for the part of " put together the real and imaginary parts of the sample in one single 36-bit data vector", do you mean I need to modify the IP core? or is there any other simple method for this? I am sorry that I have no clue for that.

Also, I just realize that do I need a PLL to generate the fastclk? If so, it is strange that why the system could be successfully generated?

Thanks you so much in advance for your patience and explanation!

Best regards

Sincerely

grit

Altera_Forum · ‎12-18-2009

Yes, you would need to modify the IP (or put a wrapper around it) to have only one data vector instead of sink_real and sink_imag.

For the clocks, in the system that you made, they are both defined as extern. This means that they will both be inputs in your component, and it is up to your top level file to provide them, either through pins, or through a PLL that you add using the megawizard.

As an alternative, you can also add a PLL directly in the SOPC system to create the fastclk, and have only clk_0 as an input to your component.

Altera_Forum · ‎12-21-2009

Hi, Daixiwen,

Thanks to your kind help previously. Now I have successfully initiated and compiled the whole design. Yet I am still trying to solve the warning data” port; hence the whole project is compiled when the warning still exists at this moment.

Now the problem came when I tried to simulate the system using the waveform that defined by myself (please refer to attachment). The result is also attached, in which as you can see there is no output at all. During the simulation, there also appeared 17 warning as follows:

I don’t know if this has anything to do with the warming in SOPC builder after having generated the system.

Are there any other possible causes to the outcome?

If it has something to do with the warning message, could you please kindly have a look at the vhd files generated for the fft (I believe this is the IP core that I need to modify, however I don't know exactly which file to look at )? Is it easier to create a wrapper or modify the IP core? At this moment, both are hard to imagine for me as I have never done them before. If possible, could you please give me some advice on how to modify the IP core or create the wrapper on my own to put together the real and imaginary parts of the sample in one single 36-bit data vector?

Meanwhile I am also trying my best to figure out how to solve these problems.

Thank you so much for your help!

Best regards

grit

Altera_Forum · ‎12-21-2009

Your reset_n signal is 0, this keeps the component in the reset state. This is why it isn't answering.

For the data bus connection, there might in fact be a simpler way. I assume that the signal that you want to inject to the FFT is in fact real, with no imaginary part. Am I right?

In that case in the component definition you could only define sink_real as data, and define sink_imag as an export. Then outside the SOPC system, just input 0 to sink_imag.

I've never used the DSP IPs in Quartus so I don't know what's the recommended way to connect them...

Altera_Forum · ‎12-21-2009

Hi, Daixiwen,

I am so glad to hear from you!

I have set the reset_n signal to be always high and I have also set the sink_sop_to_the_my_fft_0 signal to be always high. However, the output signals (source_imag_from_the_my_fft_0 and source_real_from_the_my_fft_0) still have no response. Yet the ast_sink_ready_from_the_fir_comp_0 signal does goes to high at about 57ns.

Now I guess it is really due to the warning appeared in SOPC previously? I am going to re-edit the fft component as you suggested (keep only one data signal type for the Avalon ST interface). I will update you soon. =)

Best regards

Sincerely

grit

Altera_Forum · ‎12-21-2009

--- Quote Start ---

Your reset_n signal is 0, this keeps the component in the reset state. This is why it isn't answering.

For the data bus connection, there might in fact be a simpler way. I assume that the signal that you want to inject to the FFT is in fact real, with no imaginary part. Am I right?

In that case in the component definition you could only define sink_real as data, and define sink_imag as an export. Then outside the SOPC system, just input 0 to sink_imag.

I've never used the DSP IPs in Quartus so I don't know what's the recommended way to connect them...

--- Quote End ---

Hi, Daixiwen,

Thanks to your advice. Now the warning from the SOPC builder has disappeared after I set the imaginary part input as external input.

I have been trying till just now but still nothing from the output side appears except for the ast_sink_ready_from_the_fir_comp signal. I think it indicates that the FIR is working and has the correct output from the FIR side. Am I right?

In the document of FFT, it says that sink_ready and sink_valid must both be asserted in order to obtain a successful data transfer. However, I cannot view whether these two signals are asserted or not since they are not defined as Avalon conduit interface (they are both defined as Avalon ST interface in the component editor). Is there a way to do so for debugging?

Or is there anything wrong with my input signals in the simulation waveform? Especially for the position and duration of the sop and eop signals, are they correctly asserted? Could you please take a look at the simulation (attached) and give some advice? I truly appreciate for your consistent help. Please don't hesitate to inform me if there are any other files you need for further inspection. Thank you

Best regards

Sincerely

grit

Altera_Forum · ‎12-22-2009

First you should create a reset pulse instead of leaving the reset_n signal always at 1. Put it at 0 at the beginning for a few clock cycles, and then leave it at 1. This will ensure proper initialization of the components.

For the sink, the filter will put ast_sink_ready at 1 when it can receive data. Then place your data sample on the data input, and put ast_sink_valid to 1. When both the ready and valid signals are at 1, the data is fed to the filter.

For the source from the fft, you must place source_ready at 1 to signal that you can receive data, and the fft will put source_valid at 1 when there is data to read.

The SOP and EOP signals must be put at 1 during one sample only, at the beginning and end of packet. This means that you place them at 1 when required, and reset them to 0 as soon as a transfer occured (i.e. valid and ready at 1 at the same time).

I couldn't open your zip file, it seems corrupted.