Problems with FIR Compiler II

[Altera_Forum]

I have a number of FIR filters in my design that I generate using FIR Compiler II. All of the filters I have exhibit the same behavior. See the attachment for screen shots of the setup. My experience is that sometimes the data through the filter is corrupted and sometimes it is good. One thing that I find interesting is that if I tell the "FIR Compiler II" to use a higher Input sample rate than what it is in reality, it works properly. Of course it is using double the number of multipliers at that time. I do know that my Clock Frequency and the Input Sample Rate is an exact multiple/fraction of each other and I'm wondering if this can cause a problem. I've had this exact filter setup in "FIR compiler" and had no problem. Is there any "gotchas" that I'm missing? 

 Quartus Version: 13.0 sp1 Device: Cyclone V E  Thanks  /Boris

[Altera_Forum]

The config you show there has 1 channel with an input sample rate that's 3/4 of the clock rate. To function correctly FIR Compiler II would expect data to appear at the input with the following valid pattern: 

 Valid: 1, 1, 1, 0, 1, 1, 1, 0, ...  While it can cope with extra pauses, it cannot cope with data being provided too quickly. (You might think the Back Pressure Support checkbox would solve this but in reality this only passes through back pressure signals from an upstream sink. Hopefully this will be resolved in a future release).  The reason it works when your sample rate is higher than your clock rate, is that then the valid signal is expected to be high on every cycle so it doesn't get confused.

[Altera_Forum]

how is it you check your data and say it is bad. Do you have a separate model for your filter. 

I feel your filter is not right for decimation by 3

[Altera_Forum]

kaz: I put through a clean CW and and sometimes it is distorted and sometimes it is not. The filter has been verified to work fine for decimation by 3  

 dabuk: You might be on to something since I do a rate conversion from from 92.16 Msps to 122.88 Msps through a FIFO and I'm relying on having enough samples in the FIFO to read out, but rdusedw is way slow and I think I might have 6 valids, 2 in-valid so if what you are saying is true I might violate that. Like you said the Back pressure does not work for this. The sink_ready is always high. I will test this out. thanks  Thanks  /Boris

[Altera_Forum]

ok I correct my reply, filter is ok cutting off at pi/3(initially I thought your speed is 122.880 

I agree that valid should enter regularly at rate of 3/4

[Altera_Forum]

Anyone knows if the Backpressure issue will be fixed?