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. 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 <tel:4012841827> -----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