I would like to expand the problems of modeling a little bit, perhaps
in a little more general way. Even though I agree with a lot of things
that has already been said along the lines of ROI, management's decisions,
etc., I want to add that a lot depends on us, engineers too.

I will try to give an example without naming names. In attempt to design
a new signaling technology a group of engineers rolled up their sleeves and
prepared for some super-duper simulations, in which they were going to count
fractions of pico-seconds. One of them made an "initial" model for their
buffer with a controlled source using relatively complicated looking
equations.
A Bessel function was also sprinkled in to be very accurate and scientific.
Another one of the engineers who wanted to simulate with this buffer had a
very
curious and suspicious mind. He ripped apart this model and plotted its
IV curves. The IV curve looked like a straight line just as if it was a
resistor. This engineer didn't like that at all, because it did not
resemble a real transistor's IV curve. He demanded an IBIS model with
correct IV curve shapes, but he never got it. This engineer went on to
another project (for different reasons), and the others continued their
work with the "initial" model for years to come. They made wonderful and
highly accurate coupled models for the interconnects, they simulated in
frequency domain, used s-parameters, etc. and put it thousands of hours of
simulation time, but the buffer model pretty much remained the same.

The long awaited day came when silicon arrived. The guys in the lab started
to discover problems. Product announcements slipped, and the simulations
had to continue to find a solution to the unexpected problems found. The
simulation gurus started to suspect their buffer models. They switched to
full transistor level SPICE models, because they realized that their
behavioral buffer model was not able to predict the kinds of problems
they saw in the lab. They know now that with a correct IV curve shape
they could have predicted these problems too.

The point here is not that we have to use SPICE models for high speed stuff.
To my knowledge, IBIS models were never tried in this project. There was a
lot of IBIS vs. SPICE controversy on this mailing list at the time.

The point is that the "initial" or "simplified" buffer model was used almost
throughout the entire project. A much more realistic IV curve could have
been made (or at least synthesized) with minimal effort. This may have not
happened for various reasons. Could have been pressure due to project
schedule, could have been lack of technical knowledge, or anything else.
The main thing is that the model was not as good as it could have been.

As a result, lots of dollars were lost not only by the company, but their
customers also. It would have been a lot cheaper to pay the cost of better
modeling. Of course, hind sight is always 20/20.

The effect of advertising in different channels is quantified and measured.
Decision makers need to do the same with regard to any money they spend
whether
it's modeling or any other expenditure such as product quality. Speaking of
product quality, for years it was ignored because it couldn't be
"quantified"
and related to ROI. Or, so people said. After the semiconductor companies
picked
themselves up off the floor they decided to invest in developing the
measures
(cost of quality, cost of lost sales, etc.) that would tell them the value
or
non-value of efforts in quality. I suspect that an up front investment in
first
developing the measures of value or non-value of efforts in modeling will
have
to occur before the value of efforts in any particular case can be assessed.
Of
course, it took a train wreck before managers in the semiconductor companies
were even interested in asking and answering the question of value with
regard
to quality. I suspect the same will be true before managers in the
semiconductor
companies will be interested in asking and answering the question of value
with
regard to modeling. Assuming the train wreck occurs, and the managers in
question get a second chance to compete, I suspect the measures will be
similar:
cost of redoing a model, cost of lost sales, etc.

I have no way at all of putting actual numbers on a given case, as I suspect
you
do not, either. I suspect the folks who quantified the quality issue for
management have experience that could be called upon. Incidentally, your
points
are identical in spirit with those made and ignored in the industries of
autos,
semiconductors, electronics, etc. I agree, the chief determinant of just how
important modeling, or quality, or - - - is - is the marketplace.

But, just because management decides a problem, or pending problem, doesn't
exists doesn't make it so. As engineers, we suspect that the problem is
real.
Heads-up management heeds the warnings and seeks out the reality, or lack
of,
behind them. Fortunately, the marketplace has a way of sorting this all out.
Trouble is, all of us, prophets and sinners, get squished under the tank
treads.

Will the train wreck occur? Perhaps. But, as switching speeds increase it
becomes more likely that the customer will be unable to sucessfully apply a
product without modeling it. Remember, modeling is a substitute for
breadboarding (perhaps through many iterations) which is becoming ever more
expensive, costly in time-to-market and ineffective in getting to
find-and-fix.

So, modeling can be viewed as a product feature. The customer may not be
able to
get his/her product to market within the market window, at an acceptable
cost
and with a quality level that their customers expect. And, modeling has to
be
presented to management as such; a required product feature when that is the
actual case.

You are correct, nobody can afford to expend infinite resources on every
good
cause. Further, the customer won't pay for it or care past a certain point.
Also, I recommend to my designers that they use the concepts of
desensitising
their designs, design margins, etc., instead of asking for unreasonably
complicated and accurate models. Customers have their part to play too.
I.e.,
back to your point of quantifying the choices to be made.

But, let's get real. The nature of the complaints on this reflector on this
subject have to do with plain shoddy work or no work at all. Not with the
fine
or esoteric points of modeling.

1. Suppliers spend millions on advertising because they have proven
to themselves a hard link between increased advertising and increased
sales. Advertising is scaled back in media channels that yield little
sales increase.

With respect to IBIS modeling, there is little history to guide the
investment. Will you spend millions and see no increase in sales? If
you spend millions and see an increase in sales, how much of the
increase
was due to IBIS and how much to other factors?

I would like to put a marketing wrapper on an argument for investment
in IBIS modeling. How can I put some numbers on it? Managers want
to know what the return will be on their investment.

2. The costs associated with bad or non-existent modeling is just as
you say: apparent and hidden. That is, not quantified. How can the
numbers be quantified?

Finally, things that are worth doing are worth doing well. The problem
is selecting the things you will do out of the nearly infinite space
of things that are worth doing. You can't do everything.

**** To unsubscribe from si-list or si-list-digest: send e-mail to
majordomo@silab.eng.sun.com. In the BODY of message put: UNSUBSCRIBE si-list
or
UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu
****

**** To unsubscribe from si-list or si-list-digest: send e-mail to
majordomo@silab.eng.sun.com. In the BODY of message put: UNSUBSCRIBE si-list
or UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu
****

**** To unsubscribe from si-list or si-list-digest: send e-mail to majordomo@silab.eng.sun.com. In the BODY of message put: UNSUBSCRIBE si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu
****