Would it make sense that the EDA tool should over-ride any value for a particular parameter, which came back as a [Usage Out] parameter from AMI_Init, with the value it sees coming back from AMI_GetWave, once it starts `GetWaving'? If so, would that allow us to cut in half the number of new parameters being introduced in BIRD 123? David: my understanding is not. Fangyi From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Tuesday, December 06, 2011 10:35 PM To: 'IBIS-ATM' Subject: [ibis-macro] Re: Some final questions on BIRD 123. David, I would like to respond to your last question: "? What is the purpose of this phrase?" This phrase has a long history and lots of heated discussions behind it. Here is why: Model_Specific parameters cannot be described in the specification, because they can be anything the model maker can imagine. For this reason, the specification cannot describe the meaning of Model_Specific parameters, and EDA tool vendors cannot implement any actions based on them. We should really not have any Model_Specific Usage Out parameters in the specification, because other than displaying them on the screen or saving them into some log files, the EDA tool really can't use them for anything else. This is why we started to put verbiage in some of the recent BIRDs like the one you are questioning, because currently the spec doesn't prohibit Usage Out Model_Specific parameters. On the other hand, Reserved parameters are fully described in the specification i.e. their meaning and how the model or EDA tool supposed to use or generate them is completely described. Such parameters can be Usage Out and the EDA tool will understand what to do with them based on the specification. The jitter parameters in BIRD 123 seem to be all Reserved parameters. This means that we can fully describe what they mean and how they are used and generated. However, another question that needs to be considered is this: A parameter is defined in the .ami file. The tool reads it. If a parameter is Usage Out, the model is outputting it to the EDA tool. If the .ami file contains a value for a Usage Out parameter, what is the tool supposed to do with it? Being Usage Out, it will not pass it into the DLL, or should it pass it in as an initial condition for the DLL? Or is the tool supposed to use it as an initializer for itself before the DLL outputs its own (perhaps new) value? In some ways it really doesn't make sense to have values in the .ami file for parameters of Usage Out, because they are really supposed to be an output from the DLL. But the spec doesn't discuss this as far as I know. So what is the meaning of the value in the .ami file for parameters Usage Out? Another question: If the parameter is Usage Out, and we have AMI_parameters_out arguments in both AMI_Init and AMI_GetWave functions, then the spec has to describe which of those two functions is returning the value for the EDA tool so it would know when and where to look for the returned value. This depends entirely on the meaning and purpose of the parameter. This may be the reason for that statement in Walter's BIRD you are questioning. I hope this answers your question. Thanks, Arpad =========================================================== From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of David Banas Sent: Tuesday, December 06, 2011 4:28 PM To: 'Walter Katz'; 'James Zhou' Cc: 'IBIS-ATM' Subject: [ibis-macro] Some final questions on BIRD 123. Hi Walter, I think I'm just about there. Just a couple of questions: 1. Referring to this excerpt from the most recent version of the BIRD (123.3_Draft1): Note: The EDA Tool/Simulator shall use the values of these Jitter and Noise parameters directly if they are Usage Info. If they are Usage Out, then the EDA Tool/Simulator shall use their values generated by AMI_Init. The model's AMI_GetWave function may return different values for these parameters than the values returned by AMI_Init; the EDA Tool/Simulator may report the values of such parameters to the user, but the EDA Tool/Simulator may not change any inputs to AMI models or change other result of the simulation based on the values returned for the parameters in this BIRD by AMI_GetWave. a. Why is there a necessary difference in EDA tool behavior, depending upon whether the parameters are of type Info or Out? b. If Init and GetWave can return different values for these parameters, then why do we need 2 sets (i.e. - Rx_Sj and Rx_CDR_Sj)? It seems like we ought to be able to have just one parameter, Rx_Sj, and let Init return one value for it, while GetWave returns another, depending upon how sophisticated its CDR modeling is. c. Referring to the last phrase, above, "or change other result of the simulation based on the values returned for the parameters in this BIRD by AMI_GetWave.": broadly interpreted, couldn't this phrase preclude an EDA tool from applying the post-processing necessary for accurate BER estimation? What is the purpose of this phrase? Thanks, -db ________________________________ Confidentiality Notice. This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you. ________________________________ Confidentiality Notice. This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you.