From: Pragmatic C Software (sjmeyer@pragmatic-c.com)
Date: Mon Aug 13 2001 - 06:03:23 PDT
Quoting Shalom Bresticker (Shalom.Bresticker@motorola.com):
<snip - some irrelevant stuff>
>
> By the way, when I read the standard, I understood the meaning to
> allow a defparam from one iteration of the generate loop to another iteration,
> and not as Steven Sharp wrote.
> If that was not the intention, it has to be rewritten.
>
>
> > >I definitely agree that defparams are not a good.
>
> I partly disagree.
>
> I think defparams have a place.
>
> First of all, if I am not mistaken, they allow a capability not easily achievable otherwise.
> See the following example:
>
> module B ();
> parameter P = 0 ;
> endmodule
>
> module A () ;
> B B ;
> endmodule
>
> module top ;
> A A1 ;
> A A2 ;
> defparam A1.B.P = 1 ;
> defparam A2.B.P = 2 ;
>
> A instantiates B.
> A is itself instantiated twice, as A1 and A2.
> I want A1.B.P to have one value and A2.B.P to have another value.
In Verilog 2000, this can be written using pound parameters that passed
down hierarchy. I think at least analog designers would never use
defparams for this but instead would write:
module A () ;
paramter A_P = 0;
B #(.P(P)) B ;
endmodule
module top ;
A #(.A_P(1)) A1 ;
A #(.A_P(2)) A2 ;
// > defparam A1.B.P = 1 ;
// > defparam A2.B.P = 2 ;
endmodule
This has advantage that code of module must plan for instance tree
paramter setting and parameter values can be determined from
reading relevant source. I think main reason defparam usage is so
rare is that in large design it is very hard to figure out where
defparam statements appear in source and because of order rules,
designer must read entire source including libraries. Although
placing defparms in hard to determine places is bad coding style,
one someone hacks a design to add one, it becomes unmaintainable.
I think defparms should be deprecated and only support older P1364 1995
usage.
/Steve Meyer
>
> There are other ways to do this, but this is the easiest.
>
> They also have advantages of readability (in 1364-1995),
> the possibility to centrally group all parameters together
> (similar to a central `defines file),
> and the ability to customize a design from outside it,
> without having to change its contents (e.g., IP reuse).
>
> --
> **************************************************************************
> Shalom Bresticker Shalom.Bresticker@motorola.com
> Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268
> P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890
> **************************************************************************
>
>
-- Steve Meyer sjmeyer@pragmatic-c.com
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:44 PDT
and
sponsored by Boyd Technology, Inc.