[ibis-macro] Re: Question about Model Specific parameters
- From: "Scott McMorrow"<scott@xxxxxxxxxxxxx>
- To: kwillis@xxxxxxxxxxx, Arpad_Muranyi@xxxxxxxxxx, ibis-macro@xxxxxxxxxxxxx
- Date: Thu, 17 Feb 2011 21:21:42 -0500
Ken
I agree and would like to make model specific output parameters illegal when
they are not accompanied with a machine parsible spec for processing.
Scott McMorrow
President
Teraspeed Consulting Group LLC
(401) 284-1827
-----Original message-----
From: Ken Willis <kwillis@xxxxxxxxxxx>
To: Arpad_Muranyi@xxxxxxxxxx, ibis-macro@xxxxxxxxxxxxx
Sent: Thu, Feb 17, 2011 15:47:43 GMT+00:00
Subject: [ibis-macro] Re: Question about Model Specific parameters
Hi Arpad,
I am working on a back-channel BIRD draft now, so this will hopefully help
to shed some light on the parameter usage being considered. But I agree that
if there are standard things the EDA tools are supposed to do with model
outputs, they have to go in the spec. Otherwise it is all open to
interpretation and model makers don't have a standard to build their models
to.
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 Muranyi, Arpad
Sent: Thursday, February 17, 2011 10:36 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Question about Model Specific parameters
Thanks for all the responses. None of these concepts were unfamiliar
to me, but it was still nice to see them mentioned and summarized.
But most of you missed the point of my question, most notably Mike's
question at the end of his reply:
Given that so much information has been publicly and widely available
since before IBIS 5.0 was ratified, how is it that you came to
conclude
that "no EDA vendor has the knowledge on how to interpret or post
process these returned parameters"?
The answer to Mike's question "how is it that you came to conclude" is
exactly the point of my discussion: ---> Because the specification
doesn't say so. A Model Specific parameter can be anything. I agree
that in case of a Type Tap the EDA tool could have some clues to show
or print the returned values to the user, but the specification doesn't
say so. If this is an expectation from the EDA tool, then the
specification
should talk about that. But the bigger problem is that there are other
Types also which could be Out or InOut. What if my AMI model has a
parameter called CorDeNuit, Type Float, Usage Out? What should my tool
do with it? Blow its horn at the frequency given in the parameter
value?
(Those of you who know pipe organs will get this...) :-)
I am not challenging the technical explanations give to me in any of
your responses. The point I am trying to make is that this is simply
bad spec writing. If the model returns something to the tool which
supposed to be plotted or printed, or post processed in any way as shown
in Mike's DesignCon 2008 paper, the specification should define the
appropriate mechanisms to do so.
I am getting even more concerned that the Back Channel communication
was also mentioned in this discussion as a reason to keep Out and
InOut for Model Specific parameters. I am concerned that these will
cause further problems and confusions in the future. I think we should
strive to have a well defined feature set in the specification so that
individual misinterpretations or tool specific features based on secret
insider information etc... could be prevented.
Any comments or suggestions?
Thanks,
Arpad
========================================================================
===
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
Sent: Thursday, February 17, 2011 8:43 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Question about Model Specific parameters
Arpad-
Please find attached a copy of our DesignCon2008 paper on AMI modeling.
Among other things, this paper describes the use of parameters of Usage
Out to monitor the adaptive loops in receivers. In point of fact, every
receiver model that SiSoft writes (and most will admit that's a fair
few) reports the behavior of its adaptive loops in exactly this way.
Furthermore, many users of SiSoft's Quantum Channel Designer use this
data to obtain valuable information about their systems.
Even at the last IBIS Summit, there were two presentations on channel
optimization that reported the application of parameters of Usage Out
and InOut.
If you want to know how all this is done, Mike LaBonte's explanation is
right on target..
Given that so much information has been publicly and widely available
since before IBIS 5.0 was ratified, how is it that you came to conclude
that "no EDA vendor has the knowledge on how to interpret or post
process these returned parameters"?
Mike S.
On 2/16/2011 7:02 PM, Muranyi, Arpad wrote:
Hello everyone,
I stumbled on a situation with an .ami file which has
a few Model Specific parameters of Usage InOut. Our
customer is wondering why we don't do this and that
with the data that is returned by the model in those
parameters. This triggers the following thoughts in
my mind.
Model Specific parameters are specific to the model and
their meaning is not described by the AMI specification.
Therefore no EDA vendor has the knowledge on how to
interpret or post process these returned parameters
because there is simply no way of knowing what to do
with them.
For this reason, I would suggest that we make a rule in
the IBIS AMI specification that Model Specific parameter
must be Usage In, and Usage Out or InOut should not be
allowed.
Any Comments?
Thanks,
Arpad
========================================================
---------------------------------------------------------------------
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:
