From: Adam Krolnik (krolnik@lsil.com)
Date: Wed Jul 21 1999 - 08:18:46 PDT
Good morning Steve:
I would like to suggest answers/extensions to the spec for these
questions you
raise.
> 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).
Current tasks and functions have no definition for the values of
registers
from call to call. Without explicit statements, they follow other
registers
that initialize to X and hold their value until changed. I have no
preference
for the value specified. But for simplicity I would suggest they always
get
initialized to X. Leaving them uninitialized - or copied from the
previous
task would not seem to be a better answer.
> 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?
This is an interesting example. I would expect that all declared
variables within
the automatic task/function would be setup when the task is
called/enabled. This
would then imply that $display would only get executed once.
> 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.
We talked about delayed assignments such as these in the context of
static
tasks. I believe the resolution was that their effect would remain
unspecified.
We also asked the PLI task force to consider accessibility of automatic
variables by PLI (for the purposes of debugging code.)
>
> 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.
Disallow, or don't specify the behavior. I would agree disallowing these
constructs would be better than letting them get away with it.
>
> 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.
A common construct in verification is forking two processes, one doing
work,
the second a timeout check or waiting for specific events from the other
parallel block. I would like to see this functionality retained. To
remove
it limits the usefulness of automatic tasks.
>
> 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.
The task force decided that disabling an automatic task would terminate
execution
of all executing copies. Consideration of disabling a specific/single
copy was
given but not supported by the group. I would presume that disabling any
block
within an automatic function would disable all executing copies. I think
another
type of disable would be necessary to allow disabling of the current
scope
and not the scope of all executing copies.
>
> 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.
You are correct, with automatic tasks the disable statement is not a
replacement
for 'break'. There is no current replacement except for a different
coding style.
<p>Thanks for bringing up questions from an implementation standpoint.
Adam Krolnik
Verification Lead
LSI Logic Corp.
Plano TX. 75082
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:29 PDT
and
sponsored by Boyd Technology, Inc.