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

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.

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

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.

Does the above recommendation help?

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.

Do you have more question>

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.

Thanks for your feedback, here are some reasoning behind:

On the larger FPGA, Quartus has more total resources (ALMs + M20Ks) to distribute memory more flexibly.

On the smaller FPGA, it might prioritize M20Ks for timing, routing, or stability reasons, avoiding MLABs unless explicitly forced.

Different Default "Auto" Settings Per Device

Quartus may have different default optimization strategies for different device sizes.

Some device families default to MLAB for small FIFOs, while others default to M20K, even when set to "Auto".

MLAB Timing Constraints in Smaller FPGA

If Quartus predicted MLAB timing to be worse on the smaller FPGA, it may have avoided them unless explicitly forced.

The smaller FPGA may have different routing congestion issues that caused Quartus to prefer M20Ks.

Platform Designer Defaults Might Differ Per Target Device

The Platform Designer's "Auto" setting may not be purely a Quartus decision—it could be pre-optimized per FPGA family.

The larger FPGA might default to "best-fit" (MLAB + M20K mix), while the smaller FPGA defaults to "safe-fit" (M20K only).

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

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