Arpad, I'm say the tool collects all the parameter data, in a format suitable for display. Let me put together an example for you. I should have some time mid afternoon to pull something together. 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 On Feb 21, 2011, at 10:41 AM, "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx> wrote: > 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 > > ============================================================= > > > > From: ibis-macro-bounce@xxxxxxxxxxxxx > [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff > Sent: Monday, February 21, 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, > > > > It’s School Vacation week here in MA and I’m out this week – which just means > my access to email will be sporadic, so please bear with me. > > > > 1. If we collect data returned by a parameter of (Type Tap), we get a > list of timestamps and floating point numbers > > 2. If we collect data returned by a parameter of (Type Float), we get a > list of timestamps and floating point numbers > > 3. If we collect data returned by a parameter of (Type Integer), we get > a list of timestamps and integer numbers > > 4. If we collect data returned by a parameter of (Type String), we get > a list of timestamps and strings > > > > There’s nothing special about (Type Tap). > > > > Does that help? I have to run a few errands, but can put an example together > later today if needed. > > > > 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: Sunday, February 20, 2011 12:35 PM > To: ibis-macro@xxxxxxxxxxxxx > Subject: [ibis-macro] Re: One MORE time without the typo ... RE: Re: Question > about Model Specific parameters > > > > Todd, Scott, > > > > Let’s put the finger pointing and personal overtones aside > > and talk on a technical level. The issue is not whether > > anyone did or does something special. The issue is that > > the spec allows that to happen. > > > > Todd, > > > > SiSoft’s responses to this thread mentioned on multiple > > occasions that since the parameter is a Type Tap, the tool > > should know to plot the returned values. In that case we > > should put it into the specification that for Type Tap the > > tool is expected or encouraged to plot, or write a log file, > > or report the returned values in some way that is useful to > > the user. But we have other Types in the spec in addition > > to Tap. What are we suggesting for the EDA tool to do with > > those? > > > > Regarding “The model’s documentation should describe what each parameter > > represents, and therefore whether it makes sense to plot it in some special > way” > > I don’t see how you can say that an EDA tool could do anything > > based on interpreting each model’s documentation and respond > > accordingly. This would take a little too much of artificial > > intelligence and a self modifying software code. Remember, > > there are other Types of Model Specific parameters of Usage > > Out or InOut. What should be the expectations for those? > > > > Take for example my previous example of the Float parameter > > CorDeNuit. If I put it in the “Description” of this parameter > > that the EDA tool should blow its horn, but only at night, > > is your tool going to be able to read and interpret this > > description (documentation) and blow its horn if this > > parameter returns a value during the night time hours? > > Besides, what is the definition of night time hours? Is it > > midnight to 6 a.m. or 5 p.m. to 8 a.m., etc…? In addition, > > I don’t see how an EDA tool will read a Word document or PDF > > file, or a Readme.txt file to find out how to interpret the > > Model Specific parameters of an .ami file… This sounds a > > little too new age-ish to me… > > > > Arpad > > =============================================================== > > > > From: ibis-macro-bounce@xxxxxxxxxxxxx > [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff > Sent: Friday, February 18, 2011 5:15 PM > To: ibis-macro@xxxxxxxxxxxxx > Subject: [ibis-macro] Re: One MORE time without the typo ... RE: Re: Question > about Model Specific parameters > > > > Scott, > > > > Looks like you’re assuming we’re doing something special because we “know” > something about the parameter being plotted. That isn’t the case. The .ami > file snippet for the model in Mike’s paper looks something like this: > > > > (dfe > > (taps > > (1 (Usage InOut)(Format Range 0 -1.0 1.0)(Type Tap) > > (Default 0)(Description "First DFE tap.")) > > (2 (Usage InOut)(Format Range 0 -1.0 1.0)(Type Tap) > > (Default 0)(Description "Second DFE tap.")) > > (3 (Usage InOut)(Format Range 0 -1.0 1.0)(Type Tap) > > (Default 0)(Description "Third DFE tap.")) > > (4 (Usage InOut)(Format Range 0 -1.0 1.0)(Type Tap) > > (Default 0)(Description "Fourth DFE tap."))) > > > > This declares the parameter names used to pass tap data into the model, and > tells the simulator the model may pass data back via ami_parameters_out using > the same parameter names. Declaring the parameters as (Type Tap) tells the > simulator the data to be passed to/from the model is a floating point number > – so, in this case, the simulator collects the values for each parameter at > each Getwave call, associates them with the appropriate timestamp, and then > plots them. No magic there. > > > > Fact is, we could have just as easily called the parameters “Frobozz” or > “My_Little_Froggie” with (Type Float) … and the process would have worked the > same. There’s nothing magic about the parameter names. If you want to > collect a whole bunch of parameters and scatter plot them against each other, > go for it. The model’s documentation should describe what each parameter > represents, and therefore whether it makes sense to plot it in some special > way. When a parameter returns a number, it just makes sense to plot how that > value progresses throughout the simulation. I can’t imagine why it wouldn’t. > Making that “illegal” makes no sense at all. > > > > If you’re proposing a standardized form of post-processing ami_parameters_out > data, then write it down & let’s discuss it in the Tuesday meetings. Talking > about potential applications is all well and good, but it doesn’t move the > spec forward. > > > > Have a good weekend, > > > > 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 Scott McMorrow > Sent: Friday, February 18, 2011 2:14 PM > To: ibis-macro@xxxxxxxxxxxxx > Subject: [ibis-macro] Re: One MORE time without the typo ... RE: Re: Question > about Model Specific parameters > > > > Todd > > In short, no. You keep avoiding the point. Your last step is undefined and > requires someone, either the EDA software writer, or the end-user, to > determine: > > What the parameter is. > What to do with the parameter. > > If you are both the model maker and the EDA vendor, then you are in the > privileged position of knowing what the parameters are, how they work, and > whether or not there is an "interesting" way to present or post-process the > data. Since a model specific parameter is provided blind, without additional > documentation, processing or presentation of these parameters by anyone else, > would be a guess, possibly educated, but still a guess. > > The only way to know how to plot, present, or post-process a Model Specific > output parameter today is via a-priori knowledge of the "meaning" of the > parameter. Yes, DFE taps are a no-brainer, only because we all believe we > have a-priori knowledge of what a Tap is. The parameters could have just as > easily have been named XYZ_frog1, XYZ_frog2 ... etc. Do you know how to > deal with this parameter? Neither do I. > > I maintain that the model maker needs to document, in a machine and human > understandable way, what the EDA tool is expected to do with these parameters > whether it be, plotting, presentation, or post-processing. Otherwise, the > parameter is not needed. This means that we as a committee have to come up > with documentation on what to do with these model specific output parameters. > The point is, no one knows whether these outputs are important unless they > are documented. IF they are unimportant, then they should not be there. > > An example of acceptable processing might be: > > Reserved for Model Development/Debug > Plot with respect to time > Plot against another parameter as a scatter plot > Status with a some sort of text description > For example 0 = PLL out of lock, 1 = PLL locked > Loss of signal > > 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® is the registered service mark of > Teraspeed Consulting Group LLC > > On 2/18/2011 1:38 PM, Todd Westerhoff wrote: > > Arpad (and Scott), > > > > For anyone who may not recognize the picture, the excerpted diagram is Figure > 7 from the 2008 DesignCon Paper “Demonstration of SerDes Modeling using the > Algorithmic Modeling Interface (AMI) Standard”. > > The paper is available on-line from both the DesignCon InfoVault > (http://www.designcon.com/infovault/) and SiSoft’s eLearning site > (http://www.sisoft.com/elearning/). > > > > I think we’re debating a semantic difference between post-processing and > plotting. The graph in the presentation was created by accumulating the > AMI_parameters_out data passed back from each Getwave call and then plotting > the value of the DFE taps as a function of time. I’m hoping you’ll agree > that the EDA tool knows the timestamp associated with Getwave call, so we > don’t need to debate the meaning of “as a function of time.” > > > > If you believe we need to spell this out in more detail, how does the > following text: > > > > > > Add the following step to each of the application scenarios in section 10.2: > > Optionally, the EDA platform may log the contents of AMI_parameters_out for > later display. The generic steps to do this are: > > Parse AMI_parameters_out according to the syntax definition provided in > section 10.3.1.2.6. > > Record the name and value of each leaf of the parameter tree. The type of > each value is determined directly by the BNF syntax rules that were used to > parse the value's representation in the parameter string. > > Present the data to the user in whatever manner the EDA tool deems suitable > > > > > > Suit you? > > > > Todd. > > > > P.S. I really proofread this one … hopefully I got all the typos out! > > > > ________________________ > > > 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: Muranyi, Arpad [mailto:Arpad_Muranyi@xxxxxxxxxx] > Sent: Friday, February 18, 2011 9:53 AM > To: twesterh@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx > Subject: RE: [ibis-macro] One MORE time without the typo ... RE: Re: Question > about Model Specific parameters > > > > Todd, > > > > Regarding “Thus far, I don’t see any examples of that, which leaves me > wondering what > > the actual problem we’re debating here is.” your own tools and presentations > > are the examples for that… The very fact that your tool displays a > > plot of the tap coefficients as they converge to a final value as > > the optimizer is doing its job is post processing. > > > > <image001.png> > > > > Or even just putting these values into a log file is post processing. > > The only thing that is not post processing is if these returned parameters > > would be ignored. But in that case the model might as well not return > > them, which is the same as prohibiting Out and InOut for Model Specific > > parameters… > > > > Arpad > > =========================================================================== > > > > > > > > From: ibis-macro-bounce@xxxxxxxxxxxxx > [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff > Sent: Friday, February 18, 2011 7:27 AM > To: ibis-macro@xxxxxxxxxxxxx > Subject: [ibis-macro] One MORE time without the typo ... RE: Re: Question > about Model Specific parameters > > > > Man, I hate it when this happens … perhaps a sign that I should be using my > reading glasses more often? > > > > > > > > All, > > > > I’d like to point out that Model Specific output parameters already have a > machine parsable spec, because their names, data types and output format > (i.e. how the model passes them back) are defined by the combination of the > IBIS 5.0 spec and the .ami file. Thus, if the EDA tool wants to collect and > display that data (even if it’s in a tool-dependent fashion), there’s > absolutely nothing wrong with that. > > > > The potential issue with model portability arises when the simulator is > expected to post-process the Parameters_Out data in some fashion, affecting > the assessment of the link’S BER (or whatever other key metric you choose to > focus on). Thus far, I don’t see any examples of that, which leaves me > wondering what the actual problem we’re debating here is. > > > > My $0.02. > > > > 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 Scott McMorrow > Sent: Thursday, February 17, 2011 9:22 PM > To: kwillis@xxxxxxxxxxx; Arpad_Muranyi@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx > Subject: [ibis-macro] Re: Question about Model Specific parameters > > > > Ken > > I agree and would like to make model specific output parameters illegal when > they are not accompanied with a machine parsible spec for processing. > > Scott McMorrow > President > Teraspeed Consulting Group LLC > (401) 284-1827 > > > -----Original message----- > > From: Ken Willis <kwillis@xxxxxxxxxxx> > To: Arpad_Muranyi@xxxxxxxxxx, ibis-macro@xxxxxxxxxxxxx > Sent: Thu, Feb 17, 2011 15:47:43 GMT+00:00 > Subject: [ibis-macro] Re: Question about Model Specific parameters > > Hi Arpad, > > I am working on a back-channel BIRD draft now, so this will hopefully help > to shed some light on the parameter usage being considered. But I agree that > if there are standard things the EDA tools are supposed to do with model > outputs, they have to go in the spec. Otherwise it is all open to > interpretation and model makers don't have a standard to build their models > to. > > Thanks, > > Ken Willis > Sigrity, Inc. > 860-871-7070 > kwillis@xxxxxxxxxxx > > > -----Original Message----- > From: ibis-macro-bounce@xxxxxxxxxxxxx > [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad > Sent: Thursday, February 17, 2011 10:36 AM > To: ibis-macro@xxxxxxxxxxxxx > Subject: [ibis-macro] Re: Question about Model Specific parameters > > Thanks for all the responses. None of these concepts were unfamiliar > to me, but it was still nice to see them mentioned and summarized. > But most of you missed the point of my question, most notably Mike's > question at the end of his reply: > > > > Given that so much information has been publicly and widely available > > since before IBIS 5.0 was ratified, how is it that you came to > conclude > > that "no EDA vendor has the knowledge on how to interpret or post > > process these returned parameters"? > > > The answer to Mike's question "how is it that you came to conclude" is > exactly the point of my discussion: ---> Because the specification > doesn't say so. A Model Specific parameter can be anything. I agree > that in case of a Type Tap the EDA tool could have some clues to show > or print the returned values to the user, but the specification doesn't > say so. If this is an expectation from the EDA tool, then the > specification > should talk about that. But the bigger problem is that there are other > Types also which could be Out or InOut. What if my AMI model has a > parameter called CorDeNuit, Type Float, Usage Out? What should my tool > do with it? Blow its horn at the frequency given in the parameter > value? > (Those of you who know pipe organs will get this...) :-) > > I am not challenging the technical explanations give to me in any of > your responses. The point I am trying to make is that this is simply > bad spec writing. If the model returns something to the tool which > supposed to be plotted or printed, or post processed in any way as shown > in Mike's DesignCon 2008 paper, the specification should define the > appropriate mechanisms to do so. > > I am getting even more concerned that the Back Channel communication > was also mentioned in this discussion as a reason to keep Out and > InOut for Model Specific parameters. I am concerned that these will > cause further problems and confusions in the future. I think we should > strive to have a well defined feature set in the specification so that > individual misinterpretations or tool specific features based on secret > insider information etc... could be prevented. > > Any comments or suggestions? > > Thanks, > > Arpad > ======================================================================== > === > > > > > > > > -----Original Message----- > From: ibis-macro-bounce@xxxxxxxxxxxxx > [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger > Sent: Thursday, February 17, 2011 8:43 AM > To: ibis-macro@xxxxxxxxxxxxx > Subject: [ibis-macro] Re: Question about Model Specific parameters > > Arpad- > > Please find attached a copy of our DesignCon2008 paper on AMI modeling. > Among other things, this paper describes the use of parameters of Usage > Out to monitor the adaptive loops in receivers. In point of fact, every > receiver model that SiSoft writes (and most will admit that's a fair > few) reports the behavior of its adaptive loops in exactly this way. > Furthermore, many users of SiSoft's Quantum Channel Designer use this > data to obtain valuable information about their systems. > > Even at the last IBIS Summit, there were two presentations on channel > optimization that reported the application of parameters of Usage Out > and InOut. > > If you want to know how all this is done, Mike LaBonte's explanation is > right on target.. > > Given that so much information has been publicly and widely available > since before IBIS 5.0 was ratified, how is it that you came to conclude > that "no EDA vendor has the knowledge on how to interpret or post > process these returned parameters"? > > Mike S. > > On 2/16/2011 7:02 PM, Muranyi, Arpad wrote: > > Hello everyone, > > > > I stumbled on a situation with an .ami file which has > > a few Model Specific parameters of Usage InOut. Our > > customer is wondering why we don't do this and that > > with the data that is returned by the model in those > > parameters. This triggers the following thoughts in > > my mind. > > > > Model Specific parameters are specific to the model and > > their meaning is not described by the AMI specification. > > Therefore no EDA vendor has the knowledge on how to > > interpret or post process these returned parameters > > because there is simply no way of knowing what to do > > with them. > > > > For this reason, I would suggest that we make a rule in > > the IBIS AMI specification that Model Specific parameter > > must be Usage In, and Usage Out or InOut should not be > > allowed. > > > > Any Comments? > > > > Thanks, > > > > Arpad > > ======================================================== > > > > --------------------------------------------------------------------- > > IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ > > IBIS Macro reflector: //www.freelists.org/list/ibis-macro > > To unsubscribe send an email: > > To: ibis-macro-request@xxxxxxxxxxxxx > > Subject: unsubscribe > > > > --------------------------------------------------------------------- > IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ > IBIS Macro reflector: //www.freelists.org/list/ibis-macro > To unsubscribe send an email: > To: ibis-macro-request@xxxxxxxxxxxxx > Subject: unsubscribe > > > --------------------------------------------------------------------- > IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ > IBIS Macro reflector: //www.freelists.org/list/ibis-macro > To unsubscribe send an email: > To: ibis-macro-request@xxxxxxxxxxxxx > Subject: unsubscribe