RE: enhancement/350: PROPOSAL - Deprecate configs in Verilog source

From: Jayaram Bhasker (JBhasker@esilicon.com)
Date: Mon May 17 2004 - 11:10:00 PDT

  • Next message: Clifford E. Cummings: "RE: enhancement/350: PROPOSAL - Deprecate configs in Verilog source"

    The following reply was made to PR enhancement/350; it has been noted by GNATS.

    From: "Jayaram Bhasker" <JBhasker@eSilicon.com>
    To: "Steven Sharp" <sharp@cadence.com>, <etf-bugs@boyd.com>
    Cc:
    Subject: RE: enhancement/350: PROPOSAL - Deprecate configs in Verilog source
    Date: Mon, 17 May 2004 14:28:20 -0400

     Steven:
     
     Thanks for the clarification. And yes, you are right - i was objecting to the
     fact that configs have to be declared in library map files.
     
     To me, the intent of configs have been clear - allow indirect binding of instances
     (similar to VHDL).
     Also Sec 13.1 states "... a config is a design element, similar to a module, which
     exists in the Verilog namespace . .". Even though, I agree that the BNF is not complete,
     I believe the intention was to allow config declarations as part of the Verilog source.
     So a file can contain many modules, and config declarations; all
     of these design elements get compiled into a library (specified by the library map file
     for that file) and user simulates the appropriate top, could be either a config or a
     module. At least, this has been my interpretation of the LRM.
     
     Deprecating a newly added "standard" feature is not a straightforward task. I suggest:
     
     1. Retain the current functionality and fix bugs (and state limitations if any), and
     2. Suggest modeling style to write each config in a separate file (as Verilog HDL source)
        and state advantages.
     
     regards,
     - bhasker
     
     eSilicon Corporation
     1605 N. Cedar Crest Blvd, Ste 615, Allentown, PA 18104
     e-mail: jbhasker@esilicon.com, phone: 610.439.6831, fax: 610.770.9634(fax)
     
     
     
     
     -----Original Message-----
     From: Steven Sharp [mailto:sharp@cadence.com]
     Sent: Friday, May 14, 2004 5:32 PM
     To: etf-bugs@boyd.com; Jayaram Bhasker
     Subject: RE: enhancement/350: PROPOSAL - Deprecate configs in Verilog
     source
     
     
     Bhasker,
     
     First, thanks for commenting on the details of the proposal. I want to
     be sure that I'm not missing something.
     
    > If configs are limited to occur in library map files, how would configs be
     referenced
    > within configs? Is the idea not to allow a config to reference other configs?
     
     The proposal would still allow configs to reference other configs. I am
     assuming that your issue is with the library portion of the config reference,
     and how that would be specified for a config in a library map file.
     
     Note that configs were allowed in library map files already, so this issue
     was already present. Perhaps your assumption was that a config in the
     library mapping file couldn't be referenced in another config. Maybe that
     is even what was intended. The section isn't very clear.
     
     
    > In the current config definition, a config can be in a file, the file is
     compiled
    > into a library and the library.config can be referenced in another config.
     
     It was not clear to me whether this was possible in all use models (see 13.4)
     or only with separate compilation. In 13.4.4, it says that "In the
     single-pass use-models, the config can be specified by including its source
     description file on the command line. In the case where the config includes
     a design statement, then the specified cell shall be the top-level module..."
     
     Note that this description seems to assume that there is only one config in
     the source being compiled. That one config specifies the top-level cell. It
     does not seem to allow for multiple configs, since it provides no rule for
     determining which config's design rule to use for the top-level cell if there
     are multiple configs. If this is the case, then a config cannot contain a
     reference to another config in this use model.
     
     There could be extended versions of this single-pass use model that allow
     multiple configs, with one referencing others. There needs to be a rule for
     determining which is the top-level config. Perhaps this could be an implicit
     rule similar to the one for determining top-level modules. Or the tool could
     allow the top-level cell to be specified explicitly on the command line.
     
     This still leaves the issue of how to reference a config that is in the
     library mapping file being read in this invocation, i.e. what is its library
     name. That issue already existed for configs in the library mapping file.
     It just becomes more important with this proposal. I don't know whether it
     makes sense to apply the library mapping rules to the filename of the library
     mapping file itself. If not, I would expect that since none of the mappings
     were applied, the config would be considered to be in the default library,
     which is named work.
     
     Regardless, a config in a library mapping file could refer to another config
     in the same library mapping file by leaving off the library identifier. By
     section 13.3.1.1, "If the library identifier is omitted, then the library
     which contains the config shall be used to search for the cell." Regardless
     of what library the config is supposed to be in, the other config will be in
     the same library, so this should work.
     
     Now let me move on to the separate compilation use model, which is probably
     the one you were really concerned with. Here my proposal was probably
     unclear. In 13.4.4, the proposal says:
     
       In this strategy, a specified config can be obtained from the library
       mapping file, or the tool can provide a mechanism for precompiling
       configs into a library like other cells.
     
     My intent was to allow these tools to do what you described: compile the
     configs into a library so the library.config can be referenced in another
     config. The change is that the files containing these configs would not
     be Verilog HDL source files, but separate files containing configs.
     
     I think I created confusion by referring to these files as "library map
     files". I meant input files that have the syntax of a library map file
     instead of the syntax of Verilog HDL. As stated in 13.2.1, a tool shall
     provide a mechanism to read in multiple library mapping files (which means
     that the tool knows that these files contain library mapping syntax).
     Unfortunately, the name implies that their main purpose is to provide the
     library mappings for a particular invocation. But in a separate compilation
     use model with a mechanism for precompiling configs, such a file might
     contain only configs, which are being compiled into a library for later
     reference, possibly in another config.
     
     So a separate compilation use model could allow compilation of Verilog
     HDL files into the libraries, and compilation of configs (in so-called
     library mapping files) into the libraries. As stated in 13.2.1, there
     would be some tool-specific mechanism for specifying library mapping
     files, so the tool would know which it was compiling. However, 13.2.1
     implies that reading the library mapping files is a kind of set-up step
     to get library mappings before starting "real" compilation of Verilog HDL.
     This obscures the possibility that compiling the configs from the library
     mapping files into a library might be the primary purpose of this
     invocation of the tool.
     
     Does this make my intent clear? If so, does my intended meaning allow
     the capability that you were asking about (assuming that a tool supports
     this particular use model, which it was never required to do)?
     
     Is there some particular way that this could be re-worded to make the
     intent clearer?
     
     Steven Sharp
     sharp@cadence.com
     
     

    This archive was generated by hypermail 2.1.4 : Mon May 17 2004 - 11:10:07 PDT and
    sponsored by Boyd Technology, Inc.