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 1993Received 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