RE: [sv-bc] RE: [sv-ec] New proposal for Mantis 0001556: in-line static variable initialization - require keyword static?

 

 

________________________________

From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Brad Pierce
Sent: Thursday, September 13, 2007 2:56 PM
To: sv-ec@server.eda-stds.org
Cc: sv-bc@server.eda-stds.org
Subject: [sv-bc] RE: [sv-ec] New proposal for Mantis 0001556: in-line
static variable initialization - require keyword static?

 

Dave,

Why is the mandatory use of the keyword 'static' considered necessary?
Users are already free to add it to their code if their own coding
methodology requires it.  There's no ambiguity about the semantics of
static variables.  

[DR] There's ambiguity in the user's intent. I've answered this question
many times before; it's for the same reason we require literals in
concatenations to be explicitly sized, don't allow 'tri reg'
declarations, require parenthesis in assignments used in expressions, as
well as a few other places; to keep them from making hard-to debug
mistakes.

Aren't users going to get confused by this rule?  They might guess that
omitting the required keyword would give them an automatic variable, but
instead they will get either an error message from a 2008 implementation
or a static variable from a 2005 implementation.

[DR] Most users are already confused by the concept of a task/function
with a static lifetime. It's counter-intuitive to every other
programming language.

Old Verilog had many static variables with initializers and no 'static'
keyword, and, even after this change, in those contexts SV still won't
require the 'static' keyword for static variables with initializers.
What's so special about these new contexts where 'automatic' would also
be legal?  Why no requirement that 'automatic' be required for an
automatic variable with an initializer if it's in a context where
'static' would be legal?

[DR] Because most users expect locally declared variables to by
automatic unless explicitly declared as static, and they expect the
initialization to happen on entry to the scope. It's illegal to have an
initialization on a static variable for synthesis, so I am talking about
testbench users only. Since class methods are by default automatic, that
leaves very few places where this might be an issue.

The SV-EC have assured that the proposed change is backward compatible,
because in old Verilog there were no initializers for the variables in
static tasks and functions.  But that only means the change is backward
compatible with old Verilog.  

Surely there are at least a few existing SV designs that are legal in
IEEE Std 1800-2005 but that would suddenly become illegal after this
change?

[DR] I don't know why any would want to do this. If this were in a
class, they probably meant 'static function logint f(byte n);' so they
are likely to get an error when they try to statically access the method
anyways.

   function static longint f(byte n);

      longint subtotal = 0;  // Illegal

      return (subtotal += n);

   endfunction

Don't get me wrong -- if it's progress, I'm for it.  I just don't see
yet why this change would be progress.

[DR] Because this will most likely be exposing a bug in the user's code.

-- Brad

 

________________________________

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Rich, Dave
Sent: Thursday, September 13, 2007 2:01 PM
To: sv-ec@eda-stds.org
Subject: [sv-ec] New proposal for Mantis 0001556: in-line static
variable initialization - require keyword static?

A new proposal has been uploaded with a new example. The example has
been split into two modules, one legal and the other illegal. All
implementation dependencies (race conditions) have been removed.

 

David Rich
Verification Technologist
Design Verification & Test Division
Mentor Graphics Corporation
dave_rich@mentor.com
Office:   408 487-7206
Cell:     510 589-2625

 


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 

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