Re: Mfactor proposal

Geoffrey.Coram wrote:

>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 }
>
>
I presume you would mention "mfactor" in the text along with the {} - or
whatever other syntax is used - so it's not going to be hard to find
with a search. I've got to say "hard to find in the LRM" is the lamest
excuse for not doing something I've heard in a while.

>$<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.
>
>
Good point. Are you going to allow user-override too? If you do then you
probably need PLI support so the user can get the m-factor value
determined by elaboration.

>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).
>
>
While I can see how "m" bears on simulation, what do the others do and
how do they affect simulation?

Kev.

>-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 09:42:26 2004