On Jul 19, 2:03pm, Roy Leventhal wrote:
> Subject: Re: [SI-LIST] : Edge rates
>
>
> Mike,
>
> I'll take the position that data sheet specsmanship problems have relatively
> little to do with technology issues and quite a lot to do with people
protecting
> themselves. I'll explain myself.
Yes. You could be write for two reasons. One is that the specwriter
is simply padding the results to cover any unknown or neglected 2nd
order effects. The other reason is that if they keep specifying
the part with a capacitive load, then they never have to be responsible
for SI effects such as ringing and so on. I would think that
SLOW/TYP/FAST IBIS models should be sufficient for the SI engineer
to gaurentee SI and timing.
>
> But first, let me say, up front that switching behavior into a transmission
line
> would be a welcome addition to data sheets. I say addition, because people
tend
> to cling to baselines. In this case switching behavior into a lumped load.
This
> gives them, so they feel, a comparison with something they are familiar with
and
> understand. Then also, folks who are standards and procedures oriented like
> component (yep, been there - done that) engineers, test engineers, etc., are
> control oriented and like repeatability. So, even if people start testing
into
> transmission lines don't expect the old methods to disappear any time soon.
>
Yes, I've been through this already. We designed a 200Mhz buffer
for a group and they "verify" the design by extracting the design
and simulate against capacitive loads. We had them modify their
procedure to drive an unterminated 50 ohm line. We also had to
explain how to spec the driver delay and tline delay equations.
We think that everything worked out with the verification folks. However,
the "battle" has only begun in that, as you pointed out, the test
folks, managers, and so on, will also need to be educated.
If anyone goes through this same exercise, I would highly recommend
that the simulation conditions are fully specified. Otherwise
they might try a 10ns tline at 200Mhz or something to that effect.
Another example - if the buffer is effectively source terminated such
as a CMOS buffer, then it is very difficult to convey to others that the
buffer delay is from 50% of the input to 25% of the output signal!
For this case, I opted instead to spec. the delay as the 50% crossing
of the signal at the far end of the transmission line minus the 50%
crossing of the input signal minus the progation delay of the
transmission line.
> Your story brings to mind a recent simulation I ran where the question was
the
> correct Vol - the value from the data sheet or the prediction of the IBIS
model?
> The issue was simulating the correct values for noise margin. Inquiring into
> this at the Silicon vendor we were informed that "The value on the data sheet
is
> guard banded by 200 mV because we guarantee it."
>
> Of course, try collecting on those guarantees even if you test for them. I
can
> recall characterizing processes and publishing many semiconductor device data
> sheets. Disclaimers were standard fare in any of them as they are today. Or,
> open any IBIS or SPICE file and look at the disclaimers therein. All of what
I
> am asserting is, I believe, a result of the usual adversarial nature of the
> relationship between supplier and customer. Also, a result of people wishing
to
> avoid responsibility for their own actions. Specifically, I include specs
that
> are set far wider than they need to be, parts that are misapplied in a lazy
> design and anything else where it doesn't take rocket science to come up with
a
> better answer. As far as I'm concerned the whole specsmanship discussion plus
> the "why do anything until the customer absolutely demands it" discussions
sound
> like rationalizations for doing a second class job.
>
> If you want to break out of the adversarial loop and have the numbers to mean
> anything at all, you have to look two things:
>
> 1. Communicate what you really need in a Purchase Spec under your control.
>
> 2. Get buy-in to that Spec by building trust, understanding - especially
> technical understanding, etc., with the supplier. Be sure you both listen
> absorbtively.
>
> I can only re-emphasize the many fine suggestions by D.C., yourself and many
> others regarding specs and the exchange of technical information.
>
> But, there are three other points I've been trying to make:
>
> 1. The earlier the "what-if" simulation the better even if you have to
"suppose
> (invent)" the model characteristics that will work, loosely based on a real
> device.
>
> 2. Early efforts to desensitize the design to device variations and
> characteristics - shared with your device supplier.
>
> 3. Then listen to your supplier and respond to their suggestions until you
come
> to the most mutually beneficial agreement = specification.
>
> Finally, take steps to deal with those things that cannot be solved
effectively
> at the device level and don't believe that expected problems will magically
cure
> themselves.
>
I totally agree with you and D.C. regarding how to get real specs
for real parts. Unfortunately, I suspect that many of us don't
have the clout to work that closely with the supplier. (Or maybe
we don't have or don't bother to take the time). Those
that do have the resources to leverage the supplier into providing
realistic specs can pave the way for the rest of us.
>
> Regards,
>
>
> Roy
>
>
-- _______________________________________________________________ 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 WWW: http://www.mayo.edu/sppdg/sppdg_home_page.html _______________________________________________________________**** 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 ****