Re: [IBIS] Question about keyword ordering

From: Mike LaBonte <mikelabonte@eda.org>
Date: Tue Dec 17 2013 - 15:07:23 PST
There is of course a natural ordering that would help parsers to 
generate structural links on the fly, by insuring that things that need 
to be linked to have already been read in. The pins certainly need to 
come after the component keyword, for example.

The IBISCHK parser code does some linking on the fly, but because it 
eventually has to check absolutely everything it uses a more relational 
style. Pins are parsed and linked to the component. Pin mappings are 
parsed and linked to the component. The checks of one against the other 
happen after all parsing is done. It has to be that way because one of 
the checks is that if [Pin Mapping] is present then all pins have to be 
mapped (this is news to me):

PIN_ERR_12: "Component '%s': Pin '%s' not referenced in Pin Mappings."

Since IBISCHK checks each pin against the mappings and each mapping 
against the pins, the parsing must be written to be order independent, 
with only minimal on-the-fly checking. It still could check order 
anyway, but maybe we simply never asked for that.

Another viewpoint: what should IBISCHK do if we decided [Pin Mapping] 
can't come before [Pin]? Flag an ERROR, calling an otherwise perfectly 
usable file illegal?

Mike

On 12/16/2013 4:43 PM, Bob Ross wrote:
> Arpad:
>
> The general rule is that there is no keyword ordering requirement as long
> as keywords are scoped within the higher level keywords or sections.
>   For example, the keywords under [Component] must be scoped by
> [Component], but can be in any order.  So placing [Pin Mapping] ahead
> of [Pin] is legal.
>
> However, there are purposeful exceptions.
>
> The File Header Section must appear first and the [IBIS Ver] keyword
> must be the first keyword.  Proper keyword and subparameter
> processing rules depend on the file version.  [Comment Char] is
> and exception since it placed anywhere and multiple times
> within a .ibs, .pkg or .ebd file.
>
> Under [Model]:  the [Model Spec] and [Receiver Thresholds] (if used)
> must be the first keywords because they are closely related to the
> specification subparameters.  We chose to do this for visual inspection
> convenience.
>
> Under [Component]: [Node Declarations] must appear before any or
> all [Circuit Call] keywords to define the nodes.
>
> Under [Begin Package Model]: [Number Of Sections] (if used) and
> [Number Of Pins] must appear before [Pin Numbers].
>
> I cannot recall if there are any other rules, but all the existing rules are
> handled by the ibischk5 parser and therefore can be handled by
> any EDA tool.
>
> Bob
>
> -----Original Message-----
> From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Muranyi,
> Arpad
> Sent: Monday, December 16, 2013 12:20 PM
> To: IBIS
> Subject: [IBIS] Question about keyword ordering
>
> Hello Everyone,
>
> We ran across an IBIS file in which the [Pin Mapping] keyword
> is placed before the [Pin] keyword.  It seems that the IBIS
> parser is not complaining about this, as there are no errors.
> I don't recall any requirements in the specification about the
> order of the keywords.  On the other hand, if we want to make
> it easier on the tools, it would make sense to have certain
> keywords in a certain order.
>
> Could someone comment on this?  Does the IBIS specification
> really have no requirements about the order of these keywords?
> Was this intentional or an oversight?
>
> Thanks,
>
> Arpad
> =================================================================
>


-- 
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 mikelabonte@eda-stds.org
|or ibis-request@eda-stds.org
|
|IBIS reflector archives exist under:
|
|  http://www.eda-stds.org/ibis/email_archive/ Recent
|  http://www.eda-stds.org/ibis/users_archive/ Recent
|  http://www.eda-stds.org/ibis/email/         E-mail since 1993
Received on Tue Dec 17 15:07:19 2013

This archive was generated by hypermail 2.1.8 : Tue Dec 17 2013 - 15:08:04 PST