[sv-bc] RE: [sv-ac] New keywords in SV-AC proposals

Hello Stu,

please allow me to express my possibly very subjective opinion regarding
the point you raised. See below.

Best regards,
ed


> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Stuart
> Sutherland
> Sent: Monday, March 10, 2008 6:32 PM
> To: stuart@sutherland-hdl.com; sv-bc@eda.org; sv-ec@eda.org; sv-
> cc@eda.org; sv-ac@eda.org
> Subject: RE: [sv-ac] New keywords in SV-AC proposals
> 
> Now to add my 2 cents worth of opinion...
> 
> I am very concerned about some of the proposed new keywords,
specifically:
> 
>   checker, free, global, implies, let, next, restrict, strong, until,
weak
> 
> These are common English words that are likely to be in use as
identifiers
> in existing code.  The `begin_keywords compatibility directive can
help
> for
> code that is specifically written with these keywords in mind, but
> assertions should be able to be used to verify models written in older
> versions of Verilog and SystemVerilog.  I'd like some reassurance from
> those
> that write compilers and elaborators that checker (that's the English
> "checker" word) and assertion code using these new keywords can be
used to
> verify legacy design models.
[Ed:] 
1800-2005 already introduced many new keywords which are also
potentially common words: cross, design, protected, priority, etc. Yet,
people got used to it and managed to work around the problem. Assertions
are relatively new to Verilog (or VHDL) and so their vocabulary is still
developing. The terminology is less known to people used to classical
simulation / verification. There is a choice between keeping assertions
with their keywords out, not integrated with the language, e.g., PSL, or
we can add keywords that are commonly used in temporal languages and
have assertions as an integral part of the language while running the
risk of some collisions with legacy code, in addition to those that were
created earlier. 
I think that connecting "checkers" to legacy code should be possible
using bind statements, since different parts of the model can be
compiled with different vocabularies. 

> 
> I am also mildly concerned about the use of $ as the first character
in
> new
> functions like $inferred_clock.  Is it appropriate to us a system
function
> for this functionality?  I don't have an answer...I just to make sure
the
> usage of $-type names is appropriate.
[Ed:] 
These are treated as system functions and are interpreted at compilation
/ elaboration time. There is already precedent, e.g., $bits. AT one
point there was a discussion whether new keywords should be introduced
instead (or find existing ones that would fit the purpose). However, it
was judged that system functions are a better choice.
> 
> I do not like the inconsistency of "clock" (spelled out) in some
system
> function names, and "clk" (abbreviated) in other names.  Even though I
> tend
> to use and abbreviated "clk" as part of design clock names, I would
prefer
> that the function names that are part of the language spell the full
word
> to
> ensure users know what is intended (e.g. $inferred_gclock or
> $inferred_global_clock instead of $inferred_gclk).
[Ed:] 
This is a good point. I think that the abbreviations came about to keep
the names short so that the writer does not get too tired typing long
names... 
> 
> 
> Stu
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> Stuart Sutherland
> stuart@sutherland-hdl.com
> +1-503-692-0898
> 
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> > Stuart Sutherland
> > Sent: Monday, March 10, 2008 2:07 PM
> > To: sv-bc@eda.org; sv-ec@eda.org; sv-cc@eda.org; sv-ac@eda.org
> > Subject: [sv-ac] New keywords in SV-AC proposals
> >
> > If it helps, I have culled the new keywords, operators, and system
> > task/functions in the assertions proposals under consideration for
> > P1800
> > (several of these proposals are already approved to be added in
draft
> > 5, and
> > a couple are already in draft 4).  I cannot guarantee I have found
> > every new
> > keyword, but I tried...
> >
> > accept_on            (Mantis 1757)
> > always_check         (Mantis 1900)
> > checker              (Mantis 1900)
> > checkvar             (Mantis 1900)
> > endchecker           (Mantis 1900)
> > eventually           (Mantis 1932)
> > free                 (Mantis 1900)
> > global               (Mantis 1681)
> > implies              (Mantis 1932)
> > initial_check        (Mantis 1900)
> > let                  (Mantis 1728)
> > next                 (Mantis 1932)
> > reject_on            (Mantis 1757)
> > restrict             (Mantis 1806)
> > s_always             (Mantis 1932)
> > s_eventually         (Mantis 1932)
> > s_next               (Mantis 1932)
> > s_until              (Mantis 1932)
> > s_until_with         (Mantis 1932)
> > strong               (Mantis 1932)
> > sync_accept_on       (Mantis 2100)
> > sync_reject_on       (Mantis 2100)
> > until                (Mantis 1932)
> > until_with           (Mantis 1932)
> > untyped              (Mantis 1601)
> > weak                 (Mantis 1932)
> >
> > ->                   (Mantis 1758) (same as Verilog's -> event
trigger
> > operator)
> > <->                  (Mantis 1758)
> > #-#                  (Mantis 1932)
> > #=#                  (Mantis 1932)
> >
> > $changed             (Mantis 1677)
> > $changed_gclk        (Mantis 1682)
> > $changing_gclk       (Mantis 1682)
> > $falling_gclk        (Mantis 1682)
> > $fell_gclk           (Mantis 1682)
> > $future_gclk         (Mantis 1682)
> > $inferred_clock      (Mantis 1674) (also spelled "$inferred_clk" in
> > Mantis
> > 1674)
> > $inferred_disable    (Mantis 1674)
> > $inferred_enable     (Mantis 1674)
> > $past_gclk           (Mantis 1682)
> > $rising_gclk         (Mantis 1682)
> > $rose_gclk           (Mantis 1682)
> > $stable_gclk         (Mantis 1682)
> > $steady_gclk         (Mantis 1682)
> >
> > $assertpasson        (Mantis 1361)
> > $assertpassoff       (Mantis 1361)
> > $assertfailon        (Mantis 1361)
> > $assertfailoff       (Mantis 1361)
> > $assertnonvacuouson  (Mantis 1361)
> > $assertvacuousoff    (Mantis 1361)
> >
> >
> > Dmitry's slides also mention $next_gclk.  I could not find this in
any
> > Mantis proposals.
> >
> >
> >
> > Stu
> > ~~~~~~~~~~~~~~~~~~~~~~~~~
> > Stuart Sutherland
> > stuart@sutherland-hdl.com
> > +1-503-692-0898
> >
> >
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> 
> 
> 
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.