Forward from Stu. I've uploaded the proposals in the SVDB
http://www.eda.org/svdb/bug_view_page.php?bug_id=0000328
See Attached files:
P1800_keyword_compatibility_directive_proposal.pdf
P1800_keyword_compatibility_pragma_proposal.pdf
From: "Stuart Sutherland" <stuart@sutherland-hdl.com>
To: <sv-bc@server.eda.org>
Subject: URGENT: please review updated proposal for keyword
compatibility (SV issue 328)
Date: Thu, 16 Dec 2004 22:19:53 -0800
Organization: Sutherland HDL, Inc.
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0112_01C4E3BD.5E51A6B0"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcTkABsdCOKyhuQzTLm8nzylI9O1lA==
Message-Id: <200412162219479.SM03256@WileECoyote>
X-Virus-Scanned: clamd / ClamAV version 0.74, clamav-milter version
0.74a
on server.eda.org
X-Virus-Status: Clean
This is a multi-part message in MIME format.
------=_NextPart_000_0112_01C4E3BD.5E51A6B0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
SV-BC members,
Attached is a new proposal for the keyword compatibility problem when
using
a mix of Verilog and SystemVerilog models (SV issue 328). Actually,
there
are two variations of the proposal attached.
BUT BEFORE LOOKING AND THE PROPOSALS, PLEASE READ ON...
The P1800 working group gave permission yesterday for the BC committee
to
try to complete the keywords compatibility proposal in time for the
P1800-2005 standard. The working group members generally agreed that
this
proposal solves an important need, and should be incorporated in the
standard if at all possible. Karen Pieper (SV champions chair) has
agreed
that if the SV-BC committee can approve the keyword compatibility
proposal
by the end of Monday, December 20, the champions can discuss it in their
meeting on December 21. The P1800 working group will hold a special
teleconference just after the holidays to vote on this, and a few other
proposals that are being finalized.
Towards this end, I have modified the keywords compatibility proposal to
reflect the discussion at our last two SV-BC meetings. There were two
major
concerns about the last proposal. First, should compiler directives be
used, or should invocation switches or some other mechanism be used, to
specify what set of keywords should apply to different sections of the
source code. Second, if compiler directives are used, should they have
a
source-code stream behavior or a nested (stacked) behavior.
In regards to using directives versus command line switches, there were
good
arguments given for each approach. The attached proposals provide both
approaches, directives and switches. I specifically asked the P1800
working
group if specifying command line switches in the standard would be an
issue,
since neither Verilog nor SystemVerilog have done this in the past. The
working group did not voice objections to adding a standard invocation
switch to the standard.
The invocation switch complements the compiler directives. The switch
establishes the default keyword set for one or more source files, for
when
no 'keywords directive is in effect. The combination of compiler
directives
and invocation switches will give users total control over how source
files
are interpreted by software tools. Engineers can specify this control
within
source code if desired, but by using a standard invocation switch, end
users
do not have to modify source code in order to specify what version of
keywords are to be used.
Regarding the behavior of the 'keywords...'endkeywords compiler
directives,
I have modified the proposal to specify a stacked behavior for nested
directives. My take on the recent SV-BC discussions was that most SV-BC
members seemed to feel that a stacked behavior was the better (even
necessary) choice for specifying keyword compatibility for different
portions of a design. There was not consensus on using stacked
behavior,
primarily because it is a departure from the behavior of most Verilog
compiler directives. However, it is not unlike the 'ifdef...'endif
directives, so there is some precedence to stacked behavior with
compiler
directives. IMHO, stacked behavior for 'keywords...'endkeywords is
intuitive for this usage of compiler directives, and will not confuse
users.
The difference between the two attached proposals is:
- One proposal uses `keywords...`endkeywords directives
- The other proposal uses the `pragma directive, as proposed in the
encryption proposal.
The proposal using the `pragma directive may need some background
explanation, since this directive is new. The encryption proposal (SV
issue
314) includes adding a general purpose compiler directive to the 1364
Verilog standard. This general purpose directive can be used in
different
ways. The basic usage is:
`pragma pragma_name <optional_pragma_expression>
The `pragma directive itself does not define specific semantics or
limitations. The semantics are part of the specification for specific
pragma names. Thus a specific pragma can have streaming behavior or
nested
(stacking) behavior. The pragmas specified in the encryption proposal
have
a mix of these two behaviors.
Personally, I do not have a strong preference for pragmas versus
specific
compiler directives. They work equally well for this keyword
compatibility
proposal. The `pragma directive is intended to a universal directive
that
prevents having to add more and more specialized directives to the
Verilog/SystemVerilog languages. It fits well with the keyword
compatibility proposal. My one concern about the pragma approach is
that
the definition of the `pragma directive is specified as part of the
encryption proposal for 1364. If the encryption proposal fails to make
it
into the 1364 standard, then the `pragma directive will not be available
for
the keywords compatibility proposal to use in the P1800 standard.
Matt, the ball is now in the SV-BC court to see if one of these two
keyword
compatibility proposals can be finalized, approved by the SV-BC, and
sent to
the SV champions ASAP. Thanks for the support!
Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
+1-503-692-0898
Received on Thu Dec 16 23:59:25 2004
This archive was generated by hypermail 2.1.8 : Thu Dec 16 2004 - 23:59:49 PST