Jonathan Bromley wrote: [...] > For clarity: when I say "upwards defparam" I mean defparams > that affect sibling or ancestor modules. There's a common > and useful case where hierarchy-wide defparams are located > in an annotation or configuration module which is then > elaborated at the top level; I suppose that, strictly > speaking, every defparam in such a module is an upwards > reference, since its name search must float upwards from > the top-level annotation module to find the main > simulation hierarchy. I don't really see that as an > upwards defparam, although I suspect it would be rather > hard to capture the distinction in a language standard. > In any case, it could trivially be worked around by > instantiating the main top-level within the annotation > module, which I suppose is somewhat like the way a > VHDL configuration works. Since SV has the concept of $root, it might be perfectly reasonable to say that any defparam whose left hand side is an upwards hierarchical reference shall be treated as though it were prefixed by $root. That doesn't quite eliminate the upwards issues since name resolution allows one to get into upwards resolution mid-name but that is resolvable if we want to. Although I have a philosophical appreciation of the "defparams should be removed" approach, I don't think that is viable due to both legacy designs and just basic usefulness of the model. Certainly an implementation would have a tough battle if it removed defparam support. Given that, I am very hesitant to shut our eyes to this reality as implementations will likely diverge in terms of various interactions. Gord -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.comReceived on Thu Jun 15 07:31:48 2006
This archive was generated by hypermail 2.1.8 : Thu Jun 15 2006 - 07:31:53 PDT