From: D. C. Sessions ([email protected])
Date: Wed Dec 22 1999 - 15:04:44 PST
Jim Freeman wrote:
>
> You.ve just made the argument for more transistors on a chip to perform ops on signals that would normally go off chip for interaction. i.e.a greater level of
> integration.
Absolutely. That's a consequence of the scaling of ICs anyway.
Still, there are things that don't integrate economically for whatever
reason (multiple gigabytes of DRAM come to mind.) For them we need to
squirt signals between chips and AFAIK there weren't any 3.3 v mandates
handed down at Sinai.
> Jim Freeman
> "D. C. Sessions" wrote:
>
> > Jim Freeman wrote:
> > >
> > > Hi DC,
> > > You Are stuck with 3.3v technology on the ring , but the interior can be much higher performance with dual gat oxide processes.
> >
> > Ummm... yes, but that's the point. You've shackled your I/O performance when
> > much higher performance is possible (and probably needed.) It makes *no* sense
> > to have two 150 nm devices with core voltages of 1.5 v communicating by demuxing
> > internal 1.2 GHz signals down to 150 MHz, pumping them up through level shifters
> > to 3.3v, using low-performance transistors to drive the line, burning lots of
> > power and radiating like crazy shipping them to another IC which then has to use
> > low-performance transistors to receive the signal ans shift it down to 1.5 v
> > signals to be muxed up to 1.2 GHz again.
> >
> > Rube Goldberg would have blushed.
> >
> > (Not to belabor the point but I'm an I/O cell designer and rather more
> > familiar with the details of dual-oxide processes than I'd really like!)
> >
> > > "D. C. Sessions" wrote:
> > >
> > > > [email protected] wrote:
> > > > >
> > > > > DC,
> > > > >
> > > > > I like your suggestion to start with a clean sheet of paper and ask
> > > > > ourselves what should be done to optimize the I/O design.
> > > > >
> > > > > In my experience working with computer system architects, they always want
> > > > > more and more bandwidth, which in the past has meant more and more pins at
> > > > > the boundary of an IC and more and more pins through connectors. And also
> > > > > increased data rates. To combat the higher data rates (and associated
> > > > > issues of noise, SSO, timing, ...) I have suggested to them to use
> > > > > differential signalling. The complaint that I get back is that this takes
> > > > > more pins. "I don't want to use two pins per signal when I can get twice
> > > > > as many signals using single ended." they whine. Of course this isn't
> > > > > really true since an increasing number of ground and power pins are
> > > > > required, but system architects don't consider these since they don't show
> > > > > up on any block diagram.
> > > >
> > > > That's what grouches like me are for :-)
> > > > We make nuisances of ourselves pointing out that SSO effects are
> > > > the #1 limiter on available performance. That using DC-balanced
> > > > signaling cuts SSO effects more than the equivalent number of pins
> > > > dedicated to power connections. That the balanced signals cause
> > > > less crosstalk and less EMI. That they can cut the cost of their
> > > > termination supplies dramatically and reduce the number of PWB layers
> > > > required.
> > > >
> > > > Of course, if those considerations aren't important to them, then
> > > > we'll be perfectly happy to charge extra for more advanced process
> > > > technology, packaging, and core area to make up the difference.
> > > >
> > > > > If it is really true that "Padrings are some of the most expensive real
> > > > > estate around, so pin count should be minimized." then why don't we start
> > > > > using each precious location on the padring to get more than one signal?
> > > >
> > > > We do. For busses, we crank up the clock rate and lower the number of
> > > > lines needed. If we have more bandwidth per pin than a single channel
> > > > can use, we use packet burst protocols.
> > > >
> > > > > I'm suggesting keeping differential signalling to alleviate some of the SI
> > > > > issues, but putting more than one logical signal on each differential pair.
> > > >
> > > > Basically broadband. The desirability of broadband depends a lot on both
> > > > the nature of your traffic and the limitations of your interconnect. For
> > > > short interconnects it's not really attractive for quite a while yet (we
> > > > did a science project of this sort recently. No, I can't discuss it.)
> > > >
> > > > > With two logical signals per pair I'm back to the one signal to one wire
> > > > > ratio that system architects love. See U.S. patent #5,872,813 "Dual
> > > > > Differential and Binary Data Receiver Arrangement" as an example. Although
> > > > > that patent refers to bipolar ECL-like circuits, I believe that some
> > > > > similar concepts could be implemented in CMOS circuits.
> > > > >
> > > > > The added complexity of the driver and receiver (and a little more power
> > > > > due to increased voltage swing) may be worth it if we gain one or more
> > > > > logical signals for each precious pin on the IC.
> > > >
> > > > Don't underestimate the grief that that "little more ... voltage swing"
> > > > causes. It really messes with your S/N ratio, but worst of all is the
> > > > fact that it runs up against the voltage-scaling objective. If you use
> > > > voltages larger than the native supply for a technology, you have to
> > > > degrade performance to what might as well be the technology appropriate
> > > > for that voltage. IOW, if you inisist on 3.3v signaling you're going to
> > > > be stuck with 350 nm CMOS performance.
> > > >
> > > > > ***************************************************************
> > > > >
> > > > > With the year wrapping up and my inbox filling with
> > > > > "Out of Office Autoresponse" messages, I thought I'd
> > > > > kick off something more interesting than the joys of LVDS.
> > > > >
> > > > > In particular, what would we use for signaling if we could
> > > > > start with a totally clean sheet of paper? Rather than
> > > > > immediately jump to a solution, I'm looking for some criteria:
> > > > >
> > > > > * It has to be scalable. Given silicon technology trends, it
> > > > > should migrate gracefully to lower-voltages and less
> > > > > voltage-stress-tolerant semiconductors.
> > > > >
> > > > > * It has to be SI clean. Output impedance should be matched
> > > > > (stringency variable) to the line across the switching range.
> > > > > Inputs switchpoints should be symmetrical and well-defined
> > > > > (ie differential receivers). Power plane proliferation
> > > > > leads to bad SI and wasted money, so separate termination
> > > > > supplies are a Bad Thing.
> > > > >
> > > > > * It has to be versatile. Single-ended, balanced single-ended, or
> > > > > differential; multidrop or point-to-point; uni- or bidirectional;
> > > > > all should be minor variations on the same system.
> > > > >
> > > > > * It should be economical. Wasted power is a Bad Thing, so low
> > > > > swing is a must. Padrings are some of the most expensive real
> > > > > estate around, so pincount should be minimized. Line termination
> > > > > can dominate a PWB so KISS is the rule. Power supplies (esp.
> > > > > ones that can both sink and source current) are expensive and
> > > > > nasty to deal with, so do without (both for termination and
> > > > > funny analog functions in the I/O circuits.)
> > > > >
> > > > > What can we add to the list? Remove? Priorities? (This is
> > > > > engineering, we make tradeoffs.) Where does this take us?
> > > > >
> > > > > --
> > > > > D. C. Sessions
> > > > > [email protected]
> > > > >
> > > > > **** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP.
> > > > > si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list
> > > > > ****
> > > >
> > > > --
> > > > D. C. Sessions
> > > > [email protected]
> > > >
> > > > **** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP.
> > > > si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list
> > > > ****
> > >
> > > **** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP.
> > > si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list
> > > ****
> >
> > --
> > D. C. Sessions
> > [email protected]
> >
> > **** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP.
> > si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list
> > ****
>
> **** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP.
> si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list
> ****
-- D. C. Sessions [email protected]**** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list ****
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 11:39:12 PST