All: Walter is absolutely correct with his observations and detalis. I could even add a few more implications. Notice, NO RULES ARE STATED. That is simply unacceptable in any Specification. A few rules are implied (only by example) for the paramater file (.ami), but carry unstated contradictory implications (like mixing Types as Walter states) - but there are no stated rules that even begin to cover the available possibities. To add to Walter's other point, there are no stated rules or exceptions on how Tables are handled by the .DLL. Tables are supported in the Model_Specific parameter for all Usage modes. Furthermore, Tables are explicitly supported by Reserved_Parameters: RX_Clock_PDF and TX_Jitter. AND for Usage Out. Therefore, Tables are explicitly identified as something that the EDA tool can process from the .DLL (but with no guidence). To support Walter's question in the negative, what is the parameter tree syntax rule that allow any parameter with a Table to be processed? If the unstated new syntax for tables were added such as (parameter_name (( ) ( ) ... ( ))), this a first order deviation this is an unstated deviation of the tree syntax and not could also be an unintended error. If Table parameter were identified by the .ami file in a legal manner: (parameter name (val1 ... val1) there is still no indication of number or rows or columns. A special rule for Table parameter passing to/from the .dll could be added such as: (parameter_name (no_rows val1 ... valn) allowing an integer type first (we already know the parameter is for a Table). Even string labels within Tables could have a rule for .dll to EDA tool communication. The whole .dll is itself passed as a string (different context) so mixing types here is no problem. --------- The big mistake is that we did not even identify these most fundamental and obvious issues. My hot button is that we have been dealing with the IBIS-AMI containing so much (new) information with complex interactions (but badly organized) that even the most obvious ommisions or implication were not even detected. With better structure, (such clear set of rules and implicatons and set(s) of examples for each of the Format options) template-like organized manner would have discovered that no rules were stated for Table or even Labels within a Table. The .dll implications were not identified. So all of this escaped even the most basic review. While helpful, a listing of problems by a parser developer is not needed. It is already obvious that the spec not fully considered and incomplete in Table, Label, and probably several other areas. I am open to considering several ideas and converging to a concensus solution that may even have some non-optimal purity trade-offs. But whatever is decided must be documented fully so that it can be reviewed. Bob Walter Katz wrote:
Kumar,From pages 186/187 of IBIS 5.0| The syntax for this string is: | | 1. Neither names nor individual values can contain white space characters. | 2. Parameter name/value pairs are always enclosed in parentheses, with the | value separated from the name by white space. | 3. A parameter value in a name/value pair can be either a single value or a | list of values separated by whitespace. | 4. Parameter name/value pairs can be grouped together into parameter groups | by starting with an open parenthesis followed by the group name followed | by the concatenation of one or more name/value pairs followed by a close | parenthesis. | 5. Parameter name/values pairs and parameter groups can be freely | intermixed inside a parameter group. | 6. The top level parameter string must be a parameter group. | 7. White space is ignored, except as a delimiter between the parameter name | and value. | 8. Parameter values can be expressed either as a string literal, decimal | number or in the standard ANCI 'C' notation for floating point numbers | (e.g., 2.0e-9). String literal values are delimited using a double | quote (") and no double quotes are allowed inside the string literals. | 9. A parameter can be assigned an array of values by enclosing the | parameter name and the array of values inside a single set of | parentheses, with the parameter name and the individual values all | separated by white space.Note 2. above:| 2. Parameter name/value pairs are always enclosed in parentheses, with the | value separated from the name by white space. The following (from Ambrish and Ken) follow this rule: (abc 10.1 20.2 30.3 ) The following example that you propose for multi-row tables violates this rule: (name (a11 a12 a13) (b11 b12 b13)) Walter Walter Katz 303.449-2308 Mobile 303.883-2120 wkatz@xxxxxxxxxx www.sisoft.com -----Original Message----- From: ckumar [mailto:ckumar@xxxxxxxxxxx] Sent: Thursday, September 30, 2010 2:26 PM To: wkatz@xxxxxxxxxx Cc: kwillis@xxxxxxxxxxx; IBIS-ATM Subject: Re: [ibis-macro] Re: Table usage a single row table can be passed as (name a11 a12 a13) multi rows (name (a11 a12 a13) (b11 b12 b13)) On Thu, 30 Sep 2010 12:31:37 -0400, "Walter Katz" <wkatz@xxxxxxxxxx> wrote:Ken, A Table, by definition, supports multiple rows. How would you pass the following? (abc (Usage In) (Type Float) (Format Table (10.1 20.2 30.3) (1. 2. 3.)(4.5. 6.)) (Description "Table example")) It is this case that makes Format Table as a Usage In, InOut or Out parameter problematic, and not defined, or allowed in the IBIS 5.0 definition of the AMI_parameters_in or AMI_parameters_out string definition. We need to pass similar types of data into the DLL's that we write; we chose to do this in the following manner: (abc (Usage In) (Type String) (Format Value "10.1 20.2 30.3")(Description"Alternative example")) Here is what it looks like when being passed to the DLL: (abc "10.1 20.2 30.3") Your method satisfies all of the rules defined in pages 186 and 187, as long as the Table only contains one row. I think there are the following options: 1. Allow a Format Table to have Usage In (or InOut, or Out), but require that such a Table have only one Row. 2. Require that Format Table has (Usage Info) Option 1 requires some work by all of the other EDA vendors, and a clarification to the definition of Format Table. Option 2 requires some work by Sigrity, and a clarification to the definition of Format Table. Does anyone have any other (preferably better) ideas? Walter Walter Katz 303.449-2308 Mobile 303.883-2120 wkatz@xxxxxxxxxx www.sisoft.com -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of Ken Willis Sent: Thursday, September 30, 2010 11:50 AM To: IBIS-ATM Subject: [ibis-macro] Table usage Hi, Following up from the last call, here is an example of Table being usedinan AMI file: (abc (Usage In) (Type Float) (Format Table (10.1 20.2 30.3))(Description"Table example")) Here is what it looks like when being passed to the DLL: (abc 10.1 20.2 30.3 ) Thanks, Ken Willis Sigrity, Inc. 860-871-7070 kwillis@xxxxxxxxxxx <mailto:kwillis@xxxxxxxxxxx>--------------------------------------------------------------------- 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
-- 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