Subject: [sv-bc] defparam
From: Karen Pieper (Karen.Pieper@synopsys.com)
Date: Sat Aug 23 2003 - 08:08:37 PDT
I'm forwarding bounced mail from Guillermo Maturana <maturana@sbcglobal.net>]
K
>In the 3.1 LRM under 25.2, first paragraph it says "The defparam
>statement does
>not provide a capability that can not be done by another method, ...".
>
>I think this is incorrect: I don't think it is possible to override
>parameters
>declared in subscopes of a module this way, as in the following somewhat
>contribed example:
>
>module a;
>parameter p;
>task t;
>parameter p;
>begin :n
>parameter p;
>end
>endtask
>endmodule
>
>I don't think instance overrides can cause t.p or t.n.p to be overriden.
>
>Of course a module could have parameters in arbitrarily nested named blocks.
>The named parameter overrides can only refer to the module level parameters,
>but they are incapable of overriding parameters in nested scopes.
>
>One solution to this would be to extend the name to be full hierarchical
>name
>of parameters in any subscope, with a single '.' representing the module
>level,
>and successive tokens refering to the path to any subscope.
>
>So for the example above, an instance a1 of a one could override "p" at
>top level, "p" under task t, and "p" under task t's named block n as
>follows:
>
>a #(.p(1), .t.p(2), .t.n.p(3)) a1;
>
>Oh well, I don't like defparams either, but without some way to override
>nested parameters the argument in 25.2 is not solid.
>
> _Matute
This archive was generated by hypermail 2b28 : Sat Aug 23 2003 - 08:09:47 PDT