cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
7,122 Views
Registered: ‎02-26-2015

MIG-core for DDR3 in Virtex-7 hangs after every other reset and slow read performance

Hi all,
 
I'm having troubles with the MIG core for a DDR3 SODIMM module (see details below). This core does seem to hang every other reset and when it is working, read acces over the user interface to the core is extermely slow.
 
Reset problem:
After the first reset of the core it is usually possible to perform a few (usually something like 3) read cycles over the user interface. When performing a single read command, the core is extremely slow in asserting the "app_rd_data_valid" signal. This can easily take up to 600 (!) clock cycles of the user interface clock! After a few single read commands, the core does not assert the "app_rd_data_valid" signal anymore at all.
Another reset is then necessary. Now the core will not hang anymore, but it is still slow. Assertion of the "app_rd_data_valid" signal varies between 40 - 130 clock cycles after the command is accepted by the core.
 
If the core is reset again, the whole thing starts over, the core will hang after a few accesses and needs to be reset again.
 
Performance:
As described above the performance on read access is extermely poor when doing single (isolated) read access. Things get a little bit better when doing consecutive read accessess (address incremented). When issuing 8 consecutive read commands, the "app_rd_data_valid" signal is asserted after some 40 clock cyles for the first 6 words, for the last 2 words it takes something like an additional 140 clock cycles.
 
Generating the core with 'NORMAL' or 'STRICT' ordering does not seem to make any difference.
Resetting the core twice without doing read access after the first reset does not help. It seems that the core MUST hang before issuing the second reset in order to make sure it will not hang after reset ....
 
The behaviour and perfomance obeserved in system is a world apart from my simulations ..... :-(
Does anyone have some hints or tips on what could cause the hanging and the poor performance?
 
Thanks!
 
Best regards, Filip
0 Kudos
4 Replies
Highlighted
Xilinx Employee
Xilinx Employee
7,112 Views
Registered: ‎07-11-2011

Hi,

 

For performance improvements please go through below AR and links with in it.

http://www.xilinx.com/support/answers/63234.html

 

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.

 

Regards,

Vanitha

---------------------------------------------------------------------------------------------
Please do google search before posting, you may find relavant information.
Mark the post - "Accept as solution" and give kudos if information provided is helpful and reply oriented
0 Kudos
Visitor
Visitor
7,104 Views
Registered: ‎02-26-2015

Hi Vanhita,

 

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.

 

Best regards,

 

Filip

0 Kudos
Highlighted
Visitor
Visitor
7,082 Views
Registered: ‎02-26-2015

Hi all,

 

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).

 

Best regards,

 

Filip

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
7,065 Views
Registered: ‎07-11-2011

Hi,

 

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.

 

Regards,

Vanitha

---------------------------------------------------------------------------------------------
Please do google search before posting, you may find relavant information.
Mark the post - "Accept as solution" and give kudos if information provided is helpful and reply oriented
0 Kudos