Re: [sv-bc] value parameter types

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Tue Jun 19 2007 - 06:58:11 PDT
Mantis 1685 and 1618 get at some of this; 1618 deals with
"string" in particular.

Some of this will touch on exactly what level of "compatibility"
between 1364 and 1800 we want.  For example, my suggestion in
1618 is to have an untyped parameter adopt the SV type "string"
when overridden by a string literal.  However in 1364 such an
override causes the parameter to be a "reg" type of the
appropriate width.

Since we now have "type" in SV, if one has:
    module child;
       parameter p = 1;
       type(p) foo;
    endmodule
the exact type of the parameter is important.


Personally, I think that any non-class type makes sense.
One could argue that even class types make sense but since
the only static class value is null, such a parameter would
only really be useful as essentially a type parameter.  I'd
rather not allow classes at this point in case we ever do
want to allow static construction in the future.

Gord.


Bresticker, Shalom wrote:
> Hi,
> 
> The rules regarding the type of a value parameter, as formulated in 
> 1364, say basically that a value parameter whose type is not specified 
> in the declaration gets the type of the value assigned to it in the 
> parameter declaration or in the parameter override.(see 6.20.2 and 
> 22.9.1 in D3a.)
> 
> For example, in 1364 an untyped parameter can be assigned an integral 
> value or a real value and the parameter gets the type of the value.
> 
> Question: in 1800, can one do this for other types as well? That is, can 
> one assign to an untyped value parameter a structure, an array, a 
> string, an enum, etc.? Can one assign an untyped value parameter an 
> integral value in the declaration and then override it with an unpacked 
> array, etc.?
> 
> I would guess so, but it is not completely clear since the rules were 
> just copied from 1364, but not updated to additional 1800 data types.
> 
> (The 1364 terminology, which still appears in the merged LRM, is 
> somewhat inconsistent with 1800, in that the bit range is not considered 
> part of the type, whereas I think it is in 1800. Also, the rules 
> concerning the signedness are different in that if the parameter is 
> declared as signed, but without a range, then it stays signed, but also 
> gets the range of the value assigned to it.)
> 
> Thanks,
> 
> Shalom
> 
> Shalom Bresticker
> 
> Intel Jerusalem LAD DA
> 
> +972 2 589-6852
> 
> +972 54 721-1033 
> 
>  
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Jun 19 06:58:28 2007

This archive was generated by hypermail 2.1.8 : Tue Jun 19 2007 - 06:58:55 PDT