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

[TSchu3]

Hello I have a design that fits on the Arria 10 GX dev board with chip 10AX11552F4sI1SG  which has 2713 M20K blocks.
The total memory bits for this design are 36,171,984,  all 2713 blocks are used.

I am moving this design to a smaller Arria 10, 10AX066H2F34I2sG, which has 2131 M20K blocks.
I reduced the memory usage to 32,961,368 memory bits, BUT here is where I am getting really confused. The fitter fails and says it now needs 2845 M20k blocks more than the design when it used 36,171,984 memory bits.

How can  the same design, with reduced memory, need more M20k blocks than the original design?  Any suggestions are greatly appreciated.

This project is being compiled in Quartus Pro 23.4.0.

[KennyTan_Altera]

Unfortunately, Quartus does not provide a user-accessible setting or report that lets you explicitly choose or see whether "AUTO" is operating in a "Best-Fit" or "Safe-Fit" mode.

[KennyTan_Altera]

Do you have more question>

[TSchu3]

I remain very unsatisfied with the proposed possibilities.  The most recent ( Best Fit vs Safe Fit) cannot be confirmed or checked.  I also don't even have a definition for the two options.

Either way it does nothing to explain why the Quartus compilation claims that the design needs MORE memory bits on the small chip than on the larger (see my first post).  If we had a situation where the smaller chip did not fit but the number of memory bits required was consistent then I could understand why it wasn't working.  But that is not the case.

[KennyTan_Altera]

I’m truly sorry to hear that you're unsatisfied with the answer. 

Unfortunately, without access to the design, it will be challenging to narrow down the issue precisely. However, here are some additional key considerations that might help you troubleshoot the increased M20K usage:

Understanding Device-Specific Fitting Differences

Different Architectures Affect Fitting Strategies:

• M20K Usage Variation:
• The way Quartus utilizes M20Ks is device-specific and influenced by the internal architecture of the target FPGA. Even for the same design, different devices may lead to different allocations of M20Ks, logic elements (LEs), or MLABs.
• Trade-offs Between M20Ks and LEs:
• Quartus may adjust the balance between M20K usage and LE-based logic, depending on constraints and heuristics tied to the target device.

What This Means in Your Case:

• On the larger FPGA, Quartus had more routing flexibility, allowing it to optimize M20K usage more efficiently.
• On the smaller Arria 10 FPGA, Quartus might be adopting a more conservative approach, leading to less efficient packing and a higher M20K count. This could cause some RAMs to shift unnecessarily from MLABs (logic-based memory) to M20Ks.

Suggested Actions to Improve M20K Usage

1. Specify RAM Type Explicitly with the ramstyle Attribute:
2. This attribute can guide Quartus to optimize M20K or MLAB usage more effectively.

• For Critical FIFOs (Reduce Wasted M20Ks):
• Use the following directive to maximize M20K usage and avoid inefficient logic consumption:
• (* ramstyle = "no_rw_check, M20K" *) reg [31:0] my_fifo_ram [0:1023];
  • This forces Quartus to reuse partially filled M20Ks instead of allocating additional, unnecessary blocks.
• For Small RAM Instances (Shift to Logic):
• To avoid over-consuming M20Ks for smaller RAMs, encourage Quartus to fit them into logic:
• (* ramstyle = "no_rw_check, logic" *) reg [31:0] small_ram [0:63];
  • This can help reduce M20K usage by utilizing available logic resources instead.

1. Review MLAB Usage Settings:
2. If Quartus isn’t efficiently using MLABs (640-bit blocks), explicitly specify them for smaller RAMs and FIFOs:
3. (* ramstyle = "MLAB" *) reg [31:0] my_small_fifo [0:31];
4. This helps offload memory from M20Ks to MLABs, improving overall resource balance.

Next Steps for Verification:

Once you’ve applied these strategies, check the following to evaluate their impact:

• RAM Summary Report and Fitter Report:
• These reports will show whether M20K usage improves after modifying the RAM style.
• Chip Planner Analysis:
• Open the Chip Planner tool to inspect how memory blocks are packed. Look for any inefficient packing or routing issues that might be contributing to inflated memory usage.

By applying these adjustments and reviewing the updated reports, you may achieve better memory resource optimization in the smaller FPGA.

[KennyTan_Altera]

Does the above recommendation help?

[TSchu3]

Yes, it does help to an extent.  I can manipulate Quartus into using different types of memory or logic on a component by component basis.  This is very time consuming and not really scalable.  Any changes to the design require additional requirements.
It seems to be the best we are going to get at this time, since I am un-able to send the design to you for review.

Thanks

[KennyTan_Altera]

Understand that manually adjusting each component is not a scalable long-term solution. A more efficient approach is to explore global settings, macros, or scripting to minimize maintenance overhead. Future versions of Quartus may introduce improved heuristics to address this issue more effectively. However, without a project available for experimentation, testing and refining scripts is currently not feasible. This remains a limitation we can manage for now.

[TSchu3]

Thanks for all the follow ups and suggestions.  I have no further questions at this time.

[KennyTan_Altera]

I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, Please login to ‘https://supporttickets.intel.com/s/?language=en_US’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.