Mike, So are you suggesting that it is perfectly OK for a model writer to return any of these parameters in the AMI_parameters_out argument of EITHER the Init OR the GetWave OR BOTH functions? Do you think that all EDA vendors are going to know what to with these parameters if they are returned to the tool by either of these two functions? Quoting from the current specification from the very bottom of pg. 145: "It tells the EDA platform how much jitter exists at the input to the transmitter's analog output buffer." Do you think that if someone wrote a model in which the Tx_Jitter is a Usage Out and the DLL returns the value ONLY in the GetWave function that this will work in all EDA tools? I fully understand that a specification cannot be written so that the model writer could never write a nonsense model, I just want to make sure we are fully aware of this possibility and chose the correct actions to fix or leave the spec alone as it is... Thanks, Arpad ====================================================== From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx] Sent: Wednesday, February 23, 2011 10:14 AM To: Ken Willis Cc: Muranyi, Arpad Subject: Re: jitter question - Info only? Ken- What I'm suggesting is that we _don't_ _make_ _any_ _changes_ related to the possible output of jitter parameters from model unless/until there's substantive information about how this information would be used. I'm further suggesting that we devote our efforts to the BIRDs that are already in flight. Mike S. On 02/23/2011 09:01 AM, Ken Willis wrote: Arpad, Mike I think some of the discussion yesterday was about the model writing Out values "on the fly" for these standard parameters, which would then have to be utilized by the EDA tool however it is defined in the spec. Mike, are you saying that we should consider dropping the Out, and just make them Info, as Out is never used? In this case, the EDA tool would still need to handle all of them, but it would not complicate the flow by making it so that you have to ping the Init functions, get the data, then process it. It would all be there up front and the general flow would stay the same. If this is the case, then making them just "Info" seems like it would be much cleaner, no? Thanks, Ken Willis Sigrity, Inc. 860-871-7070 kwillis@xxxxxxxxxxx ________________________________ From: ibis-macro-bounce@xxxxxxxxxxxxx [ mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger Sent: Wednesday, February 23, 2011 5:53 AM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: One MORE time without the typo ... RE: Re: Question about Model Specific parameters Arpad- The reason the jitter parameters were originally allowed to have Usage Out was that there was some thought that the model could report the jitter it was seeing or generating. The idea at the time was that once the model reported this jitter, the data might be used in some unspecified way in some future simulation or analysis. That was a couple of years ago. (My, how time flies when you're having fun.) I'm not aware of a single model that outputs any of the reserved jitter parameters in this way. Therefore I have not seen any application of this feature and have no further information on how it might be used. Perhaps someone else does, and can give us more information to go on. It seems to me that we have enough work to do on applications that are already out there and in daily use. I suggest that we leave the current spec as is rather than attempt to make decisions about applications we haven't seen yet. Mike S. On 02/22/2011 11:33 PM, Muranyi, Arpad wrote: Thanks Scott and Ambirsh for the suggestions. I will come back to these later. I would like to respond to something else first that was mentioned in the meeting today. When Bob showed us the Table he compiled with the jitter parameters, I noted that they were Usage Info or Out. This scared me because it seemed like this was a similar situation to what we were discussing in this thread. How would the tool know what to do with a value like Tx_Jitter that is returned by a DLL? After looking at the details I realized that all of the parameters in the table Bob sowed us are Reserved Parameters, therefore their definition (meaning) is clear from the specification, and consequently the EDA tool will know exactly what to do with them. So there are no issues with these being Usage Out. | +------------------------+-------------------+ | | General Rules | Allowed Usage | | ======================================================================== | | Reserved Parameter | Required Default | Info In Out InOut | | +-------------------------+------------------------+-------------------+ | | Tx_Jitter | No No Jitter | X X | | | Tx_DCD | No 0 | X X | | | Tx_Rj | No 0 | X X | | | Tx_Sj | No 0 | X X | | | Tx_Sj_Frequency | No 0 | X X | | | Rx_Receiver_Sensitivity | No 0 | X X | | | Rx_Clock_PDF | No Clock Centered | X X | | | Rx_Recovery_Mean | No 0 | X X | | | Rx_Clock_Recovery_Rj | No 0 | X X | | | Rx_Clock_Recovery_Sj | No 0 | X X | | | Rx_Clock_Recovery_DCD | No 0 | X X | | | Rx_Rj | No 0 | X X | | | Rx_Sj | No 0 | X X | | | Rx_DCD | No 0 | X X | | | Rx_Noise | No 0 | X X | | +-------------------------+------------------------+-------------------+ However, looking at BIRD 123, I noticed that the BIRD does not specify which function's AMI_parameters_out argument will or is allowed to return these. In the discussion today it was mentioned that only the Init function should return these values, and the GetWave function shouldn't. The reason being is that the EDA tool will either use these parameters to alter the stimulus given to GetWave or the results coming from GetWave, but these parameters should not change between GetWave calls. Given this, it seems that we need to mention somewhere in BIRD 123 that these parameters can only be returned by the Init function. Comments, questions? Thanks, Arpad =================================================================== From: ibis-macro-bounce@xxxxxxxxxxxxx [ mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow Sent: Tuesday, February 22, 2011 4:33 PM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: One MORE time without the typo ... RE: Re: Question about Model Specific parameters I suggest a slight further clarification to that sentence For Model_Specific parameters with Usage InOut/Out the simulation results *must* not change, be changed, or require an AMI_INIT, as a result of the output values of the parameters. The EDA tool is not required to do anything with Model_Specific outputs. In effect, if any output parameter can result in a dynamic change in the end-to-end simulation environment (such as happens with back-channel communication) that parameter must be standardized. Otherwise interoperability issues may occur. 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(r) is the registered service mark of Teraspeed Consulting Group LLC On 2/22/2011 5:15 PM, Ambrish Varma wrote: Thanks for the clarification Scott, Arpad and Vladimir, I agree, it will be tricky to legislate what the EDA tools should/could do with Model_Specific parameter with Usage InOut/Out. I believe we should simply clarify that the simulation results *must* not change as a result of the output values of the parameters and that the EDA tool is not required to do anything with it. Thanks, Ambrish. Ambrish Varma | Member of Consulting Staff P: 978.262.6431 www.cadence.com ________________________________ From: ibis-macro-bounce@xxxxxxxxxxxxx [ mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow Sent: Tuesday, February 22, 2011 2:32 PM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: One MORE time without the typo ... RE: Re: Question about Model Specific parameters Ambrish The problem is one of "meaning". We know what clock ticks and waveforms mean. That is well-defined within the spec. We think we know what "Taps" mean. The meaning of Taps has not been formally defined. But we probably all know how to present taps to the user in a way that is meaningful. We might even provide some post processing to determine if any tap has reached is limit stop. What is the "meaning" of a general Model Specific Parameter output? 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(r) is the registered service mark of Teraspeed Consulting Group LLC On 2/22/2011 1:53 PM, Ambrish Varma wrote: Arpad, I have been following this thread carefully - and am tempted to jump in and ask a question. Would it be conceivable that the parameters of Usage InOut/Out be considered as an output of the simulation itself and "may be post-processed by the simulation tool or presented to the user as is" (from BIRD 120, section 3.2) in the same manner as clock ticks and the output waveform from GetWave? Each EDA tool presents that data in its own way, be it eye contours, full time domain waveform, voltage/time bathtub curves etc. Thanks, Ambrish. Ambrish Varma | Member of Consulting Staff P: 978.262.6431 www.cadence.com ________________________________ From: ibis-macro-bounce@xxxxxxxxxxxxx [ mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Tuesday, February 22, 2011 12:20 PM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: One MORE time without the typo ... RE: Re: Question about Model Specific parameters 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. The model is not allowed to output parameters that are not of (Type Tap) The model may output, but the simulator may not collect, output parameters that are not of (Type Tap) 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>