FIR Cyclone2 M4K switch to Cyclone3 M9K No AUTO Block for storage

[Altera_Forum]

Using Quartus 7.2SP3 with the coressponding FIR. 

 We have used Cyclone II Devices with a couple of FIR The FIR IP Tool wizzard currently does not have the feature to match device to project defaults. So it creates M4k memory blocks for data and coefficient. No Auto option available  Now we are using Cyclone III for new projects and the have M9K blocks and no M4K any more. I do not want to keep 2 versions of the fir stuff depending on the target fpga.  each night a script is executed and all fpga images for all projects are build and we want to use only one source. so if an ip function is included in different fpga then the source has to be the same. so each fpga is build from the same source pool.  how do you out there handle this ?  does anybody know if quartus V8 will have the auto option ? the manual on the web site meantions both auto options data / coeff storage. but does this means the wizzard will be executed depending on the target fpga to create different files ? one set if M4K and another if M9K ??  Regards  Michael

[Altera_Forum]

In a QII 7.2 SP3 test case starting with EP2C15AF256A7 initially selected, I created a FIR Compiler variation with all default settings except "Data Storage" set to "Auto" and "Coefficient Storage" set to M4K. I verified that would compile. Then I changed the Quartus project device selection to EP3C5F256C6 and recompiled without regenerating the FIR Compiler. Compilation was successful with Analysis & Synthesis messages like those below. I don't know that the Cyclone III compilation gave functionally correct results, but it appears to be OK to recompile your Cyclone II FIR Compiler variation with Cyclone III selected in the Quartus project. 

   --- Quote Start ---  Warning: Device family Cyclone III does not have M4K blocks -- using available memory blocks  Warning: Assertion warning: Device family Cyclone III does not have M4K blocks -- using available memory blocks  --- Quote End ---  

[Altera_Forum]

Yes its compiles, but it there is memory waste. i get the same warnings. 

if you compile a cyclone II fir for a cyclone III then i would expect that the amount of memory would be the same, and the numer of memory blocks would be less due to M9K instead of M4K. but the number of memory blocks used is the same. for each M4K a M9K is used. so if your cyclone II design uses 36 M4K blocks then it will use 36 M9K. so i copied the fir stuff to the cyclone III project folder and run the wizzard again, only changing the target. and ... now the same design uses less memory blocks.  it is clear that the amount will not be half as it depends on the fir.  but if both versions produce correct results ... the pcb with a cyclone III is currently in the fab so i have to wait until i can test that, and meanwhile ... quartus 8 is on its way ...

[Altera_Forum]

It may be instructive to check, how the RAM blocks are actually utilized in your design. Particularly with FIR filters, there may be a problem, that RAM blocks are used incompletely, in other words that some address lines of a 36-bit RAM blocks are unused. In this case, migrating from CII 128x36 bit blocks to CIII 256x36 blocks doesn't reduce block count respectively increases waste of memory. Coming Quartus V8.0 couldn't change this behaviour in any way.

[Altera_Forum]

I agree with you FvM but looking at our target, recompiling for C3 leed to around 20 M9K Blocks less than the C2 FIRs used. 

 So as i have set whenever possible to AUTO to use what M?K could be used freed a lot of M9K over all. So still FIR is currently the last that needs to be handled different.  But i saw the FIR 8.0 pdf and there both coefficient and data storage has the option auto ... maybe this is what i was looking for

[Altera_Forum]

Is this a parallel FIR? Assuming each memory block feeds a tap of the filter, you're not going to use any fewer memory blocks when they're 9k than you would when they're 4k in size. In a fully parallel FIR, each memory block provides one coefficient or one data item each clock. Unless you do something special like running the memories at 2x the filter speed and sharing the outputs across two taps, you're going to be limited by the number of memory ports needed, not the amount of memory bits.

[Altera_Forum]

This sounds logical, so what about multi cycle filter as i use them ?