Re: Mfactor proposal

Hard to look up in comparison to $mfactor, since braces appear
in many places in the LRM, so you can't do a search on it.
I suppose {} would be OK if it had a special name in the syntax,
e.g.
  mfactor ::= { constant_expression }

$<name> parameters won't clash for parameter names, but we intend
for them to be accessible from within the module, so we have to
watch out for collisions with other system tasks/functions.

And yes, all the special parameters accumulate down the hierarchy:
m, n, hflip, vflip by multiplication; x, y, angle by addition
(mod 360 for angle).

-Geoffrey

Kevin Cameron wrote:
> Hard to look up in comparison to what? NB: I suggested the {} syntax
> because it is similar to the instance multiplier syntax already used in
> Verilog - I'd probably document it in the same part of a (unified) LRM .
>
> $m seems a reasonable alternative but I wouldn't make the choice on how
> much work goes into fixing the parsers (since that is usually minor).
> Does somebody already use/allow $<name> parameters?
>
> >One concern is that this tries to reserve a lot of system
> >function names. It would probably be better to use longer
> >names to reduce the chance of collisions (SV in particular
> >has a lot of $system_tasks). $mfactor, $xposition, etc.
> >
> If there is no prior use of $<name> parameters then there should be no
> name clashes, so short names would be OK. Since the long names only make
> sense in English and there are plenty of non-english speaking users out
> there I tend to just vote for minimal typing these days.
>
> How would all these "special" parameters work? - Do they accumulate down
> through the hierarchy like m-factor?
>
> Kev.
Received on Thu Jun 17 06:04:39 2004