[ibis-macro] Re: Minutes from the 26 Apr 2011 ibis-atm meeting
- From: Mike LaBonte <milabont@xxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 27 Apr 2011 14:02:24 -0400
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
>
>
Other related posts:
