11-06-2018 10:11 AM
Is there a bug with the DDR3 IP, mig_7seriess:4.0.
I send in 4 app_en during app_rdy=H with a read command to the memory controller interface and most of the time I get back 4 app_rd_data_valid=H.
But sometime I only get back 3
11-07-2018 08:01 AM
I ran a continuous loop where I keep reading the same 4 address in DDR3 memory.
My sequence is to send 4 app_en when app_rdy=H then wait for 4 app_rd_data_valid then repeat this sequence.
after a while ( a few second) the memory controller doesn't return any app_rd_data_valid signal
11-08-2018 10:01 AM
Please upload your waveform so it can be analyzed.
11-08-2018 10:13 AM
I found the issue, it was subtle but since the refresh occur so often, even though the rdy=h it drop the same time which coincide with my en=H
11-08-2018 10:52 AM
How often does XiIlinx memory controller DDR3 refreshes because I noticed that APP_RDY occur very often periodically.
I assume this is because it is refreshing the memory. It was measured (ILA) at 977 ns.
Is this the refresh rate at 977 ns. This is very fast. I thought it is normally it is 7.8 us?
11-08-2018 12:25 PM
There are only a few reason we de-assert APP_RDY as found in PG150:
11-08-2018 12:56 PM
The app_rdy from the ddr3 memory controller is pulsing continuously at a period of 997 ns when there is no user activity.
pulse is 15 ns low.
Since I'm not generating any request this pulsing should come from the memory controller during refresh mode. Where else could cause this? It is very frequent.
11-08-2018 12:59 PM
Please provide your waveform so we can look into this issue.
11-08-2018 01:19 PM
11-13-2018 11:25 AM
Hi, based on the request and what I send to you, any idea why the interface ddr signal app_rdy pulses so frequent?
11-16-2018 12:41 PM
I have looked at your ILA data. As I thought, there is not enough information included to understand why the reset is triggering to often. A simulation will be the only way to understand the problem as I will be able to traverse throughout more transactions. There is something in your traffic pattern that is causing this issue, but I can't tell from the original waveform or this ILA capture. Make sure that you log ALL signals in your next simulation before uploading it.
11-16-2018 12:56 PM
What signal do you need.
The only signal that affects the MIG IP controller APP_RDY are the
APP_EN, , APPCMD, APP_ADDR,
APP_WDF_WREN, APP_WDF_END, APP_WDF_RDY
From my hardcopy waveform, it shows all that.
There aren't any signal that could affects the APP_RDY from pulsing so often.
The other side on the controller go directly to SODIMM which is the MT8KTF51264HZ
11-16-2018 02:03 PM
You are correct. Those are the signals I need to analyze. The waveform you sent doesn't have these signals logged at the u2 level (which is the ddr3 controller) or at the u8_ddr3 level. I have traversed all through your hierarchy and do not see data. Are you sure you logged your simulation properly? If you could please "Log All Signals" during simulation and send that WBD, then we can continue debug.
11-16-2018 02:11 PM
Strange, when I open the WDB file, I also do not see all the waveform.
I did a save before I generate this wdb file.
actually when I read this into vivado, it doesn't even shows the waveform window. it only show the object window. I never use this file before therefore i could have miss a step or two when saving and opening it.
All I did was a save then an open
11-26-2018 09:51 AM
Attached is the ILA save result . this shows all activity with SODIMM from ddr3 controller.
The rdy signal is occurring very fast as mentioned
12-06-2018 12:42 PM