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

From: Steven Sharp (sharp@cadence.com)
Date: Wed May 19 2004 - 18:20:00 PDT

  • Next message: Michael McNamara: "Re: Minutes of BTF meeting on May 17, 2004, 11:05 AM PDT."

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

    From: Steven Sharp <sharp@cadence.com>
    To: sharp@cadence.com, etf-bugs@boyd.com, JBhasker@eSilicon.com
    Cc:
    Subject: RE: enhancement/350: PROPOSAL - Deprecate configs in Verilog source
    Date: Wed, 19 May 2004 21:40:33 -0400 (EDT)

     Bhasker,
     
    >Also Sec 13.1 states "... a config is a design element, similar to a module,
     which
    >exists in the Verilog namespace . .".
     
     The second half of this statement is misleading or wrong, since 13.1.1 talks
     about the case where a config has the same name as a module, which would not
     be possible if they existed in the same namespace. That is why I removed
     this statement in my proposal.
     
     At any rate, satisfying this statement does not require that configs be in
     the same files as modules. Modules from one kind of files (Verilog source)
     and configs from another kind of file (library mapping files) can still be
     compiled into the same design libraries. In fact, the current text already
     requires compiling configs from the non-Verilog library mapping files.
     
     
    > 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.
     
     I agree. An interpretation based solely on the LRM text might conclude
     that they are not allowed already. However, I am not trying to make such
     a legalistic argument. I believe that the intent was to allow them,
     regardless of what the BNF says. I also believe that allowing them is a
     bad idea.
     
     
    >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.
     
     Aside from having modules and config declarations in the same file, this
     proposal does not change any of that.
     
     
    >Deprecating a newly added "standard" feature is not a straightforward task.
     
     I would have thought that a newly added feature was the easiest kind to
     deprecate. It may be more embarassing, but that isn't as important as
     fixing problems.
     
     
    > 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.
     
     Suggested modeling styles don't solve the most serious problem. As long as
     configs are allowed in Verilog source files, the config keywords have to be
     reserved in Verilog HDL. That creates a serious backward compatibility
     problem for legacy Verilog code. 15% of the customer designs in our suite
     will not compile in Verilog-2001 if these particular keywords are reserved.
     If that is typical of legacy Verilog code, I think the impact on the Verilog
     user community is severe enough to justify making this change.
     
     I have pointed out other issues with this modeling style mainly to show
     that users wouldn't be losing much.
     
     Steven Sharp
     sharp@cadence.com
     

    This archive was generated by hypermail 2.1.4 : Wed May 19 2004 - 18:20:12 PDT and
    sponsored by Boyd Technology, Inc.