Hi John: Thanks for your reply. But I think it is too dangerous for such = constraint like Intel, say X-4.4<=3DY. This is a lower bound constraint for DQ/DQS = or upper bound constraint for CK/CK#. We all know that it is impossible to implement another delay mechanism in the DDR memory cell, for more = accurate data latched by internal device in the cell, it should put a constraint = like X-4.4<=3DY<=3Dsome value, that will more make sure that data arrived = later than clock for internal device in the memory cell, isn't it?=20 Jack -----Original Message----- From: John Phillips [mailto:John.Phillips@xxxxxxxxxxxxxx]=20 Sent: Thursday, October 17, 2002 5:05 PM To: Jack W.C. Lin; si-list@xxxxxxxxxxxxx Subject: RE: [SI-LIST] Constraints on DQ/DQS and CK/CK# in DDR Once DQS latches the DQ at the input to the part, the device must then synchronise the data to its local clock. If the clocks between say the = NB and the DDR memory devices are to far out of alignment, it will not be possibble to compensate for this mis-alignment in the recieving device. = This will mean that the data cannot be properly sampled in the local devices recieving clock domain. Best Regards John > -----Original Message----- > From: si-list-bounce@xxxxxxxxxxxxx=20 > [mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of Jack W.C. Lin > Sent: 17 October 2002 09:32 > To: si-list@xxxxxxxxxxxxx > Subject: [SI-LIST] Constraints on DQ/DQS and CK/CK# in DDR > > > Hi All SI friends: > I met a question about DDR. We all know that DDR is a source=20 > synchronus structure, data transfer will not depend on bus clock any > more. In chip > design, there exist Delay mechanism for DQ and DQS (90 degree > phase shift) > which is controlled by bus clock. But we found that either in > Intel 845 chip > series or AMD K8 =A1K., they all have some layout constraint on > DQ/DQS and > command clock (CK&CK#). For example in Intel, if DQ/DQS > length is Y, CK/CK# > is X, then they should follow X-4.4<=3DY. In AMD, Y=3DX+0.5 or > Y=3DX-0.5. Why? In > DDR mechanism, it seems no reason to put such constraints on > them. Maybe I > miss something, is there anyone could provide a reasonable > explanation? > Thanks > > Jack > > ------------------------------------------------------------------ > 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:=20 > //www.freelists.org/webpage/si-list > > For help: > si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field > > List archives are viewable at: > //www.freelists.org/archives/si-list > or at our remote archives: > http://groups.yahoo.com/group/si-list/messages > Old (prior to June 6, 2001) list archives are viewable at: > http://www.qsl.net/wb6tpu > > > > __________________________________________________ > Virus checked by MessageLabs Virus Control Centre. > __________________________________________________ Virus checked by MessageLabs Virus Control Centre. ------------------------------------------------------------------ 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 archives are viewable at: //www.freelists.org/archives/si-list or at our remote archives: http://groups.yahoo.com/group/si-list/messages Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu