[ibis-macro] Re: Table usage

  • From: Bob Ross <bob@xxxxxxxxxxxxx>
  • To: wkatz@xxxxxxxxxx
  • Date: Thu, 30 Sep 2010 16:48:46 -0700

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 used

in

an 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

Other related posts: