MIG (Memory Interface Generator)

[dguisinger]

Hey guys, I've got a problem I'm hoping someone with experience around the Virtex-5 and the DDR2 core could help me with.

I have a project for testing interfaces on my board, it includes a DDR2 and a QDRII interface. 

The Error signals are connected back to an LED on the design, if everything is reporting fine, it shows green, if there is a problem it shows red.

Every time I load the design, it starts out working okay.  The DDR2 interface comes up green.  As my temperature reported reaches about 75C (according to chipscope), the memory interface is failing.  This is rather odd, its within the stated temperature range of the part.  If I quickly reload the design, it comes back as working momentarily and then fails.... however if I let the part cool for 5 minutes and try again, it lasts the three or four minutes until 75C is reached and fails again.

Any ideas?

Does the calibration of the IDELAYs need to be adjusted as the chip gets warmer? 

Could I not be closing timing and be getting lucky at lower temps but running into problems once the chip warms up?

Before finishing this post I just performed an additional test using lung power to keep the design below 65C.  The core performed perfectly and didn't fail during the 10 minutes I tested it.  The only thing that failed that time was by ability to see straight ;)

[dguisinger]

I'm sorry, thats MIG DDR2 core v2.3 not v2.4.

[jschmitz]

What frequency are you running the interface at?  What speed grade device are you using?  Does the QDR II interface have any difficulties?  What happes if you just reset (not reload) the design while it is at 75 degrees?  What is the initial temperature before it heats up?

[dguisinger]

The initial temperature is about 34C I believe if I turn the chip on cold.  I've actually currently pulled the QDRII interface out while trying to nail this problem down.  I've got two identical boards, one appears to lose the DDR2 at 75C, the other at 79C.  I am currently using a LX30T-1C so I've trying to run it at 266MHz, though MIG says it should be capable of 333MHz if i change the speed grade with its current design, and I would like to keep that headroom.  The design also appears to refuse to re-calibrate upon reloading unless I wait for the temperature to drop back down into the 30's before reloading the bitstream.

I have 3 timing failures with the MIG 2.3 constraints.

They appear to all be on u_iddr_dq_ce to the following:

gen_dq[1].u_iob_dq/gen_stg2_0s.u_iddr_dq

gen_dq[0].u_iob_dq/gen_stg2_0m.u_iddr_dq

gen_dq[1].u_iob_dq/gen_stg2_0s.u_iddr_dq

 and they all seem to be setup time failures with a slack of -0.229ns  (that is approximately 10% of a DDR cycle, or 5% of the clock)

I've also stuck a fan on there this afternoon (just in front of it, still no heatsink) and have seen the DDR2 stay completely stable for several hours at 71C, so it is definately temperature specific. 

I am in process right now of completely upgrading my core to MIG v3.2 , I do see there were some calibration changes for reliability (the release notes don't list what that actually means)

I previously had this stable on my previous pcb revision, nothing changed in the DDR2 area.  I was previously jumping the core voltage on Rev A which did lead to a gradual decrease in core voltage while the current across the jumper wires increased with time due to the FPGA heating up...so its possible this problem was hiding if the FPGA core voltage was running low but you can imagine my surprise this time around.

[dguisinger]

Alright, I got some improvement this evening though I'm still not there.

I was able to reach 85-86C before the DDR2 cut out.  That is commercial grade limits, I'm tempted to say yes, the interface works but feel there is room for improvement on the timing (if it is possible)... and thats cutting it awfully close.  It also still refuses to recalibrate when warm, or if it does recalibrate loses it at a much lower temperature if I didn't wait to reload at an idle / no bitstream temp.

When I upgraded from v2.3 to v3.2, the slack tightened up a tiny bit on the 3 signals I listed previously.

It is now down to about -0.175ns out of spec instead of -0.229ns. 

Those paths are connecting to ILOGIC resources on the last 3 pads of the bank (i.e. DQ0, DQ1, DQ2), which again makes some sense if this is a timing issue at high temps.

Any ideas? 

[jschmitz]

Something is wrong if it doesn't calibrate at a specific temperature within the normal operating range.  The V5 does not recalibrate after the initial calibration, but that should not matter here.  Also, temperature usually has a smaller effect than voltage.

Have you hooked up to the debug signals to see how the calibration fails?  Have you simulated the board to check signal integrity?  Checked Vref and and the terminations?

Which specific signals are not meeting timing?  High temperature could indeed be an issue for these if they are critical signals.

http://www.xilinx.com/support/documentation/ip_documentation/ug086.pdf does have a debug section that might be helpful.

[dguisinger]

Thanks.  The calibration problem appears to have gone away now that I got the timing almost within spec and I've been able to reach higher temps as well.

I'm to the point of where moving the DQS gate up an I/O block causes the timing violation to move to a different I/O, leaving it where it is currently at gives me the smallest timing violation I've seen yet.  

Actually I have read that 8-bit interfaces are the optimum, this is a 16-bit interface.  Beyond that there is also reference to the DQS gate being the critical path and it apparently is impacted from what i've read by slower propagation at higher temperatures.  I was mainly running to test that it worked at 85C, i've gotten the boards to reach 85C with the newest changes, though pushing beyond that some fail immediately and others don't.  It appears to be bumping against the limit of the chip.  I don't plan at running with a junction temp of 85C on a 1C chip, but I wanted to test it to the commercial limits.