[ibis-macro] Re: Minutes from the 26 Apr 2011 ibis-atm meeting

  • From: "Ken Willis" <kwillis@xxxxxxxxxxx>
  • To: <fangyi_rao@xxxxxxxxxxx>, <scott@xxxxxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 27 Apr 2011 10:19:40 -0400

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

Other related posts: