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

From: Mark Hartoog (Mark.Hartoog@synopsys.com)
Date: Wed Apr 20 2005 - 14:10:05 PDT

  • Next message: Brad Pierce: "Re: [sv-bc] potential command line option"

    You say that you were expecting the config and verilog syntax
    to be separate, but were you expecting configurations to be
    allowed only in library mapping files?

    If you were expecting them only in library mapping files, how
    do you get a config into a logical library. As I describe in
    more detail in the attached email, the LRM says/implies:

    1) configs only appear in library mapping files.
    2) configs can be cells in logical libraries.
    3) the library map file is NOT a source file
    4) the library mapping in a libmap file applies to
    source files only.

    This leaves no mechanism for specifying how a configuration
    gets into a logical library.

    It is clear to me that configs are part of the design, and therefore
    should be in a "source file". The libmap file does not really look
    like a source file to me. It looks more like a tool/library setup file.
    I think it is a bad idea to mix tool setup information with design
    information in the same file.

    Many people interested in using configs in Verilog are coming from a vhdl
    background, where configs are part of the language and could appear in
    the same file as other vhdl. They may find it strange that Verilog has
    a separate configuration language that is only allowed in separate files,
    and I am sure they will find it strange if it is only allowed in libmap files.

    I believe the current proposal creates a separate class of source files
    for configurations, as well as allowing them in libmap files, and then
    recommends some command line options to specify to tools that the next
    file is a config source file rather than a verilog source file. Having
    to specify that extra option all the time looks inconvient to me. It means
    I cannot do something like

    <tool-name> *.v <other_options>

    You cannot even do

    <tool-name> *.v *.cfg <other_options>

    because you would need a command line option in front of every config file.

    I don't really like that.

    > Behalf Of Adam Krolnik
    > Hi Randy;
    >
    > A little history about configurations.
    >
    > The BTF originally did not combine the configuration file
    > syntax with the verilog file syntax. That was done during
    > editing of the final specification. We were expecting that
    > the configuration file syntax and keywords was separate from
    > the verilog language syntax and keyword set.
    >
    > Thanks.
    >
    > --
    > Adam Krolnik
    > ZSP Verification Mgr.
    > LSI Logic Corp.
    > Plano TX. 75074
    > Co-author "Assertion-Based Design"
    >


    attached mail follows:

    In the section on Hierarchical configurations the 1364-2001/1364-2005
    LRMs say you can specify the following mapping:

    instance top.a1.foo use lib1.foo:config;
    // bind to the config foo in library lib1

    This clearly implies that a config can be an "cell" in a library.

    The BNF only allows configs in library mapping files. How would
    you get the configs into a libraries? Would you name the library mapping
    file in the wild card patterns so that its contents would be mapped
    into the library also?

    In the section on libraries (13.2.1 in 1364-2001) it says "When parsing
    a source description file (or files), the parser shall first read the
    library mapping information from a pre-defined file prior to reading
    any source files." This implies that library mapping files are NOT
    source files.

    In the section on "Mapping source files to libraries" (13.2.3 in
    1364-2001) it says "For each cell definition encountered during
    parsing/compiling, the name of the source file being parsed is
    compared to the file path specifications of the library declarations
    in all of the library map files being used. The cell is mapped into
    the library whose file path specification matches the source file name."

    This implies that library mapping only applies to source files, and
    library map files are NOT source files. I don't see any way to get
    a configuration into a library if configurations are not allowed
    in some kind of source file.

    I think the 1364-2001 LRM is inconsistent about where configuration may
    appear. Either it was an error in the BNF that configurations can not
    appear in source files, or it was an error that configurations can be
    cells that are in libraries.

    I think we should allow configurations in libraries, so I think we should
    say it was an error in the BNF. I don't like the idea of creating two
    classes of source files, normal verilog and config, but I suppose I can
    live with that, if we have too.

    > -----Original Message-----
    > From: owner-btf@boyd.com [mailto:owner-btf@boyd.com] On
    > Behalf Of Shalom.Bresticker@freescale.com
    > Sent: Tuesday, April 19, 2005 8:18 PM
    > To: Steven Sharp
    > Cc: btf@boyd.com; etf@boyd.com
    > Subject: Re: [sv-bc] potential command line option
    >
    > Just to be fair, I should point out that IEEE rules state
    > that where the standard is ambiguous, an interpretation needs
    > to allow the most liberal interpretation. This is because the
    > content of a standard is determined by what is written there,
    > not by what was intended to be written there, and here there
    > was not even an intent at that time.
    >
    > Shalom
    >
    >
    > > It is not clear that this would be a change to what is specified in
    > > 1364-2001. The text doesn't state where configs can
    > appear, and the
    > > syntax boxes and BNF clearly specify that they cannot appear in
    > > Verilog source files. This proposal could be viewed as an official
    > > interpretation with a corresponding clarification in the
    > LRM. There
    > > has been no prior request for interpretation that would
    > conflict with
    > > this. Supporting both 1364-2001 and 1364-2005 would not
    > require different behavior.
    >
    > --
    > Shalom.Bresticker @freescale.com Tel:
    > +972 9 9522268
    > Freescale Semiconductor Israel, Ltd. Fax:
    > +972 9 9522890
    > POB 2208, Herzlia 46120, ISRAEL Cell:
    > +972 50 5441478
    >
    > [ ]Freescale Internal Use Only [ ]Freescale Confidential
    > Proprietary
    >

    This archive was generated by hypermail 2.1.4 : Wed Apr 20 2005 - 13:47:10 PDT and
    sponsored by Boyd Technology, Inc.