Arpad, You are correct. The current 5.0 is confusing on Default and Format, and Ambrish suggests on e solution for Format but does not clarify how to use Default. I personally would much rather deprecate Format, and make Value, Range, List, Corner, Increment, and Steps reserved parameters. Ambrish suggests: | (Format <data format>) (Value <values>) (Default <values>) I much prefer | (<format> <values>) (Default <values>) Because of the inconsistent definition of Format in the IBIS 5.0, IC Vendors have been all over the map in generating .ami files, and also in generating the strings that get passed into the Init call. We have solved this problem by simply always stripping off Format from the .ami files when we read them in. Just removing Format is what our customers have recommended to us. And to answer your specific concern about Default, I suggest the following language: | Default <value>: | Depending on the Type and <format>, <value> will provide a default value for the | parameter. For example, if the Type is Boolean, <value> could be True | or False, if the Type is Integer, the <value> can be an integer value. | Default is not allowed if <format> is Corner. Computed is a reserved value for | Default. If {Default Computed), then the value of this parameter is computed | from the values of other parameters by the Computation Engine. If Default is not | specified, then the default value of a parameter shall depend on the <format> as | described below | Value: (Only Computed is allowed) | Range: <typ value> | List: <value1> | Label: NA | Corner: NA | Increment: <typ value > | Steps: <typ value > Note that Label and Computation Engine are enhancements to AMI that we were planning to introduce shortly. Note that the answer to the formulation of the string passed to Init is now very simple. A "leaf" is either a parameter or a reserved keyword. Only leaves that are "parameters" and In or InOut are passed to the DLL, and the leaves are always passed in the form: (<parameter> <value>). <value> is determined by the EDA tool. If the <format> is Value, then there can only be one value that the EDA tool can pass. If the <format> is Corner, then the process Corner determines <value> selected for the simulation. Otherwise, the EDA tool can choose any mechanism for determining <value> based in its allowed values determined by <format> being Range, List, Increment or Steps. Note that there is no <format> that allows more than one <value>. Gaussian, Table, Dual-Dirac and DjRj that are only used for Reserved parameters Clock_PDF and Tx_Jitter, and were not well thought out when we wrote the original AMI specification, and in fact are not useful and just add to confusion on using AMI. We are planning on correcting this in our proposed changes to AMI. In what I am planning to propose, the new reserved leaf Vector can be used combine the other sibling leaves into a list of values of the parent leaf. This is the way that the following would occur (<parameter> <value> <value> <value> <value>). Using Vector has two applications. The first application is Taps: Without Vector (Tap (-1 .1) (0 .8) (1 -.1)) With Vector (Tap .1 .8 -.1) Similarly, for clock PDF, we have found that IC vendors need to control the mean and standard deviation of the clock independently. Our current formulation of clock PDF does not allow the IC Vendors to do this. That is why we will offer new reserved parameters for Clock_PDF_Mean and Clock_PDF_Sigma. This can be done in either of the two following forms:in the ami file: (Clock_PDF (Mean (Usage In) (Range 0. -.5UI +.5UI)) (Sigma (Usage In) (Range 0. -.3UI +.3UI)) ) (Clock_PDF (Mean (Usage In) (Range 0. -.5UI +.5UI)) (Sigma (Usage In) (Range .1UI. 0. .3UI)) (Vector (Value True)) ) The strings passed to the DLL would be (assuming UI is 1.e-10, and using Default values): (Clock_PDF (Mean 0.) (Sigma .1e-11)) (Clock_PDF 0. 1e-11) .As I have said in previous meetings, all of these deficiencies in the IBIS 5.0 are interrelated, and need to be fixed in a unified way, Walter Walter Katz 303.449-2308 Mobile 720.333-1107 wkatz@xxxxxxxxxx www.sisoft.com -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of Muranyi, Arpad Sent: Tuesday, August 25, 2009 12:17 AM To: IBIS-ATM Subject: [ibis-macro] Re: IBIS AMI Specification Questions/Proposal Ambrish, Thanks for pointing this problem out. I am sure we will address these issues as our discussions on AMI improvements continue. I would like to ask you a couple of questions about the usage of "default". 1) Considering your statement that "we have used the word Default to specify the value for that model/simulation", what would you say is the difference between the typical value of a range and the default? 2) Your statement "we have used the word Default to specify the value for that model/simulation" opens up the question I asked a several weeks ago about parameter strings. Remember, my impression about the specification was that the entire .ami file was supposed to be passed into the DLL's parameter string and consequently the DLL was supposed to parse it and extract the values from it. Your statement that "we have used the word Default to specify the value for that model/simulation" seems to underline that thinking, because it seems that you are saying that the DLL will extract the default value and simulate using that. In this case, the EDA tool could modify the original .ami file's default values before passing it to the DLL according to the user's wishes for each specific simulation. On the other hand, if this was not the intent, in other words, if the DLL is supposed to get only a subset of the .ami file in the parameter string, I am still looking for a description in the AMI specification that explains how to formulate that subset. Thanks, Arpad ====================================================================== -----Original Message----- From: Ambrish Varma [mailto:ambrishv@xxxxxxxxxxx] Sent: Monday, August 24, 2009 3:03 PM To: IBIS-ATM Cc: Muranyi, Arpad Subject: RE: [ibis-macro] Re: IBIS AMI Specification Questions/Proposal Hi All, I feel there is some real confusion about "Values" and "Default". Defaults, generally mean that if there is no value provided, the tool will use the default value. In the spec, we have used the word Default to specify the value for that model/simulation (particularly in the reserved parameters section). There is also confusion because we have defined the format for declaring the parameters at 2 places for the reserved parameters (one with format, one without). Please refer to the attached document to see the changes that I am proposing to the parameter section. Thanks, -Ambrish. -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Tuesday, August 18, 2009 6:51 PM To: IBIS-ATM Subject: [ibis-macro] Re: IBIS AMI Specification Questions/Proposal Bob, Thanks for posting this summary of the problem. I read trough the attached file and I am not sure what the reasons are for these inconsistencies. In order to make the right decisions, I feel we need to ask those who wrote these portions of the AMI spec to find out what was their intent. Authors, please speak up... Thanks, Arpad ======================================================== -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross Sent: Tuesday, August 18, 2009 5:11 PM To: IBIS-ATM Subject: [ibis-macro] IBIS AMI Specification Questions/Proposal All: This is being sent out per the issue raised at the Aug. 18 meeting concerning parser interpretation of the AMI Spec. The ibischk5 parser with the -ami flag will check the syntax of the <file name>.ami file. The attached document shows several forms for <parameter_name> that are in the specification. Some of the forms imply a restricted set of parameters, but then this is contradicted by the example at the end. This implies that some parameters are really optional and not excluded according to the syntaxes given. The propposal is simply to make all parameters at least optional, and some required according to a draft Table 4 that is NOT in the specification. Do the choices in Table 4 look reasonable? Bob -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@xxxxxxxxxxxxx Teraspeed is a registered service mark of Teraspeed Consulting Group LLC --------------------------------------------------------------------- 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