Re: [IBIS] BIRD135: Add Boolean to BNF for IBIS-AMI

From: Mike LaBonte <milabont@cisco.com>
Date: Fri Jul 15 2011 - 10:42:24 PDT

In the Open Forum meeting today I agreed with Arpad that this BIRD is
limited to BNF changes, and improvements to the definition of acceptable
Boolean values is a separate matter. However, looking at the full BNF for
AMI I am beginning to think it needs even more work.

The IBIS 5.0 spec has:

| The modified BNF specification for the syntax is:
|
| <tree>:
| <branch>
|
| <branch>:
| ( <branch name> <leaf list> )
|
| <leaf list>:
| <branch>
| <leaf>
| <leaf list> <branch>
| <leaf list> <leaf>
|
| <leaf>:
| ( <parameter name> whitespace <value list> )
|
| <value list>:
| <value>
| <value list> whitespace <value>
| <value>:
| <string literals>
| <decimal number>
| <decimal number>e<exponent>
| <decimal number>E<exponent>

In BNF, everything inside <angle brackets> is called a non-terminal. It is
called that because the definition of it is not yet complete. A terminal
definition specifies actual characters, which are not in angle brackets. An
exception is terms like "white-space", "lbracket", and other characters that
have to be built into the BNF language as symbolic names because BNF itself
is expressed using them.

Our BNF does not define the non-terminals <string literals>, <decimal
number>, and <exponent>. In the meeting I heard Bob make the point that if
we add <Boolean> to the BNF then we will have one more undefined
non-terminal (he might not have called it that).

Below my signature I have pasted the BNF that describes <literal> for C++.
Note that they don't use angle brackets, which is a bit confusing. They use
the style where anything not defined is a terminal that has to be taken
exactly as it appears. You can see that <boolean> is the last definition and
it either maps to exactly the words "true" or "false", or they made the same
mistake and left true and false undefined.

Anyway, the BNF in the IBIS spec is insufficient in that you could not pass
it to YACC or BISON to create a parser that is able to discriminate between
string literals, decimal numbers, or exponents. A complete BNF is usually
pretty long.

At this point I have to agree with Bob that we might not want to add Boolean
until we have a better handle on how complete our BNF should be. At a
minimum I would advise adding a definition for Boolean if <Boolean> is added
to <value>:

<Boolean>:
True
False

Mike

http://www.csci.csusb.edu/dick/c++std/cd2/gram.html

          literal:
                  integer-literal
                  character-literal
                  floating-literal
                  string-literal
                  boolean-literal
          integer-literal:
                  decimal-literal integer-suffixopt
                  octal-literal integer-suffixopt
                  hexadecimal-literal integer-suffixopt
          decimal-literal:
                  nonzero-digit
                  decimal-literal digit
          octal-literal:
                  0
                  octal-literal octal-digit
          hexadecimal-literal:
                  0x hexadecimal-digit
                  0X hexadecimal-digit
                  hexadecimal-literal hexadecimal-digit
          nonzero-digit: one of
                  1 2 3 4 5 6 7 8 9
          octal-digit: one of
                  0 1 2 3 4 5 6 7
          hexadecimal-digit: one of
                  0 1 2 3 4 5 6 7 8 9
                  a b c d e f
                  A B C D E F
          integer-suffix:
                  unsigned-suffix long-suffixopt
                  long-suffix unsigned-suffixopt
          unsigned-suffix: one of
                  u U
          long-suffix: one of
                  l L
          character-literal:
                  'c-char-sequence'
                  L'c-char-sequence'
          c-char-sequence:
                  c-char
                  c-char-sequence c-char

          c-char:
                  any member of the source character set except
                          the single-quote ', backslash \, or new-line
character
                  escape-sequence
                  universal-character-name
          escape-sequence:
                  simple-escape-sequence
                  octal-escape-sequence
                  hexadecimal-escape-sequence
          simple-escape-sequence: one of
                  \' \" \? \\
                  \a \b \f \n \r \t \v
          octal-escape-sequence:
                  \ octal-digit
                  \ octal-digit octal-digit
                  \ octal-digit octal-digit octal-digit
          hexadecimal-escape-sequence:
                  \x hexadecimal-digit
                  hexadecimal-escape-sequence hexadecimal-digit
          floating-literal:
                  fractional-constant exponent-partopt floating-suffixopt
                  digit-sequence exponent-part floating-suffixopt
          fractional-constant:
                  digit-sequenceopt . digit-sequence
                  digit-sequence .
          exponent-part:
                  e signopt digit-sequence
                  E signopt digit-sequence
          sign: one of
                  + -
          digit-sequence:
                  digit
                  digit-sequence digit
          floating-suffix: one of
                  f l F L
          string-literal:
                  "s-char-sequenceopt"
                  L"s-char-sequenceopt"
          s-char-sequence:
                  s-char
                  s-char-sequence s-char
          s-char:
                  any member of the source character set except
                          the double-quote ", backslash \, or new-line
character
                  escape-sequence
                  universal-character-name
          boolean-literal:
                  false
                  true

On 7/15/11 1:43 AM, "Arpad Muranyi" <Arpad_Muranyi@mentor.com> wrote:

> Bob, Mike,
>
> When I wrote this BIRD, I took the description on pg. 140 as
> the definition for Boolean, so I used the same style for
> correcting the BNF on pg. 187.
>
> You are correct, the parenthetical indication for the allowable
> values of Boolean is really not much of a "definition", but
> BIRD 135 was not written to correct that. BIRD 135 is correcting
> the omission of Boolean in the BNF.
>
> I would suggest to approve this BIRD as is, and if we have an
> issue about defining Boolean in a more formal way, we should
> either write a new BIRD for that, or add that to BIRD 127.1
> "IBIS-AMI Typographical Corrections".
>
> Thanks,
>
> Arpad
> ==================================================================
>
> -----Original Message-----
> From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Bob Ross
> Sent: Thursday, July 14, 2011 5:43 PM
> To: 'Mike LaBonte'; 'Mirmak, Michael'; 'IBIS'
> Cc: bob@teraspeed.com
> Subject: RE: [IBIS] BIRD135: Add Boolean to BNF for IBIS-AMI
>
> Mike:
>
> You raise some good points.
>
> 1. For IBIS .ami files, the ONLY acceptable values for the Boolean type
> will be True or False. These values are case-sensitive, and
> no other choices are allowed.
>
> 2. However, the BIRD is intended to clarify what the EDA tool
> does when it transmits or receives the values associated the Boolean
> type. I think we goofed because we thought there was a Boolean type
> in ANSI C. ANSI C appears to use integers 0 and 1 for Boolean values.
>
> Thanks for the head's up. I think we should bring this up at the meeting
> and plan to return BIRD135 to the ATM committee for correction..
>
> Bob
>
>
> -----Original Message-----
> From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Mike
> LaBonte
> Sent: Thursday, July 14, 2011 2:22 PM
> To: Mirmak, Michael; IBIS
> Subject: Re: [IBIS] BIRD135: Add Boolean to BNF for IBIS-AMI
>
> With BIRD 135 łAdd Boolean to BNF for IBIS-AMI˛ scheduled for a vote
> tomorrow this is late, but I have a question. The BIRD describes allowable
> Boolean values only in a parenthetical comment:
>
> |*8. Parameter values can be expressed either as a string literal, Boolean
> |* literal (True or False), decimal number, or a floating point number in
> |* the standard ANSI 'C' notation (e.g., 2.0e-9). String literal values
> |* are delimited using a double quote (") and no double quotes are allowed
> |* inside the string literals.
>
> There is a similar parenthetical comment on page 140 where the Type
> parameter values are listed.
>
> | Type: (default is Float)
> | Float
> | Integer
> | String
> | Boolean (True/False)
> | Tap (For use by TX and RX equalizers)
> | UI (Unit Interval, 1 UI is the inverse of the data rate frequency,
> | for example 1 UI of a channel operating at 10 Gb/s is 100 ps)
>
> Since tools and models will have to decide if a submitted Boolean value is
> true or false, it seems to me there should be more guidance. For example,
> which of these are true and which are false, if any?
>
> true
> false
> yes
> no
> t
> 0
> 1
> <-- empty string
>
> What to do if a value is not exactly "True" or "False"? One approach is for
> the IBIS parser to reject any other value for Boolean parameters, as long as
> it always knows the type expectation of every parameter (Boolean Table
> contents, anyone?). Ibischk5 says nothing no matter which of the above
> values I set a Boolean parameter to, so currently we can't count on this
> kind of checking.
>
> But it is not uncommon for languages that support Boolean types to
> case-insensitively regard "true", "t", "yes", "y", or any non-zero number as
> True, and all else as False. Should we add some exact description that
> yields only two outcomes to the spec in this BIRD? What will existing tools
> accept as true and false today?
>
> Mike
>
> On 6/15/11 4:50 PM, "Mirmak, Michael" <michael.mirmak@intel.com> wrote:
>
>> The enclosed BIRD 135, Add Boolean to BNF for IBIS-AMI, is submitted on
> behalf
>> of Arpad Muranyi of Mentor Graphics Corp. It will be discussed at the
> next
>> IBIS Open Forum teleconference.
>>
>> A complete list of BIRDs is available at http://www.eda.org/ibis/birds/.
>>
>> Michael Mirmak
>> Intel Corp.
>> Chair, IBIS Open Forum
>>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org
|with the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or e-mail a request to ibis-request@eda-stds.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda-stds.org/pub/ibis/email_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/users_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/email/         E-mail since 1993
Received on Fri Jul 15 10:42:36 2011

This archive was generated by hypermail 2.1.8 : Fri Jul 15 2011 - 10:42:59 PDT