Hi, no reason to be sorry for formatting .. The DRAM needs just to have some alignment between the Write Command and the corresponding Write Data. This is required to ensure the DRAM can switch on it's Receivers at the right time and not while the bus is in any undefined (midlevel) state or too late so that it is missing the first DQS edge. Be happy to have so much margins .. usually you need it to avoid extensive length matching. Dependent of your CA bus your clock is longer as the Data signals (e.g. if the data balls of the DRAM face towards the controller). In order ot avoid extensive stretching of DQS (and therefore also DQ singals) by lots of meandering it is quite good to have some wide margin there (especially for early DQS). But I have seen controller datasheets that do eatup a lot of the margins from TDQSS... The real datacapturing is done based on Setup/Hold DQS vs. DQ and this is the tight parameter. Hermann Our next Events: ================ "Open the Black Box of Memory" Seminar on 08/09. November 2012 Check our website or contact us for details EKH - EyeKnowHow Hermann Ruckerbauer www.EyeKnowHow.de Hermann.Ruckerbauer@xxxxxxxxxxxxx Veilchenstrasse 1 94554 Moos Tel.: +49 (0)9938 / 902 083 Mobile: +49 (0)176 / 787 787 77 Fax: +49 (0)3212 / 121 9008 Am 18.09.2012 10:31, schrieb qinzuli: > Hi Hermann, I'm sorry for bad formats. I re-format my words so hope you > can have better reading on it. The confusing to me is why LPDDR2 spec define > tDQSSmin/tDQSSmax two values? > Should I think at normal operation state controller set CK and DQS almost > edge aligned and tDQSSmin/tDQSSmax will never be entered? > According to tDQSSmin/tDQSSmax value defined on JEDEC spec, it's 0.25 > *tCK(per), and sum of total uncertainty of transmitter/interconnect is only > small amount of tDQSSmin/tDQSSmax margin. Not sure if I expalined my thoughts > clearly. Thanks. Best regards,Ben > > Date: Tue, 18 Sep 2012 09:24:11 +0200 >> From: Hermann.Ruckerbauer@xxxxxxxxxxxxx >> To: zlqin80@xxxxxxxxxxx >> CC: si-list@xxxxxxxxxxxxx >> Subject: [SI-LIST] Re: Check LPDDR2 CK-DQS timing >> >> Yes, >> all DRAM specs just define what need to be applied at the DRAM inputs. >> Controller are not commodity (unfortionally ;-) ). >> Calculating the timing budget is therefore part of the design process >> for each design. >> >> I guess you mentioned this already (but somehow the formatting was lost, >> so your e-mail was difficult to read): >> You need to consider all uncertainties: Contoller output uncertainty, >> Routing lenght mismatch and Channel introduced jitter on clock and DQS >> (not sure if I forgot anything). Add all of this together and you should >> be still below the allowed skew at the DRAM inputs... >> >> Hemrann >> >> Our next Events: >> ================ >> >> "Open the Black Box of Memory" >> Seminar on 08/09. November 2012 >> >> Check our website or contact us for details >> >> EKH - EyeKnowHow >> Hermann Ruckerbauer >> www.EyeKnowHow.de >> Hermann.Ruckerbauer@xxxxxxxxxxxxx >> Veilchenstrasse 1 >> 94554 Moos >> Tel.: +49 (0)9938 / 902 083 >> Mobile: +49 (0)176 / 787 787 77 >> Fax: +49 (0)3212 / 121 9008 >> >> Am 18.09.2012 08:57, schrieb qinzuli: >>> Hi, I'm going through LPDDR2 spec for CK-DQS timing definition on DRAM >>> side. The spec has defined tDQSS/tDSS/tDSH parameter to represent >>> tDQSS: the min./max. latching time from clock rising edge to the first >>> strobe rising edge tDSS: the min. setup time margin >>> required from strobe falling edge to corresponding clock rising edge >>> tDSH: the min. hold time margin required from strobe falling edge >>> to corresponding clock rising edge. For LPDDR2 there is no write >>> leveling feature. I know {tDQSSmin, tDSH} and {tDQSSmax, tDSS} should be >>> checked pairly. According to LPDDR2 spec, tDQSSmin = >>> -0.25 * tCK(per) tDQSSmax = 0.25 * tCK(per) >>> tDSS = 0.2 * tCK(per) tDSH = 0.2 * >>> tCK(per) tDQSSmin and tDQSSmax could be regarded as Worst Case timing >>> relationship between CK and DQS rising edge, right? For 533 MHz clock >>> frequency, there is only 0.05 * tCK(per) = > 93.75 ps skew margin. I checked some LPDDR2 design IP (Driver side) spec > which give total transmitter uncertainty from DQS to CK is 130 ps @533MHz. > How should user to consider the Driver side skew while checking CK-DQS > timing? Seems LPDDR2 spec only focus on DRAM side. If the max. transmitter > skew is about 130ps, also adding to interconnect skew(Package/PCB/RDL skew > and mismatch), then totally all the Tx/Interconnect Skew will acceed the > allowed skew margin of DRAM. Is my understanding right? Thanks for your > correction. Best regards,Ben. > > > ------------------------------------------------------------------ > To unsubscribe from si-list: > si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field > > or to administer your membership from a web page, go to: > //www.freelists.org/webpage/si-list > > For help: > si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field > > > List forum is accessible at: > http://tech.groups.yahoo.com/group/si-list > > List archives are viewable at: > //www.freelists.org/archives/si-list > > Old (prior to June 6, 2001) list archives are viewable at: > http://www.qsl.net/wb6tpu > > ------------------------------------------------------------------ To unsubscribe from si-list: si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field or to administer your membership from a web page, go to: //www.freelists.org/webpage/si-list For help: si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field List forum is accessible at: http://tech.groups.yahoo.com/group/si-list List archives are viewable at: //www.freelists.org/archives/si-list Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu