Re: [SI-LIST] : Edge rates

Mike Degerstrom ([email protected])
Mon, 19 Jul 1999 10:06:33 -0500


Interesting points. I too must lament these silly data
sheets that are more tailored for technologies 10 to 15 years
ago. In fact, I hated these data sheets back then as well.
In 1988 I had to do the SI for a memory box under a very
tight schedule. The data sheets couldn't tell me much, so
I got samples of all the the parts we were planning to
use. Then I measured the LOW and HIGH state I-V curves
and the rise/falltime into t-line and capacitive loaded
conditions. These were used into a "pre-IBIS" home-grown
simulator. All net types were simulated and I wrote rules
to guarentee SI and timing. The whole process was
very successful. Now 11 years later, I still do pretty
much the same unless there are IBIS models already available.
Another difference is that we also do a lot of high speed
point-to-point nets. And, as I posted earlier, many of
the parts available are tuned for "LVTTL" levels so HIGH
and LOW going drive strength are unbalanced with both
strengths having effective impedances much lower than 50 ohms.
But a series resistor of ~30 ohms usually works OK for both HIGH
and LOW transitions.

It would be great if spec. sheets were updated to reflect
how the parts are now more typically used. I have, on occasion,
told the application engineers for the supplying companies to
give me more realistic specs. If we all do the same, then
maybe we can get some useful spec. sheets!


On Jul 16, 12:53pm, D. C. Sessions wrote:
> Subject: Re: [SI-LIST] : Edge rates
> [email protected] wrote:
> >
> > D.C.
> >
> > Why not provide data for both a 45pF load and something more realistic,
> > like a 50 ohm tline or a capacitively loaded 65 ohm bus? That way you'll
> > make the "standard load" folks happy as well as the SI community?
> Sideband, we do. If your relationship with your vendor is good enough
> that you can get past the marketing department (which generally includes
> the FAEs) and talk to a real engineer you can generally get useful models
> from just about anyone. Of course, the engineer is taking a bit of a
> career risk GIVING them to you, but that's par for the course. (I say
> this, knowing that I'm being quite inconsistent with my other expressed
> annoyance with customers who call often enough to make getting any design
> work done difficult. Sue me.)
> The problem is getting the data PUBLISHED. Remember, data sheets are
> not engineering documents, they are marketing documents that engineers
> use because they can't get anything better.
> To your point: test engineers resist (often VERY strenuously) having
> more than one test load for a given pin. Component engineers resist
> (often strenuously) having critical design parameters not backed by
> test. They also get nasty about companies that publish parametric
> data that looks better (eg faster) than the competition under test
> conditions that would make anything look faster (specsmanship.)
> PAs hear from test and component engineering far more than from
> design, and Si vendor marketing and sales hear far more from PAs
> and component engineering than from design and they almost NEVER
> pay any attention to their own engineering staff.
> It's possible to get past these roadblocks, but not easy. There was
> blood on the floor before JEDEC was able to back DDR down from a
> 45-pf lumped load test model to 30-pf, even though all of the engineers
> knew that 0pf was the best technical choice. Being the same as
> the competition is SAFE even if it's less helpful to the customer.
> Remember, the trick is to bully one's own marketing department into
> doing something that they don't understand and that they perceive as
> a risk in order to get them to change one of THEIR documents.
> Of course, if the customers beat up the salessuits badly enough they
> may get a clue. You have my own very unofficial invitation to beat
> on VLSI marketing until your arm gets tired, because they will most
> certainly listen more to you than to me.
> Be nice to everyone else :-)
> > "D. C. Sessions" <[email protected]> on 07/16/99 12:02:43 PM
> >
> > Please respond to [email protected]
> >
> > Sent by: "D. C. Sessions" <[email protected]>
> >
> > To: [email protected], [email protected]
> > cc: (Chris Heard/US/3Com)
> > Subject: Re: [SI-LIST] : Edge rates
> >
> > Roy Leventhal wrote:
> > >
> > > Fabrizio,
> > >
> > > Interesting.
> > >
> > > Also, what I'm seeing is that simple edge rates, as opposed to a full V-T
> > > Waveform / Fall Waveform] curve gives you very misleading results on
> > > multidrop backplane busses. If you want to see the effects of controlled
> > > rate / soft turnon-turnoff parts, such as GTLP, you need those curves. A
> > > straight dV/dt_r and dV/dt_f hard turnon-turnoff driver contains much
more high
> > > frequency content and will show much more ringing in a simulation.
> > I'm probably sounding like a broken record in this regard. Sorry.
> > The problem is that real-world applications are far more impacted by the
> > di/dt of a driver than with the dv/dt of the wave when it hits the load.
> > The dv/dt numbers we see published are usually into a 30-50 pf load, so
> > they are far more representative of the output impedance than of the
> > "event edge rate" -- the slew rates in the predriver stage. The data
> > sheet numbers, thanks to that honking great lowpass filter of a load,
> > have all of the interesting data smeared out.
> > The trouble is that, as manufacturers, we have this one little obstacle
> > to doing better characterization: customers. Not necessarily you guys,
> > but collectively including your PAs and test engineering groups. In
> > JEDEC JC-16 meetings we've had some long discussions about trying to
> > provide characterization into more realistic loads, and the conversation
> > goes something like this:
> > 1) We HAVE to provide TTL-type 45-pf load values because the customers
> > reject anything 'nonstandard' as 'specsmanship'.
> > 2) The customer components/test engineering groups insist on having no
> > more than one test condition for each parameter.
> > 3) The design community insists that the IBIS models and the data sheet
> > use consistent test conditions so that the simulations match up
> > 3) Therefore, we can't provide anything other than the 45-pf load data
> > Now personally this sounds a lot like rationalization from our collective
> > marketing groups. That doesn't make it totally bogus, though, and it's
> > a tangled enough mess that it's going to take collective effort from
> > several directions to unravel it.
> > > "fabrizio zanella" <[email protected]> on 07/16/99 06:45:33
> > AM
> > >
> > > Please respond to [email protected]
> > >
> > > Sent by: "fabrizio zanella" <[email protected]>
> > >
> > > To: [email protected]
> > > cc: (Roy Leventhal/MW/US/3Com)
> > > Subject: RE: [SI-LIST] : Edge rates
> > >
> > > Regarding edge rates of devices, here's a point which has not been
> > > up. Edge rates are characterized by semiconductor manufacturers into
> > > lumped loads, which means nothing if the customer is using the parts to
> > > drive backplane signals. We've found consistently that published driver
> > > edge rates are 800ps to 1ns faster when these same drivers are driving a
> > > backplane with multiple loads (ie 1.5ns data sheet tr/tf is really
> > > 0.5-0.7ns in system). It has been our task to tell the logic
> > > how fast their device edges really are, therefore causing problems with
> > > ringing, multiple reflections, etc.
> --
> 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 ****
>-- End of excerpt from D. C. Sessions

Mike Degerstrom         Email:    [email protected]	
Mayo Clinic 
200 1st Street SW 
Gugg. Bldg. RM 1042A                 Phone:    (507) 284-3292
Rochester, MN 55905                    FAX:    (507) 284-9171

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