[SI-LIST] Re: SDRAM timing
- From: "Chris McGrath" <chris.mcgrath@xxxxxxxx>
- Date: Tue, 30 Nov 2004 09:13:27 -0500
Peter,
As I mentioned on this list a couple of weeks ago regarding embedded DDR
SDRAM, the group-to-group length matching has as much to do with timing
(and margins) as the details of the memory controller and how much
control you have over each group with relation to the read and write
clocks. Use caution when trying to boil a reasonably complex interface
to a single design rule- odd are, there are enough caviats to cause
trouble.
-Chris
> -----Original Message-----
> From: si-list-bounce@xxxxxxxxxxxxx=20
> [mailto:si-list-bounce@xxxxxxxxxxxxx] On Behalf Of Peterson,=20
> James F (FL51)
> Sent: Tuesday, November 30, 2004 8:18 AM
> To: peter.zhu@xxxxxxxxxx; crjohnson11@xxxxxxxxxxx
> Cc: si-list@xxxxxxxxxxxxx
> Subject: [SI-LIST] Re: SDRAM timing
>=20
>=20
> Peter,
> In response to your point in your last paragraph (two devices=20
> that interface with each other and have the same external=20
> clock with the same phase) :
> =20
> The longest trace is important only in the setup time analysis.
>=20
> But as was mentioned earlier, the shortest trace is key in=20
> the hold time analysis. Take a look at terms in the classic=20
> equation for hold time analysis and you will see that the=20
> minimum trace delay is a critical term in that equation. If=20
> you don't include this, then you could have metastability=20
> issues because of hold time violations. It is often the case=20
> that the trace needs to be lengthened to meet hold time needs.
>=20
> Best regards,
> Jim
> Honeywell
>=20
> -----Original Message-----
> From: si-list-bounce@xxxxxxxxxxxxx=20
> [mailto:si-list-bounce@xxxxxxxxxxxxx] On Behalf Of peter zhu
> Sent: Tuesday, November 30, 2004 7:30 AM
> To: crjohnson11@xxxxxxxxxxx
> Cc: si-list@xxxxxxxxxxxxx
> Subject: [SI-LIST] Re: SDRAM timing
>=20
> Johnson:
>=20
> Thanks for your explaination.. In your mail, maintaining the=20
> equal lenth in data bus is for a optimum point. But you know,=20
> for some SDR SDRAM controller, the clock is from SDRAM=20
> controller, we can not adjunt the clock forward. In fact,=20
> majority of SDR SDRAM clock scheme is as such. In such=20
> situation, I think the timing is only determined by the=20
> longest data trace, and the shorter the better. Do you aggree with me?
>=20
> Thinking about another clocking scheme in SDR SDRAM. The=20
> SDRAM controller and SDRAM is clocked by the same external=20
> clock with same phase. In this situation, I also think the=20
> timing is only determined by the longest trace, and the=20
> shorter the better.
>=20
> Regards
>=20
> Peter
> ----- Original Message -----
> From: "Christopher R. Johnson" <crjohnson11@xxxxxxxxxxx>
> To: <peter.zhu@xxxxxxxxxx>
> Cc: <si-list@xxxxxxxxxxxxx>
> Sent: Monday, November 29, 2004 11:20 PM
> Subject: [SI-LIST] Re: SDRAM timing
>=20
>=20
> > If you have zero skew (all lines the same length), then=20
> there is some=20
> > optimum point at which you can place your clock to give the=20
> best setup=20
> > and hold for all signals. Once you introduce skew between=20
> any of the=20
> > signals, from trace length, different output prop delays, different=20
> > receiver thresholds, clock jitter, etc. you no longer have a single=20
> > point in the cycle which is best for all signals. Your=20
> best point is=20
> > now fuzzed out to
> a
> > band of different best points across all of the signals. =20
> The best you=20
> > can do is minimize the difference between the individual best clock=20
> > placements and the actual clock placement. To do this, you=20
> place your=20
> > clock midway between the best placement for slowest and fastest=20
> > signals. The point at which the "fuzzed out" clock=20
> placement equals=20
> > the system clock is the fastest that you can go.
> >
> >
> > ----- Original Message -----
> > From: "peter zhu" <peter.zhu@xxxxxxxxxx>
> > To: <bmgman@xxxxxxxxxx>
> > Cc: <si-list@xxxxxxxxxxxxx>
> > Sent: Monday, November 29, 2004 7:26 AM
> > Subject: [SI-LIST] Re: SDRAM timing
> >
> >
> > > Mike and all:
> > >
> > > I think the setup and hold time is not a problem in shortest data=20
> > > bus. Assume that the length of data bus is ZERO, because=20
> no any data=20
> > > bus
> delay,
> > > so the timing will be just the timing in SDRAM or SDRAM=20
> controller=20
> > > datasheet!!! It's perfect! So I think the shorter, the better.
> > > Can anybody explain it? Do we really need to maintain the=20
> almost same
> > length
> > > in SDRAM data bus?
> > >
> > > Thanks in advanced.
> > >
> > > Peter
> >
> >
> > ------------------------------------------------------------------
> > To unsubscribe from si-list:
> > si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the=20
> 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 FAQ wiki page is located at:
> > http://si-list.org/wiki/wiki.pl?Si-List_FAQ
> >
> > List technical documents are available at:
> > http://www.si-list.org
> >
> > List archives are viewable at:=20
> > //www.freelists.org/archives/si-list
> > or at our remote archives:=20
> > http://groups.yahoo.com/group/si-list/messages
> > Old (prior to June 6, 2001) list archives are viewable at:
> > http://www.qsl.net/wb6tpu
> >
> >
>=20
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>=20
> or to administer your membership from a web page, go to:=20
> //www.freelists.org/webpage/si-list
>=20
> For help:
> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>=20
> List FAQ wiki page is located at:
> http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>=20
> List technical documents are available at:
> http://www.si-list.org
>=20
> List archives are viewable at: =20
> //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
> =20
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>=20
> or to administer your membership from a web page, go to:=20
> //www.freelists.org/webpage/si-list
>=20
> For help:
> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>=20
> List FAQ wiki page is located at:
> http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>=20
> List technical documents are available at:
> http://www.si-list.org
>=20
> List archives are viewable at: =20
> //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
> =20
>=20
>=20
------------------------------------------------------------------
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 FAQ wiki page is located at:
http://si-list.org/wiki/wiki.pl?Si-List_FAQ
List technical documents are available at:
http://www.si-list.org
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
Other related posts:
