Honored Contributor II
07-12-2017 11:41 PM
For the last couple of days I've been trying to get the Altera FIR Compiler II Qsys core to work with coefficient reloading, with no success until now. I'm posting this for reference if anyone else finds themselves struggling.Basically if you are using Qsys and the FIR filter core there is a mistake in the IP core which has taken me two days of failed simulation and hardware testing to fathom. Simply put the TCL file incorrectly specifies the "coeff_in_areset" signal as an active low (reset_n) signal which means essentially when you connect it to a reset source in Qsys the polarity is incorrect putting the core in reset when it shouldn't be. As a second point, the line in the documentation stating that for coefficient reloading to work you must assert the "coeff_in_areset" signal before attempting to write is complete and utter nonsense. There is no need to do this because the signal connects only to a pipeline register and the coefficient memory. There is no need to reset either of these before writing because there is nothing in the design that latches. I've confirmed this to be true both in simulation and through checking the RTL and Technology outputs. The solution to the issue is to navigate to: "<altera root>\ip\altera\dsp\altera_fir_compiler_ii\src\" and open the file called "HP_FIR_hw.tcl", then scroll to line 688. Replace the following:
# connection point coefficient reset add_interface coeff_reset reset end set_interface_property coeff_reset ENABLED true set_interface_property coeff_reset associatedClock clk add_interface_port coeff_reset coeff_in_areset reset_n Input 1With the following:
# connection point coefficient reset add_interface coeff_reset reset end set_interface_property coeff_reset ENABLED true set_interface_property coeff_reset associatedClock clk add_interface_port coeff_reset coeff_in_areset reset Input 1Save and reload Qsys. And then as if by magic the design should actually start working because the reset is now the correct polarity. Note that this applies to Quartus 15.0. I don't know whether or not this issue has been fixed in later versions of the IP core, but there is no mention of it in the change log in the datasheet. Altera (well Intel now) really needs to get its act together and do some actual verification of its IP cores. This is yet another example of an Altera IP core with a mistake in its integration.
Honored Contributor II
07-20-2018 02:38 PM
Hello,I am also working with the FIR compiler and there still seems to be an issue with coefficient reloading (18.0). When I try to read a coefficient the whole Nios system hangs/deadlock. I assume that it waits for the valid signal of the MM slace interface that never arrives (I still need to do some further investigation). Anyway the line "add_interface_port coeff_reset coeff_in_areset reset_n Input 1" is still the same in Version 18.0, so I tried your fix. However, now I am no longer able to program the processor. When ever I try, it says: Using cable "USB-Blaster [1-8.3]", device 1, instance 0x00 Pausing target processor: not responding. Resetting and trying again: FAILED Leaving target processor paused Output of nios2-download Did you ever experience such a behaviour?