10-28-2020 05:55 AM - edited 10-29-2020 07:30 AM
We have an Artix7 design which has a MIG IP with two DDR3 controllers, and have noticed some signal integrity issues with a PCB batch so have reduced the memory speed from 400MHz (2500ps) down to to 350MHz (2857ps) which helped with the issues we were seeing. However we then noticed that at the slower speed the AXI bus would occasionally lock up, after some debugging with various ILAs it showed that the MIG controller was generating a single clock wide RVALID signal when no read cycles had been issued on the AXI bus.
We first saw this using Vivado 2017.2 running on Windows 10, but have upgraded to 2020.1 and are still seeing the same issue.
Both controllers in the MIG are configured the same, DDR3, 16bit wide components, 200MHz input clock, with the clock period set to 2500ps on both it works fine, but when both are set to 2857ps we get the erroneous RVALID.
The 4 CAM AXI busses are write only, CAM1 is configured to only write to C0_DDR3, and the 3x CAM2 to only write to C1_DDR3. The HWJPEG & PCIE AXI busses can read and write to both DDR3 controllers. On start up the 4 CAM AXI busses will start writing data, but the HWJPEG & PCIE busses will only do anything when controlled by the application running on the host CPU. For the testing the host application isn't running so the HWJPEG & PCIE AXI busses are idle, so only write cycles should be happening.
Sometimes on start up it works normally and the RVALID isn't generated, but sometimes (about 1 in 3 resets) the RVALID would be generated and lockup the AXI bus.
Attached is the block diagram and a screen capture of the waveform showing the RVALID without a read cycle.
Any thoughts about why the RVALID is being generated without a read cycle?
10-28-2020 06:51 AM
I had a very similar problem some time back. After doing a lot of chasing it down, it appears as though the memory controller issues reads as a way of keeping the PLL locked. If your memory's delay doesn't match what the memory controller is expecting, you'll get an RVALID you aren't expecting. Bottom line: make sure all the timing's match what the MIG controller is expecting, and these extraneous RVALID's should disappear.
10-29-2020 02:07 AM
Thanks for the information. Looking into it, the MIG controller was set for using MT41K256M16XX-125 devices although some time ago we switched to using -107 devices but never noticed any issues then. It seems as though we have now switched to Kingston equivalents instead of the Micron -107 ones and that seems to be the issue. I have changed the MIG to target MT41K256M16XX-107 now and it has improved a bit with the Kingston chips, so think I'll have to delve deeper into the Kingston datasheet to see if there are any difference in the timings.
10-29-2020 06:35 AM
It looks like the Kingston DDR3 devices just aren't compatible with MIG IP, the device used is D2516ECMDXGJDI-U (256Mx16). Going through the datasheet there doesn't seem to be any different timings compared to the Micron MT41K256M16XX-107, although the Kingston datasheet doesn't list all of the Micron ones. I have tried creating various custom devices in MIG and even with all the timings set to the slowest allowed it still doesn't work with the Kingston devices.
Has anyone else managed to get Kingston DDR3 devices working with MIG?