James, Once again, I will put some comments between your lines in RED BOLD. Thanks, Arpad =================================================== From: James Zhou [mailto:james.zhou@xxxxxxxxxx] Sent: Monday, December 19, 2011 9:43 PM To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx Subject: RE: [ibis-macro] Re: Usage Out syntax rules Arpad, Thanks for your reply to my questions. Taking the three relevant statements in your email and put them side by side, we have : (1) the .ami file and the model code is authored by the same person ... Therefore the algorithmic model (DLL) doesn't have to read the content of the .ami file to find out what the Usage Out parameters are... The only requirement is that the model maker should be consistent with their executable model and their .ami file. (2) The (Usage Out) parameter has to be defined in the .ami file so that the EDA tool can find out about it and look for it in the AMI_parameters_out string. (3) the <data> either shouldn't be there in the .ami file, or the spec should say something about having to ignore it. According (1) , the model creator is required to put the same information at two places, for the same intended audience. I could hardly see any benefit of doing so. At the same time, it has caused some confusion and potential contention of values. In this strict sense I agree with you, and that's why I started this BIRD draft which blew up into this long email thread. However, the general "philosophy" here is that the .ami file is used for the parameter definitions plus <data> for the tool to read. Depending on the definition, the tool will "route" the <data> to the appropriate place, to its engine, or the AMI model. The third case when the model sends the <data> to the tool has to be defined (declared) also somewhere, otherwise the tool wouldn't know what to expect and how to deal with it. This is why Usage Out parameters must also be defined in the .ami file. The only questionable thing here is whether the .ami file should have a value assigned to such parameters, since the value comes from the model by other definitions in the spec. We have identified some differences in opinion on this and the associated Default keyword, which we need to clarify to eliminate the ambiguity from the spec. (2) is not only unnecessary but also inconsistent with the intended purpose of Usage Out (which is to pass parameters from DLL to EDA tool). If a parameter is passed from DLL to EDA tool through **AMI_parameters_out, why does it "has to be defined (again) in the .ami file so that the EDA tool can find out about it and look for it in the AMI_parameters_out string." ? We need to define the parameter somewhere so the tool would know what it is, where it is coming from, etc... The AMI model can't send definitions to the EDA tool, only the value. So the definition must be in the .ami file. (3) addresses the last question in my email. If <data> is not allowed for Usage Out, then obviously there couldn't be any possibility of contention. However, the last paragraph in your email suggest some operations which are fundamentally different from the descriptions in (1). According to (1): "the model maker should be consistent with their executable model and their .ami file ". If any operations (initialization, optimization, etc.) were to be introduced by using different values in .ami and **AMI_parameters_out, they should be defined clearly instead of leaving the doors open for interpretations. These operations were completely unknown to me when I put together the BIRD draft. That's why my draft says that <data> should be ignored for Usage Out parameters. Those who opposed or questioned my BIRD draft suggested that <data> could be used for initializing variables. I can live with that notion, but then we need to define other things, such as what is the meaning of Default. Is it simply a "Default pick" to select a single value from the multi-valued parameter types, or is it a "Default value" for the EDA tool (or possibly the AMI model) to initialize variables? I think these things must be explained in the spec, otherwise model makers and EDA vendors might implement things with different assumptions and the promise of interoperability and portability will depart from us... Conclusions and recommendations: (1) For model creators, the Specification should not ask them to put the same information at two places. If such requirement is needed, the Specification should provide a way to resolve potential contentions (intended or unintended). R That's exactly what I was trying to achieve with my BIRD draft... (2) For EDA tools, the Specification should not ask them to parse one string (in .ami) before it can parse another string (in **AMI_parameters_out). If such requirement is needed, the Specification should provide a way to resolve potential intended or unintended contentions. I tend to disagree with this, for the reasons explained above (the variable definition has to be done somewhere and the only place I can see for that is in the .ami file). Thank you again, James Zhou 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: Sunday, December 18, 2011 9:52 PM To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: [ibis-macro] Re: Usage Out syntax rules James, You are raising an interesting question. However, don't forget that the .ami file and the model code is authored by the same person (or at least the same company). Therefore the algorithmic model (DLL) doesn't have to read the content of the .ami file to find out what the Usage Out parameters are. So there is no need for these parameters to be passed to the executable model, or for the model to parser the .ami file. The only requirement is that the model maker should be consistent with their executable model and their .ami file. Regarding: "If Usage Out parameters are not allowed to be passed to AMI_Init or AMI_GetWave, why include them in the .ami file (since Usage Out is designed to pass parameters from AMI_Init or AMI_GetWave to EDA tools) ?" The parameter has to be defined in the .ami file so that the EDA tool can find out about it and look for it in the AMI_parameters_out string. But as far as supplying a value with these, I fully agree with your observation that the <data> either shouldn't be there in the .ami file, or the spec should say something about having to ignore it. I am concerned that if we don't do this, people might read into things and start using it for unintended purposes (as this thread uncovered some differences of opinion about Default), creating incompatibilities between models and EDA tools. Regarding "the Specification does not seem to distinguish between AMI_Init-returned Usage Out or, AMI_GetWave-returned Usage Out", you are absolutely correct, and we started addressing that in a BIRD draft, which is still in the draft stage: http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20110613/arpadmuranyi/Out-InOut%20BIRD%20draft%2010/Out_InOut_BIRD_10.pdf The solution we are thinking of implementing is that for Model_Specific parameters these would only be allowed to be used for display, or logging purposes in the EDA tool, and for Reserved parameters the parameter definition and description in the spec will have to give full detail on which function returns them and how they shall be treated by the EDA tool. The reason I started "fussing" about the jitter BIRD and Usage Out is because I didn't think that the description was adequate for them regarding Usage Out and felt that it either needed to be discussed in more detail in the BIRD 123 or elsewhere in the spec. That's what started this thread. I think you are correct about the list of the parameters. We will have to check out "Ignore_Bits" in this context to see if there is enough detail in its description, or if we write some text in a general location as I proposed, to make sure that it doesn't cause any conflicts. I think our decision last time was to remove Usage Out from the BIRD 123 jitter parameters, so that problem will go away. You are making a very good suggestion with saying: "The answer (or insight) to the following question should help us to better understand the issue of parameter contention between .ami and **AMI_parameters_out: what are the reasons/justifications that models could have different values in .ami and **AMI_parameters_out, for the same reserved parameter?" I can think of two possible reasons, optimization and/or initialization, but both of these could/should really be done using InOut parameters, not Out. This thread uncovered at least two interpretations for how "Default" supposed to be interpreted, and depending on the outcome, we might get a different answer to the above question... Thanks, Arpad ======================================================================== From: James Zhou [mailto:james.zhou@xxxxxxxxxx]<mailto:[mailto:james.zhou@xxxxxxxxxx]> Sent: Friday, December 16, 2011 6:54 PM To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: RE: [ibis-macro] Re: Usage Out syntax rules Arpad, The statements in BIRD 127.4 (as quoted in your email) appear to be inconsistent: the first paragraph states that only Usage In and InOut parameters should be included in the string and "No other information may be included in this string". The second paragraph states that, the string must contain Usage Out AMI parameters "if there are any defined in the .ami file". If the Usage Out parameters are prohibited from being passed by *AMI_parameters_in into AMI_Init, the only way AMI_Init could find out "if there are any defined in the .ami file" is to parse the .ami file directly. Is this what's implied by the Specification? If Usage Out parameters are not allowed to be passed to AMI_Init or AMI_GetWave, why include them in the .ami file (since Usage Out is designed to pass parameters from AMI_Init or AMI_GetWave to EDA tools) ? If a parameter is merely passed from model creator to EDA tool/user, it should be Usage Info. Also, with respect to Usage Out parameters, the Specification does not seem to distinguish between AMI_Init-returned Usage Out or, AMI_GetWave-returned Usage Out. However, AMI_Init-returned Usage Out parameters can be processed by both AMI_GetWave and/or EDA tool; AMI_GetWave-returned Usage Out parameters can be processed only by EDA tool (if it is processed at all). The Specification should clarify what EDA tool operations are required/allowed to process **AMI_parameters_out returned by AMI_Init and AMI_GetWave. When looking at all reserved parameters defined by IBIS 5.0 and Bird 123, I found six of them that are either Info or Out: Ignore_Bits, TX_Jitter, Tx_DCD, Rx_Receiver_Sensitivity, Rx_Clock_PDF, Rx_Noise. Please let me know if any are missing from this list. All other reserved parameters are Usage Info. I also do not see any Usage In and InOut parameters. As described in previous emails between you and Mike, existing models may overwrite some of these values provided by .ami and return them with **AMI_parameters_out string. In this case, we do have a situation of logical contention as you have pointed out in earlier emails. As a user of these models, I would think that it is highly undesirable to have models that have inconsistent parameter values (between .ami and **AMI_parameters_out returned by AMI_Init or AMI_GetWave) and the Specification allows the EDA tools to pick any one without clear decision criteria defined in the Specification. The answer (or insight) to the following question should help us to better understand the issue of parameter contention between .ami and **AMI_parameters_out: what are the reasons/justifications that models could have different values in .ami and **AMI_parameters_out, for the same reserved parameter? Thanks, James Zhou ________________________________ This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.