<plug=blatant>
Of course not.
If it'd been one of mine you wouldn't be HAVING this problem.
<smiley>
</plug>
> You
> know, the one with less than 500ps rise time on a 4 MHz bi-directional
> multi-drop bus with no room for the termination that I've shown will clean up
> the ringing.
>
> If you were our supplier I would be asking you what your turn-around, cost,
> etc., is as a possible solution. More to the point, Mr. Supplier, I've got a
> problem you created. Any way you can help?
There are a couple of lessons here.
One -- that we've probably ALL lost hair over -- is that SI needs to be
moved to the front of the design process. Certainly sanity checks as a
bare minimum before signing off on silicon. Preferably having the
PWB designed before the IC, so that the IC footprint makes sense and
the SI issues are headed off before they become problems. Please note
that all too often we could take major $$$ out of the system cost by
adding a few cents to the IC cost, but the early decision binding of
the IC design gets in the way of an optimal solution.
Another, which I've been trying to push internally for several years,
is that Si manufacturers <plug=subtle> such as VLSI </plug> have had
a largely ignored chance to differentiate themselves by helping their
customers *avoid* SI problems rather than solve them after the fact.
Believe it or not, 3COM was the subject of one of those discussions
in that our sales-suit was trying to land a design at 3COM and I tried
to convince him to push proactive SI as an advantage of choosing us.
I honestly don't know whether the disconnect was at our end, your end,
or just attenuation in the middle, but the feedback I got was that
3COM was far, far, too expert in such matters to need any help from us
and might be insulted if we tried it.
Now perhaps the other list members could chime in and say whether this
kind of disconnect between the Si and SI engineers is SOP or just local.
> "D. C. Sessions" <[email protected]> on 07/13/99 10:12:32 AM
>
> Please respond to [email protected]
>
> Sent by: "D. C. Sessions" <[email protected]>
>
> To: [email protected]
> cc: (Roy Leventhal/MW/US/3Com)
> Subject: Re: [SI-LIST] : Some Semiconductors are Unnecessarily Fast
>
> Roy Leventhal wrote:
> >
> > Bob,
> >
> > It is exactly my contention that increased edge rates as a consequence of
> > semiconductor die shrinkage, not application need, is the opposite of job
> > security for SI engineers.
> >
> > I am certain that semiconductor manufactures are not intentionally making my
> job
> > harder.
> >
> > But, the winners in this game will be a team consisting of semiconductor
> > manufacturer plus circuit designer who get the neatest, lowest cost widgets to
> > market fastest and without fuss.
>
> I can design an I/O to give you exactly the edge rate you want on any given
> pin of a custom IC. Sometimes that's exactly what a customer pays for. Most
> of the time, though, they want "How fast can I make my critical path" -- and
> they're not necessarily talking about the hardware.
>
> I/O library development is a large part of bringing out a new process
> technology.
> Thanks to core-vs-I/O voltage mismatches there's a lot of redesign every time
> around. Since the effort to redesign, requalify, and recharacterize a library
> increases with the size of the library we have a STRONG reason to keep the
> libraries simple.
>
> There's only one edge rate that we KNOW will be required in any library: full
> speed, minimum intrinsic, and let the customer deal with the SI. Aside from
> that, every customer who wants controlled edge rates wants a *different* edge
> rate. One wants 1000ps, because he's running only 50 MHz synchronous across
> ten cm of point-to-pont trace. Another wants 5000ps to use at 16 MHz in a
> random-routed bus. And so forth.
>
> Keep in mind that I have it relatively easy. *MY* customers know what the PWB
> environment will be in advance. Now what is my opposite number over in Philips
> logic products going to do with his new 74xxx244 part (Or the one at Altera
> doing a new line of PLDs)? Make it fast enough to suit the DIMM buffer
> customers, or slow enough to use with IEEE 1284? Maybe somewhere in the middle?
> Should we have several edge-rate variants within each family of standard logic
> (multiply the number of catalog items in each generation by the number of
> desired edge rates.)
>
> While we're cranking away at the 10ns library our competitors will be shipping
> product for the next generation and designing cells for the one after that.
> Then when we finally release the 0.5 micron CMOS library for customer design,
> both of the ones who waited that long will use the fast cells. One because
> she needs the speed and the other because it was specified in the RFP as being
> available from multiple vendors and the PHB who picked us doesn't even know
> what edge-rate control IS.
>
> Now none of these are insurmountable obstacles. Just don't expect the Si
> manufacturers to do it all in hopes of being noticed (been there, done that,
> can show you the scars.) We're in the business of providing customers with
> things that THEY think are important, and our test of their priorities is
> straightforward: are they (that means YOU) willing to pay for it? Will it
> disqualify us from a (large) design win? If customers aren't hard-currency
> serious we'd be fools to waste resources on an empty gesture to the Right
> Way to Do Things.
>
> So, people, the ball is in your court. If you really need controlled edge
> rates, make them part of your purchase qualification process. Pass that
> bit of news along to your suppliers, and I can promise you that if enough
> of you vote with your purchase orders you WILL get those controlled edge
> rates. Even if you're the only one who wants them -- because that's what
> I do for a living.
>
> > Robert Tsai <[email protected]> on 07/12/99 04:24:02 PM
> >
> > Please respond to [email protected]
> >
> > Sent by: Robert Tsai <[email protected]>
> >
> > To: [email protected]
> > cc: (Roy Leventhal/MW/US/3Com)
> > Subject: Re: [SI-LIST] : Some Semiconductors are Unnecessarily Fast
> >
> > Roy Leventhal wrote:
> >
> > > Several recent threads have commented that few nets on a board used to be a
> > > signal integrity challenge in the past and now almost all are.
> > >
> > > What we are seeing are a number of instances where the semiconductor
> companies
> > > are producing parts with edge rates way faster than the clock and
> application
> > > calls for. Parts with 500ps rise times or less and clock periods of 100ns or
> > > more. SI engineers are seeing more demand for their skills what with
> shrinking
> > > geometries and lack of (care? concern?) edge rate control on drivers.
> > >
> > > But, this is "make work" and is not the road to world class competitiveness
> > for
> > > our companies. There are enough real world signal integrity problems for us
> to
> > > tackle without any "help" of this sort from the semiconductor manufactures.
> > >
> > > Roy Leventhal
> > >
> > > **** 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 ****
> >
> > Hi Roy,
> >
> > As many of you already know that the edge rate is directly related to the
> > channel length of the drivers. When the semiconductor technology shrinks its
> > feature sizes from 0.5 to 0.35 to 0.18 um the edge rate goes up accordingly.
> > Unless special designs are implemented to intentionly slow down the edge rate,
> > the edge rate will keep going up. We are not making everybody's life tough
> > purposely.
> >
> > Think positively, this is job security for all of you.
> >
> > Robert Tsai
> >
> > **** 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 ****