RE: [sv-bc] changing the lifetime of begin end block

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
 

________________________________

From: owner-sv-bc@eda.org on behalf of John Michael Williams
Sent: Fri 2/12/2010 11:16 AM
Cc: sv-bc@eda.org
Subject: Re: [sv-bc] changing the lifetime of begin end block

You are right, Daniel.

On 02/11/2010 10:00 PM, Daniel Mlynek wrote:
> I think that in whole disciussion you've forget about my orginal doubt.
> Which is : is automatic lifetime defined for module should change the
> lifetime of the variable defined in begin...end blocks in always/initial
> processes?
> LRM 1800-2009 says: "The module header defines the following: - The
> default lifetime (static or automatic) of subroutines defined within the
> module"
> If this lifetime from module header should change also lifetime of variables
> from begin...end blocks then above sentence should be changed. If not then
> it is ok.
>

Whereas named blocks includes subroutines, subroutines do not
include all named blocks. So, I would say that variables in
named always blocks should ignore the "module automatic"
declaration. Assuming the LRM wording is not changed.

What I don't see is the practical value of "module automatic".
It seems contrary to object-oriented principles. One has
to keep checking the module header to be sure of how
a subroutine would behave.

To be sure, I think that regardless
of "automatic" in the header, a careful designer would now
explicitly declare subroutines "automatic" anyway, so that
reading the local code would properly describe its behavior.

This also would make subroutines portable, whereas
the module header effect makes every subroutine in the
module nonportable without individual modification.

Here's another question: Suppose I had to deal with a
module declared automatic and wanted to declare a task
which could share its local variables among several running
instances: Could I depend on using "static" exactly to
reverse the effect of "automatic"; or should I remove
"automatic" from the module header and use "automatic"
on other subroutines?

If the LRm were changed, and all module variables inherited
the module "automatic", none of my nonautomatic subroutines
would run predictably without careful (and error-prone)
attention.

My suggestion would be to disallow "module automatic" as
one of the many complexities in SystemVerilog which
make adoption of it so difficult.

--
      John Michael Williams
      Senior Adjunct Faculty
Silicon Valley Technical Institute
--
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.