RE: [IBIS] RE: [ibis-macro] Re: Minutes from the 26 Apr 2011 ibis-atm meeting Proposed

Doug,

Even though your message is addressed to Scott, I feel I have to

respond to it because you made several comments about (I assume

the ATM) committee, its chairman's responsibilities (me) and our

motivations.

I wonder what is the basis of the claims you are making with such

great authority when I could count on one hand how many times you

have attended the ATM meetings in the last several years. You

simply have no clue on what is going on in the meetings and it

seems that the information you are getting from your colleagues

who do attend the meetings is heavily filtered and biased.

The number of constructive feedback given to your company's or anyone

else's proposals is countless and come in written or verbal, public or

private forms. Your claim that we are "Just saying I don't understand
or I disagree ..."

is simply not true. Also, your claim that "...the committee focuses on
trying to

eliminate that possible use as its number one crusade..." and "the
reason the committee

chose to focus on this instead of the functionality is, in my opinion,
politically motivated"

is dead wrong. The committee's number one priority currently is to

clean up the errors and inconsistencies in the existing specification.

The issues with Model_Specific (Usage Out/InOut/Info) are simple logical

problems in the specification that need to be addressed. The rules in

the current specification simply do not make logical sense. There is

nothing political about this, it is a plain logic problem. I am very

sorry to hear that you are unable to comprehend that. Unfortunately

this is just one of the many logical nonsenses in the specification.

But now that you reminded me to what my responsibility as the chairman

of the committee is "It is the responsibility of the committee members
to look past the

individual and address the topic and it is the responsibility of the
Chairman to ensure that that

happens." I am getting very close to sending a request to our postmaster

to remove you from the ATM email reflector, in order to make sure that

we can make progress in our work without individuals like yourself

hindering us with useless, false and inflammatory accusations.

Sincerely,

Arpad

=======================================================================

From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Doug
Burns
Sent: Friday, April 29, 2011 12:46 PM
To: scott@teraspeed.com; ibis-macro@freelists.org; ibis@eda.org
Subject: [IBIS] RE: [ibis-macro] Re: Minutes from the 26 Apr 2011
ibis-atm meeting Proposed

Scott,

Let me address your comments one by one:

1. I have never stated that OPAL is the final word on every topic
and if additional clarifications or capabilities are needed, I for one
would be glad to have the discussion. However, the issue is not OPAL
since at IBIS we only deal with BIRDS before the committee.

2. Your statement: "Your assumption that network analysis stops
with 2 ports at the die is just silly" is your assumption, not ours.

3. That statement continued as: It's a good first approximation, but
not something that I want to take into the future, where I will be
modeling power, ground, termination networks and multiple serdes
channels simultaneously". We agree about the issues in the future, but
we are not in the future. There are specific issues that need to be
addressed today and addressed quickly. I will also say that we should
try to make sure that what we do implement today has capability for
expansion toward these other topics, but waiting for resolution of these
futures impedes the present.

4. You express concerns about the clarity of the submitted BIRDS in
various parts of your email. I take this seriously and will work to
ensure that they are clear and concise. We have no agenda to frustrate
the committee, but I require clear, concise, constructive feedback. Just
saying I don't understand or I disagree doesn't cut it. I need specifics
as to what or why as well as alternatives that you may suggest. You may
constructively criticize what I propose only if you are willing to
provide real feedback and examples of what you require.

5. As far as the committee trying to slow us down. Scott, as they
say, the proof is in the pudding. Let's look at history.

a. When we proposed new features and included them as |SiSoft
parameters, all hell broke loose from our esteemed colleagues about
"Non-Standard Models". There was no discussion about what was were
needed, it was purely attack mode.

b. We then modified our approach and used the model specific
parameters to convey information. Now instead of addressing the needs of
the extensions, the committee focuses on trying to eliminate that
possible use as its number one crusade. When asked for a solution, the
response is "Make non compliant models". What do you think will be the
response if we go down that road? There is a saying here Scott, "I may
have been born at night, but it was not last night!"

c. We have asked the committee for a way such that advanced features
don't get attacked and so far we have made little progress.

6. As for "Lump me together with that thought one more time in a
public forum and I'll come up there and we'll have words". I have this
to say, Please do not threaten me either publicly or privately.
Personally, that sort of comment is improper and is beneath the type of
individual that I think you are. I expressed my opinion and I stand by
what I said. I want to move forward and would gladly be willing to work
with you in a constructive way to advance our goals concerning IBIS-AMI
modeling.

7. We all understand that a committee is a democratic process. We
also need to understand that each individual involved brings along
certain baggage that needs to be worked with (That include you, me,
Walter, and the rest of the crew). It is the responsibility of the
committee members to look past the individual and address the topic and
it is the responsibility of the Chairman to ensure that that happens.

8. Let's talk about Model Specific IN/OUT.

a. "The reason we're arguing about Model specific Outputs and
In/Outs, is because there are a plethora of models out there that meet
the spec, but don't run in all tools, unless time is spent to reverse
engineer what was actually done. This bothers customers. An example
that I've observed is that the brilliant S-parameter analog model
methodology provides two different results if driven by a 50 ohm driver
or a pure voltage source. This bothers me, since the requirement is an
isolation boundary between the algorithmic and the analog domain. Had
the interface been thought out more carefully, this need have been the
case, which is why I am against the approach that you advocate." The
issue here appears to be more a matter that the assumptions of what was
a valid construct are not clear and that such clarification is needed.
This example surely does not rise to the level as a reason to outlaw the
use of the IN/Out parameters. I'll also note here that how you
punctuated your comments was meant to insult or inflame. We all need to
refrain from this behavior if we expect civil discourse.

b. "I think it's absolutely fine to have Model Specific outputs that
provide information that can be stored, plotted, tabulated, or displayed
in any way that any one desires. This is not at issue. The issue is
with non-standard parameters that are designed to alter simulation flow
or results. This cannot be acceptable in an industry specification,
since it requires knowledge that exists only with the model maker and
simulation vendor that the model was targeted for. Yet you guys have
spent the last month arguing against that perfectly rational position,
which is why it has taken up so much committee time. Just capitulate
and go on. Accept that you will not get a consensus that agrees with
your position." The issue here is with the new parameter not with the
actual Model Specific IN/OUT. The REAL concern is that this allows a
proposed parameter to pass the parser and get advertised as compliant.
We do understand the issue, but as stated before, the behavior of the
committee and their associated companies when new features are
introduced is to start throwing FUD into the air. This argument would
not be needed if the committee was working to address the current
shortcomings in functionality. I am sorry, but the reason the committee
chose to focus on this instead of the functionality is, in my opinion,
politically motivated. Give me a way to build models the industry needs
now without always being attacked and then I will be willing to rethink
my position.

c. Todd is going to make a proposal that try's to meet the needs of
both developers and EDA suppliers.

9. As for the rest, we are in agreement that discussion is needed on
many fronts. You mentioned many topics and I await the proposals.

Best regards,

 Doug

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org
|with the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or e-mail a request to ibis-request@eda-stds.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda-stds.org/pub/ibis/email_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/users_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/email/         E-mail since 1993