[ibis-macro] Re: Minutes from the 26 Apr 2011 ibis-atm meeting Proposed
- From: Scott McMorrow <scott@xxxxxxxxxxxxx>
- To: ibis-macro@xxxxxxxxxxxxx
- Date: Thu, 28 Apr 2011 00:56:40 -0400
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
Teraspeed® 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 agreethat 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:
1.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.
2.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
Other related posts:
