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>