http://www.verilog.org/mantis/ EDA.org Mantis - ISSUES http://www.verilog.org/mantis/ http://www.verilog.org/mantis/images/mantis_logo_button.gif http://www.verilog.org/mantis/ EDA.org Mantis - ISSUES All Projects 10 hourly 1 2010-09-08T03:27:52-07:00 http://www.verilog.org/mantis/view.php?id=3197 On 2010-08-25, <a href="mailto:jf.liu@samsung.com">jf.liu@samsung.com</a> wrote:<br /> <br /> > 2. Are there any way in UPF one can specify a port which is not the<br /> > power domain interface, and insert isolation cell at this port? http://www.verilog.org/mantis/view.php?id=3197 John_Biggs <John_Biggs@example.com> http://www.verilog.org/mantis/view.php?id=3197#bugnotes http://www.verilog.org/mantis/view.php?id=3195 16.10 Local Variables<br /> This section of the LRM provides several restrictions in the flow out of local variables when the and,or, intersect operators for sequences / properties are used. However, there is a need to be able to set and read local variables in one sequence or property (the LHS), and to read those local variables in another sequence / property (RHS).<br /> See attached file http://www.verilog.org/mantis/view.php?id=3195 Ben Cohen <Ben Cohen@example.com> http://www.verilog.org/mantis/view.php?id=3195#bugnotes http://www.verilog.org/mantis/view.php?id=1183 This is a request from my Verilog-AMS contact. <br /> <br /> They would like to add a feature called mfactor for Verilog parameters. I don't fully understand this, but it involves special rules for passing parameter values down the hierarchy, with the local value being set to the locally defined value being multiplied by the value passed in, instead of replaced by it. The current mechanism they are using for this is an mfactor attribute. <br /> This is a misuse of Verilog attributes, which should not affect the language semantics. They would need to come up with a different syntax/mechanism for this. I am not sure how useful this feature would be for digital Verilog users. I am just putting this in as a placeholder for the request. http://www.verilog.org/mantis/view.php?id=1183 Steven Sharp <Steven Sharp@example.com> http://www.verilog.org/mantis/view.php?id=1183#bugnotes http://www.verilog.org/mantis/view.php?id=3166 Original Question by Dave Allen:<br /> Here is an interesting question about UPF for level shifter strategies on macro pins. Please see attached powerpoint slide (modified by RL). It has a little animation in order to show the key information first. <br /> Suppose I have a design with two domains at different voltages. <br /> The first domain contains a macro which has an output associated with the second domain's supply net. <br /> A level shifter is required between this macro's output and any receivers in the first domain. <br /> But, the macro is not within the hierarchical boundary of the second domain. We do not believe there is any way to write UPF to give a level shifter strategy for this macro output. It "may be" that a synthesizer will automatically insert a level shifter; but we do not wish to rely on this behavior.<br /> <br /> Is it possible to write a level shifter strategy for pins of a macro which are not in the domain? Is there special syntax in UPF 2.0 which makes this possible? http://www.verilog.org/mantis/view.php?id=3166 Rolf_Lagerquist <Rolf_Lagerquist@example.com> http://www.verilog.org/mantis/view.php?id=3166#bugnotes http://www.verilog.org/mantis/view.php?id=3196 The description in the set_isolation syntax table for "-instance" is a bit terse - it simple says:<br /> <br /> instance_name is a hierarchical name. <br /> port_name is a hierarchical name.<br /> <br /> It would have been more useful not to mention consistent with set_level_shifter and set_retention if it had said something like:<br /> <br /> The name of a technology library leaf cell instance and<br /> the name of the logic port that it isolates.<br /> If this instance has any unconnected supply ports, then<br /> these ports need to have identifying attributes in the<br /> cell model and the ports shall be connected in accordance<br /> with this set_isolation command.<br /> <br /> --John http://www.verilog.org/mantis/view.php?id=3196 John_Biggs <John_Biggs@example.com> http://www.verilog.org/mantis/view.php?id=3196#bugnotes http://www.verilog.org/mantis/view.php?id=1185 This is a request from my Verilog-AMS contact. <br /> <br /> This appears to be a request to allow user-defined PLI functions to be called in constant expressions. This would raise some issues because there is no way of knowing that the user-defined function is appropriate for this use (effectively, a pure function). If it isn't, this provides an easy way for the user to shoot themself in the foot. It shouldn't be too difficult to implement. http://www.verilog.org/mantis/view.php?id=1185 Steven Sharp <Steven Sharp@example.com> http://www.verilog.org/mantis/view.php?id=1185#bugnotes http://www.verilog.org/mantis/view.php?id=3188 We need a VPI property for fork and named fork block objects that would allow<br /> applications to know what type of "join" statement terminates the block, i.e. default vs. "join_none" and "join_any". http://www.verilog.org/mantis/view.php?id=3188 Chuck_Berking <Chuck_Berking@example.com> http://www.verilog.org/mantis/view.php?id=3188#bugnotes http://www.verilog.org/mantis/view.php?id=3176 The global report server does not implement the singleton properly. The get_server() method requires that an instance of the uvm_report_global_server be created.<br /> <br /> The code in src/base/uvm_report_server.svh be changed from:<br /> <br /> class uvm_report_global_server;<br /> <br /> static uvm_report_server global_report_server = null;<br /> <br /> function new();<br /> if (global_report_server == null)<br /> global_report_server = new;<br /> endfunction<br /> <br /> <br /> // Function: get_server<br /> //<br /> // Returns a handle to the central report server.<br /> <br /> function uvm_report_server get_server();<br /> return global_report_server;<br /> endfunction <br /> <br /> <br /> // Function- set_server<br /> //<br /> //<br /> <br /> function void set_server(uvm_report_server server);<br /> server.set_max_quit_count(global_report_server.get_max_quit_count());<br /> server.set_quit_count(global_report_server.get_quit_count());<br /> global_report_server.copy_severity_counts(server);<br /> global_report_server.copy_id_counts(server);<br /> global_report_server = server;<br /> endfunction<br /> endclass<br /> <br /> <br /> to<br /> <br /> <br /> class uvm_report_global_server;<br /> <br /> static uvm_report_server global_report_server = null;<br /> <br /> local function new();<br /> endfunction<br /> <br /> <br /> // Function: get_server<br /> //<br /> // Returns a handle to the central report server.<br /> <br /> static function uvm_report_server get_server();<br /> if (global_report_server == null)<br /> global_report_server = new;<br /> return global_report_server;<br /> endfunction <br /> <br /> <br /> // Function- set_server<br /> //<br /> //<br /> <br /> static function void set_server(uvm_report_server server);<br /> if (global_report_server != null) begin<br /> server.set_max_quit_count(global_report_server.get_max_quit_count());<br /> server.set_quit_count(global_report_server.get_quit_count());<br /> global_report_server.copy_severity_counts(server);<br /> global_report_server.copy_id_counts(server);<br /> end<br /> global_report_server = server;<br /> endfunction<br /> endclass http://www.verilog.org/mantis/view.php?id=3176 Janick Bergeron <Janick Bergeron@example.com> http://www.verilog.org/mantis/view.php?id=3176#bugnotes http://www.verilog.org/mantis/view.php?id=2571 In 16.15.6 in Draft 8-preliminary, the rules for clock inference confuse some people. See the thread beginning <a href="http://www.eda-stds.org/sv-sc/hm/0874.html">http://www.eda-stds.org/sv-sc/hm/0874.html.</a> [<a href="http://www.eda-stds.org/sv-sc/hm/0874.html" target="_blank">^</a>]<br /> <br /> The text says,<br /> <br /> "A clock shall be inferred for the context of an always or initial procedure that satisfies the following requirements:<br /> ...<br /> 3) Within the event control of the procedure, there is exactly one event expression that satisfies both of the following conditions:<br /> a) The event expression is of the form edge_identifier expression1 [ iff expression2 ] and is not a proper subexpression of an event expression of this form.<br /> b) No term in expression1 appears anywhere else in the body of the procedure."<br /> <br /> Requirement 3 can be misinterpreted to mean that the event control contains only one event expression and it must satisfy 3a and 3b.<br /> <br /> The correct interpretation is that the event control may contain more than one event but only one that satisifies 3a and 3b.<br /> <br /> The requirement could be reworded like this:<br /> "One and only one of the event expressions within the event control satisfies both of the following conditions:"<br /> <br /> Another, more minor, ambiguity is that the form "@(e1 or e2)" can be regarded as containing two event expressions, "e1" and "e2", or one event expression, "e1 or e2". The first interpretation is what is intended here. This ambiguity is less likely to confuse people, though, and is also more difficult to disambiguate. http://www.verilog.org/mantis/view.php?id=2571 shalom <shalom@example.com> http://www.verilog.org/mantis/view.php?id=2571#bugnotes http://www.verilog.org/mantis/view.php?id=2205 Stu raised the following issue about $asseroff and $assertkill tasks:<br /> <br /> "Do the $assertoff and related assertion controls and assertion action<br /> controls only affect "assert" directives, or do they also affect<br /> "assume", and "cover" directives? What about immediate assertions?"<br /> <br /> The description in the LRM is ambiguous, need to provide a clarification. http://www.verilog.org/mantis/view.php?id=2205 Dmitry Korchemny <Dmitry Korchemny@example.com> http://www.verilog.org/mantis/view.php?id=2205#bugnotes http://www.verilog.org/mantis/view.php?id=3194 Whilst the other values of 'location' define where in the hierarchy (domain or logical?) the cells should be inserted the value 'sibling' does not seem to.<br /> <br /> "sibling—a new sibling is created into which the isolation cells are placed."<br /> <br /> 1. This infers that new hierarchy is created to store the cells of this strategy but where should this reside? Should we assume the location for this new hierarchy is derived from automatic location or something else?<br /> <br /> 2. This probably depends on the answer to #1 but is one sibling used per strategy or per domain?<br /> <br /> 3. Should 'sibling' be entered in 3.1 Definitions?<br /> <br /> Location sibling is also used in 6.41 and 6.42. http://www.verilog.org/mantis/view.php?id=3194 Jon Worthington <Jon Worthington@example.com> http://www.verilog.org/mantis/view.php?id=3194#bugnotes http://www.verilog.org/mantis/view.php?id=1477 The information model for virtual interfaces should be changed. I think that it does not model accurately what virtual interfaces are. When I wrote the information model for virtual interfaces, I did not completely understand what<br /> they were.<br /> <br /> Today virtual interfaces are modelled as refObj (reference objects). I think that a better model would be to model them as variables with a datatype:<br /> virtualInterfaceTypespec. Moreover you can declare a type definition for a virtual interface datatype:<br /> <br /> typedef virtual SyncBus VIT;<br /> <br /> This declared a datatype "VIT" for a virtual interface of name SyncBUs.<br /> <br /> You can even create an array of virtual interfaces, or have a virtual interface type be a member of a struture data type.<br /> <br /> I am proposing the following:<br /> <br /> virtual interfaces are merely variables with a datatype which get assigned during simulation. These variables can be declared anywhere a variable can be declared except in a static interface or in a union data type or as a port.<br /> <br /> In diagram 27.12 (refObj):<br /> remove 4th bullet of Note 1: a virtual interface declaration in a class definition<br /> <br /> Remove note 4 about the vpiVirtual property.<br /> <br /> Remove example 2 in section 27.12.1 or better modify example 2 and move it to section 27.17.<br /> <br /> Add vpiVirtual property to variables diagram 27.14<br /> <br /> In the header file, remove vpiInterfaceDecl iteration.<br /> <br /> in the typespec diagram (27.17), add a virtualInterfaceTypespec class, with a paramAssign iteration. This is in order to model virtual interfaces declarations with parameters:<br /> <br /> interface SyncBus #( p = 0, q = 1);<br /> endinterface<br /> <br /> <br /> typedef virtual #(1, 2) SyncBus VIT;<br /> <br /> <br /> In the class diagram (27.21 and 27.22) remove the iteration on vpiInterfaceDecl which returns refObj. A virtual interface declaration will now be returned as a class member through the vpiVariables iteration.<br /> <br /> In 27.21 remove note 6,<br /> In 27.22 remove note 5 http://www.verilog.org/mantis/view.php?id=1477 Françoise Martinolle <Françoise Martinolle@example.com> http://www.verilog.org/mantis/view.php?id=1477#bugnotes http://www.verilog.org/mantis/view.php?id=3192 Section 37.8 (Interface task or function declaration), detail #2 indicates vpiAccessType has values vpiForkJoin and vpiExtern. These value defines were changed to vpiForkJoinAcc and vpiExternAcc, respectively, in the sv_vpi_user.h header file for 2009 to avoid related conflicts. This detail should be fixed to be consistent. http://www.verilog.org/mantis/view.php?id=3192 Chuck_Berking <Chuck_Berking@example.com> http://www.verilog.org/mantis/view.php?id=3192#bugnotes http://www.verilog.org/mantis/view.php?id=3193 The built-in class types are indicated by the vpiClassType property which can be accessed for class typespecs (see 37.28).<br /> <br /> Section 9.7 ("Fine-grain process control") defines a "process" class type that is not represented in the vpiClassType property values defined in the header file.<br /> <br /> A value for this built-in type needs to be added to the values for this property.<br /> - CB http://www.verilog.org/mantis/view.php?id=3193 Chuck_Berking <Chuck_Berking@example.com> http://www.verilog.org/mantis/view.php?id=3193#bugnotes http://www.verilog.org/mantis/view.php?id=2845 The virtual interface datatype equivalence type check with an interface type is only defined in terms of the values and types of the top level parameters of the interface. This is not sufficient as defparam are allowed to target parameters defined inside the interface which are not top level parameters. Hence the defparam could change the "structure" of the interface. An interface can also contain sub instances which could be defparam targets.<br /> <br /> I think that the definition of type equivalence and assignment compatibility are incorrect in the presence of defparams. So we have 2 alternatives:<br /> 1. enhance the definition of VIFC type equivalence to take into account parameters inside the interface which are defparam'd<br /> <br /> 2. Make a defparam to inside an interface or to any of the interface sub-instances an error when that interface is assigned to a virtual interface. http://www.verilog.org/mantis/view.php?id=2845 Françoise Martinolle <Françoise Martinolle@example.com> http://www.verilog.org/mantis/view.php?id=2845#bugnotes http://www.verilog.org/mantis/view.php?id=3179 when the following paths are included and the following packages are compiled it crash due redefinition of macros.<br /> <br /> incdir:<br /> $UVM_HOME/src<br /> $OVM_HOME/src<br /> <br /> packages:<br /> $UVM_HOME/src/uvm_pkg.svh<br /> $OVM_HOME/src/ovm_pkg.svh<br /> <br /> <br /> it shows messages like:<br /> <br /> ovm-/2.1.1/src/ovm_macros.svh, 32<br /> Text macro (_protected) is redefined. The last definition will override<br /> previous ones.<br /> In uvm-/1.0ea/all/src/uvm_macros.svh, 28, it was defined as<br /> protected<br /> <br /> ovm-/2.1.1/src/macros/ovm_object_defines.svh, 2831<br /> Text macro (DOREFERENCECOPY) is redefined. The last definition will override<br /> previous ones.<br /> In uvm-/1.0ea/all/src/macros/uvm_object_defines.svh, 2663,<br /> was defined as if( (FLAG)&UVM_REFERENCE))<br /> ARG = local_data__.``ARG;<br /> <br /> ovm-/2.1.1/src/macros/ovm_object_defines.svh, 2858<br /> Text macro (DODEEPCOPY) is redefined. The last definition will override<br /> previous ones.<br /> In uvm-/1.0ea/all/src/macros/uvm_object_defines.svh, 2690, <br /> it was defined as begin<br /> uvm_object this_d__, from_d__;<br /> if(tmp_data__ != null)<br /> if(!$cast(local_data__, tmp_data__)) begin<br /> uvm_object::m_sc.scratch1 = `"Cast failed for argument: ARG`";<br /> end<br /> if(ARG != null) $cast(this_d__,ARG);<br /> if(local_data__.ARG != null) $cast(from_d__,local_data__.ARG);<br /> <br /> if((this_d__==null) && (from_d__!=null)) begin<br /> this_d__ = from_d__.clone();<br /> this_d__.set_name(`"ARG`");<br /> end<br /> else if(from_d__ == null)<br /> this_d__ = from_d__;<br /> else begin<br /> this_d__.copy(from_d__);<br /> end<br /> if((this_d__ == null) || !$cast(ARG, this_d__)) begin<br /> uvm_object::m_sc.scratch1 = `"Cast failed for ...<br /> <br /> <br /> ovm-/2.1.1/src/macros/ovm_object_defines.svh, 2890<br /> Text macro (DOSHALLOWCOPY) is redefined. The last definition will override<br /> previous ones.<br /> In uvm-/1.0ea/all/src/macros/uvm_object_defines.svh, 2722, it<br /> was defined as if( (FLAG)&UVM_SHALLOW)<br /> begin<br /> uvm_object lhs__, rhs__;<br /> uvm_object::m_sc.scratch1 = `"Executing shallow copy of arg ARG`";<br /> <br /> <br /> if(ARG2==null) ARG1 = ARG2;<br /> else begin<br /> if(ARG1 != null) $cast(lhs__, ARG1);<br /> if(ARG2 != null) $cast(rhs__, ARG2);<br /> if(rhs__!=null && lhs__!=null)<br /> lhs__.copy(rhs__);<br /> else if(rhs__ != null) begin<br /> $cast(lhs__, rhs__.clone());<br /> if (lhs__ != null)<br /> $cast(ARG1, lhs__);<br /> end<br /> else<br /> ARG1 = null;<br /> <br /> end<br /> end<br /> else<br /> begin<br /> uvm_object::m_sc.scratch1 = `"Shallow copy off for arg ARG`";<br /> end http://www.verilog.org/mantis/view.php?id=3179 Edgar Jimenez <Edgar Jimenez@example.com> http://www.verilog.org/mantis/view.php?id=3179#bugnotes http://www.verilog.org/mantis/view.php?id=3175 Users need a way to control whether or not a report is enabled that is beyond the 'simple' verbosity setting.<br /> <br /> One key requirement (of many) that this would provide is ability to cause messages of a particular 'ID' to be emitted regardless of the 'verbosity' setting. http://www.verilog.org/mantis/view.php?id=3175 John Fowler <John Fowler@example.com> http://www.verilog.org/mantis/view.php?id=3175#bugnotes http://www.verilog.org/mantis/view.php?id=2751 pg 415 "Unlike modules, interfaces, and programs, checker formal arguments may not be connected to interfaces."<br /> <br /> [Ben] Why this restriction? The interface is one of the beauty of SystemVerilog. Are we saying that the following is illegal?<br /> interface fifo_if(..); modport fslave_if_mp (..); .. endinterface : fifo_if<br /> <br /> checker fifo_chker (logic clk, fifo_if.fslave_if_mp f_if, ...);<br /> property p_t1_full; @ (posedge clk) <br /> property p_push_error;<br /> @ (posedge clk)<br /> not (f_if.push && f_if.full && f_if.pop);<br /> endproperty : p_push_error<br /> ap_push_error : assert property (p_push_error);<br /> <br /> endchecker <br /> <br /> If the rationale is that interfaces can have outputs and outputs are illegal in checkers, then we can restrict the usage in that in checkers, all elements of an interface can only be read and not assigned regardless of the direction of the elements in the interface. <br /> <br /> Without the access to interfaces in formal arguments, we lose a lot. That would mean that every element of the interface would have to be added to the port list, unless we want to use hierarchical references. Thus, if an interface with 100 signals, instead of passing that interface as a name, one would have to enter 100 elements in the formal arguments of the checker! That defeats the use of interfaces!!!! http://www.verilog.org/mantis/view.php?id=2751 Ben Cohen <Ben Cohen@example.com> http://www.verilog.org/mantis/view.php?id=2751#bugnotes http://www.verilog.org/mantis/view.php?id=2476 A clarification is needed what can the argument type of system functions $onehot, $onehot0, $isunknown and $countones be and where these functions may be used - in assertions only or everywhere in expressions. http://www.verilog.org/mantis/view.php?id=2476 Dmitry Korchemny <Dmitry Korchemny@example.com> http://www.verilog.org/mantis/view.php?id=2476#bugnotes http://www.verilog.org/mantis/view.php?id=2770 Scenario:<br /> We are creating an IP. <br /> The IP uses only supply set handles during synthesis.<br /> We use connect_supply_set to auto connect supply set handle h_sram_supply function f_sram_array_power to all cells with pg_TI_sram_array_power.<br /> Supply sets will be created during SoC assembly and/or physical implementation.<br /> <br /> 1) Create supply set handle h_sram_supply<br /> create_power_domain PD1 -supply h_sram_supply<br /> <br /> 2) Does below create the sram_array_power function?<br /> connect_supply_set PD1.h_sram_supply -connect {f_sram_array_power pg_TI_sram_array_power}<br /> <br /> 3) When does supply function error checking occur?<br /> <br /> Assuming: associate_supply sram_supply_set -handle PD1.h_sram_supply<br /> Are the following statements true:<br /> a) It is an error if supply_set does not contain all the functions defined the supply set handle<br /> b) It is an not an error if supply_set contains additional functions which are not part of the supply set handle functions http://www.verilog.org/mantis/view.php?id=2770 Rolf_Lagerquist <Rolf_Lagerquist@example.com> http://www.verilog.org/mantis/view.php?id=2770#bugnotes http://www.verilog.org/mantis/view.php?id=3165 (On behalf of Qi)<br /> In UPF2.0, set_isolation has -force_isolation.<br /> How to avoid implementation tools insert duplicated isolation cells<br /> as the semantics seems that -force will just force the tool to insert. <br /> Imagine I use a UPF to synthesize. <br /> After that the P&R tool will read in the netlist and UPF with the same set_isolation, P&R will insert again per semantics right? am I missing anything here? thanks http://www.verilog.org/mantis/view.php?id=3165 Rolf_Lagerquist <Rolf_Lagerquist@example.com> http://www.verilog.org/mantis/view.php?id=3165#bugnotes http://www.verilog.org/mantis/view.php?id=3182 Hi,<br /> If we have wired logic where the drivers are originating in different domains and are of different drive strengths and this signal needs isolation,then:<br /> <br /> 1. What is the expected output from synthesis?<br /> 2. What is the expected strength of the final isolation signal?<br /> 3. Does the same apply to level shifters?<br /> <br /> Does the standard this specific issue?<br /> <br /> thanks<br /> prasad http://www.verilog.org/mantis/view.php?id=3182 Prasad Subbarao <Prasad Subbarao@example.com> http://www.verilog.org/mantis/view.php?id=3182#bugnotes http://www.verilog.org/mantis/view.php?id=3191 Currently sequence methods are allowed with named sequences only, not with sequence expressions. E.g.,<br /> <br /> sequence s; a ##1 b; endsequence<br /> ...s.triggered is legal<br /> <br /> whereas (a ##1 b).triggered is illegal.<br /> <br /> The proposal is to allow using sequence methods with any sequence expressions since the existing limitation is not natural.<br /> <br /> See also 17.9 Complex checker example, which does not impose any limitations on checker arguments start_event and end_events. http://www.verilog.org/mantis/view.php?id=3191 Dmitry Korchemny <Dmitry Korchemny@example.com> http://www.verilog.org/mantis/view.php?id=3191#bugnotes http://www.verilog.org/mantis/view.php?id=1706 What is the static prefix of a reference that includes a virtual interface? This impacts both sensitivity determination and decisions about procedural and continuous drivers. For example:<br /> <br /> interface intf;<br /> int x = 0;<br /> <br /> initial #1 x = 1;<br /> endinterface<br /> <br /> class C;<br /> static virtual intf i;<br /> endclass<br /> <br /> module top;<br /> int x = 1;<br /> intf i();<br /> initial C::i = i;<br /> <br /> always_comb x = C::i.x;<br /> <br /> initial $monitor($time,,x);<br /> endmodule<br /> <br /> The normal intent of longest static prefix is that you notice *at least* all the changes that you might need to see. For a virtual interface this might boil down to needing to be sensitive to *any possible* interface instance that is type compatible with the virtual interface. <br /> <br /> Similarly with procedural/continuous assignment compatibility, whether conflicts occur depends on how virtual interfaces are interpreted.<br /> <br /> The easiest solution would likely be to state that virtual interfaces "don't count" in terms of the procedural/continuous driver determination and that they can't be used in constructs such as always_comb.<br /> I'm not sure that is a reasonable solution.<br /> <br /> This overlaps with SV-BC in terms of the "static prefix" rules, but since this is tied to virtual interfaces, I've assigned this to EC for initial discussion of desired intent. http://www.verilog.org/mantis/view.php?id=1706 gordonv <gordonv@example.com> http://www.verilog.org/mantis/view.php?id=1706#bugnotes http://www.verilog.org/mantis/view.php?id=2080 See discussion in:<br /> <a href="http://www.eda-stds.org/sv-ec/hm/4852.html">http://www.eda-stds.org/sv-ec/hm/4852.html</a> [<a href="http://www.eda-stds.org/sv-ec/hm/4852.html" target="_blank">^</a>]<br /> <br /> The basic problem is the "::" can be interpreted as both scope resolution and type referencing. This needs to be clarified. http://www.verilog.org/mantis/view.php?id=2080 gordonv <gordonv@example.com> http://www.verilog.org/mantis/view.php?id=2080#bugnotes