RE: [sv-bc] non-constant variable initializers

Steven,

I believe the intent was to say that whatever is legal for the RHS of a
procedural assignment would legal as an initializer. Otherwise, class
constructors would have to be restricted to the same rules as constant
functions. I believe the only problem lies with non-determinism. 

You could leave that as a user-beware issue, but I believe it would be
better to use rules similar to that of random stability; rely on source
code order within a module/program/interface.

Dave


> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Steven
> Sharp
> Sent: Monday, July 11, 2005 1:51 PM
> To: sv-ec@eda.org; sv-bc@eda.org
> Subject: [sv-bc] non-constant variable initializers
> 
> In the SV3.1 LRM, section 5.4 said "A variable can be declared with an
> initializer, which must be a constant expression."  The similar
statement
> in section 6.4 of the latest P1800 LRM drops that clause about being a
> constant expression.  However, both LRMs state that:
> 
> "Initial values in SystemVerilog are not constrained to simple
constants;
> they can include run-time expressions, including dynamic memory
> allocation.
> For example, a static class handle or a mailbox can be created and
> initialized by calling its new method (see 14.3.1), or static
variables
> can
> be initialized to random values by calling the $urandom system task.
This
> requires a special pre-initial pass at run-time."
> 
> Exactly what is allowed is not stated.  There are just some examples
of
> things that are definitely allowed, and the vague statement that they
> don't have to be simple constants.  The implication is still there
that
> they can't be completely arbitrary expressions either, but that is not
> really clear.
> 
> If they are allowed to be arbitrary expressions, which could refer to
> other variables, then this introduces non-determinism based on the
order
> in which the initializations are performed.  This seems undesirable.
The
> examples all avoid this, but that doesn't prove anything.
> 
> Was it intended that arbitrary expressions be allowed, with the
problem
> of non-determinism?  Or was it intended that there still be
restrictions
> to ensure determinism?  If so, these restrictions need to be clearly
> specified.
> 
> Steven Sharp
> sharp@cadence.com