[SI-LIST] Re: SDRAM timing

  • From: "peter zhu" <peter.zhu@xxxxxxxxxx>
  • To: <james.f.peterson@xxxxxxxxxxxxx>, <crjohnson11@xxxxxxxxxxx>
  • Date: Wed, 1 Dec 2004 10:19:54 +0800

James:

I still insist my point that the shortest trace has no problem in both setup
and hold time when considered SDR SDRAM.

Assume that the data trace is ZERO,  and the SDRAM controller and SDRAM chip
is clocked by the same external clock, Because is data trace is ZERO, and no
any data delay,  so the timing at the receiver is JUST the timing in SDRAM
controller or SDRAM chip datasheet.that certainly meet the input
requirement.

Regards
Peter

----- Original Message ----- 
From: "Peterson, James F (FL51)" <james.f.peterson@xxxxxxxxxxxxx>
To: <peter.zhu@xxxxxxxxxx>; <crjohnson11@xxxxxxxxxxx>
Cc: <si-list@xxxxxxxxxxxxx>
Sent: Tuesday, November 30, 2004 9:18 PM
Subject: [SI-LIST] Re: SDRAM timing


> Peter,
> In response to your point in your last paragraph (two devices that
interface
> with each other and have the same external clock with the same phase) :
>
> The longest trace is important only in the setup time analysis.
>
> But as was mentioned earlier, the shortest trace is key in the hold time
> analysis. Take a look at terms in the classic equation for hold time
> analysis and you will see that the minimum trace delay is a critical term
in
> that equation. If you don't include this, then you could have
metastability
> issues because of hold time violations. It is often the case that the
trace
> needs to be lengthened to meet hold time needs.
>
> Best regards,
> Jim
> Honeywell
>
> -----Original Message-----
> From: si-list-bounce@xxxxxxxxxxxxx [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
>
> Johnson:
>
> Thanks for your explaination.. In your mail, maintaining the equal lenth
in
> data bus is for a optimum point.
> But you know, for some SDR SDRAM controller, the clock is from SDRAM
> controller, we can not adjunt the clock forward. In fact, majority of SDR
> SDRAM clock scheme is as such.
> In such situation, I think the timing is only determined by the longest
data
> trace, and the shorter the better. Do you aggree with me?
>
> Thinking about another clocking scheme in SDR SDRAM.  The SDRAM controller
> and SDRAM is clocked by the same external clock with same phase. In this
> situation, I also think the timing  is only determined by the longest
trace,
> and the shorter the better.
>
> Regards
>
> 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
>
>
> > If you have zero skew (all lines the same length), then there is some
> > optimum point at which you can place your clock to give the best setup
and
> > hold for all signals.  Once you introduce skew between any of the
signals,
> > from trace length, different output prop delays, different receiver
> > thresholds, clock jitter, etc. you no longer have a single point in the
> > cycle which is best for all signals.  Your best point is now fuzzed out
to
> a
> > band of different best points across all of the signals.  The best you
can
> > do is minimize the difference between the individual best clock
placements
> > and the actual clock placement.  To do this, you place your clock midway
> > between the best placement for slowest and fastest signals.  The point
at
> > which the "fuzzed out" clock placement equals 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 bus.
> > > Assume that the length of data bus is ZERO, because no any data bus
> delay,
> > > so the timing will be just the timing in SDRAM or SDRAM controller
> > > datasheet!!! It's perfect!
> > > So I think the shorter, the better.
> > > Can anybody explain it? Do we really need to maintain the almost same
> > length
> > > in SDRAM data bus?
> > >
> > > Thanks in advanced.
> > >
> > > Peter
> >
> >
> > ------------------------------------------------------------------
> > 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
> >
> >
>
> ------------------------------------------------------------------
> 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
>
> ------------------------------------------------------------------
> 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
>
>

------------------------------------------------------------------
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: