How to make NCO compiler use M9K blocks and not M144K

[Altera_Forum]

I am using the NCO compiler V10.1 to generate a ROM based NCO. I am using a stratix IV (EP4SE230F29C2) device.  

  According to both the manual and the wizard itself, the ROM should be implemented with M9K memory blocks. But to my disappointing surprise, it is implementing the NCO with M144K blocks. The NCO compiler manual even provides resource estimates in terms of M9K blocks.  Yet the compiler is ignoring its own estimation and goes on to use only M144K blocks. This is a major problem. I am instantiating multiple NCOs and the design won't fit. I have all the M9K blocks available in the world but the tool is insisting on using the M144K, which I don't have enough. Does anybody know what to do? Is this [yet] another Quartus II bug, or is there some hardware limitation here?

[Altera_Forum]

try Assignments > Settings > Analysis and Synthesis Settings > More A & S Settings > Max number of M44K Blocks maybe in addition to (imported) partitions

[Altera_Forum]

Thanks, I tried playing with the "Max number" settings. It doesn't help. It insists on using M144K blocks only.

[Altera_Forum]

i confirmed with a single NCO core before i posted. it used M144K until i set the number of blocks to 0, in which case it used M9K

[Altera_Forum]

i'm also using 10.1 (Linux, Subscription)

[Altera_Forum]

have you tried LogicLock?

[Altera_Forum]

Interesting. I tried it also but it fails for me. "can't fit design". I am using the windows version. 

 What can I do with LogicLock?

[Altera_Forum]

maybe reduce the design down to 1 NCO to see if you can get that to fit to M9K, then scale it up 

 with LogicLock you can define fixed regions for each NCO instance which contain the specific number of memory blocks needed

[Altera_Forum]

I did reduce it down to 1 NCO and it didn't work. That's what I was referring to above.

[Altera_Forum]

hmm, can you post the NCO specs or else the variation .v/.vhd

[Altera_Forum]

It's a Large ROM based NCO, 32 bit accumulator, 16 bit phase resolution, 14 bit amplitude resolution, single output, no modulations, no dithering. I use VHDL.

[Altera_Forum]

i see the problem now. it doesn't happen in Small ROM but does in Large ROM

[Altera_Forum]

Thanks. I'll try it also a little bit later to confirm. But this is still a problem. I need the large ROM because I can't spare the latency.

[Altera_Forum]

i think the problem is the deep RAM in the Large ROM, still taking a look

[Altera_Forum]

i think Quartus doesn't want to put a 64k deep RAM into M9K because it would need an 8:1 mux (8 M9K in 8k x 1b) 

 using M144K you can go 16k deep, so you only need a 4:1 mux (4 M144K in 16k x 18b/19b)   you can file an SR, at this point i think the issue is synthesis, not the actual NCO IP. i expect a significant fmax hit if you got the synthesizer to use M9K instead of M144K. what speed are you targeting? any way to trade fmax for latency?

[Altera_Forum]

Thanks, 

 Ok, I see this now also. But it seems that anything beyond around 2K deep it switches to M144K.   I need to run at about 268 MHz. I probably can afford the trade-off (let fmax take a hit). The synthesis should allow you to make that trade off.

[Altera_Forum]

i guess i was wondering whether you could run the NCO at double the frequency to try and compensate for lost latency in Small Table mode 

 i would probably write my own NCO at this point. you are using the easiest mode to recreate and none of the additional features. i don't think you'll get synthesis to use the RAMs as you'd like, so you'll have to stitch them together yourself

[Altera_Forum]

Thanks for your help. I opened an SR anyway.

[Altera_Forum]

it would be a nice synthesis enhancement, but i don't know exactly how you'd implement it