Bob, As I said earlier, it will take months to go through the document and correct all of the explanations and examples. My attempt here is to put together a document that we can vote on either by the ATM committee and/or the Open Forum that can give the parser writer clear directions to finish the parser and eliminate most if not all of the ambiguities in the current document. To answer your specific questions: 1. Is there any mode where the .dll reads the .ami file directly? a. This is not mode where the .dll reads in the .ami file directly. 2. Is Type always required? a. Type should always be required. 3. Question, why not make either Format and/or Default always required for the first five Reserved parameters (which only accept Value, and make Format mandatory for all other cases? a. Because many of the example in IBIS 5.0 do not have this. 4. In several cases, such as Tx_Jitter in Table 3, there is no way to interpret this parameter if Format is missing. So the rule that both Format and Default can be omitted creates syntactical ambiguity for that reserved parameter and also for Rx_Clock_PDF and possible future parameters. a. Tx_Jitter and Rx_Clock_PDF should specifically require Format. 5. For some other Type In, InOut and Out selections, mandating at least a Format and a dummy value will not be a burden and might simplify the checking. a. I proposed: "If a parameter Usage is In, Out or InOut, and the parameter has neither Format nor Default, then any value consistent with its Type is allowed as input to the DLL or as output of the DLL." b. What if a Type was Integer and any value could be input to the dll or output from the dll. What would it's Format be? 6. Question, why not make either Format and/or Default always required for the first five Reserved parameters (which only accept Value, and make Format mandatory for all other cases? a. I proposed: "If a parameter has Usage Info, then it must have Format and/or Default.", which is as you ask. 7. Format only - the stated <value> or <typ value> assumed if a single value is needed, but certain formats such as Increment and Steps are expected to pass the sequential set of values if the tool executes these operations. a. This is not correct. A Format might be (Format Steps 0. -1000. 1000. 2.) b. The tool is allowed to only pass one even numbers from -1000. to +1000. c. The tool would allow the user to choice any one of these. 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 Bob Ross Sent: Monday, August 31, 2009 7:21 PM To: wkatz@xxxxxxxxxx Cc: IBIS-ATM Subject: [ibis-macro] Re: Revised SiSoft priorities of resolving AMI issues, and BIRD to address the issues raised by the IBIS 5.0 Parser developer Walter: This is a good start, but I have some questions and implications. But first: 1. What we are looking for is some quick and simple interpretation of what we already have that can be quickly implemented and make the parser mostly useful. This could be by common agreement, because we will complete the parser development soon and ask for more money to do a more thorough fix in the next release. 2. We want a formal BIRD documenting the interpetation to stabilize the syntax. What I want is not just a simple paragraph, but absolute clarity for all cases. So the proposal below might be a starting point, but the whole section 6c must be reviewed for absolute clarity, lack of implied contradiction and perhaps clarified with more examples and options. 3. Is there any mode where the .dll reads the .ami file directly? I assume not. The EDA tool always reads the .ami file as a data intialization and/or format structure directive. The format of the data passed into or out of the .dll is according to the tree structure syntax, not the .ami syntax. ----- So far, I infer that Usage is required. Is Type always required? "Type: (default is Float)" implies it is optional, although syntactical descriptions and examples later seam to imply it is required. Question, why not make either Format and/or Default always required for the first five Reserved parameters (which only accept Value, and make Format mandatory for all other cases? In several cases, such as Tx_Jitter in Table 3, there is no way to interpret this parameter if Format is missing. So the rule that both Format and Default can be omitted creates syntactical ambiguity for that reserved parameter and also for Rx_Clock_PDF and possible future parameters. For some other Type In, InOut and Out selections, mandating at least a Format and a dummy value will not be a burden and might simplify the checking. The simple and expected interpretation for Format and/or Default is Format and Default <value> passes the <value> based on the Default entry (although the EDA tool might take over control and pass different values to the .dll depending upon the actual Format such as "Steps" or the EDA tool interface). Default <value> (no Format) - <value> is passed Format only - the stated <value> or <typ value> assumed if a single value is needed, but certain formats such as Increment and Steps are expected to pass the sequential set of values if the tool executes these operations. Bob Walter Katz wrote: > All, > > > > Based on the discussions in the recent Open Forum, and recent ATM > meetings I would like to modify the priorities for my discussions on > resolving AMI issues as follows. > > > > 1. BIRD to clarify use of Format and Default for the IBIS 5.0 Parser > 2. Discussion on an additional, optional Init output > 3. BIRD to clarify flows that support Non-LTI Tx GetWave > 4. Apply exiting keyword ?Labels? to parameters with Format List. > 5. New Keyword Vector > 6. Make Format optional > 7. Make Type optional for certain reserved keywords > 8. Make Usage optional for certain reserved keywords > 9. Make Reserved_Parameters and Model_Specific Branches optional > 10. Add AMI Version to .ami files. > > > > Specifically, the BIRD to clarify use of Format and Default is clearly > of the highest priority. I think the following interpretation should be > satisfactory for all concerned, and resolves all ambiguities in IBIS > 5.0, and should allow the parser developer to complete his task with no > ambiguity. In addition, since nothing in the above list of potential > improvements to the BIRD will deprecate anything, it will support the > fundamental IBIS premise that no model will become obsolete, and that to > be compliant, an AMI simulator should support all versions of AMI > models, and just increasing the rev of an AMI model will still make it a > valid. > > > > And change the following line on page 140 > > | Format: (default is range) > > to > > | Format: > > > > Add at the bottom of page 141 a third note in Section 6c, DEFINITIONS: > > > > 3. The Format and Default keywords are two ways of specifying the value, > or allowed values for a parameter. It is legal to use the Format > keyword, the Default keyword, both the Format and Default keyword, or > neither of the two. If both Format and Default are used, then the > Default value must be an allowed value in the Format statement. If a > parameter has Usage Info, then it must have Format and/or Default. If a > parameter Usage is In, Out or InOut, and the parameter has neither > Format nor Default, then any value consistent with its Type is allowed > as input to the DLL or as output of the DLL. This shall apply to all > Model Specific and Reserved Parameters. Descriptions or examples in this > document may show any of these four methods, and the method used for > that description or example would not prohibit using the other three > methods. > > > > > > I propose we discuss this BIRD on Tuesday, with the goal of agreeing to > formally submitting this to the Open Forum at the next Open Forum > meeting. I would hope we would have sufficient support for this BIRD in > the Tuesday meeting that the IBIS Parser sub-committee would have > confidence that the full Open Forum will approve this BIRD in a timely > fashion. > > > > Please also note, that SiSoft will introduce a BIRD at some later time > that would make using the keyword Format optional, and elevating the > following Format directives to keywords: Value, Corner, Range, List, > Increment, Steps, Table, Gaussian, Dual-Dirac, and DjRj. > > > > Walter > > > > > > Walter Katz > > 303.449-2308 > > Mobile 720.333-1107 > > wkatz@xxxxxxxxxx > > www.sisoft.com > > > -- 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