I am using ddr3 in my project, i need high throughput as much high as possible. My ddr3 part number is in the following link https://www.components-store.com/product/Micron-Technology/MT41J128M16JT-125-K.html
I am using the following fpga 5AGXA7G4F35I5
The max frequency for ddr3 operation right now i could able to acheive without any glitches in the data is 450MHz using Hard and soft EMIF IP, beyond that I couldn't able to get good outputs. but EMIF spec estimator saying max is 533MHz using Hard IP. May i know why my code not working even for hard ip, i don't see in my project much of timing errors also regarding that.
Sincerely sorry for the delay in response due to workload.
Thank you for the confirmation. I just want to make sure that it is not 2 CS.
Back to your question, you are saying that you are only able to get good output without any glitches when clock frequency is 450MHz. May I know how you see the glitches? Are you probing the EMIF pins? Did you run the calibration? If yes, is the calibration passing?
I am not doing calibration at all. after generating .sof directly testing on hardware. Just seeing timing analyser before that for any problems. May i know how to do calibration..? And for 500MHz, it's working properly initially and after the fpga core temparature rising by 70c or more then i can see glitches in the data captured for it.
Rightnow i did calibration for 450MHz clk for ddr3 and 533MHz for the same.. I can see some differences between them. But both reports calibration pass where as for 450MHz data captured is fine, 533MHz not fine(glithcy), can you review once and explain more about the situation because in online they are giving some FAQ for calibration failure only but my case is like calibration pass but data not good. RIght now I am using Altera's default settings for board and memory timing in EMIF IP. CAS Latency for read given as 11(max available), for write given as 8(max available)
Thank you for sharing the calibration result.
Based on past history, we did experienced glitches issue impacting the DQS as shown in the KDB here-->
I can see you are using Quartus version 16.1.2 Build 203, so it should be no problem.
The calibration is passing but the issue is more to signal integrity (SI). To be honest, there are many possible factors that can lead to SI issue. It could be due to your board termination, PCB routing, external noise, temperature, IP setting, board skew,.. etc. I will try my best to guide you and hopefully it helps.
My suggestions are as follow:
1) Please make sure the memory timing is fully comply with memory datasheet. Please note on the following dependent setting (picture is taken from other Quartus version). As you can see there are setting that depend on the frequency and temperature as well, thus it is important to make sure DDR3 settings and timing parameters in the GUI match the device specs in datasheet.
2) Next is board settings. As u mentioned, you are using the default setting in he GUI. The Altera default setting are representative for specific Altera’s board. Intel recommended to change this value based on your board level effects. Refer below:
- “Channel Signal Integrity”: This can cause signal distortion and reduction to timing margin. I recommend you to perform simulation and enter this value accordingly.
- “Board Skews”: This also another cause for reduction in timing margin. As the frequency increase, it is important to make sure this board skews are accurate during IP generation. Please use the latest board skew parameter tool to accurately calculate the board skews: https://www.altera.com/solutions/technology/memory/estimator/board-skew.html
- Same apply with the “Setup and Hold Derating” section.
I strongly believed you are using the correct termination at your board but just a double check. Please verify that the RZQ pin resistor is the correct value. For DDR3, the FPGA RZQ pin should connect to GND through 100 ohm resistor. For DDR3L, the resistor should be 240 ohms to GND.
You may find it useful to run the example design simulation and look at the waveforms to help understanding. 😊
Let me know if there is any concern.
For your information, I am doing all this project and .sof generation in 14.1, just because system console in my windows 10 machine for 14.1 has a problem and not able to connect, this debug alone I did in 16.1.2. And my fpga part number is 5AGXA7G4F35I5.(fpga fabric speed grade 5)
Thank you for the information. Just an extra sharing on below.
Please noted on the Core-to-Periphery (C2P) timing miscorrelation affecting Arria V and Arria V SoC. The timing model update is not included in Quartus version 14.1, you have to apply workaround as mentioned in below KDB:
I acknowledge that the timing is clean at your side, but just to be safe, i suggest you to consider using Quartus version 15.0 Update 2 as the timing model is included automatically and user doesn't need to use the workaround.
Thanks for the suggestion. I applied the patch required for the tool and seen the timing. The Timing is fine. I mean for a working 450MHz and not working 533MHz I see the timing same. So, regarding the other suggestions you mentioned above I am trying still. I will come back to you as soon as I get some result.
Any other suggestions you have.. I request you also to check EMIF Spec estimator mentioned above for the fpga part number I gave.