Re: [sv-ec] Errata: join_none and automatic variable lifetimes

Steven,

This issue you bring up was resolved by errata # 4:

    http://www.eda.org/sv-ec/Errata/ERR_4.pdf

Specifically, section 5.5 defines the lifetime of automatic variables declared
within fork/join blocks to be the union of the lifetime of all the subprocesses
spawned by that block. This definition removes the need for the restriction
that you bring up in your message. The Verilog-2001 limitations regarding
access to automatic variables continue to apply (e.g., access automatic
variables via hierarchical references is not allowed).

    Arturo

----- Original Message -----
From: "Steven Sharp" <sharp@cadence.com>
To: <sv-ec@eda.org>
Sent: Friday, August 20, 2004 3:09 PM
Subject: [sv-ec] Errata: join_none and automatic variable lifetimes

I thought that this had been discussed in committee, but apparently nothing
was ever done about it.

The join_any and join_none constructs can create subprocesses while allowing
their parent process to continue running. If they are used inside an
automatic task or function (or other scope with automatic variables in SV),
the subprocess may last longer than the lifetime of the automatic variables.
This creates a problem if the subprocess tries to access one of these
automatic variables.

Since the SV 3.1a LRM says nothing special about this situation, presumably
the Verilog-2001 rules apply. These rules state that automatic variables
shall not be used in constructs that might refer to them after they have
been deallocated. While SV join_any/join_none subprocesses are obviously not
explicitly listed among the examples of such constructs in the 1364-2001 LRM,
the general rule would still apply. So a join_any/join_none subprocess would
not be allowed to refer to an automatic variable from a scope outside the
subprocess.

However, this restriction is not explicitly mentioned in the SV 3.1a LRM,
and probably is not obvious to everyone. And when it was brought up earlier,
there were some people who did not like this restriction. I don't know
the outcome of that discussion, because there is nothing about it in the
LRM. This needs to be clarified in the LRM.

Steven Sharp
sharp@cadence.com
Received on Sun Aug 22 09:51:46 2004