[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: Tue, 22 Feb 2011 09:19:49 -0800

Todd,

 

Generally I am not opposed to plot the data, or

throw cartwheels, or reformat the hard disk or

anything you can think of, IF these expectations

or actions are documented in the specification.

 

Currently the spec doesn’t say anything, so who

would know what to do with Bob, Carol, Ted, and

Alice or what they should do with each other…  J

 

If we want the tools to just plot or save the data

into a file for any Out or InOut parameter, the

spec should say so.  But his may not satisfy the

more intellectually advanced minds for too long.

 

However, we cannot have a spec that doesn’t mention

anything.  That opens the door to really smart

marketing claims like our tools are superior to any

other tool in the world because we are so smart that

we know what to do with such data implying that

everyone else doesn’t know what they are doing,

when this situation is really caused by a badly

written specification…

 

Thanks,

 

Arpad

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

 

 

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] 
On Behalf Of Todd Westerhoff
Sent: Tuesday, February 22, 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,

 

… and so now we’re ready to take the last step.  Let’s say that instead of the 
original .ami file that used a Tap declaration, we had:

 

(My_RX_DLL

   (Reserved Parameters

      …

   )

   (Model _Specific

      (Bob (Usage InOut)(Range 0 -10.0 10.0)(Type Float)

           (Default 0)(Description "Does whatever"))

       (Carol (Usage InOut)(Range 0 -20.0 20.0)(Type Float)

           (Default 0)(Description " Does whatever"))

       (Ted (Usage InOut)(Range 0 -5.0 5.0)(Type Float)

           (Default 0)(Description " Does whatever "))

       (Alice (Usage InOut)(Range 0 -99.0 99.0)(Type Float)

           (Default 0)(Description " Does whatever "))

   )

)

 

… and, for sake of discussion, we run simulation and get a table with the same 
values as before:

 

Time      Bob     Carol  Ted     Alice             

0         0.0000  0.0000 0.0000 -0.0002

2.56E-08  0.0000  0.0000 0.0000 -0.0001

5.12E-08 -0.0002 -0.0001 0.0000 -0.0001

7.68E-08 -0.0003 -0.0001 0.0000 -0.0001

1.02E-07 -0.0004 -0.0001 0.0000 -0.0001

1.28E-07 -0.0005 -0.0001 0.0000 -0.0001

1.54E-07 -0.0006 -0.0002 0.0000 -0.0001

1.79E-07 -0.0007 -0.0002 0.0000 -0.0001

2.05E-07 -0.0008 -0.0002 0.0000 -0.0001

2.30E-07 -0.0008 -0.0002 0.0000  0.0000

2.56E-07 -0.0009 -0.0002 0.0001  0.0000

2.82E-07 -0.0010 -0.0002 0.0001  0.0000

3.07E-07 -0.0011 -0.0002 0.0001  0.0001

3.33E-07 -0.0012 -0.0003 0.0000  0.0000

3.58E-07 -0.0013 -0.0003 0.0000  0.0000

3.84E-07 -0.0015 -0.0003 0.0000  0.0000

 

And therefore,  knowing that the first column contains uniformly spaced time 
points (ideal candidates for an x-axis), we can plot:

 

 

 

… with no specific knowledge of what this data represents.  At first glance, it 
seems like Bob is having a bad day, but we really need to know what the data 
represents before we can conclude that. 

 

Have I explained why it doesn’t matter whether the data is (Type Tap) or not?

 

If you restrict the ability to plot to (Type Tap), you’re effectively saying 
one of three things.

 

1)      The model is not allowed to output parameters that are not of (Type Tap)

2)      The model may output, but the simulator may not collect, output 
parameters that are not of (Type Tap)

3)      The simulator collect and output tables of data, but may not plot them 
if they are not of (Type Tap)

 

I don’t regard any of these three options as logically defensible, and I don’t 
expect the end-users would either.

 

I think it’s time to take this back into an interactive discussion so we can 
reach a conclusion.    This email is the last of the data I wanted to put on 
the table to support that discussion.

 

Is this a potential topic for today’s IBIS-ATM meeting?  Walter is traveling 
and I’ll be running errands, but I’ll call in if needed.

 

Please let me know.

 

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: Tuesday, February 22, 2011 1:32 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: One MORE time without the typo ... RE: Re: Question 
about Model Specific parameters

 

Todd,

 

I am glad to hear that is was just a typo…

 

The discussion is NOT about whether there is anything non-standard

about recording and plotting the returned values the way you showed

it.  The discussion is about how the EDA tool (or vendor) knows that

it is expected to do this.  The specification doesn’t say that, and

really CANNOT say anything about it (except for Type Tap) because

the meaning of the Model_Specific parameters is not known to anyone

except the model maker.

 

The ONLY exception is the Type Tap because the name of this type

carries a fairly specific meaning.  Recognizing this, I am softening

my position on this and I am willing to consider allowing Usage Out

or InOut for Type Tap for this reason, but even in this case I would

mention something along the lines that the tool can present these

returned values to the user or post process it.  After all, we were

able to write such things at the end of the flow descriptions in

BIRD 120…

 

But I have to emphasize that I am NOT ONLY talking about Type Tap

in this thread.  What is the EDA tool expected to do with a

Model_Specific Usage Out or InOut of Type Float, Integer, String,

Boolean, UI parameter?  Is the tool expected to plot these also

simply vs. time as with Type Tap?

 

I think this would get pretty boring after a while, and some clever

model makers would soon come up with an unforeseen purposes.  And

if this clever model maker happens to be an EDA vendor, they could

gain a fair amount of unfair competitive advantage very quickly,

since the specification is silent about what to do with such

parameters, therefore anything goes.  I am not saying that anyone

is doing it today, but the potential is definitely there.  But

even if I overlook this potential for unfair competitive advantage

and focus only on the quality of the specification, I must say that

a specification that has open holes like this is not much of a

specification...

 

For this reason I would not allow Out or InOut for Model_Specific

parameters (other than Type Tap).

 

Regarding “I *am* maintaining my original position that the acquiring and 
plotting

of model data is completely within the current spec”, I don’t think anyone

disputed that in this thread.  The spec doesn’t say anything, so

anything you do is legal at this point…  And regarding “and any

debate about whether or not this should be “allowed” is … well, not a 
particularly

good use of our collective time.” the debate is not whether this should

be allowed or not, at least not in this context.  I don’t know

how I can explain it any better than the above.  But it seems

that you are finally also getting the idea in what you wrote in

this sentence:

 

“I’m not suggesting the computer do that automatically, *unless* we want to 
define

& standardize parameters that tell the simulator what to do.”

 

You hit the nail on its head, this IS the problem we are discussing.

Other than with the Type Tap, no one knows the meaning of the

Model_Specific parameters, therefore there is no way to automate

what the tool should do with the returned values.  So it simply

doesn’t make sense to allow Usage Out or InOut for Model_Specific

parameters.  Using your words, the computer will not be able to

process these automatically (unless someone has “insider

information”).  And that is the whole point in this thread.

 

Thanks,

 

Arpad

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

 

 

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

 

Arpad,

 

That wasn’t a trap, that was a typo.  I was editing a 5 tap example to make it 
4 taps and forgot to take out the 5th tap in the parameter string.  The .ami 
file was correct, but the parameter string should have been 

 

(My_RX_DLL(dfe(taps(1 0)(2 0)(3 0)(4 0)))

 

 as you point out.  Sorry about that.

 

Here’s what I’ve been driving at

 

-          We’ve agreed on how the AMI file declares Model_Specific parameters 
as input and outputs

-          We’ve agreed on how those parameters are communicated in the 
AMI_parameters_in string

-          We’ve agreed on how model parameters returned by the model appear in 
AMI_parameters_out

-          We’ve shown how successive calls to Getwave produce additional sets 
of parameter data

-          I’m going to assume we agree that the simulator can record data 
returned by the model

-          We’ve taken the first 16 sets of parameter data returned by the 
model and produced a table:

 

Time                      taps.1    taps.2    taps.3    taps.4

0                              0.0000   0.0000   0.0000   -0.0002

2.56E-08               0.0000   0.0000   0.0000   -0.0001

5.12E-08               -0.0002 -0.0001 0.0000   -0.0001

7.68E-08               -0.0003 -0.0001 0.0000   -0.0001

1.02E-07               -0.0004 -0.0001 0.0000   -0.0001

1.28E-07               -0.0005 -0.0001 0.0000   -0.0001

1.54E-07               -0.0006 -0.0002 0.0000   -0.0001

1.79E-07               -0.0007 -0.0002 0.0000   -0.0001

2.05E-07               -0.0008 -0.0002 0.0000   -0.0001

2.30E-07               -0.0008 -0.0002 0.0000   0.0000

2.56E-07               -0.0009 -0.0002 0.0001   0.0000

2.82E-07               -0.0010 -0.0002 0.0001   0.0000

3.07E-07               -0.0011 -0.0002 0.0001   0.0001

3.33E-07               -0.0012 -0.0003 0.0000   0.0000

3.58E-07               -0.0013 -0.0003 0.0000   0.0000

3.84E-07               -0.0015 -0.0003 0.0000   0.0000

 

If I take this data and plot it in Excel, I get something like this:

 

 

 

My point here is that there is absolutely *NOTHING* non-standard about the way 
we’ve recorded and plotted parameter data produced by AMI models.  The original 
thread, as I read it, was hypothesizing that there was something “special” 
going on between the models and the simulator, such that the simulator had some 
insight about what to plot and how to display it.  Hopefully, I managed to show 
that isn’t the case – we’re merely talking about building a table of data and 
providing a utility for plotting it – whether the parameters were taps or any 
other floating point number, the process would be exactly the same. 

 

When I talked about plotting one value as a function of another, I meant that, 
given a table of data, I can plot it any way I want, depending on the utility 
I’m using to do the plotting.  I’m not suggesting the computer do that 
automatically, *unless* we want to define & standardize parameters that tell 
the simulator what to do.  We haven’t done that.

 

I *am* maintaining my original position that the acquiring and plotting of 
model data is completely within the current spec, and any debate about whether 
or not this should be “allowed” is … well, not a particularly good use of our 
collective time.

 

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: Monday, February 21, 2011 10:18 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: One MORE time without the typo ... RE: Re: Question 
about Model Specific parameters

 

Todd,

 

Sorry for the mistake, I failed to realize that you set a trap

for me in the first part of this exercise when you described

a four tap device and the string sent to it was for five taps…

I wasn’t counting the taps, only noticed that the last one was

non zero, so I attributed that to the fifth tap.  I will not

get into the debate whether this was deliberate or not, arguing

over that would be useless.

 

Aside from this oversight, I think we are still in agreement,

but I still don’t see how all this is related to the discussion

I started.  Please explain.

 

Thanks,

 

Arpad

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

 

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

 

Arpad,

 

Actually, I think it should have been 

 

(My_RX_DLL(dfe(taps(1 0)(2 0)(3 0)(4  -0.0002)))

 

Instead of

 

(My_RX_DLL(dfe(taps(1 0)(2 0)(3 0)(4 0)(5 -0.0002)))

 

Since there are only 4 taps.  Depending on how you do the math, the timestamp 
is either 25.575ns or 25.6ns, but close enough.

 

Let’s say we call Getwave another fourteen times, with the model returning 
updated tap parameter data through AMI_parameters_out each time.  We take the 
data returned through AMI_parameters_out and create a table that looks 
something like this:

 

Time                      taps.1    taps.2    taps.3    taps.4

0                              0.0000   0.0000   0.0000   -0.0002

2.56E-08               0.0000   0.0000   0.0000   -0.0001

5.12E-08               -0.0002 -0.0001 0.0000   -0.0001

7.68E-08               -0.0003 -0.0001 0.0000   -0.0001

1.02E-07               -0.0004 -0.0001 0.0000   -0.0001

1.28E-07               -0.0005 -0.0001 0.0000   -0.0001

1.54E-07               -0.0006 -0.0002 0.0000   -0.0001

1.79E-07               -0.0007 -0.0002 0.0000   -0.0001

2.05E-07               -0.0008 -0.0002 0.0000   -0.0001

2.30E-07               -0.0008 -0.0002 0.0000   0.0000

2.56E-07               -0.0009 -0.0002 0.0001   0.0000

2.82E-07               -0.0010 -0.0002 0.0001   0.0000

3.07E-07               -0.0011 -0.0002 0.0001   0.0001

3.33E-07               -0.0012 -0.0003 0.0000   0.0000

3.58E-07               -0.0013 -0.0003 0.0000   0.0000

3.84E-07               -0.0015 -0.0003 0.0000   0.0000 

 

Still make sense?

 

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: Monday, February 21, 2011 7:28 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: One MORE time without the typo ... RE: Re: Question 
about Model Specific parameters

 

Time stamp at the end of the first GetWave call

having 1024 samples at 25 ps/sample should be

25.575 ns and the returned string should be:

 

(My_RX_DLL(dfe(taps(1 0)(2 0)(3 0)(4 0)(5 -0.0002)))

 

Now, can we go a little faster, please?  I still

don’t see how this is related to the topic we are

discussing…

 

Arpad

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

 

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

 

Arpad,

 

Understood.  I purposely made the first question trivial to make sure we were 
on the same page.

 

Let’s move on to Getwave.  To keep the math simple, let’s use a 5Gb/s link (UI 
= 200ps) running at 8 samples per bit (sample_interval = 25ps) and a Getwave 
block size of 1024.  At the end of the first Getwave call, the DLL reports that 
tap parameters 1, 2, 3, 4 are 0, 0, 0, and -0.0002, respectively.  What will 
the timestamp be (let’s assume time is measured in seconds), and what will the 
AMI_parameters_out string returned by the model be?

 

I know I’m still going slow, the pace picks up after this …

 

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: Monday, February 21, 2011 6:23 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: One MORE time without the typo ... RE: Re: Question 
about Model Specific parameters

 

Todd,

 

Regarding:  “What do you expect that string will look like?”,

I would expect that string to look the same as the

string that was set into the DLL (since you said

it echoes back the received parameters):

 

(My_RX_DLL(dfe(taps(1 0)(2 0)(3 0)(4 0)(5 0)))

 

But I don’t see how going through this exercise

answers the question we are discussing…

 

Arpad

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

 

 

 

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

 

Arpad,

 

Sorry for the delay in reply – today’s errands ran longer than I anticipated.  
I suggest we go through the tap example front to back and then see how that 
compares to other cases.

 

The .ami file for a hypothetical RX declares the following:

 

(My_RX_DLL

   (Reserved Parameters

      …

   )

   (Model _Specific

      (dfe

         (taps 

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

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

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

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

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

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

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

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

         )

   )

)

 

Let’s say the .dll is called with the default settings for the tap parameters, 
which gives an AMI_parameters_in string of:

 

(My_RX_DLL(dfe(taps(1 0)(2 0)(3 0)(4 0)(5 0)))

 

Let’s also say the .dll echoes back the control parameters it finds during the 
AMI_Init call, using the AMI_parameters_out interface.  What do you expect that 
string will look like?

 

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: Monday, February 21, 2011 10:38 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: One MORE time without the typo ... RE: Re: Question 
about Model Specific parameters

 

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

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

 

<SNIP>

JPEG image

JPEG image

Other related posts:

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