Re: [SI-LIST] : Edge rates

D. C. Sessions ([email protected])
Fri, 16 Jul 1999 12:53:50 -0700

[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 [Rise
> > Waveform / Fall Waveform] curve gives you very misleading results on complex,
> > multidrop backplane busses. If you want to see the effects of controlled edge
> > 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 brought
> > 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 manufacturers
> > 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 http://www.qsl.net/wb6tpu/si-list ****