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