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.