From: Michael McNamara (mac@surefirev.com)
Date: Wed Jul 21 1999 - 11:37:23 PDT
Steve, Adam:
A useful organizing assumption for the consideration of
automatic variables is to consider what people do today.
The goal with automatic variables is to make it much easier to
write more of the test bench in Verilog, rather than in C or C++.
The goal is not to get design compiler to build stacks, and
implement malloc in silicon.
<p>Adam Krolnik writes:
>
> 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.
Let us ask ourselves, what would C do?
Answer: C has the variable's value undefined until written to.
This would support us setting them to X upon entry to the scope where
the variable is declared. This would also support us simply
allocating memory from a stack, and leave the variables with whatever
value they might have from previous usages of that stack.
>
> > 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.
What would C do: Answer: upon entry to a scope where the
variable becomes accessable, stack space is allocated, and hence the
initial value is determined. (either set to X or left with whatever
was at that stack location).
>
> > 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.
I agree with disallowing use of automatic variables in each of these
usages. Already certain types of variables are disallowed by XL as
arguments to $monitor ( at least when used with certain % format
characters).
>
> >
> > 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.
>
>
> 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.