Subject: RE: Note on Rev

From: "Peters, Stephen" <[email-masked]>
Date: Thu, 5 Jul 2001 15:29:18 -0700

Hi Scott:

  The reason for the column 1 requirement lies in the arbitrary length of
the [Notes] field. As IBIS is defined, (implicitly by the golden parser in
Ver 3.2, explicitly in IBIS-X), the [Notes] field ends when the next keyword
is encountered.  However, a real life case arose in which a keyword was used
*within* the note.  The parser encountered it, ended the [Notes] section,
and subsequently bombed on the remaining notes text.  The fix was to
recognize [...] as keyword only when the opening bracket was in column 1.
As I mentioned, this rule was formalized in IBIS-X (which is where the
General Syntax Rules and Guidelines in the connector spec came from).

  Regards,
  Stephen Peters
  Intel Corp.

-----Original Message-----
From: Scott McMorrow [mailto:[email-masked]]
Sent: Thursday, July 05, 2001 12:21 PM
To: [email-masked]; ibis
Subject: Re: Note on Rev

All,

I see no reason why on page 3 of the document the following
is a requirement:

3) Keywords must be enclosed in square brackets, [ ] , and must start in
column 1
of the line.

The column 1 requirement seems a bit antiquated to me.

regards,

scott

--
Scott McMorrow
Principal Engineer
SiQual, Signal Quality Engineering
18735 SW Boones Ferry Road
Tualatin, OR  97062-3090
(503) 885-1231
http://www.siqual.com

[email-masked] wrote:

> <<File: icm0.pdf>>Good Catch Arpad...
>
> All...  See attached...  with correct revision number
>
> I am sending the doc again... see attached...  I didn't think this
correction
> was worth a revision number.
>
> _gus
>
> -----Original Message-----
> From: "Muranyi, Arpad" <[email-masked]>
> Sent: Thursday, July 05, 2001 1:35 PM
> To: apanella
> Subject: RE: 0.969 attached...
>
> The title page still shows rev 0.968...
>
> Arpad
> =======================================
>
> -----Original Message-----
> From: apanella
> Sent: Thursday, July 05, 2001 1:16 PM
> To: '"Peters, Stephen" <[email-masked]>'; '"Al Davis
> <[email-masked]>" <[email-masked]>'; '"Bob Ross
> <[email-masked]>" <[email-masked]>'; '"Chris Reid
> <[email-masked]>" <[email-masked]>'; '"DC Sessions
> <[email-masked]>" <[email-masked]>'; '"Gerald Bannert
> <[email-masked]>" <[email-masked]>';
> '"Greg Edlund <[email-masked]>" <[email-masked]>'; '"John Angulo
> <[email-masked]>" <[email-masked]>'; '"Lynne Green
> <[email-masked]>" <[email-masked]>'; '"Muranyi, Arpad"
> <[email-masked]>'; '"Scott McMorrow <[email-masked]>"
> <[email-masked]>'; '"Steve Nolan <[email-masked]>"
> <[email-masked]>'
> Subject: RE: 0.969 attached...
>
> See attached...
>
> The major revision in the attached document is per the last teleconference
that
> I attended.
>
> Basically it revolves around making the subparameters in 968 more line an
> assigned variable as seen in IBISX
>
> This was done for both the sub parameters for [Begin Cn Model] and the
matrix
> section.
>
> The "matrix" portion probably needs more work.
>
> We can use this for review on Tuesday.
>
> _gus
>
>
----------------------------------------------------------------------------
--------------------------------------------------------
>                Name: ICM0.PDF
>    ICM0.PDF    Type: Acrobat (application/pdf)
>            Encoding: base64

---

From: Greg Haynes <[email-masked]>
Date: Fri, 06 Jul 2001 09:35:26 -0600

> General Syntax Rules and Guidelines in the connector spec came from).

A keyword could also occur at column 1 inside a [Notes] section, so
I think good error messages are the best solution to avoiding misused
reserved words.

I agree with Scott that the column 1 rule seems antiquated (reminds
me of Fortran punch cards beginning in column 7).  A compromise might
be to require the keyword to be the first token on a line, but allow
leading white space.  This would at least allow indentation.

Greg Haynes		  [email-masked]
Aeroflex UTMC Microelectronic Systems
4350 Centennial Blvd           phone: 719 594-8197
Colorado Springs, CO 80907       fax: 719 594-5541

---

From: Scott McMorrow <[email-masked]>
Date: Fri, 06 Jul 2001 09:55:01 -0700

Stephen,

I have the following suggestions to eliminate this problem:

1) Require that keywords do not appear in any text blocks.  Where a keyword is defined to include the [keyword] syntax.  This would
be an unusual circumstance anyway.  It is highly unlikely that in production models that a [keyword] would appear in a text block
sections.  These sorts of things generally only occur in examples and can be easily removed.

2) Require an [End Block] keyword for all sections with text blocks.

The requirement that keywords begin in column 1 seems more onerous to me than either of these suggestions.  I would "really" like to
be able to use indented structure within all future models to facilitate better understandability.  Also, I would really like to not
have to deal with a stupid parser that spits out my files when somehow I managed to create a model that does not position a keyword
in column 1.

regards,

scott

---

From: Al Davis <[email-masked]>
Date: Fri, 6 Jul 2001 11:53:08 -0700

On Friday 06 July 2001 09:55 am, Scott McMorrow wrote:
> 1) Require that keywords do not appear in any text blocks.  Where a
> keyword is defined to include the [keyword] syntax.  This would be
> an unusual circumstance anyway.  It is highly unlikely that in
> production models that a [keyword] would appear in a text block
> The requirement that keywords begin in column 1 seems more onerous
> to me than either of these suggestions.  I would "really" like to
> be able to use indented structure within all future models to
> facilitate better understandability.  Also, I would really like to
> not have to deal with a stupid parser that spits out my files when
> somehow I managed to create a model that does not position a
> keyword in column 1.

We discussed this, both in connector and IBIS-X.  The problem is 
backward compatibility.  

Under suggestion #1, this basically prohibits any use of "[" in a 
text block.  This was the original intended way of doing it.  In 
testing, I found that there were too many old files being rejected.

Suggestion #2 is the obviously superior method, except that there are 
lots of files that don't have the end marker, and we want to maintain 
100% backward compatibility.

Still, this does not require that EVERY keyword begin in column 1.  
The restriction could only apply to those terminating a text block, 
or the text block could be terminated by a line containing a "[" as 
the first non-whitespace character, following a blank line.

---

From: Alan Hilton-Nickel <[email-masked]>
Date: Fri, 20 Jul 2001 10:24:21 -0700

I'm glad the IBIS and IBIS-X committes are looking at backward
compatibility. 

However, there is a required keyword in the IBIS spec called [IBIS ver].
Seems to me it should be pretty straightforward for a parser to treat
old files as requiring the column 1 limitation, while allowing and [End
Notes] keyword at the end of a [Notes] section in future versions.

Thanks for bringing this up, Scott. This limitation has bugged me for a
while, as it has anyone with a programming background (which should be
the majority of us!)

Alan Hilton-Nickel
Transmeta Corp.

Al Davis wrote:
> ? Stephen,
> ?
> ? I have the following suggestions to eliminate this problem:
> ?
> ? 1) Require that keywords do not appear in any text blocks.  Where a
> ? keyword is defined to include the [keyword] syntax.  This would be
> ? an unusual circumstance anyway.  It is highly unlikely that in
> ? production models that a [keyword] would appear in a text block
> ? sections.  These sorts of things generally only occur in examples
> ? and can be easily removed.
> ?
> ? 2) Require an [End Block] keyword for all sections with text
> ? blocks.
> ?
> ?
> ? The requirement that keywords begin in column 1 seems more onerous
> ? to me than either of these suggestions.  I would "really" like to
> ? be able to use indented structure within all future models to
> ? facilitate better understandability.  Also, I would really like to
> ? not have to deal with a stupid parser that spits out my files when
> ? somehow I managed to create a model that does not position a
> ? keyword in column 1.
>