[ibis-macro] Re: One MORE time without the typo ... RE: Re: Question about Model Specific parameters

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: <ibis-macro@xxxxxxxxxxxxx>
  • Date: Mon, 21 Feb 2011 07:38:22 -0800

Todd,

 

This was exactly my point.  On what bases would an EDA tool

be expected to plot Type Tap and none of the other Types?

Or, are we saying that the tool is expected to plot any Usage

InOut/Out regardless of its Type?  And could any other

expectations from the tool arise for the other Types,

depending on what their meaning is?  This is where the

spec is clear as mud.

 

If we say that the tool should plot the Type Tap, because

we know the meaning of it (Tap), people could also come up

with other rationale for the other types.  But these

expectations may all be very subjective, personally biased.

We can’t have such expectations and such loose ends in a

specification.

 

On the other hand, if we do not have such expectations, then

why would we allow to have InOut/Out for Model Specific

parameters?  It just doesn’t make sense…

 

In my opinion the specification should mention what the tool

should or could do with these InOut/Out parameters, or

prohibit them.

 

Thanks,

 

Arpad

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

 

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] 
On Behalf Of Todd Westerhoff
Sent: Monday, February 21, 2011 8:08 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: One MORE time without the typo ... RE: Re: Question 
about Model Specific parameters

 

Arpad,

 

It’s School Vacation week here in MA and I’m out this week – which just means 
my access to email will be sporadic, so please bear with me.

 

1.       If we collect data returned by a parameter of (Type Tap), we get a 
list of timestamps and floating point numbers

2.       If we collect data returned by a parameter of (Type Float), we get a 
list of timestamps and floating point numbers

3.       If we collect data returned by a parameter of (Type Integer), we get a 
list of timestamps and integer numbers

4.       If we collect data returned by a parameter of (Type String), we get a 
list of timestamps and strings

 

There’s nothing special about (Type Tap).

 

Does that help?  I have to run a few errands, but can put an example together 
later today if needed.

 

Todd.

 

________________________


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

 

From: 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
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] 
On Behalf Of Todd Westerhoff
Sent: Friday, February 18, 2011 5:15 PM
To: 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
www.sisoft.com

 

From: 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
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
 
Teraspeed® 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
www.sisoft.com

 

From: Muranyi, Arpad [mailto:Arpad_Muranyi@xxxxxxxxxx] 
Sent: Friday, February 18, 2011 9:53 AM
To: twesterh@xxxxxxxxxx; 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] 
On Behalf Of Todd Westerhoff
Sent: Friday, February 18, 2011 7:27 AM
To: 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
www.sisoft.com

 

From: 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; Arpad_Muranyi@xxxxxxxxxx; 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 <kwillis@xxxxxxxxxxx> <mailto: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

PNG image

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 02-2011