[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 19:17:55 -0800

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>

Other related posts:

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