Re: [sv-ec] static initialization order fiasco

Symons, Tom H wrote:

> Thanks Gord,
> 
> To clarify
> 
> Are class objects that are declared and new'ed directly in a module
> (i.e. NOT in an intial block) constructed before time zero?  Or, more
> specifically, before any intial blocks are executed?  Or does the
> constructor execute as if it was in its own initial block ?


P1800, 6.4 states:
    In SystemVerilog, setting the initial value of a static variable as
    part of the variable declaration (including static class members) shall
    occur before any initial or always blocks are started.

There are no guarantees regarding the relative ordering of design units
(or even packages).

So given:

    package pkg;
      class C;
      endclass
      C obj_p = new;
    endpackage

    module top;
      import pkg::*;
      C obj = new;
      C obj2;
      C obj3 = obj_p;

      initial obj2 = obj;
    endmodule

    module top2;
       import pgk::*;
       C obj3 = top.obj;
    endmodule

The only thing that you are guaranteed is that  obj2 will have the non-null
value of obj.

You have no guarantees the obj_p will be constructed before obj3 reads
it.  You have no guarantees that obj is constructed before obj3 reads it.
You *are* guaranteed to get a null if such constructions have not yet
occurred.

Gord.


> 
> Thanks for the help
> Tom Symons
> 
> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
> Sent: Tuesday, April 18, 2006 9:48 AM
> To: Symons, Tom H
> Cc: sv-ec@server.eda.org
> Subject: Re: [sv-ec] static initialization order fiasco
> 
> 
> 
> Symons, Tom H wrote:
> 
> 
>>So is this a problem with classes in SystemVerilog like it is with C++
> 
> ?
> 
> Yes.
> 
> 
>>This is that bummer where A's constructor references B, where A and B 
>>are defined in different files and so their construction order is 
>>indeterminate.  If B is constructed first, no problem, if not, ka
> 
> boom. 
> 
>> Worse yet, it might work at first, but then fail when
> 
> something/someone 
> 
>>unrelated changes the construction order.
> 
> 
> SystemVerilog does not provide any guarantees about initialization
> ordering between design units.
> 
> 
>>I was wondering if there were some initialization differences in
> 
> Verilog 
> 
>>that may have possibly eliminated this problem?
> 
> 
> Not really.
> 
> 
>>It seems like it could be much worse with SystemVerilog than C++ since
> 
> 
>>any object declared in a module and constructed in time zero is very 
>>much like a static object constructed in C++, yes ?  
> 
> 
> Kind of.  "time zero" is a pretty wide time frame in SV.  All
> of the elaboration time activity (parameter evaluation, etc)
> is already done before any "time zero" activitiy occurs.  Initiailizers
> in elaborated declarations is done "first" (before time zero or
> at the beginning but before any processes become sensitive).  Then
> the "time zero" activity related to continuous assigns, always_comb,
> initial blocks, etc. are all kicked off.  This is a pretty dynamic
> initialization sequence.
> 
> 
>  > Maybe even more so
> 
>>since we like to 'netlist' even our testbench components together at 
>>time zero.
> 
> 
> The thing to realize here is that "real" design topology (module
> connectivity, etc) is an *elaboration* time activity while
> "time zero" activity is later and can be more dynamic.  This
> places more of the sequencing requirements in the hands of
> the user while at the same time freeing the user from some
> of the more strict constantness requirements of elaboration
> time port connectivity.
> 
> 
>>And what about virtual interfaces ?  Could a class with an interface 
>>argument to its constructor possibly be constructed before the
> 
> interface 
> 
>>and be left with a null interface pointer? I assume also that the same
> 
> 
>>thing occurs with class pointers that are passed in as constructor 
>>arguments.
> 
> 
> For this situation, I don't think you can get into trouble.
> 
> Interfaces are *instantiated* meaning that their construction is
> an elaboration time activity and is guaranteed to preceed class
> object construction.  So there is no way to express a
> "null" interface and thus no way to pass an unconstructed
> interface into a class for a virtual interface.  So, a
> virtual interface will be null prior to object construction,
> but if you are providing an interface during construction,
> you are guaranteed that the interface will exist and that
> the virtual interface will end up being non-null.
> 
> 
> 
>>What's the recommended solution ?  Same as C++, or just strip down the
> 
> 
>>constructors, or ???
> 
> 
> I would probably do what you would do in C++ -- don't rely on
> cross-package (cross design unit) initialization assumptions.
> 
> You can rely on initialization to null for class handles so feel
> free to assume that.  You likely want to have complex class
> initialization be driven from a testbench initial block or from
> a single constructor call that "assembles" the system (again,
> only relying on null for the initial states of handles).
> 
> I hope this helps.
> 
> Gord.
> 
> 
> 
>>Thanks
>>
>>Tom Symons
>>
>> 
>>
> 
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com