From: D. C. Sessions ([email protected])
Date: Mon Apr 30 2001 - 20:29:14 PDT
On Monday 30 April 2001 09:59, Vinu Arumugham wrote:
> "D. C. Sessions" wrote:
>
> > Me, I'm a hardcase. I'm inclined to just tell the systems designers to avoid
> > resonant line lengths.
>
> For lower speeds, I think avoiding the resonant line length is the best solution. At
> lower speeds, the reflections caused by the high-Z of the driver may not even be a
> problem. At higher speeds, the ISI due to reflected-wave operation is too high and
> receiver end termination becomes necessary. So, the motivation for modifying the
> standard is not clear to me.
At sufficiently low speeds, the resonant line length is unlikely to occur on
a PWB. Example: 266 MT/s DDR memory. Cycle time is 3750 ps, round trip
distance is on the order of (15 cm/ns)(3.75 ns)~=56 cm. One-way distance
is 28 cm -- far too long for a wide bus, and narrow interfaces don't benefit
enough from reflected-wave signaling.
The case that we're trying to deal with, though, is more on the order of
600-800 MT/s for very small systems (One controller, two to four x32
memories, data lines strictly point-to-point. Lines are very unlikely to
exceed 10 cm. Trouble is, 10 cm _is_ a resonant line for 800 MT/s
Adding shunt resistors to each end of the line is simply not economical.
You'd be talking about 128-256 resistors (64 or 128-bit interface,
bidirectional) which, with routing, would chew up more real estate than
the controller and memories. Not to mention power.
> > The others aren't confident that the users will even
> > know what we're talking about. (To be fair, quite a few applications don't have
> > fixed frequencies.)
> >
> > > -----Original Message-----
> > > From: Jim Freeman [mailto:[email protected]]
> > > Sent: Friday, April 27, 2001 9:58 AM
> > > To: D. C. Sessions
> > > Cc: [email protected]
> > > Subject: Re: [SI-LIST] : Reflected-wave drivers: quality metric
> > >
> > >
> > >
> > > Hi DC,
> > > I don't see the CMOS on/off condition described below as a problem. It
> > > is an even
> > > greater problem to have crowbar current in the outputs due to both the
> > > pullup and
> > > pulldown being on simultaneously. This gives rise to simultaneous ground and
> > > VCC bounce
> > > as well as an oscillation caused by the capacitance from power to ground not
> > > responding
> > > instantaneously(in school I learned that capacitors don't like to change
> > > their voltage
> > > instantaneously)
> > >
> > > Thanks
> > > Jim Freeman
> > > P.S. VSWR may be a lost concept because most of the modern engineering
> > > programs have
> > > de-emphasized electromagnetics and emphasized Boolean algebra and its
> > > logical followon
> > > computer programming/hardware design. Most EE's think in terms of zeros and
> > > ones
> > > instead of volts and amps
> > >
> > >
> > > "D. C. Sessions" wrote:
> > >
> > > > JEDEC's JC-16 committee is in the process of revising the SSTL standards
> > > > to explicitly cover reflected-wave operation. One of the issues coming up
> > > > in the course of the work is that CMOS outputs are typically ill-behaved
> > > > during transitions (usually going to high impedance after one transistor
> > > > turns off and before the other turns on.)
> > > >
> > > > There have been several proposals to specify envelopes for the Z/T
> > > response
> > > > (majorly ugly), ignoring the matter (nope), and so forth. Right now the
> > > best bet
> > > > seems to be specifying a (two?) resonant stubs driven to have reflections
> > > arrive
> > > > back at the driver in the midst of transition.
> > > >
> > > > In other words, we're going to place bounds on the VSWR (you can stop
> > > laughing,
> > > > Ed. I had fun explaining to the kids that this wasn't exactly new and
> > > pointing them
> > > > to the ARRL handbook.)
> > > >
> > > > The question is: since these won't be pure sinusoids (anything but!) what
> > > would be
> > > > a good metric for the resultant resonant-mode waveforms that would reflect
> > > (as it
> > > > were) the cumulative S/N ratio at the receiver?
> > > >
> > > > D. C. Sessions,
> > > > Chair, JC-16
> > > >
> > > > --
> > > > | The race is not always to the swift, nor the battle to the strong. |
> > > > | Because the slow, feeble old codgers like me cheat. |
> > > > +--------------- D. C. Sessions <[email protected]> --------------+
> > > >
> > > > **** To unsubscribe from si-list or si-list-digest: send e-mail to
> > > > [email protected]. In the BODY of message put: UNSUBSCRIBE
> > > > si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
> > > > si-list archives are accessible at http://www.qsl.net/wb6tpu
> > > > ****
> > >
> > >
> > >
> > > **** To unsubscribe from si-list or si-list-digest: send e-mail to
> > > [email protected]. In the BODY of message put: UNSUBSCRIBE
> > > si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
> > > si-list archives are accessible at http://www.qsl.net/wb6tpu
> > > ****
> > >
> >
> > ----------------------------------------
> > Content-Type: text/html; charset="iso-8859-1"; name="Attachment: 1"
> > Content-Transfer-Encoding: quoted-printable
> > Content-Description:
> > ----------------------------------------
> >
> > --
> > | The race is not always to the swift, nor the battle to the strong. |
> > | Because the slow, feeble old codgers like me cheat. |
> > +--------------- D. C. Sessions <[email protected]> --------------+
> >
> > **** To unsubscribe from si-list or si-list-digest: send e-mail to
> > [email protected]. In the BODY of message put: UNSUBSCRIBE
> > si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
> > si-list archives are accessible at http://www.qsl.net/wb6tpu
> > ****
>
>
> **** To unsubscribe from si-list or si-list-digest: send e-mail to
> [email protected]. In the BODY of message put: UNSUBSCRIBE
> si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
> si-list archives are accessible at http://www.qsl.net/wb6tpu
> ****
>
>
-- | The race is not always to the swift, nor the battle to the strong. | | Because the slow, feeble old codgers like me cheat. | +--------------- D. C. Sessions <[email protected]> --------------+**** To unsubscribe from si-list or si-list-digest: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu ****
This archive was generated by hypermail 2b29 : Thu Jun 21 2001 - 10:11:48 PDT