RE: Note on Rev

Hi Scott:

  In regards to point 1) below -- the case I cited was a production file and
not an example. I find it very reasonable to include something like "To use
this model your simulator must support the [XYZ] keyword" in the notes
section. I don't think we can forbid someone from doing so.

  On point 2) -- The futures committee has discussed requiring [End] type
keywords for text blocks (in addition to the ones already there for major
sections). Note that to be consistent an [End Block] keyword would have to
follow [Notes], [Source], [Disclaimer], [Copyright], [Support] and
[Redistribution Text]. I'm not mortally opposed to adding new keywords that
serve only to aid parsing or delimit text, but at some point we end up with
keyword clutter.
  Is the real issue here simply trying to find a way to make a long file
more understandable and/or easily parsable by the human eye? Is indenting
the best way, or are there other ways to get the file to read smoothly?
Understand, I think you raise a legitimate concern. I'm just wondering
what's the best way to solve it, and at what cost.

  Regards,
  Stephen

-----Original Message-----
From: Scott McMorrow [mailto:scott@vasthorizons.com]
Sent: Friday, July 06, 2001 9:55 AM
To: Peters, Stephen
Cc: apanella@molex.com; ibis
Subject: Re: Note on Rev

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

--
Scott McMorrow
Principal Engineer
SiQual, Signal Quality Engineering
18735 SW Boones Ferry Road
Tualatin, OR  97062-3090
(503) 885-1231
http://www.siqual.com
"Peters, Stephen" wrote:
> 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:scott@vasthorizons.com]
> Sent: Thursday, July 05, 2001 12:21 PM
> To: apanella@molex.com; 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
>
> apanella@molex.com 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" <arpad.muranyi@intel.com>
> > 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" <stephen.peters@intel.com>'; '"Al Davis
> > <aldavis@ieee.org>" <aldavis@ieee.org>'; '"Bob Ross
> > <bob_ross@mentorg.com>" <bob_ross@mentorg.com>'; '"Chris Reid
> > <chris_reid@mentorg.com>" <chris_reid@mentorg.com>'; '"DC Sessions
> > <ibis@lumbercartel.com>" <ibis@lumbercartel.com>'; '"Gerald Bannert
> > <gerald.bannert@icn.siemens.de>" <gerald.bannert@icn.siemens.de>';
> > '"Greg Edlund <gedlund@us.ibm.com>" <gedlund@us.ibm.com>'; '"John Angulo
> > <angulo@hyperlynx.com>" <angulo@hyperlynx.com>'; '"Lynne Green
> > <lgreen@cadence.com>" <lgreen@cadence.com>'; '"Muranyi, Arpad"
> > <arpad.muranyi@intel.com>'; '"Scott McMorrow <scott@vasthorizons.com>"
> > <scott@vasthorizons.com>'; '"Steve Nolan <s-nolan1@ti.com>"
> > <s-nolan1@ti.com>'
> > 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