Forum Discussion
Hi Gerhard,
Thank you for your detailed feedback and for sharing your experience across device families and Quartus versions.
Regarding the clock enable issue for RAM 2-port IP generation on Stratix 10 and Agilex 5: The behavior you observed—where enabling clock enables for read input/output registers is not supported in dual clock mode—is consistent with the hardware architecture differences between Arria 10 and newer device families (Stratix 10/Agilex 5). As noted in the Stratix® 10 Embedded Memory User Guide, independent clock enables are supported for certain modes, but the direct configuration you achieved on Arria 10 is not fully available on Stratix 10 and Agilex 5 due to these hardware changes.
The Quartus IP GUI restricts these settings to prevent unsupported configurations. While manual netlist modification may work for simulation and, in some cases, implementation, we strongly advise against this for production hardware, as it may not be reliably supported and could lead to unpredictable behavior.
For true dual-port, dual-clock RAMs requiring independent clock enables on both ports (as in your RX/TX FIFO application), the recommended approach is to use the emulated true dual-port (TDP) mode described in the Stratix 10/Agilex 5 Embedded Memory User Guides. This mode is designed to provide Arria 10-compatible behavior, though it may require some adjustments in your design flow.
We appreciate your efforts to test and validate in simulation and encourage further hardware testing if you proceed with manual modifications. However, for long-term robustness and supportability, we recommend adhering to Quartus-generated IP configurations and using emulated TDP mode where necessary.
Thanks
Best regards,
Kenny
Hi Kenny,
thank you for your detailed answer and explanation. Actually switching to emulated true-dual port RAMs is no option due to the following reasons.
- The RAMs are part of our IP cores (Ethernet MAC and PTP clock/timestamping). We would be forced to create a specific IP core version just for the mentioned Altera FPGA device families. All other FPGA devices from other vendors have no issue with that. This would a require huge technical and organizational effort to create and maintain such an vendor specific IP core variant
- According to the documentation the emulated TDP require a fixed assignment of a faster and a slower clock. While this e.g. is easy to achieve for a 100/1000 Mbit MAC its impossible for a 10/25 Gbit MAC. It fully depends on the application whether the CPU frequency is faster than the line frequency or slower.
- According to the documentation the emulated TDP require a clock ration of 7:1 or higher. Again, this requirement cannot be met. The typical frequency ratios are 1:2 to 2:1
I don't know how to resolve this issue. For now it inhibits us to provide the IP cores on Altera's latest technologies.
Best regards
Gerhard
- KennyT_altera4 days ago
Super Contributor
Is there any further question?
- GerhardCadek3 days ago
New Contributor
Hi Kenny,
there are a lot of questions but I guess it does not make sense to ask why this important feature had been removed from the block RAMs. OK, one might saved some design effort when designing the block RAMs on silicon. From the user point of view this feature is one of THE FPGA features required. We are dealing with huge silicon devices today that are inherently not synchronous any more. Network on chip, vast amount of AI processing units. All this requires communication elements to connect a lrage amount of synchronous sub-systems - dual--port dual-clock RAMs. But I assume its useless to have this discussion.
For us there is a decision. We are creating a work-around in logic. While this will work on functional level it clearly degrades the RAM performance as we have to use standard routing (and routing algorithms). So, when it comes to performance we cannot use Altera FPGAs for this purpose.
Thank you Kenny, for your support!
Best regards
Gerhard