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 ? 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.comReceived on Tue Apr 18 11:34:20 2006
This archive was generated by hypermail 2.1.8 : Tue Apr 18 2006 - 11:34:28 PDT