Re: Mfactor proposal

CLC Shekar wrote:
> clc> Yes, I will rewrite that requirement indicating that mfactor
> should not be used in an expression. Will then change the
> defparam example to demonstrate the "cycle" effect when using
> m-factor in an expression.

As I noted in a previous e-mail, we do want to be able to use the
mfactor in an expression. Is the cycle problem specific to mfactor?
What if I have
  module top
    parameter real foo=3;
    I1 #(.foo(foo)) bar
  endmodule

  module bar
    parameter real foo=3;
    defparam top.foo = foo+1;
  endmodule

Ken's example

> module my_res (a, b);
> parameter real r;
> resistor #(.r(r), .m(m)) R1 (a, b);
> endmodule

where my_res is instantiated with m=5 is handled by saying
that automatic handling of the mfactor is turned off by the
access of my_res's mfactor.

     module my_res2 (a, b);
         inout a,b;
         electrical a,b;
         ground gnd;
         parameter real r;
         resistor #(.r(r), .m(m)) R1 (a, b);
         capacitor #(.c(10p)) C1 (a, gnd);
     endmodule

Capacitor C1 would have an effective mfactor of 1, which
might or might not be the right thing; it is the model
writer's duty to ensure that, if he uses m anywhere in
the module, he passes it explicitly where necessary.

> clc> Yes, the semantics/syntax should be extensible for similar class
> of parameters. One reservation though with using the '$' character
> would be that it has already been used in the language to identify
> system tasks and functions which are not considered as constant
> expressions.

The CM proposal considers $param_given and $port_connected as
constant expressions. The SV 3.1a LRM talks about the
"elaboration-time" $typeof function, and this function can
be used in parameter default expressions.

-Geoffrey
Received on Thu Jun 17 12:52:21 2004