Arpad wrote: Definition: Tells EDA platform whether the AMI_GetWave is <<<implemented>>> in this model (my emphasis) Usage Rules: Note that if Init_Returns_Impulse is set to 'False', then GetWave_Exists MUST be set to 'True'. I don't know where this definition comes from, but note that it states that this parameter supposed to tell the tool whether the function <<<exists>>> in the algorithmic model or not. There is no mention that this parameter can be used to tell the tool whether it should use the GetWave function or not when it exists. I disagree. The word chosen in the original language was "implemented", not "exists". The difference may be subtle, but it is important. Consider, for instance, the typical breakdown of the complete description of a C/C++ function: Typically, there is a <<<declaration>>> given in a *.h file, which other compilation units use only to divine the calling syntax of the function. And the function is <<<implemented>>> in a different, usually *.c, file. This implementation may or may not do anything, at all. I think that we should use the value of the "GetWave_Exists" flag, in order to determine whether or not the "AMI_GetWave" function has been <<<implemented>>>. Arpad wrote: I want to mention here in parentheses that the sentence in the Usage Rules is kind of lopsided too, because it says that if Init_Returns_Impulse is False, GetWave_Exists has to be set to True. <<<What this is really trying to say is that the model should implement and contain an AMI_GetWave function, therefore this parameter will also be to True.>>> But if someone reads the sentence as written on paper, they could interpret it as having to set this parameter to True, regardless of whether the function exists in the file or not... This is certainly not what we wanted to say. Not at all. What it is saying is this: If I can't get the impulse response from the "AMI_Init" function, then you must provide an "AMI_GetWave" function from which I can, because, after all, if I can't get an impulse response somehow, I'm sunk. Arpad wrote: For this reason, if we ended up deciding that we shouldn't use this parameter for anything else but tell the tool whether the GetWave function exists in the DLL, <<<I would make a proposal to deprecate the parameter and get rid of it.>>> There is absolutely no need for it at all. Please, don't do this! This parameter is the ONLY thing that allows us to build a reusable IBIS-AMI modeling infrastructure, in which all common boilerplate can be kept out of the device specific portion of the code base. And let us not forget that maximum factoring out of common boilerplate is, generally, considered to be a software engineering "best practice". Thanks! -db From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Friday, March 09, 2012 12:20 PM To: 'IBIS-ATM' Subject: [ibis-macro] Re: Question about GetWave_Exists Hello everyone, Here is a little update on this topic. I brought the question up in the IBIS Open Forum teleconference this morning. The group was willing to entertain the idea of dealing with this correction/clarification in the Editorial group, but a suggestion was made that I should look at the latest draft of IBIS v5.1 to see how what the specification looks like with all the BIRDs put together. This is what I found, using the Draft v0.125 version of the IBIS v5.1 document: http://www.eda.org/ibis/editorial_wip/IBIS-5.1-draft-v125.pdf A search for "GetWave_Exists" first takes me to pg. 169-170 where the Time Domain Simulation Reference Flow is discussed. This is the section to which I was proposing to add the words in red bold shown in my previous email (below). However, the next occurrence of this word appears on pg. 192-193 where the parameter is defined and described like this: Definition: Tells EDA platform whether the AMI_GetWave is implemented in this model Usage Rules: Note that if Init_Returns_Impulse is set to 'False', then GetWave_Exists MUST be set to 'True'. I don't know where this definition comes from, but note that it states that this parameter supposed to tell the tool whether the function exists in the algorithmic model or not. There is no mention that this parameter can be used to tell the tool whether it should use the GetWave function or not when it exists. I want to mention here in parentheses that the sentence in the Usage Rules is kind of lopsided too, because it says that if Init_Returns_Impulse is False, GetWave_Exists has to be set to True. What this is really trying to say is that the model should implement and contain an AMI_GetWave function, therefore this parameter will also be to True. But if someone reads the sentence as written on paper, they could interpret it as having to set this parameter to True, regardless of whether the function exists in the file or not... This is certainly not what we wanted to say. Going back to the main topic of this thread, this finding seems to indicate that the original intent was that the GetWave_Exists parameter would be used to inform the EDA tool about the content of the algorithmic model. However, if we agree that we also want to be able to use GetWave_Exists for controlling the EDA tool, we will not only have to add the words I wrote in red bold below, but we will also have to reword the Definition and Usage Rules (on pg. 192-193 of the v0.125 draft) in the v5.1 specification. Please do not take this as me trying to blow some little thing out of proportion. We are dealing with a specification which needs to be wordsmithed accurately so that there is no room for twisting it and misinterpreting it later on. The better the spec is written now, the fewer problems we will have later. Another general observation on this whole discussion is that this is one of those situations when we are dealing with a completely redundant and unenforceable parameter. (An EDA tool can check what functions exist in the DLL-s with a single line of code, and our IBIS parser will not look inside the DLL to verify whether this parameter is correct or not). For this reason, if we ended up deciding that we shouldn't use this parameter for anything else but tell the tool whether the GetWave function exists in the DLL, I would make a proposal to deprecate the parameter and get rid of it. There is absolutely no need for it at all. But for the same reason I feel that to get some use out of this parameter, we might as well allow it to be used for "flow control" with the modifications mentioned in this thread. But then the next question becomes whether the name of this parameter is appropriate based on what we are trying to use it for. But changing its name is the same as getting rid of it and introducing a new parameter... So, shall we: #1) change the definition of GetWave_Exists in IBIS v5.1 and allow it to be used to tell the tool whether or not to use the GetWave function in a DLL when it exists? #2) remove this parameter from IBIS v5.1 and come up with a new parameter for IBIS v5.2 with a better name in IBIS v5.2 to be used for "flow control"? #3) do nothing, and reap the consequences of a vague specification later? As usual, questions, comments welcome... Thanks, Arpad ================================================================== From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Thursday, March 08, 2012 11:38 AM To: 'IBIS-ATM' Subject: [ibis-macro] Re: Question about GetWave_Exists Todd, Don't take me wrong, I am not against the idea to use this parameter like that for debugging purposes, and actually I like to have that capability. I am just trying to figure out whether that was the intent of the spec, and if yes how we should say it. Even though the deadline for BIRDs is tomorrow, this might still get fixed as an editorial change for v5.1 if the change is minimal. The problem I see with BIRD 120.1 is that as you also pointed out, following those words literally introduces the possibility for calling GetWave when it doesn't exist. Even though I agree that good programming practice can eliminate the consequences of calling a non-existent function, this situation is an indication that even when we (actually I) wrote this BIRD, our (my) thinking of this parameter was that it is a true reflection of the content of the DLL and not an instruction to the EDA tool on what to with the functions in the DLL, regardless of whether they exist or not. It seems that we need to take one of two possible actions: Either fix BIRD 120.1 and make it clear that this parameter can be used to instruct the tool whether or not to execute the GetWave function when it exists, or fix BIRD 120.1 so that it would clearly state that this parameter should always truthfully reflect the content of the executable and should not be used for anything else. I wrote an example in my last posting with a suggestion on how this could be corrected along the lines of the first option above. We could also fix the wording of the "Time domain simulation reference flow" section in BIRD 120.1 like this (added words in red bold): | Step 5. If Tx GetWave_Exists is True and the GetWave function exists in | the Tx algorithmic model, the output of Step 4 is presented to | the Tx model's AMI_GetWave function and the Tx AMI_GetWave | function is executed. The output of the Tx AMI_GetWave function | is passed on to Step 6. | | Step 6a. If Tx GetWave_Exists is True and the GetWave function exists in | the Tx algorithmic model, and Rx GetWave_Exists is True and the | GetWave function exists in the Rx algorithmic model, the | output of Step 5 is convolved with the output of Step 1 by the | simulation platform and the result is passed on to Step 7. | | Step 6b. If Tx GetWave_Exists is False and Rx GetWave_Exists is True and | the GetWave function exists in the Rx algorithmic model, the | output of Step 4 is convolved with the output of Step 2 by the | simulation platform and the result is passed on to Step 7. | | Step 6c. If Tx GetWave_Exists is False and Rx GetWave_Exists is False, the | output of Step 4 is convolved with the output of Step 3 by the | simulation platform and the result is passed on to Step 8. | | Step 6d. If Tx GetWave_Exists is True and the GetWave function exists in | the Tx algorithmic model, and Rx GetWave_Exists is False, the | output of Step 5 is convolved with the output of Step 1 and the | Impulse Response of the Rx filter by the simulation platform and | the result is passed on to Step 8. (The Impulse Response of the | Rx filter may be obtained by deconvolving the output of Step 3 by | the input of Step 3). | | Note: For the scenario where the Tx AMI_Init function does NOT include | equalization effects (i.e. does not modify the impulse response of the | channel), Step 6d is functionally equivalent to simply convolving the | output of Step 5 with the output of Step 3. | | Step 7. If Rx GetWave_Exists is True and the GetWave function exists in | the Rx algorithmic model, the output of Step 6 is presented to | the Rx model's AMI_GetWave function and the Rx AMI_GetWave | function is executed. The output of the Rx AMI_GetWave function | is passed on to Step 8. These changes would convey the idea that the EDA tool should only execute the GetWave function when GetWave_Exists is true and the GetWave function exists in the algorithmic model. This would not only eliminate the problem of telling the tool to execute the function when it doesn't exist, but would also let people know that the GetWave function will only be executed if GetWave_Exists = True in the .ami file even if the function exists in the algorithmic model. If we agree on doing this, we could try to "sneak these changes in" at the 11:59,999th hour into the v5.1 specification... Thanks, Arpad ================================================================== ________________________________ 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.