Hi Dave,
On the contrary: The "static"
variables of a task can be extremely useful: They permit
communication among simultaneously (or even sequentially)
executing instances of the task. They permit concurrent
communication, the way semaphored functions can.
Perhaps, the default should be automatic; but, there is good
design reason to keep the verilog default as a special
case.
Also, I think "static" is the wrong "opposite" of "automatic".
Where tasks are concerned, the variables behave
exactly the way declared variables in (the same) module do,
unless automatic. Just the scope differs.
It is confusing to use "static", also, because a "static"
variable in C++ has file scope, as it should for a static
variable in a SystemVerilog class; however, declaring
a variable in a module as "static" limits the scope to
the module only.
I think it would be clearer to use some other word when
indicating that a variable was not automatic. Maybe,
"heap", or "persistent", or "nonautomatic"?
ave,
On the contrary: The "static"
variables of a task can be extremely useful: They permit
communication among simultaneously (or even sequentially)
executing instances of the task. They permit concurrent
communication, the way semaphored functions can.
Perhaps, the default should be automatic; but, there is good
design reason to keep the verilog default as a special
case.
Also, I think "static" is the wrong "opposite" of "automatic".
Where tasks are concerned, the variables behave
exactly the way declared variables in (the same) module do,
unless automatic. Just the scope differs.
It is confusing to use "static", also, because a "static"
variable in C++ has file scope, as it should for a static
variable in a SystemVerilog class; however, declaring
a variable in a module as "static" limits the scope to
the module only.
I think it would be clearer to use some other word when
indicating that a variable was not automatic. Maybe,
"heap", or "persistent", or "nonautomatic"?
Rich, Dave wrote:
> John,
>
> In Verilog, up through Verilog-2001, there was no such thing as automatic variables. Everything was static, including the arguments to tasks and functions.
>
> Verilog -2001 added automatic functions and tasks, which behave similarly to C/C++ subroutines. Unfortunately, to be backward compatible with Verilog-1995, the default storage lifetime remains static. This default continues with SystemVerilog.
>
> To add to the confusion, the default storage lifetime for task and functions declared inside classes is automatic. Do not confuse a static method of a class with a method with a static storage lifetime.
>
> In 1800-2009, tasks and functions in classes can now only have automatic lifetimes. Now that we have automatic lifetimes, it would have been great if we could have gotten rid of static lifetimes altogether, but we can't because of backward compatibility with Verilog-1995.
>
> The intent of having "module automatic" was to change the default lifetime of all blocks to automatic, to match the behavior of classes. I can't think of a reason anyone should ever declare a task or function with a static lifetime ever again.
>
> Dave
>
>
> ...
-- John Michael Williams jwill@BasicISP.net -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sat Feb 13 22:15:27 2010
This archive was generated by hypermail 2.1.8 : Sat Feb 13 2010 - 22:15:37 PST