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
_____
From: ibis-macro-bounce@freelists.org
[mailto:ibis-macro-bounce@freelists.org] On Behalf Of Scott McMorrow
Sent: Thursday, April 28, 2011 12:57 AM
To: ibis-macro@freelists.org
Subject: [ibis-macro] Re: Minutes from the 26 Apr 2011 ibis-atm meeting
Proposed
Doug
You are way off base here. To start with parts of opal are technically
suboptimal, in my opinion. There is some good stuff in there, but most of
it is lacking both technically, in it's documentation, and in integration
into the IBIS framework. The reason why those birds are still sitting
around is that they are not fully documented nor support full
functionality that needs to be in models that interface in an IBIS
framework. Your assumption that network analysis stops with 2 ports at
the die is just silly. 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.
IT took months to figure out wtf you guys were doing with your s-parameter
methodology, after asking for clarification over and over again and
receiving conflicting answers from Walter, until I ran across a slide from
IBM that clarifies what they are doing and what you took on as your own
modeling methodology. Unfortunately, the IBM methodology is only a
partial methodology, and does not fit correctly into the specified IBIS
AMI requirement of an isolation boundary. That solution is only workable
if you know what the assumptions are, and those were never spelled out in
your BIRD.
First, please get off your high handed believe that the collective IBIS
community is trying to slow you down. I don't think they are, and I know
that I am not. Lump me together with that thought one more time in a
public forum and I'll come up there and we'll have words. Second, your
agent, Walter, presents your proposals as take it or leave it. Sorry,
when your proposals are technically good, I am quite happy to support
them. When they are not I will ask you to defend them. When I ask one of
your team to do that, eventually they just go dark. I have asked over and
over again to have parts of the Opal birds defended, and I've got nothing
back in response. I've asked for pretty pictures and diagrams to clarify
the jitter bird so that I and my experts can evaluate it technically, and
I've gotten 'nuttin back. What I get in response is condescension,
disdain for anyone that dare suggest something different than you've
already implemented, and that you won't change it because that's what your
customers want.
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.
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.
As for your list:
* Sparameter support
* Jitter handling
* Back Channel/Optimization
* Repeaters/Retimer
* 25G extensions
* Etc
Quite a few of us are happy to have discussions on them, as long as you
are willing to accept constructive feedback and changes. There are others
that you might be surprised to find that as much or more about some of
these things. Silly me, I actually have some specific expertise in a few
of these areas, as well do other people. Quit thinking that you are the
only guys who innovate. But please be prepared to defend your proposals
on a documentation, operational, flow, integration and technical basis.
You cannot keep stuffing everything into the AMI file and ignore IBIS
integration and side effects. You want to talk jitter, lets start by
better documenting what you have, where specifically it is applied in the
real world, what it is intended to model, what it actually models, what
the operational approximations are , where it fits in each of the flows
and whether the pre, post or whatever processing that is done either makes
sense, or is even technically accurate. Defend your positions.
Sparameters, lets discuss generalized multiport analog models that include
at least all aspects of a SerDes Tx and Rx cell, since that is often the
minimal unit that interfaces to the package. Lets talk about the
assumptions used in the methodology, it's limitations, simulation issues,
power, ground and termination, and those pesky little common modes that we
all love so dearly and usually break stuff. Lets make sure that it can be
interfaced to other non-AMI IBIS models, and does not only have just 4
ports.
BackChannel/Optimization - how about you guys using the reflector that you
set up to start having a dialog. There hasn't been a posting in over a
month, yet Walter says that he has a solution that will solve all our
problems. I'm sure the guys over at Sigrity, and other interested
parties, would be happy to discuss the technical merits of different
approaches with you. I would.
Repeaters/Retimers - a great topic. How bout we start discussing on the
ATM reflector. You've got ideas. I've got ideas. We all got ideas.
25 G extensions - a subject near and dear to my heart. I've been involved
in designing 28G channels for the past year and a half, and have just a
small amount of experience in modeling the passive elements. I know where
quite a few bodies are buried. Lets get ahead of the game and make sure
that all bases are covered, not just the one that you learned from Inphi.
Input referred noise is a nasty little problem with those amplifiers when
the signals get down to low levels, and the input becomes non-linear.
How about we add a topic called - how the heck do we faithfully extract
complex peaked termination elements on silicion (a.k.a. T-coils) that are
currently used in packages.
Or how are IBIS-AMI models going to be used in a multiport simulation of
multiple channels all operating with the same supply and termination
voltages with correlated differential and common-mode coupling within a
package.
There are lots of topics up for discussion, if you care to discuss them
and not dictate.
kindest regards,
Scott
Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax
http://www.teraspeed.com
TeraspeedR is the registered service mark of
Teraspeed Consulting Group LLC
On 4/27/2011 10:36 PM, Doug Burns wrote:
Scott, Arpad, Ken, and Fangyi
We all agree that everyone should be free to innovate. But, respectfully,
what is happening here is a concerted effort to make sure that any new
capabilities are squashed until slower implementers can provide a
solution. I interpret this as a deliberate intent to slow the usage and
adoption of new capabilities that customers require today.
I know that Scott's so called "Red Herring" (i.e. Innovation: i.e. the
ability to bring new user capabilities to the market) is a distressing
issue. From his comment
"I've seen way too much "innovation" in IBIS-AMI that did not go through
the committee, and did not have input from a broader community."
I've learned that there is a belief that the proper way to get an idea
drafted is to bring a rough idea to a large committee for discussion
before there are concrete examples. Fortunately, wasting people's time is
not a pastime we enjoy as much as others. In that light, we drafted OPAL
tm which provided not only our thoughts on model development, but
parameters and associated definitions we wanted to see in the IBIS
specification. Key insights that we believed would be considered by the
EDA/Model developer community over 10 months ago. We then broke those down
into individual IBIS Birds for group discussion which has been happening
for the last 6 months.
Did we implement the concepts in the BIRD? YES! They were needed for
design work we were doing and we are fully committed to updating those
models once the final definition of parameters is agreed upon within IBIS.
We just are not willing to wait years for this to happen!
The discussion about how IBIS-AMI should mature and develop is so twisted
that at times it defies belief. I quote
"There seems to be an implicit assumption in this discussion that what the
"innovators" decide to do should not be modified at such time that the
"innovation" is submitted to the IBIS-ATM committee for consideration."
As a group submitting a proposal, of course we will defend what we wrote.
Make a good suggestion or counter proposal and as all committee members we
will debate the merits. No one assumes that everyone will agree with
everything they write, but I guess some get offended when you defend your
ideas.
Another term that gets bantered around is the term "Compliant". This is a
major issue since any model that a vendor develops with advanced
capability would now get labeled as non-compliant. What exactly is a
compliant model? Let's take 2 cases:
Case 1: I add the capability to add back-channel communication to a model
and that such capability is fully documented and runs in only my simulator
upon introduction. In other vendor tools the model runs correctly, but
without the back channel operation.
Case 2: Same model and code as above, but with the back-channel code
disabled in all simulators
In other simulators, Case 1 and Case 2 provide the same results. Only in
my simulator can alternative results be obtained due to the advanced
function. Why should the Case 1 model be considered "non-compliant"? Yes,
it has parameters beyond those in the released specification version, but
its usage is documented and available for review, discussion, acceptance,
or rejection by the open forum and it besides its advanced capability, it
is no different from Case 2
The group must come to terms with a fair way of allowing advanced models
without penalty before it takes actions to outlaw such models!
Scott, two things I direct to you:
One: I wish you would stop being only a rock thrower and instead be a
constructive influence and contributor. In your last sermon you complained
specifically about the S-parameter proposal and Jitter proposal. This is
not the first time you have expressed such an opinion and you claim they
are incomplete and that there are:
"deep practical and technical issues that require clear and precise
communication, so that we are all absolutely sure that these parameters
meet present and future needs"
But your specific inputs, alternative Bird proposal, or other action to
advance the state of the art in these areas is sorely lacking.
All IBIS AMI files that we have developed for suppliers are fully
compliant with IBIS 5.0 and run in all simulators without modification. I
have had no feedback from IC vendors to the contrary except on the first
models we provided. If you have received an improper model, please
communicate the model and vendor to me privately so I can make sure that
they are providing only fully standard IBIS models. Given your
characterization of us as a dog, I will happily choose to be the Greyhound
since the scenery only changes for the lead dog.
The last item I will touch upon is how the committee uses it's time. While
I appreciate everyone's commitment, it is truly amazing that of all the
important topics to be discussed, at the forefront is making sure that new
features in a model can be immediately labeled as non-compliant. I'm
sorry, but this smells like an agenda for companies that can't or won't
keep up with customer demands. IBIS has long been criticized as being
behind in the times and this type of action is making sure it stays there.
I would argue that the specification should be supporting ways that
designers can add new features in a way that is compliant. Instead, what I
hear being proposed is that every idea must pass through the 1-2 year
process of this committee before it can be used. Given the preciousness of
a person's time, I wonder why that time is not being spend on critical
customer issues such as?
Sparameter support
Jitter handling
Back Channel/Optimization
Repeaters/Retimer
25G extensions
Etc
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 1993Received on Fri Apr 29 10:47:19 2011
This archive was generated by hypermail 2.1.8 : Fri Apr 29 2011 - 10:48:22 PDT