Arria 10 M20k block usage- More block with less memory bits?

Are you saying on the original device you used *exactly* the number of M20K blocks available, 2713? That is quite a feat.

As for why it may need more now, it really depends on how you are implementing the RAM. It may not be able to be optimized exactly the same way it was on the original chip.

Showing some code might help.

Can you attached both of your design for our investigation?

Hi, no I can't send the design it is proprietary.
Can you point me to any Quartus reports or settings that might shed some light on this?

Another point of information. If I further reduce memory usage to 30,466,048 which is a reduction of 2,495,320 it is suddenly able to fit and uses all 2131 M20k blocks. But somehow the design with 32,961,368 bits needs 2845 blocks? That's a difference of 714 M20k blocks or 14,280,000 bits but I only needed 2,295,530 bits.

This is really not adding up for me.

Thanks again.

Hmm, the number of bits mentioned doesn't seem correct. M20K represents 20Kbits = 1024*20 bits

To use all of 2713 M20K your design would need to use:

1024*20*2713 = 55562240 bits

To use all of 2131 M20K your design would need to use:

1024*20*2131 = 43642880 bits

Perhaps you got the array size or index calculation wrong?

Here is some of the key Quartus Reports to Check

1. Fitter Resource Usage Report (.fit.rpt)

Location: quartus_fit_report.html or in the Quartus GUI under Processing → Compilation Report → Fitter → Resource Section → RAM Summary

What to Look For:

Compare how many M20K blocks are used in both the working and failing designs.

Look for any significant changes in RAM block utilization patterns.

Identify whether certain RAMs suddenly require multiple M20Ks instead of fewer.

2. RAM Classification Report (.ram_summary.rpt)

Location: Quartus GUI → Fitter → Resource Section → RAM Summary

What to Look For:

How Quartus is mapping logical RAMs to M20Ks.

Whether the Fitter is splitting memories into multiple blocks inefficiently.

3. RAM Packing Efficiency (.fit.rpt)

Location: In the Fitter → RAM Summary section of the report.

What to Look For:

If Quartus is failing to pack RAMs efficiently in the smaller device.

Look at the average block utilization to see if it has dropped.

4. Post-Mapping Resource Usage (.map.rpt)

Location: quartus_map_report.html or Quartus GUI under Processing → Compilation Report → Synthesis → RAM Usage

What to Look For:

How Quartus initially assigns memory to M20K blocks before placement constraints.

This can highlight unexpected fragmentation before the fitter even runs.

Possible Causes Based on Your Observation

Fragmentation Threshold Effect

Quartus could be fitting RAMs optimally up to a certain utilization threshold but then failing when the M20Ks get too full.

Instead of packing smaller memories efficiently, it breaks them up inefficiently across additional blocks.

Auto-Merging of Smaller RAMs

Quartus sometimes merges small RAMs into single M20Ks for efficiency.

If you crossed a memory limit where it can no longer merge, it may be splitting these into extra M20Ks instead.

FIFO Depth Adjustments

Since you have FIFOs and instantiated Block RAM, check if Quartus is suddenly adding padding or increasing depth beyond what’s needed.

Address Width Misalignment

If a change in memory size increased an address width (e.g., from 9 to 10 bits), it could be using more M20Ks to store extra address bits.

Quartus Settings to Try

If the reports show inefficient memory packing, try forcing Quartus to optimize RAM placement:

Disable Power Optimization (Which Can Impact Packing)

Quartus setting -> advance fitter setting -> power optimize during fitting -> Off

Sometimes Quartus optimizes power at the cost of more RAM blocks.

Force Specific RAM Implementation (If Quartus is Mapping Poorly)

set_instance_assignment -name AUTO_RAM_REPLACEMENT -to <ram_instance_name>

set_instance_assignment -name Infer_Ram_from_raw_logic -to <ram_instance_name>

Look for the setting that you can play in the advance fitter setting or advance synthesis setting.

Hi,

May I know is there any further update or concern?

Thanks,

Regards,

Sheng

Sorry for the late reply as I am off for a week

The fact that the smaller Arria 10 design isn't using any MLABs while the original one does is likely the root cause of the extra M20K block usage. MLABs (which use ALM-based memory) help offload some RAM demand from M20Ks, so their absence forces Quartus to place everything in M20Ks, explaining the increased block count.

Possible Reasons MLABs Are Not Being Used

Even though the MLAB-related settings match between projects, there are a few other factors that might be preventing Quartus from using MLABs in the smaller device:

1. MLAB Utilization Can Depend on Fitter Heuristics

Even if "Auto RAM to MLAB Conversion" is ON, Quartus still makes a decision based on available resources and timing feasibility.

Since the smaller device has fewer ALMs and M20Ks, Quartus may have chosen to disable MLAB usage to meet timing or placement constraints.

Check in the Fitter Report

Look at the MLAB Utilization section in .fit.rpt in both projects and see if Quartus states a reason for not using MLABs.

Quartus may be rejecting MLABs due to high logic utilization or routing congestion in the smaller chip.

2. Synthesis and Fitting Differences Due to Chip Resource Constraints

Since the smaller FPGA has fewer total ALMs, Quartus might prioritize ALMs for logic instead of MLABs for memory.

If the larger FPGA had excess ALMs, Quartus may have felt comfortable assigning MLABs, but in the smaller FPGA, it might reserve ALMs for combinational logic instead.

Check Logic Utilization

Open Fitter → Resource Usage Report and see if ALM usage is significantly higher in the smaller device compared to the original.

If ALM utilization is high, Quartus might be avoiding MLABs to prevent routing congestion.

3. Memory Depth and Width Constraints for MLAB Usage

MLABs can only store 32-bit wide words with a depth of 640 words. If Quartus synthesized the RAM slightly differently (e.g., with increased depth/width due to address alignment constraints), it may have disqualified MLAB usage.

Check RAM Depth & Width

Look at the RAM Summary Report (.ram_summary.rpt) and check if:

Quartus changed the width or depth of certain RAM blocks.

Some RAMs that previously fit in MLABs are now too deep or too wide.

Manually force certain RAMs to use MLABs and see if Quartus accepts it

set_instance_assignment -name RAM_BLOCK_TYPE MLAB -to <ram_instance>

4. MLAB Timing Constraints Might Be More Strict in the Smaller FPGA

MLABs have higher access latency than M20Ks. If Quartus detected that using MLABs would violate timing constraints (especially due to tighter placement in the smaller FPGA), it may have disabled their use.

Check Timing Report

Run a Timing Analysis (.sta.rpt) and check for MLAB-related timing violations.

If Quartus is failing to meet setup/hold timing with MLABs, it may have automatically forced all RAMs into M20Ks instead.

Is there any further queries?

Hi, I'm still digging through this as time permits. I will update later today or next week.

I am still skeptical that any of the above listed options will explain the current problem but I will check them all.

Thanks

Understood, let me know the feedback by end of the week.