This really is one of the more important discussions we've had. There
is a parallel to the browser war in which Mozilla and Microsoft each
proposed competitive new language features and implemented them in
their browsers before standardization was achieved. It was painful
because pages tested against one browser often would not work right in
the other. That condition persists today, to a lesser extent.
Many useful new features emerged from the browser war. The essential
platform that made it possible is HTML (based on SGML), a language
structure that allows unrecognized information to be easily ignored,
coupled with a specification that suggests silently ignoring
unrecognized content. From HTML 2.0 (
http://tools.ietf.org/html/rfc1866, 1995):
*4.2.1. Undeclared Markup Error Handling
*
To facilitate experimentation and interoperability between
implementations of various versions of HTML, the installed base of
HTML user agents supports a superset of the HTML 2.0 language by
reducing it to HTML 2.0: markup in the form of a start-tag or end-
tag, whose generic identifier is not declared is mapped to nothing
during tokenization. Undeclared attributes are treated similarly. The
entire attribute specification of an unknown attribute (i.e., the
unknown attribute and its value, if any) should be ignored.
Adding the BIRD clause we discussed this week would have an entirely
different tone. Instead of recommending that unrecognized content be
ignored, it calls for unrecognized content to be absent. The
philosophical question may be if, as a standards organization, we are
more likely to foster and incorporate useful new additions to the
standard by taking experimentation into the fold or leaving it outside.
Mike
On 4/27/11 1:09 PM, "fangyi_rao@xxxxxxxxxxx" <fangyi_rao@xxxxxxxxxxx>
wrote:
Hi, Mike;
I am suggesting model specific parameters can't interfere the
simulation flow or have effect on results. It's fine for models to
report parameter values to users.
Regards,
Fangyi
*From:* ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] *On Behalf Of *Mike
Steinberger
*Sent:* Wednesday, April 27, 2011 4:29 AM
*To:* ibis-macro@xxxxxxxxxxxxx
*Subject:* [ibis-macro] Re: Minutes from the 26 Apr 2011 ibis-atm
meeting
Fanyi-
Are you suggesting that AMI_parameters_out should have no content,
and that models should not be able to report their state? Please
be aware that this information can be very useful to model users,
and many existing models use AMI_parameters_out to make this type
of information available.
Mike S.
On 04/27/2011 12:51 AM, fangyi_rao@xxxxxxxxxxx wrote:
I agree with Arpad and Scott. If the standard allows model
specific parameters to change simulation results, then we don't
have a standard at all, because only model vendors know what those
parameters mean and how they should be used. I'd suggest the spec
explicitly states that all model specific parameters must be of
usage In.
I do not see a problem with innovation here. By definition
innovation is always something outside of an existing standard.
After it's reviewed and accepted by the rest of the committee
members, it can be incorporated into the standard.
As for the concern on how quickly can the committee pass an
innovation proposal, it's an operational issue, not a standard issue.
Regards,
Fangyi
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow
Sent: Tuesday, April 26, 2011 3:40 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Minutes from the 26 Apr 2011 ibis-atm
meeting
Any company is free to innovate in any way that it wants. That
does not
mean that the innovation will necessarily be accepted for
standardization, and become an IBIS compliant solution. So what?
That
is the way standardization processes work. However, some would argue
that all Model Specific parameter innovation should be accepted as
IBIS
specification compliant, even when that parameter output effects the
past, present, or future simulation process flow, and therefore
the end
results. This is not standardization. It is chaos.
Respectfully. The discussion regarding "innovation" is a red
herring.
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. As a
result it is sub-optimal. Sometimes "innovation" can be wrong.
It is
the purpose of the committee to navigate through the broad
implications
of all new parameters and features so that we are certain that we can
accommodate both present and future modeling requirements. There is
always a dynamic tension between innovation and specification
processes.
A good example of this has been the attempt to specify s-parameter
usage
for IBIS-AMI. Technically the solution is partial. Practically the
solution as originally presented was poorly defined, imprecise,
and did
not allow for extension to other analog modeling requirements,
such as
power and termination noise injection, or the ability to model the
analog transient power currents. Another example is the
"innovation" of
design kits. If you go to a well-known FPGA vendor and download
their
IBIS-AMI models you'll find that these models are essentially useless
without a specific EDA vendor supplied design kit. The IBIS analog
models within the downloaded model are worthless, except in
conjunction
with the design kit. Essentially, that FPGA vendor has chosen a
dog in
the fight, and has produced models that cannot produce correct
results
as-is.
Jitter parameters are going to quickly devolve into an absolute
mess (in
my opinion) which have less to do with the technical nature of jitter
processes, and more with the multitude of ways that others have
chosen
historically to imperfectly model jitter. Care should be
exercised in
whatever we choose to include in the jitter specification. 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.
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. The "innovation" will be deemed to be worthy for
inclusion in the specification as-is. With this sort of operational
assumption, it makes absolute sense to argue that Model Specific
parameters can be used for any purpose whatsoever, without regard to
standardization compliance. It is therefore an a priori
conclusion that
eventually the parameters will be included in the specification,
and all
will be well with the world.
I submit that only well-defined reserved parameters can be the
basis of
the IBIS-AMI standard, and that optional model specific parameters
that
potentially modify the simulation flow and/or past, present, or
future
results, based on their outputs have no place in being blessed by the
specification. They are not specification compliant, but may very
well
be used to prototype new innovative features, which may or may not be
submitted to or included in a future version of the specification.
However, if there is merit to the proposed innovation, then it can be
submitted to the committee, debated, and modified appropriately,
as the
full committee sees fit.
There are always inherent risks in innovation. One persons
innovation
may just be a bad idea when viewed from a different perspective.
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(r) is the registered service mark of
Teraspeed Consulting Group LLC
On 4/26/2011 4:55 PM, Mike LaBonte wrote:
Minutes from the 26 Apr 2011 ibis-atm meeting are attached.
Mike
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
