Mike, We can't change history, but we can certain try to avoid repeating it (especially if it was painful for us)... Thanks, Arpad ============================================= From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger Sent: Monday, December 12, 2011 11:10 PM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: How to make tap coefficients Reserved Parameters with Table Arpad- Model Specific Out parameters are out there and in daily use. You can't take them back. Sorry. Mike S. On 12/12/2011 08:22 PM, Muranyi, Arpad wrote: Mike, It seems that you are starting to be splitting hair here. Converting a string representation of a number to a numeric representation of the same number is just a programming artifact. The human eye still reads the same thing on the screen and the human brain still gets the same message when it reads it. Converting a bunch of numbers from a column representation to a graphical plot is a similar format conversion to aid human understanding of the raw data. The choice of what unit you use on the X-axis of this data (GetWave number or time) is just another type of conversion of the raw data to aid human understanding. Since GetWave can only be used in time domain simulations, the GetWave number is obviously related to time. These are all conversions which are based on known factors. You might also chose to display the Y-axis values in hexadecimal, or binary format if that makes you or your customer happier. But if this hex or binary representation is used to carry a special meaning, such as binary selector code in the hardware implementation, than we are talking about non-obvious or publicly known information, which I would call non-dumb display. I would have a problem with that, because only the model maker knows this meaning, and the EDA tool vendor would not know when to display the data in binary or decimal format. But this is still only a borderline problem, because those who are skillful in the art can read and interpret numbers regardless of whether they are written in decimal, hex, or binary format, right? :) The real problem starts when you start acting on these specialized meanings, like post processing the raw data to generate histograms, probability distribution functions, and the like, because in order to know what to do with the data you have to know its meaning. This information is not available unless you are the model maker and the EDA vendor in one person. Everyone else is left out from the party. Like I wrote it before, the meaning of Tap parameters is relatively well known, but we have no way of knowing anything about the meaning of the rest of the Model_Specific parameters. The problem I see is that even if the spec says that these Model_Specific parameters can only be used for dumb display purposes, there is no way to enforce it. A vendor who acts as both model maker and tool maker can still implement special competitive edge features in their models and tools through Model_Specific Info and Out parameters which will only work in their tool environment. Yes, they can satisfy the spec by doing the dumb display, but there is nothing to stop them from doing much, much more... The only way I see this issue resolved is if we eliminated Model_Specific Info, InOut and Out parameters from the spec. Sorry. Regarding "You seem to be thinking about a specific application that would depend on the semantics of a model's output parameter and not just its syntax. I think it would be helpful if you would state what that application is.", absolutely not. I have nothing on my mind, other than trying to solve the problem in the specification that potentially allows special features to be snuck in through Model_Specific Out/InOut parameter at the expense of those who are left out of the party. Thanks, Arpad ================================================================ From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger Sent: Monday, December 12, 2011 6:36 PM To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: [ibis-macro] Re: How to make tap coefficients Reserved Parameters with Table Arpad- So, if I were to multiply the GetWave call number by the sample interval and block size so as to obtain a plot vs. time, you would no longer consider that "dumb"? Also, if I were to put the string representing the parameter value in a buffer called buf, then put a double precision floating point value in the temporary variable tmp_dbl using the statement item_count = sscanf( buf, "%lg", &tmp_dbl ); and then displayed tmp_dbl in a plot, you would no longer consider that "dumb"? I'm perfectly happy with the phrase "dumb display", however, I may be giving that a broader meaning than you do. What we're discussing here is classic distinction between syntax and semantics. IBIS 5.0 provides a reasonably rigorous definition of the syntax for all parameters- Reserved or Model Specific, for all values of Usage. However, it only defines the semantics (that is, meaning) for Reserved parameters. Model Specific parameters also have semantics defined by the model developer; however, the EDA tool cannot be expected to know those semantics. That is as it should be. The syntax definition in IBIS 5.0 has been sufficient to allow EDA tools to do a lot of useful things with Model Specific Out parameters. All of them happen to have been more or less what you call "dumb display". You seem to be thinking about a specific application that would depend on the semantics of a model's output parameter and not just its syntax. I think it would be helpful if you would state what that application is. Thanks. Mike S. On 12/12/2011 05:43 PM, Muranyi, Arpad wrote: Mike, Regarding "Do you consider plotting to be anything other than displaying the data in a dumb manner?", yes I do. If the model returns a bunch of values for each GetWave call, without knowing anything about the nature of the data all you can do is save it into a file, put it on the screen in ASCII text format, or plot them against the GetWave call number in a plot. I call all of these "dumb display". Thanks, Arpad ========================================================================== From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger Sent: Monday, December 12, 2011 5:27 PM To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: [ibis-macro] Re: How to make tap coefficients Reserved Parameters with Table Arpad- You still haven't made yourself clear. In your fifth paragraph, you state Since I thought this plotting capability was only needed for the tap parameters, and yet in your first paragraph you state Without a detailed description of the data, an EDA tool can at most display the data in a dumb manner. Do you consider plotting to be anything other than displaying the data in a dumb manner? Thanks. Mike S. On 12/12/2011 05:19 PM, Muranyi, Arpad wrote: Mike, Interpret and display are two different things in this context. Without a detailed description of the data, an EDA tool can at most display the data in a dumb manner. Interpretation is out of the question. In the case of Type Tap the tool knows a little more about the nature of the data because it is Type Tap, so it can interpret the data to a certain extent, but for all other Types the tool is out of luck. But I was really not referring to these topics. I was mostly talking about what Walter summarized this way: "The EDA tool should not modify the simulation flow based on Out Model Specific parameters unless they have been formally submitted as BIRDs to the Open Forum." Since I thought this plotting capability was only needed for the tap parameters, I thought we can fix this issue by making the tap parameters Reserved and then prohibit any Model_Specific InOut and Out types. According to Walter's email, however, this is not the only parameter type that needs the plotting (or logging) capability... Thanks, Arpad ============================================================= From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger Sent: Monday, December 12, 2011 4:25 PM To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: [ibis-macro] Re: How to make tap coefficients Reserved Parameters with Table Arpad- It's difficult to be sure I understand what you're saying, but what you seem to be saying is that it's hard for an EDA tool to interpret and display the contents of AMI_parameters_out to the user. Have I understood you correctly? Mike S. On 12/12/2011 02:21 PM, Muranyi, Arpad wrote: Mike, These emails might have been flying around too fast, but I think I have stated it clearly what problem I am trying to solve. I will attempt to summarize it again: We have an unfinished discussion topic on Model_Specific parameters and InOut/Out. This was tabled, but it will soon flare up again (if it hasn't yet with this email thread). This topic deals with the issue whether InOut and Out should ever be allowed in the spec for Model_Specific parameters, because Model_Specific parameters can't be adequately described by the spec, and consequently the EDA tool would not have enough information to know how to deal with them. One of the main reasons this notion is being questioned is the tap parameters, because if the model has optimization, than it would be desirable to return the optimized values to the tool so it can display it to the user. Up to now we (I) thought that tap parameters can only be described as Model_Specific parameters, and concluded that for that reason we must not eliminate Model_Specific parameters of InOut and Out from the spec. The idea of making the tap parameters Reserved parameters was sparked in my mind by the BIRD 123 thread, in which the question of making them Out or not was brought up. It occurred to me that there might be a way to make the tap parameters Reserved parameters too with the Table syntax. I do not have any examples for the "added benefit" on what else the EDA tool could do with them if they were Reserved parameters, but that is not the main point of this discussion. The main point is to eliminate the reason for needing InOut and Out Model_Specific parameters. Let me know if this doesn't answer your question about my intent. Thanks, Arpad ================================================================== From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger Sent: Monday, December 12, 2011 1:54 PM To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: [ibis-macro] Re: How to make tap coefficients Reserved Parameters with Table Arpad- It's not at all clear what problem you're trying to solve. If you want models to be able to report their tap values to the EDA tool so that they can be displayed to the user then, as Walter says, we've already had that since IBIS 5.0. For this purpose, what we have in IBIS 5.0 is actually better than what you propose because the model can choose to report its state using exactly the parameter definitions which most directly apply to the model. The point is that what Reserved parameters are really useful for is communicating directly with the EDA tool and not directly with the user. In that context, what would you have the EDA tool do other than report the tap values to the user? Thanks. Mike S. On 12/12/2011 01:43 PM, Muranyi, Arpad wrote: Walter, I wasn't talking about added functionality. The reason I got into this brain storming is to find a way to make tap parameters Reserved parameters. This is motivated by the discussion of whether InOut and Out should be allowed with Model_Specific parameters. Your reason for wanting that was the tap coefficient example. Your argument is that these can be only Model_Specific, and these need to have the Out capability so that the model can return its optimized tap coefficients to the EDA tool. The idea I am proposing is an attempt to make tap parameters Reserved and thereby being able to make them Out and InOut without sacrificing the integrity of the specification. If I understand it correctly, currently we are making the tap parameters Model_Specific because the number of taps and their names might be specific to each model which is hard to make Reserved. Regarding the "removed functionality", I do not intend to do that. This is in the brain storming stage at this point. However, the second example indicates that there might be ways to come up with syntax that includes Range, Increment, List, and the like. I don't see a limitation there, we would just have to define each of these representations in the spec. Thanks, Arpad ======================================================== From: Walter Katz [mailto:wkatz@xxxxxxxxxx] Sent: Monday, December 12, 2011 1:32 PM To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: RE: [ibis-macro] How to make tap coefficients Reserved Parameters with Table Arpad, What you are proposing does not give any additional functionality to what is in BIRD 5.0, and in fact removes functionality. The existing structure allows List, Increment, ... for each Tap. This is important because taps does have constrained values. Also taps be InOut or Out. Although Table now support "Out", they return the full table, not just the tap value. What in your proposal adds functionality to what already is in IBIS 5.0? Walter From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]> On Behalf Of Muranyi, Arpad Sent: Monday, December 12, 2011 2:24 PM To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: [ibis-macro] How to make tap coefficients Reserved Parameters with Table All, I just couldn't leave this idea alone, and looked at BIRD 132 to see how Tables could be used for taps. Here is an example that I can imagine: (DFE_taps (Usage InOut) (Type String Float) (Table (Labels "Tap name" "Tap value") ("tp-1" -0.1) ("tp0" 0.8) ("tp1" 0.1) ) (Description "Initial DFE tap coefficients.") ) I don't see why this couldn't be under the Reserved parameters section. Note that it doesn't have to be a required parameter because not all models may have a DFE. The specification can provide a detailed description on when/how/why this parameter is used by the EDA tool and model, etc... A more elaborate version of the above example is an equivalent of the example on pg. 150 of the v5.0 spec (including Range and Default): (DFE_taps (Usage InOut) (Type String Float Float Float Float) (Table (Labels "Tap name" "Typ value" "Min value" "Max value" "Default value") ("-2" 0.1 -0.1 0.2 0.1) ("-1" 0.2 -0.4 0.4 0.2) ("0" 1 -1 2 1) ("1" 0.2 -0.4 0.4 0.2) ("2" 0.1 -0.1 0.2 0.1) ) (Description "DFE tap coefficients.") ) Comments? Questions? Thanks, Arpad ================================================================