From: Steven Sharp (sharp@cadence.com)
Date: Mon Jul 19 1999 - 13:23:20 PDT
Here are some other problems and unspecified behavior for re-entrant tasks
and functions.
<p>1. What is the value of an automatic variable that has not been written
before it is read? Is it initialized to X, or is its value not defined by
the standard (i.e. whatever garbage got left in that memory).
<p>2. If automatic variables get initialized to X, when does it happen? Suppose
there is a named block inside an automatic task that declares an automatic
variable. Does the variable get initialized to X once when the task is
invoked, or does it get re-initialized every time execution enters the
named block? Example:
task automatic foo;
integer i;
begin
for (i = 0; i < 10; i = i + 1)
begin: bar
reg r;
if (r === 1'bx)
$display("initialized to X");
r = 1'b0;
end
end
endtask
How many times should the message be printed, 1 time or 10 times?
<p>3. There are problems due to the limited lifespan of automatic variables
(which include the ones for argument passing and function return values).
There are other features in the language that were defined with the
assumption that all data objects are static. It is possible for a task to
create subprocesses that read or modify data objects and which survive
longer than the task invocation (and therefore the data objects if they are
not static). Examples of such subprocesses include non-blocking assignments
to automatic regs, non-blocking assignments with intra-assignment event
controls waiting on automatic regs, procedural continuous assignments to
automatic regs, and procedural continuous assignments or procedural force
statements that reference an automatic reg on the right-hand side. This
problem would also arise if system tasks such as $monitor or $dumpvars
were called with an automatic variable as an argument.
The simplest solution is to disallow automatic variables in these situations.
It is rather ugly to have to disallow them for arguments to some system tasks
while allowing them for others, but it can certainly be done.
<p>4. What happens with $dumpvars and other system tasks that can act on all
objects within a scope? Are automatic variables excluded from these? It
would be simplest if they were.
<p>5. Is it legal to wait on an automatic variable (e.g. "@(posedge i)")?
This is painful to implement. It also has limited usefulness, since only
a sibling process created by fork/join in the same activation can alter the
value of the variable while this process is waiting on it.
<p>6. Automatic tasks can be disabled. What about named blocks within automatic
tasks? The proposal disallows hierarchical references to automatic items,
but it is not clear whether this includes named blocks.
<p>7. Extrapolating from the proposal, disabling a named block in an automatic
task from inside that block will not behave like a C break statement. It
will disable all active processes presently in that block. This is how
static tasks behave, but they aren't expected to behave sanely with
re-entrant calls.
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:29 PDT
and
sponsored by Boyd Technology, Inc.