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

From: Steven Sharp (sharp@cadence.com)
Date: Tue Apr 26 2005 - 16:28:51 PDT

  • Next message: Steven Sharp: "Re: Config facts & Dangerous Precedent - was: potential command line option"

    Randy Misustin wrote:

    >But then again, my major concern isn't whether
    >the 2001 spec does or doesn't allow a config to appear in Verilog
    >source. My major concern is that the config keywords remain in the
    >keyword list for the upcoming 1364 specification. Whether the reason for
    >doing so is that configs are intended to be in Verilog source today,
    >whether it's to reserve that capability for the future, or whether its
    >for the frankly insightful reason you mentioned below (minus the
    >extended identifier silliness) isn't nearly as important to me (OK, I do
    >prefer the 1st but I'm pragmatic).

    Let's consider the situation if configs were not allowed in Verilog
    source, but the keywords were reserved.

    Your implementation would have a non-standard extension that was
    backward compatible with Verilog-2001 (i.e. configs in Verilog source).

    Our implementation would have a non-standard extension that was
    backward compatible with Verilog-2001 (i.e. greater backward
    compatibility with Verilog-1995).

    This might not look too bad from from both our points of view.
    However, these two non-standard extensions would be mutually
    incompatible. Neither could be standardized without the other
    extension becoming incompatible with the standard.

    From the user point of view, this looks rather like the worst of
    both worlds. I would hope we could come to a better conclusion.

    >Other messages in this thread have suggested that configs were, in fact,
    >intended to be part of Verilog source files. I guess you're arguing that
    >this was botched and, rather than fix it for the next version of the
    >spec, you'd like to drop it. Is this your position?

    More or less. We have more information about the seriousness of the
    keyword conflict than they had originally. The unintentional error in
    the BNF may provide an opportunity to respond to that, because it means
    that we don't clearly have a backward compatibility issue with the
    previous standard.

    Steven Sharp
    sharp@cadence.com

    This archive was generated by hypermail 2.1.4 : Tue Apr 26 2005 - 16:05:42 PDT and
    sponsored by Boyd Technology, Inc.