Re: [sv-ec] Re: [sv-bc] potential command line option

From: Steven Sharp (sharp@cadence.com)
Date: Sat Apr 23 2005 - 16:07:49 PDT

  • Next message: Steven Sharp: "Re: [sv-ec] Re: [sv-bc] potential command line option"

    Randy,

    A lot of the issues here are necessarily matters of opinion and
    judgement, and what the current LRM says is only one of the factors
    to be considered. However, it helps to establish any facts that
    we can.

    You wrote:
    >I've tried to go back and divine from where you derive your strong
    >assertion "syntax boxes and BNF clearly specify that they cannot appear
    >in Verilog source files". The best I could come up with is that
    >source_text in A.1.3 and library_text in A.1.1 don't grammatically
    >derive each other. Your view must therefor be that source_text cannot
    >share a file with library_text, correct? I didn't find this restriction
    >anywhere.

    This restriction does not have to be spelled out separately, any more
    than the rest of the meaning of the BNF notation does. It follows from
    the accepted definitions of formal language theory and the BNF notation.
    Note that there is no separate restriction saying that this email is
    not valid Verilog source either; that follows in the same way.

    A formal language is defined by a formal grammar and a start symbol.
    It consists of the set of all strings that can be derived from the
    start symbol using the grammar. The BNF in the LRM fails to specify
    the start symbol for Verilog source, though we can deduce from
    information outside the BNF that it is source_text. You could argue
    that some other start symbol should be used (thus defining a different
    language), and there is nothing in the BNF to contradict it. However,
    there is no start symbol that can be chosen that derives a string
    containing both a config and a module. Therefore we can state with
    certainty that no language defined by the BNF allows it.

    If someone wanted to define such a language, they could do so by
    modifying the BNF to specifically allow it. This BNF does not.

    You might instead be suggesting that when the syntax of a programming
    language is specified by a formal language, only a sub-string of the
    source input needs to be a valid string in the formal language. This
    is not the accepted convention, and it is easy to see why not. The
    formalism would lose its power to fully specify legal input. For
    example, any input would have to be accepted as Verilog source, since
    it contains a legal string as a sub-string (specifically, the empty
    string).

    >The keywords
    >are already part of the 2001 specification. Whether you view
    >configurations as allowable within a source file or not doesn't create
    >the problem. The problem already exists. The keywords are part of the
    >existing 1364-2001 standard.

    While I can come up with some arguments otherwise, I would have to
    agree with you that a strict interpretation of the LRM text supports
    this. All of the keywords in Annex B are reserved in both Verilog
    source files and library map files.

    >In fact, the inclusion of the configuration keywords in a
    >common list of keywords in Appendix B would seem to support the
    >conclusion that both grammars can share a common parse.

    If we move from strict interpretation to speculation, there are many
    possible conclusions. Annex B may simply contain a combined list of
    keywords from the two different source languages defined in the BNF,
    and may not intend to say that all are reserved everywhere.

    There is also a reason why you might want to reserve the library map
    file keywords in Verilog source files, even though they can never be
    used as keywords in a Verilog source file. If they are not reserved,
    then they are valid identifiers that can be used for a module name.
    However, that module name could not be referenced in a config, since
    it is a keyword there. Fortunately, it could be referenced by using
    the escaped version of the name (since in Verilog, the escaped version
    of an identifier is considered to match the non-escaped version, unlike
    VHDL). Once this is recognized, the reason for reserving the keywords
    is bypassed.

    >I'm quite sympathetic to your motivations
    >of wanting to limit keyword explosion, but this is a bit like trying to
    >close the barn door after the horses have already left, no?

    With a strict interpretation of the current LRM, I would describe the
    situation as "the barn door is open, but the horses have not left yet,
    so we can safely close it".

    Reserving a keyword can create a backward compatibility problem.
    Unreserving an unused keyword cannot.

    Every program that compiled with the keyword reserved will also compile
    with it unreserved. The only problem is that it allows programs that
    will be illegal if you reserve it in the future. But since the keywords
    were not reserved before the 2001 standard, there are already plenty of
    such programs. And having them reserved in the 2001 standard isn't really
    helping if most tools aren't enforcing it.

    So while the interpretation that configs are not allowed in Verilog
    source files does not automatically allow "config" as an identifier in
    1364-2001, it means that allowing it as an identifier in 1364-2005 would
    be backward compatible with 1364-2001.

    Steven Sharp
    sharp@cadence.com

    This archive was generated by hypermail 2.1.4 : Sat Apr 23 2005 - 15:45:47 PDT and
    sponsored by Boyd Technology, Inc.