Hi all, I also agree here, the spec can't let Model_Specific parameters go drive tool behavior directly, since model makers can make up any Model_Specific parameters they want for their model. Obviously EDA tools can't be coded for that. That is the role of the Reserved_Parameters. I also agree with some of Arpad's other comments that we need to get away from "innovation" meaning "add lots of new Reserved_Parameters". That causes lots of churn, and tools are constantly needing updates to keep up with the latest keywords (and AMI models that introduce them pre-standardization). Model users are then always caught between new models and tool support. It quickly gets out of control. The basic approach of hard-coding some item, then parameterizing a whole bunch of items for the hard-coded item, is not a desirable one. When the hard-coded item runs out of steam, you have a bunch of new keywords to go implement for the next item, etc. A key concept in this is that we need to try very carefully to choose few, general, and powerful Reserved_Parameters, and try to keep them to a minimum. Less is more in this respect. I sent feedback of this nature on the review of the jitter spec, and am also trying to do the same with our back-channel BIRD. It is not the easiest thing to do, granted, but I believe we need to think along these lines. Thanks, Ken Willis Sigrity, Inc. 860-871-7070 kwillis@xxxxxxxxxxx -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of fangyi_rao@xxxxxxxxxxx Sent: Wednesday, April 27, 2011 1:51 AM To: scott@xxxxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: Minutes from the 26 Apr 2011 ibis-atm meeting 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 --------------------------------------------------------------------- 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