FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6343 Discussions

FIR II Coefficient scaling and reloading

Altera_Forum
Honored Contributor II
972 Views

FYI: 

 

I've encountered some strange behaviour using the FIR II compiler in Quartus 10.1SP1. 

 

First of all the coefficient scaling while generating the component is fixed to the setting that corresponds with the 'auto' setting in FIR (1) compiler. (largest coefficient will be scaled to full bitsize) 

According to altera: 

 

i agree, there is no option but tool creates the ideal coef set and then convert to fixed point for the given bit width, which results in quantisation noise. i have spoken to the developer who coded the fir ii filter used in the megacore and he says this part (coeff scaling, etc) is handled by the gui part of the mega function and the actual fir core code only handles a given set of coeffs given in fixed point numbers.  

 

i have played around it a little, it seems that even if you give the numbers in fixed point, it scales somehow, and it seems to me the tool tries to scale it so that your maximum coefficient will use full range of the available number of bits. so workaround could be if you manually re-calculated your coefficients to take this into account, that may be possible although i have not tested it myself. unfortunately, there is no other way to stop this from happening with the current gui.  

 

 

Because in my project I need the reloading of the FIR coefficients anyway, I can overcome the stuff mentioned above by reloading the coefficients (at runtime) with my custom set. 

 

Following the descriptions and waveforms in chapter 4-19 of the FIRII user guide, I implemented the reloading mechanism.  

According to the manual Coeff_areset must be toggled before interaction, however, as I found out toggling this reset, restores the coefficients to their power-on defaults. 

 

--> But reading out the coefficients still returns your custom set of coefficients!! 

 

I checked the source of the core, and found that the target of a coefficient write action is a RAM and a register per coefficient (which is routed to the multipliers).  

So the RAM and the registers exist in parallel. The RAM is used for read-back of the coefficients and the registers are used for the actual FIR calculations.. 

 

A coeff_areset toggle resets the registers to their power-on defaults, but the RAM remains untouched, leading to the situation that the actual filter coefficients (and so its response) can be quite different than what its assumed to be.. 

 

So if you've encountered similar behaviour this might be a cause.. ;) 

 

Grtz, 

 

Olaf
0 Kudos
0 Replies
Reply