LPC177x EMC and SDRAM conundrum

[lpcware]

Content originally posted in LPCWare by teeysensei on Mon Jul 09 02:04:10 MST 2012
Hi everybody!

I'd like to extend my greetings, since this is my initiation post and I hope someone could help me. I am pretty much in the same boat as sebgonzo in his thread (http://lpcware.com/content/forum/lpc1788-sdram-timing-problem), but I didn't want to hijack his thread for my problems.

I'm treading new ground here, working on a design with the LPC1776 harboring an SDRAM. I managed to complete my routing, and went on to try and verify my timings. This is where I got stuck.

Here is what I ended up with,

setup-margin = Tclk - Td - Tsu - TOF + Tskew
hold-margin  = Th(tx) - Th(rx) + TOF - Tskew

RAM Tac = Td = 6ns, Tsu = 2ns, Th = 2.5ns, all the other numbers are from the LPC177x/178x datasheet, page 85, command delayed mode table 19.

1.) Data write:

RAM(su-margin) = 12.5 - 7.3 - 2 - 0.2 = 3 + Tskew
RAM(h-margin)  = 0.2 - 1 + 0.2        = -0.6 - Tskew

Right, so we can solve that with the EMC getting clocked last - a negative clock skew. There's enough room in setup, or use command delay mode.

2.) Data read:

EMC(su-margin) = 12.5 - 6 - 5.3 - 0.2 = 1ns + Tskew
EMC(h-margin)  = 2.5 - 5.2 + 0.2      = -2.5 - Tskew

Here the sunshine sets. By these margins there is no way you can compensate for the hold margin. Trying to delay the RAM (EMC clocked first - negative skew) will break the setup margin. The only way to fix what's broken is to throttle down to about 70MHz (~15ns period).

Also, by looking at the LPC177x/178x user manual, page 157, fig. 13, there is no way to delay the SDRAM without delaying the EMC along with it - except by clocking the SDRAM out from CLKOUT1, since CLKOUT0, already delayed, leads right back into the EMC as the feedback clock.

Am I wrong? I really could use a bucket of sound advice.

I think I've got the maths and the numbers right, please do correct me if I made a silly blunder along the way, since I am in no way an expert at these things. This is just the result of the past several days of heavy research that I've managed to come up with while my head wasn't completely spinning :)

Thank you for the help, I really appreciate it!

Regards,
Matt

[lpcware]

Content originally posted in LPCWare by teeysensei on Fri Jul 13 08:41:46 MST 2012
Thank you wmues. Your words are worth its weight in gold - and a place in some decent NXP documentation! :)

I really appreciate you taking the time and serving up such invaluable information for me, or anyone else stuck in this sort of a sticky situation.

I'll be sure to check back.

Cheers!

Matt

[lpcware]

Content originally posted in LPCWare by wmues on Thu Jul 12 01:51:42 MST 2012
Yes, the controller is a "bit peculiar". On the ARM website, this IP is classified as "not for new designs".

I do not think you have to feel uneasy. The interface is rated at 80MHz, but works up to 120MHz. So there is enough headroom, I think.

Regarding the delay of CLKOUT: you don't want to do that at 80MHz clock! The CLKOUT delay is for low frequencies. What you have to do at 80MHz is:

a) output all command signals (Axxx, RAS, CAS, Dout, etc) one cycle earlier ("command delayed strategie"). And then do a delay on every command line so that the commands have the right setup/hold timing at the SDRAM.

b) use the feedback clock delay to clock in the data from the SDRAM at the right moment. You do not need a negative delay here. In fact, using a feedback delay of 0 will most likely not work. (I got mine running from 4 to 31, at 78 MHz).

I got the following information from an engineer at nxp, who has done some practice with the SDRAM interface:

1. EMC clock <= 60 MHz: clock delayed read strategy.
CMDDLY=0, CLKOUT0DLY=31, FBCLKDLY=16. Fastest option.

2. EMC clock <= 80 MHz: command delayed read strategy + 0.
CLKOUT0DLY=0, FBCLKDLY=20. CMDDLY in relation to EMC clock! CMDDLY=31 for EMCCLK <= 48 MHz, CMDDLY=27 for EMCCLK=60 MHz, CMDDLY=16 for EMCCLK=72 MHz.

3. EMC clock >= 80 MHz: command delayed read strategy + 1.
CLKOUT0DLY=0, FBCLKDLY=20. CMDDLY=2. (Not valid area, but working)

[lpcware]

Content originally posted in LPCWare by teeysensei on Wed Jul 11 06:23:26 MST 2012
Alright. Thank you for the low-down. Then I'm not the only one finding this controller a bit peculiar.

Not being able to verify the timings by a few calculations does make me somewhat uneasy. The few prototypes can work flawlessly, but what about the hundredth, or the thousandth piece in production? Don't know.

The thing that makes me uneasy is that, by the looks of it, while reading data, you are able to adjust for the positive clock-skew, but not the negative skew, since delaying the CLKOUT automatically adds to the delay of the feedback sampling clock. Unless there is significant on-chip to off-chip pad delay, already causing a negative skew...many such quirks come to mind. I'll stick to the datasheet's footnote recommendations for now and do run-time calibrations as you recommended :)

Thank you very much for the help so far wmues!

Matt

[lpcware]

Content originally posted in LPCWare by wmues on Mon Jul 09 06:28:49 MST 2012
Matt,

You use the Command delayed strategy + 0, using EMCCLKDELAY (command delayed, clock out not delayed)
to delay all signals from the EMC to the SDRAM (in relation to the clock).

You use the FBCLKDLY to delay the sampling clock for the data input register of the EMC, until you are in the middle of the valid data area of the SDRAM output data.

Both delays are computed at SDRAM setup time, doing a SDRAM test for each possible delay value.

I have posted some code here:
http://www.lpcware.com/content/forum/lpc1788-sdram-timing-problem#comment-1790

The usual way of timing constrains (using min/max values from the data sheet) does *not* work for this type of SDRAM controller. Values have to be adjusted in runtime.