A few comments I have that your ideas brought to my mind:
Correlation/verification studies are usually trust building exercises - in the
theory, the simulator engine, the new semiconductor process being developed, the
SI engineer doing support work - whatever. As such, they
do indeed interfere with product development schedules. When they are combined
with product development they rarely lead to happy results because the
commitment to careful work is at odds with meeting a schedule.
Correlations do not have to be as tight for robust designs. Models do not have
to be as tight for robust designs. By robust designs I mean those that are not
sensitive to part and process variation. Part of the "proactivity" the board
designer, signal integrity engineer and product/digital engineer can exercise is
to architecture and implement a design so that an I/O cells' characteristics are
well centered and have good design margins.
A Monte Carlo simulation (and other statistical design techniques) can provide a
predicted envelope of expected performance. Then, actual production measurements
over time can provide a confidence building/trust building verification - which
I call statistical variation - that can be much more timely and cost effective.
This approach leads naturally to Statistical Process Control. The process of
designing the verification testing and parameters to be monitored also flows
naturally into test engineering. Of course, there has to be a reasonable amount
of trust and design margin already existing for people to commit to this.
Jonathan Dowling <email@example.com> on 07/14/99 04:56:56 PM
Please respond to firstname.lastname@example.org
Sent by: Jonathan Dowling <email@example.com>
cc: firstname.lastname@example.org (Roy Leventhal/MW/US/3Com)
Subject: Re: [SI-LIST] : Some Semiconductors are Unnecessarily Fast
Gentle SI-List Demons,
The 'spec' based I/O buffer design is the best way I've
found to design high speed interfaces. The way it works
is as follows:
1. I/O design determines various strengths/edge-rates/
pad delays which are possible to fabricate.
2. Interconnect design performs pre-layout simulation
to determine a desired range of strength/edge-rate/
pad delay for the I/O.
3. I/O design and interconnect design agree on a range
of operation for the I/O buffer which is a) possible
to fabricate and b) meets the bus interface Timing/SI
requirements over all PVT. Interestingly, the 'spec'
model does not have to line up exactly with the actual
buffer's performance. The only requirement is that the
'spec' model envelope the I/O buffer performance at all
PVT. E.g. If the timings are loose, the slow corner
'spec' could have extra margin to anticipate a poor
silicon process. Tester guardbands can be introduced
into the 'spec' model, etc.
Throughout the remainder of the design process, detailed
timing/SI analysis is then performed with the 'spec'
buffer with the knowledge that the I/O design will
eventually fit inside the prescribed box (whether it be
the 1st, 2nd, or 3rd silicon tapeout). If the I/O
buffer comes in off-target, it will change in the next
spin of silicon rather than the interconnect. This method
prevents the major headache of constantly spinning new
sets of models every time the I/O design is tweaked.
The time savings is important because typically there
is only enough design time to perform a decent bus
interface timing/SI margin analysis once in the process.
I/O design benefits by having fixed requirements to
target. If the bus interface requires impedance
controlled or slew-rate controlled drivers, I/O design
is made aware of it early in the process. Interconnect
design benefits because a fixed set of models is
necessary to perform a detailed analysis which will have
lasting meaning. Due to an unforseen problem, the 'spec'
models may have to change during the design process.
Typically these changes are slight adjustments rather than
major alterations and will not mandate a project RESET#.
The beauty of behavioral modeling is that it is easy to
alter the strength/edge-rate and run a quick sim. As Roy
suggests, the interconnect designer can be proactive
rather than reactive in the process by influencing the
I/O design early enough to make a difference.
Many successful high speed bus interfaces have been
designed with the 'spec' based modeling method. It
lends itself well to timely Monte Carlo and/or margin
The 'Spec' based modeling method does not lend itself to
exact correlation of interconnect simulation to lab
measurement because slow/fast PVT corners are difficult
to reproduce in a lab environment. However, designers
can verify that the I/O performance fits within the
allowable range by making measurements under various
switching conditions. I have been willing to accept this
limitation given that detailed correlation work is
extremely time consuming and is not supported by real
world design schedules. (It's good for graduate school
thesis work, seminar presentations, simulation tool
algorithm development, etc. where timeliness is not an
--- Roy Leventhal <Roy_Leventhal@mw.3com.com> wrote:
> You have some really great ideas on the edge rate problem that I am
> going to try.
> First, I'm working on a complex bi-directional backplane bus where we would
> to increase the daughter card stub lengths a little. Simulation shows that the
> IBIS "Max" selection (Cadence = "Fast") on the supplier's model is just a hair
> too fast in that we start failing Noise Margin on a few slot/driver
> I will clone the model provided, slow down the V-T curve and/or edit the V-I
> curves for a slightly lower Vol. Re-simulation will then tell me if my Noise
> Margin problem is fixed. I can then go to my supplier(s) with a max edge rate
> specification that they can respond to in a businesslike manner.
> This kind of interactive proposal - counterproposal testing of design
> feasibility is just what early simulation and reality checking should be doing
> for both supplier and user. And, obviously, not just for edge rates.
> Best Regards,
> "D. C. Sessions" <email@example.com> on 07/13/99 04:12:06 PM
> Please respond to firstname.lastname@example.org
> Sent by: "D. C. Sessions" <email@example.com>
> To: firstname.lastname@example.org
> cc: (Roy Leventhal/MW/US/3Com)
> Subject: Re: [SI-LIST] : Some Semiconductors are Unnecessarily Fast
> Roy Leventhal wrote:
> > D.C.,
> > Some additional thoughts & questions:
> > I use Cadence's SpecctraQuest/SigExplore to simulate the boards. Those tools
> > IBIS I/O cell models. SPICE models would cause me lots of extra time and
> > to get into IBIS format. We have found topology simulation, timing guided
> > placement, impedance guided routing, etc. to be all very helpful.
> > I STRONGLY advocate sanity checks very early in the process. For such checks
> > we get "+/-20%" models early on?
> No prob. The standard-cell libraries have been IBIS-characterized since 0.6
> We've had some rough spots with model quality but we've taken them as
> to improve the modelling process. Customer feedback on matters like that is
> extremely critical (and on that I think I can safely speak for the other Si
> of the IBIS committee.)
> Other companies may be different. After all, why should they go to the
> trouble? Unless, of course, your components acquisition team gets brutal
> with "no IBIS models? Don't bother bidding."
> Better yet, though, why don't you (plural: meaning customers) take charge of
> process and start specifying device I/O with IBIS models in the first place?
> YOU know your application better than we do (or blinking well *should*!)
> That way our sales force, who are of course clueless, *have* to come to the
> Geek Force to make sense of things. As it is, they (mistakenly) think that
> they know what they're talking about with nonsense such as "4x driver" and
> "8 mA driver."
> Demand the moon, stars, and Aurora Borealis. You won't get them, of course,
> but at least we'll be talking -- and the engineers will actually be dialed
> in for a change. Sure beats hearing about it later.
> Oh, and BTW: make the IBIS model part of the purchase contract. If you get
> a batch of parts that are outside of the envelope, make the vendor eat 'em.
> It's long past time that my colleagues got religion in the only sure way.
> > There are several caveats. Of course we don't want to get into "you said - -
> > finger pointing of early, first cut models. Then too, I would guess that
> > models give you no process control information feedback. Lastly, more
> > topologies need more accurate, worst case models not usually avilable early
> > Unless you're designing into a standard process.
> > What's your ideas on dealing with these issues?
> Love it. Keep in mind that we *are* using a standard process, so I can get
> some pretty good models very early in the game. Better yet, as above, YOU do
> the IBIS models. It's not like SPICE, after all; you don't need access to
> burn-before-reading process tables. Don't take OUR word for what the limits
> are; we'll push them out as far as we think we can get away with it so that
> the yield points are better and we can be sloppier about the design
> One of our people put it very well recently. He pointed out that
> companies don't make 'product'. We make 'parts', and YOU make 'product'.
> Until YOUR _products_ ship to revenue customers WE haven't succeeded. Making
> you get by with some silly library modeled after thirty-year-old
> parts that were doing well to get two flip-flops into a 14-pin package and
> hold the clock-to-Q times to a few hundred nanoseconds -- now THAT is really
> dumb. It's also exactly what's going to keep on happening until customers
> start demanding real, meets-our-needs technology instead of data sheet
> templates copied off of French cave walls.
> D. C. Sessions
> **** To unsubscribe from si-list: send e-mail to email@example.com.
> the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP.
> archives are accessible at http://www.qsl.net/wb6tpu/si-list ****
> **** To unsubscribe from si-list: send e-mail to firstname.lastname@example.org.
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 ****
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
**** To unsubscribe from si-list: send e-mail to email@example.com. 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 firstname.lastname@example.org. 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 ****