[ibis-macro] Re: user-defined block size

  • From: Mike Steinberger <msteinb@xxxxxxxxxx>
  • To: ibis-macro@xxxxxxxxxxxxx
  • Date: Thu, 24 Feb 2011 08:55:41 -0600

Arpad-

I don't know who this "really smart EDA vendor" is that you're talking about, but I sure hope they don't actually exist because I wouldn't want to compete with them.

I agree that it would be a good thing to state in the spec that:
Within any given simulation, the block size is assumed to be the same for every call to AMI_GetWave().

That's what we're doing now, so if everyone can agree on this statement, that's less work for me. I also don't see any way that this could constrain some future solution, so I don't see any downside to this statement.

Alfred-

Block size is the number of samples in the waveform segment, not the number of bits.

Mike S.

On 02/24/2011 01:48 AM, Chong, Alfred wrote:

Arpad,

I like your proactive attitude and yes I agree to spell out the detail now than latter.

I had been running AMI model smoothly with couple of EDA tools until one day I ran the AMI model

with a particular EDA tool that generated fractional bit for each block. Eg: instead of 1000 bits per block

it generates 1000.3 bits.

Should the block size in integer or float format? Should this be specified in the spec if we allow

the block size to be type float as this will change the implementation detail of the AMI model.

Thanks,

Alfred

------------------------------------------------------------------------

*From:*ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] *On Behalf Of *Muranyi, Arpad
*Sent:* Thursday, February 24, 2011 12:50 AM
*To:* ibis-macro@xxxxxxxxxxxxx
*Subject:* [ibis-macro] Re: user-defined block size

Mike,

I can't help but live up to your expectation:

"I do see this question as an excellent candidate for a prolonged debate"

and prolong this thread a little bit.  This example is

a perfect one to illustrate why a well written specification

is so valuable.

Let's say that some really smart EDA vendor decides for

some super secret patented reason that they will call

GetWave with all kinds of different sizes.  This is

currently legal according to the specification because

it doesn't say anything about it, correct?  All of the

sudden models start crashing with splashing fireworks.

You won't be able to blame this really smart EDA vendor,

because they didn't violate the specification.  What

would you do in this situation?  Have everyone rewrite

their models, or change the specification?  Also, now

that this issue was brought up to the surface, would

you wait in silence until the fireworks begins, or

would you rather do something before that happens?

Wouldn't it have been better if the authors of the

specification would have already thought about this

before the fireworks begins and spelled out in the

specification that all GetWAve calls shall have the

same size within a certain simulation run?

Well, the really smart EDA vendor would probably say

that it would be better not to say that in the spec

because that way they would not be able to sell

their patented super secret smart idea.

The other alternative is to change the spec so that

it would say that each GetWave should have provisions

in its algorithm to be called with a different block

size.  But this will put the burden on the model makers

to essentially rewrite their models under the new rules.

So the tension is now between the really smart EDA vendor

and the model makers.  I don't know who will win at the

end.  But I do know that if the specification would have

been better written in the first place, this issue would

have not happen or may have caused a lot less headache...

I prefer to be proactive, but I know with complicated

stuff like ours it is hard not miss something.  However,

when we notice that we missed something, I think it is

only fair to ask the questions, and ask what we should do

about them.  That's what I am doing.  I am not spending

my time with these emails with the purpose to irritate

my audience, or waste the ATM committee time...  I am doing

this with the purpose of having a better specification,

and to limit the number of problems in the future as

far as possible.

So I would like to ask you to make comments which help

resolving the technical issues discovered in the spec

instead of fostering prolonged defensive messages like

this one...

Arpad

==========================================================

*From:*ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] *On Behalf Of *Mike Steinberger
*Sent:* Wednesday, February 23, 2011 3:47 PM
*To:* ibis-macro@xxxxxxxxxxxxx
*Subject:* [ibis-macro] Re: user-defined block size

Arpad-

Now there you have an interesting question that has not been addressed yet.

I will admit that there are a two or three models I've helped write (no more than that) that did assume that the block size would always be constant, or at least that the block size would never increase beyond the block size for the first call. (Sub-par programming practice on my part.) If there were an important reason to do so, I could add the little bit of additional code it would take to support completely variable block size. No big deal.

On the other hand, I don't see what problem would be solved by making the block size different for every call.

I do see this question as an excellent candidate for a prolonged debate.

Mike S.

On 02/23/2011 02:14 PM, Muranyi, Arpad wrote:

A related question:

Does the GetWave call size have to be

the same for each call or can they be

different between calls?

Arpad

======================================

*From:*ibis-macro-bounce@xxxxxxxxxxxxx <mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] *On Behalf Of *Ken Willis
*Sent:* Wednesday, February 23, 2011 12:49 PM
*To:* 'Mike Steinberger'
*Cc:* ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
*Subject:* [ibis-macro] Re: user-defined block size

Hi Mike,

I am not sure. But I am also not sure how the user would know what to set the block size to be.

Thanks,

Ken Willis

Sigrity, Inc.

860-871-7070

kwillis@xxxxxxxxxxx <mailto:kwillis@xxxxxxxxxxx>

------------------------------------------------------------------------

*From:*Mike Steinberger [mailto:msteinb@xxxxxxxxxx]
*Sent:* Wednesday, February 23, 2011 10:55 AM
*To:* Ken Willis
*Cc:* ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
*Subject:* Re: user-defined block size

Ken-

What bad things do you expect to happen if the user makes an unfortunate choice of block size?

FYI, I don't know what that would be.

Mike S.

On 02/23/2011 08:30 AM, Ken Willis wrote:

Hi Mike,

How would the user know what to select for block size? From some documentation in the model? What if the Tx and Rx both use GetWave and come from different suppliers, and each recommend a different block size? I don't know if relying on the user to figure this part out is the best direction to take.

Thanks,

Ken Willis

Sigrity, Inc.

860-871-7070

kwillis@xxxxxxxxxxx <mailto:kwillis@xxxxxxxxxxx>

------------------------------------------------------------------------

*From:*ibis-macro-bounce@xxxxxxxxxxxxx <mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] *On Behalf Of *Mike Steinberger
*Sent:* Sunday, February 20, 2011 4:35 PM
*To:* ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
*Subject:* [ibis-macro] Re: One MORE time without the typo ... RE: Re: Question about Model Specific parameters

Vladimir-

Good technical question. Thank you for that.

Given the current definitions, the EDA platform gets one instance of the AMI_parameters_out string every time it calls AMI_GetWave(). Therefore, there is one sample of every parameter in the AMI_parameters_out string every time AMI_GetWave() is called. Given this definition, the time resolution of the output parameters is equal to the time domain waveform block size. No more, no less, no other possibility.

The question, therefore, is how the block size gets chosen. This value is definitely supplied by the EDA platform in the call to AMI_GetWave(). How the EDA platform determines the block size is implementation dependent and outside the scope of the IBIS-AMI specification. One would typically expect, however, for the EDA platform to get the block size from the user. In that case, the user can specify the time resolution of the output parameters directly to be anything from one time domain sample to however many millions of time domain samples.

In our experience, this solution has been working quite satisfactorily; so I don't see any reason to change it. If the IBIS-AMI specification needs to present this solution more clearly, then I believe the text Todd offered should be sufficient.

Mike S.

On 02/20/2011 01:47 PM, Dmitriev-Zdorov, Vladimir wrote:

Doug,

> the model developer can put data into a time stamped file with the "OUT" parameter

Do you mean the AMI model developer, or EDA platform? Of course, the DLL may internally damp the data into certain files, but if I recall correctly that was called a bad style (in Opal document) because of possible conflicts with many models. Plus, the running tool must be aware about this file, however it normally gets an info saying that a certain parameter with a certain name has a type 'out'. The spec does not detail about files being of type 'out'.

If we put files aside, and consider some parameter of the type 'out' being specified in the parameter_out_string, here is what I cannot understand. This string becomes available to EDA platform only after calling GetWave. However, as we know, the length of the portion processed by GetWave can be very different, depending on the user choice (e.g. 1000 bit per call, or 10,000 bits per call). Hence, the value we'll get out of GetWave will have different resolution and in some cases will be more or less useful. Does any 'out' type parameter be associated with the resolution? You may reply that the out type could be a list or array, but then again, the length of this list or array should be related to the length of the waveform processed by GetWave. How to resolve this?

Vladimir


-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx <mailto:ibis-macro-bounce@xxxxxxxxxxxxx> on behalf of Doug Burns
Sent: Sun 2/20/2011 11:00 AM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> Subject: [ibis-macro] Re: One MORE time without the typo ... RE: Re: Question about Model Specific parameters

This is a truly amusing thread. Let us look at the facts and what appears
to be agreed upon:

1)       The DLL accepts data on items labeled with an "IN" declaration
and the model developer can put data into a time stamped file with the
"OUT" parameter.  (Hey. This is already defined!!!)

2)       Everyone accepts that the data in the "Out" file should not be
used to then determine the simulator response (BER, Jitter, or whatever).
(Maybe this is what should be Spec'ed to keep a level playing field)

3)       The "OUT" file should be in a machine readable format, Such as
CSV so that ANY reasonable display tool can import and plot. (Look another
thing to "Spec" that clarifies usage)

4)       If a Model contains an "OUT" Statement, the variable should be
described in the AMI file and the user documentation for the model (Ahhh,
more stuff to spec to clarify the developers responsibility)



So, with the above, the EDA platform does not need to know anything. It's
not using the data to solve the design problem

We have not restricted developers from providing informational data to the
user, not have we required it.

Any plotting tool, either in the EDA platform or not, that reads a CSV
file can access the data..

The user gets to determine if they care about what is in the "OUT" file
based upon the documentation



Arpad,



 The issue with your example is that it violates the above. You are asking
for the EDA platform to do something with the data other than just be able
to display. That violates item 2 above.  If a model is supposed to blow a
horn, then I agree that a Model specific parameter is needed, However,
that is an "IN" parameter telling the EDA platform to do that. If the
model also "OUT" a value whenever it was supposed to blow the horn, then
that is OK.



Doug



  _____

From: ibis-macro-bounce@xxxxxxxxxxxxx <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Sunday, February 20, 2011 12:35 PM
To: ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: One MORE time without the typo ... RE: Re:
Question about Model Specific parameters



Todd, Scott,



Let's put the finger pointing and personal overtones aside

and talk on a technical level.  The issue is not whether

anyone did or does something special.  The issue is that

the spec allows that to happen.



Todd,



SiSoft's responses to this thread mentioned on multiple

occasions that since the parameter is a Type Tap, the tool

should know to plot the returned values.  In that case we

should put it into the specification that for Type Tap the

tool is expected or encouraged to plot, or write a log file,

or report the returned values in some way that is useful to

the user.  But we have other Types in the spec in addition

to Tap.  What are we suggesting for the EDA tool to do with

those?



Regarding "The model's documentation should describe what each parameter

represents, and therefore whether it makes sense to plot it in some
special way"

I don't see how you can say that an EDA tool could do anything

based on interpreting each model's documentation and respond

accordingly.  This would take a little too much of artificial

intelligence and a self modifying software code.  Remember,

there are other Types of Model Specific parameters of Usage

Out or InOut.  What should be the expectations for those?



Take for example my previous example of the Float parameter

CorDeNuit.  If I put it in the "Description" of this parameter

that the EDA tool should blow its horn, but only at night,

is your tool going to be able to read and interpret this

description (documentation) and blow its horn if this

parameter returns a value during the night time hours?

Besides, what is the definition of night time hours?  Is it

midnight to 6 a.m. or 5 p.m. to 8 a.m., etc.?  In addition,

I don't see how an EDA tool will read a Word document or PDF

file, or a Readme.txt file to find out how to interpret the

Model Specific parameters of an .ami file.  This sounds a

little too new age-ish to me.



Arpad

===============================================================



From: ibis-macro-bounce@xxxxxxxxxxxxx <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
Sent: Friday, February 18, 2011 5:15 PM
To: ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: One MORE time without the typo ... RE: Re:
Question about Model Specific parameters



Scott,



Looks like you're assuming we're doing something special because we "know"
something about the parameter being plotted.  That isn't the case.  The
.ami file snippet for the model in Mike's paper looks something like this:



      (dfe

         (taps

             (1 (Usage InOut)(Format Range 0 -1.0 1.0)(Type Tap)

                 (Default 0)(Description "First DFE tap."))

             (2 (Usage InOut)(Format Range 0 -1.0 1.0)(Type Tap)

                 (Default 0)(Description "Second DFE tap."))

             (3 (Usage InOut)(Format Range 0 -1.0 1.0)(Type Tap)

                 (Default 0)(Description "Third DFE tap."))

             (4 (Usage InOut)(Format Range 0 -1.0 1.0)(Type Tap)

                 (Default 0)(Description "Fourth DFE tap.")))



This declares the parameter names used to pass tap data into the model,
and tells the simulator the model may pass data back via
ami_parameters_out using the same parameter names.  Declaring the
parameters as (Type Tap) tells the simulator the data to be passed to/from
the model is a floating point number - so, in this case, the simulator
collects the values for each parameter at each Getwave call, associates
them with the appropriate timestamp, and then plots them.  No magic there.



Fact is, we could have just as easily called the parameters "Frobozz" or
"My_Little_Froggie" with (Type Float) . and the process would have worked
the same. There's nothing magic about the parameter names.  If you want to
collect a whole bunch of parameters and scatter plot them against each
other, go for it.  The model's documentation should describe what each
parameter represents, and therefore whether it makes sense to plot it in
some special way.  When a parameter returns a number, it just makes sense
to plot how that value progresses throughout the simulation.  I can't
imagine why it wouldn't. Making that "illegal" makes no sense at all.



If you're proposing a standardized form of post-processing
ami_parameters_out data, then write it down & let's discuss it in the
Tuesday meetings.  Talking about potential applications is all well and
good, but it doesn't move the spec forward.



Have a good weekend,



Todd.



________________________


Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx <mailto:twesterh@xxxxxxxxxx>
www.sisoft.com <http://www.sisoft.com>



From: ibis-macro-bounce@xxxxxxxxxxxxx <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow
Sent: Friday, February 18, 2011 2:14 PM
To: ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: One MORE time without the typo ... RE: Re:
Question about Model Specific parameters



Todd

In short, no.  You keep avoiding the point.  Your last step is undefined
and requires someone, either the EDA software writer, or the end-user, to
determine:

1.      What the parameter is.
2.      What to do with the parameter.


If you are both the model maker and the EDA vendor, then you are in the
privileged position of knowing what the parameters are, how they work, and
whether or not there is an "interesting" way to present or post-process
the data.  Since a model specific parameter is provided blind, without
additional documentation, processing or presentation of these parameters
by anyone else, would be a guess, possibly educated, but still a guess.

The only way to know how to plot, present, or post-process a Model
Specific output parameter today is via a-priori knowledge of the "meaning"
of the parameter.  Yes, DFE taps are a no-brainer, only because we all
believe we have a-priori knowledge of what a Tap is.  The parameters could
have just as easily have been named  XYZ_frog1, XYZ_frog2 ... etc.  Do you
know how to deal with this parameter?  Neither do I.

I maintain that the model maker needs to document, in a machine and human
understandable way, what the EDA tool is expected to do with these
parameters whether it be, plotting, presentation, or post-processing.
Otherwise, the parameter is not needed.  This means that we as a committee
have to come up with documentation on what to do with these model specific
output parameters.  The point is, no one knows whether these outputs are
important unless they are documented.  IF they are unimportant, then they
should not be there.

An example of acceptable processing might be:

*       Reserved for Model Development/Debug
*       Plot with respect to time
*       Plot against another parameter as a scatter plot
*       Status with a some sort of text description

*       For example 0 = PLL out of lock, 1 = PLL locked
*       Loss of signal


Scott

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

TeraspeedR is the registered service mark of
Teraspeed Consulting Group LLC


On 2/18/2011 1:38 PM, Todd Westerhoff wrote:

Arpad (and Scott),



For anyone who may not recognize the picture, the excerpted diagram is
Figure 7 from the 2008 DesignCon Paper "Demonstration of SerDes Modeling
using the Algorithmic Modeling Interface (AMI) Standard".

The paper is available on-line from both the DesignCon InfoVault
(http://www.designcon.com/infovault/) and SiSoft's eLearning site
(http://www.sisoft.com/elearning/).



I think we're debating a semantic difference between post-processing and
plotting.  The graph in the presentation was created by accumulating the
AMI_parameters_out data passed back from each Getwave call and then
plotting the value of the DFE taps as a function of time.  I'm hoping
you'll agree that the EDA tool knows the timestamp associated with Getwave
call, so we don't need to debate the meaning of "as a function of time."



If you believe we need to spell this out in more detail, how does the
following text:





Add the following step to each of the application scenarios in section
10.2:

Optionally, the EDA platform may log the contents of AMI_parameters_out
for later display. The generic steps to do this are:

Parse AMI_parameters_out according to the syntax definition provided in
section 10.3.1.2.6.

Record the name and value of each leaf of the parameter tree. The type of
each value is determined directly by the BNF syntax rules that were used
to parse the value's representation in the parameter string.

Present the data to the user in whatever manner the EDA tool deems
suitable





Suit you?



Todd.



P.S.  I really proofread this one . hopefully I got all the typos out!



________________________


Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx <mailto:twesterh@xxxxxxxxxx>
www.sisoft.com <http://www.sisoft.com>



From: Muranyi, Arpad [mailto:Arpad_Muranyi@xxxxxxxxxx]
Sent: Friday, February 18, 2011 9:53 AM
To: twesterh@xxxxxxxxxx <mailto:twesterh@xxxxxxxxxx>; ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] One MORE time without the typo ... RE: Re:
Question about Model Specific parameters



Todd,



Regarding "Thus far, I don't see any examples of that, which leaves me
wondering what

the actual problem we're debating here is." your own tools and
presentations

are the examples for that.  The very fact that your tool displays a

plot of the tap coefficients as they converge to a final value as

the optimizer is doing its job is post processing.







Or even just putting these values into a log file is post processing.

The only thing that is not post processing is if these returned parameters

would be ignored.  But in that case the model might as well not return

them, which is the same as prohibiting Out and InOut for Model Specific

parameters.



Arpad

==========================================================================
=







From: ibis-macro-bounce@xxxxxxxxxxxxx <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
Sent: Friday, February 18, 2011 7:27 AM
To: ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] One MORE time without the typo ... RE: Re: Question
about Model Specific parameters



Man, I hate it when this happens . perhaps a sign that I should be using
my reading glasses more often?







All,



I'd like to point out that Model Specific output parameters already have a
machine parsable spec, because their names, data types and output format
(i.e. how the model passes them back) are defined by the combination of
the IBIS 5.0 spec and the .ami file.  Thus, if the EDA tool wants to
collect and display that data (even if it's in a tool-dependent fashion),
there's absolutely nothing wrong with that.



The potential issue with model portability arises when the simulator is
expected to post-process the Parameters_Out data in some fashion,
affecting the assessment of the link'S BER (or whatever other key metric
you choose to focus on).  Thus far, I don't see any examples of that,
which leaves me wondering what the actual problem we're debating here is.



My $0.02.



Todd.

________________________


Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx <mailto:twesterh@xxxxxxxxxx>
www.sisoft.com <http://www.sisoft.com>



From: ibis-macro-bounce@xxxxxxxxxxxxx <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow
Sent: Thursday, February 17, 2011 9:22 PM
To: kwillis@xxxxxxxxxxx <mailto:kwillis@xxxxxxxxxxx>; Arpad_Muranyi@xxxxxxxxxx <mailto:Arpad_Muranyi@xxxxxxxxxx>;
ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Question about Model Specific parameters



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 <tel:4012841827>


-----Original message-----

From: Ken Willis <mailto:kwillis@xxxxxxxxxxx> <kwillis@xxxxxxxxxxx> <mailto:kwillis@xxxxxxxxxxx> To: Arpad_Muranyi@xxxxxxxxxx <mailto:Arpad_Muranyi@xxxxxxxxxx>, ibis-macro@xxxxxxxxxxxxx <mailto: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 <mailto:kwillis@xxxxxxxxxxx>


-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx <mailto: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 <mailto: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>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
Sent: Thursday, February 17, 2011 8:43 AM
To: ibis-macro@xxxxxxxxxxxxx <mailto: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 <mailto: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 <mailto: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 <mailto:ibis-macro-request@xxxxxxxxxxxxx>
Subject: unsubscribe


Other related posts: