06-23-2015 12:26 AM
06-23-2015 02:17 AM
For performance improvements please go through below AR and links with in it.
You mean core hang happens only in Hardware and not in simulation? Is calibration always successfull?
I hope you are monitoring calib_done siganl and your write/read requests are satisfying UG586 wite, read and command timing diagrams, please double check on the same.
Also to minimize as many variables as possible I would suggest to use example design, If the issue is reproducible and as this happens for reads, I suspect if DDR3 chip is responding properly with data strobes, double check if your read command reaches memory with external scope and monitor DQS.
Make sure you have met all the design guideliness specified in UG586.
06-23-2015 05:06 AM
Thanks for your reply!
The performance I'm experiencing is dramatically slow: latency on the user interface between an accepted read command and the 'app_rd_data_valid' going high is extreme and can easily go up to a few hundred clock cycles.
After the first reset I can read a couple of times from the core before it hangs. After the second reset the core keeps on working and data can be written and read reliably, although the performance remains (far too) low.
In simulation everything works fine, I would be very happy with the data throughput seen there. In simulation the core never hangs. This only happens in real hardware. I do monitor the 'init_calib_complete' signal, it always goes high after reset (normally this takes just under 6 seconds). As far as I can see the timing requirements for read and write commands are satisfied.
I will try your suggestion regarding the example design, although using an external scope may prove rather difficult...
In the mean time, if you have any further suggestions please let me know. It seems that there are a few more people experiencing hanging of the core during read cycles.
06-24-2015 02:39 AM
I've did some testing with the example design. First of all I ran a simulation of this design: on the user interface bus of the MIG-core it shows similar behaviour compared to my own design.
Then I downloaded the example design in my target board and observed its behaviour through the ILA debug facility. The example design runs normally (w.r.t. performance) for a short time, then it also hangs (but differently then my own design): a read command is being issued, but the 'app_rdy' remains low indefinitely.
In case that the example design also did show problems Vanhita's suggestion was that in this case the DDR module itself may be suspect. Luckily we did have a second target boad, so I downloaded the example design in the second board ... and it works like a charm! Then I downloaded my own design in this second board and this also works flawlessly!! It does not hang at all and the performance is fine (comparable to behavioural simulation).
So indeed it seems to be a hardware problem. In my opinion there are two possible causes:
1 - the RAM module on the first board is defective
2 - the RAM module on the first board is a different type then the second board. These two boards were not ordered at the same time, manufacturer may have used different SODIMM modules (we will investigate this).
06-24-2015 11:46 PM
Good that the issue is located,
But as you mentioned that the boards are manufactured at difefrent times, before confirming that the memory chip is bad, make sure controller commands are reaching the chip and power supplies and terminations, SI are all fine.