Gordon Vreugdenhil wrote: > Just to put my own stake in the ground -- obviously having > "specialization" semantics for modules does not work for > data objects. The two concepts are simply not related. There is no data access syntax which begins with a "module specialization" node, and no one has proposed such syntax. The most one might imagine along that line of reasoning would be to use scope operator to inspect the (few) entities owned by a module specialization. Acknowledging the concept of module specialization does not prevent module instances from having unique data objects. > Having different rules for types versus > data objects would be incredibly confusing and would lead > to a huge number of questions and issues ... When type systems emerged from the primordial ooze their first essential role was to express the invariant attributes of a multiplicity of object instances. By forcing types declared by instances of a module specialization to vary based on the $instance_id - you are introducing a varying attribute where it is not otherwise needed. You're artificially adding variety which is masking some very potent underlying invariants - namely the data layouts, and source provenance of the type declaration. Were it not for this consideration, I would find your appeal to symmetry persuasive. But Ockham's razor says you've drawn more distinctions here than are logically necessary. > [Different rules for types versus data objects leads] to > serious backwards compatibility issues. I'm not seeing these issues in practical designs yet. I believe we still have time to set this definition right. The "backward compatibility" does not affect Verilog designs, so it is not the same level of sacred cow as, for example, the details of the macro preprocessor (into which numerous compatibility conundrums were introduced with no alarming results). I may be mistaken, but I think there is no synthesis engine currently implementing instance-specific structs and enums. I think they are all implementing from first principles and share this "bug" - I propose fixing the LRM to resemble what implementations are doing in the field. > I would oppose any such change. I feel the same way, I just hate to add an unnecessary cost to a system that currently works quite well and is firmly built atop the "module specialization" abstraction. Greg > Brad Pierce wrote: >> I opened Mantis 2028 about this -- >> >> http://www.eda-stds.org/svdb/view.php?id=2028 >> -- Brad >> > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Sep 10 12:12:17 2007
This archive was generated by hypermail 2.1.8 : Mon Sep 10 2007 - 12:12:25 PDT