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
