Re: [sv-bc] Type of a concat expression

Hi John.

Maybe so, but expressions don't have any "self-determined" result
type, because expressions aren't declared. Similarly,

bit a;
logic[3:0] b;
reg[3:0] A, B;

compare a = A & B; to b = A & B;.

"type( A & B)" is meaningless.

Probably, that part of 6.23 should be deleted.

On 06/16/2010 07:53 AM, Havlicek John-R8AAAU wrote:
> The following is a pretty clear statement from 6.23:
>
> The type operator applied to an expression shall represent the
> self-determined result type of that expression.
>
> J.H.
>
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of John
> Michael Williams
> Sent: Tuesday, June 15, 2010 12:57 PM
> To: sv-bc@eda.org
> Subject: Re: [sv-bc] Type of a concat expression
>
> Hi All.
>
> Expressions are not declared and therefore should have no type.
>
> The question is how an expression should be cast when used in
> a statement. This is why the Std doesn't directly address
> the "type" of an expression: It shouldn't!
>
> For example, reg[3:0] X, Y;
>
> type(X) or type(Y) makes sense because it is applied to the declared
> name; but,
>
> type(X& Y) doesn't make sense, except as the result of an implied
> type-cast.
>
> If I write Z<= Y& X;
>
> the RHS expression can not be treated as a type, because the expression
> will be adjusted in width according to the width of Z.
>
> Similarly, a concatenation is governed by width rules, but
> it is an expression, not a declared type. However, the
> components of a concatenation may have types (or may be, for
> example, literals with implied types. This doesn't mean
> that a concatenation "has" a type. The type of a concatenation,
> is determined by how it is used.
>
> In my opinion, type( {x,Y} ) should return a null (empty) string "".
>
> If SystemVerilog were more like C, then perhaps type( Z = {X,Y} ) might
> have a well-defined type (the type of Z).
>
> On 06/15/2010 08:28 AM, Gordon Vreugdenhil wrote:
>> Surya,
>>
>> The expression rules define the type of the expression. There are a
>> few areas that are not well defined, but most are trivial to
>> extrapolate from the defined behavior of concat (i.e. that width,
>> size, and sign count). The main thing that isn't clear is selects --
>> i.e. should type(a[5:4]) == type(a[3:2]) That does need to be
>> clarified.
>>
>> Surya Pratik Saha wrote:
>>> Hi Gordon,
>>> I have looked at table 11-21. That is all related to bit length
>>> calculation of expression, nothing related to type of expression. And
>
>>> also sections 11.6 - 11.8 all talk about the evaluation rule of
>>> expression, but not about the type. But if you have an expression
>>> inside a type operator and used in comparison rule with another type
>>> operator, it needs specific rule to check which is missing in LRM I
>>> can see. For e.g. what is a type of a binary operator consisting of
>>> two numbers:
>>>
>>> initial
>>> if (type(100 + 2'b11) == type (int)) // Will it match or not?
>>
>> No - signedness and 2/4 state mismatch.
>>
>>> x = 1;
>>> else
>>> x = 2;
>>>
>>> Regarding 2-state/4-state, a logic can contain both 2-state and
>>> 4-state values. So it is not clear whether following comparison will
>>> match or not:
>>>
>>> typedef logic[1:0] mylogic;
>>> type (type({1'b1, 1'b0}) == type (mylogic))
>>
>> Yes. Both types are unsigned, 4-state, vectors ranged 1:0.
>>
>> The LRM isn't quite as clear on the type of a sized, based literal;
>> for an unsized it clearly says integer (i.e. 4-state) and since the
>> LRM section starts with "There are two forms to express integer
>> literal constants." I think it is fair to extrapolate that they are
>> 4-state.
>>
>> BTW, this does imply that there are no natural 2-state numbers at all.
>
>> In most cases this is immaterial, but in "type"
>> expressions the difference can be noticed.
>>
>>
>>> I think LRM should have some guidelines to clarify all.
>>
>> I don't think there is much to do. A few edge cases, yes. But the
>> expression rules for sign, width, and state define the basic rule set.
>>
>> Gord
>>
>>
>>>
>>> Regards
>>> Surya
>>>
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Re:[sv-bc] Type of a concat expression
>>> From: Gordon Vreugdenhil<gordonv@model.com>
>>> To: Surya Pratik Saha<spsaha@cal.interrasystems.com>
>>> Cc: "sv-bc@eda.org"<sv-bc@eda.org>, "'Pradip Mukhopadhyay'"
>>> <pradip@cal.interrasystems.com>, Subhankar Ghosh
>>> <sghosh@cal.interrasystems.com>
>>> Date: Monday, June 14, 2010 10:09:44 PM
>>>> Have you looked at Table 11-21? And generally Section 11.6 - 11.8 in
>
>>>> 1800-2009?
>>>>
>>>> If you have a specific question about a specific rule application,
>>>> please do ask. But first, carefully work through Clause 11; there
>>>> are many rules covering self-determined result types for
>>>> expressions.
>>>>
>>>> The rules in SV are not trivial, but they are in the LRM.
>>>>
>>>> Gord.
>>>>
>>>>
>>>> Surya Pratik Saha wrote:
>>>>> Hi Shalom,
>>>>> Thanks for your response. But I think we should have a list of all
>>>>> self determined result type of an expression. For e.g. what is the
>>>>> type of a binary expression?
>>>>>
>>>>> Regards
>>>>> Surya
>>>>>
>>>>>
>>>>>
>>>>> -------- Original Message --------
>>>>> Subject: Re:[sv-bc] Type of a concat expression
>>>>> From: Bresticker, Shalom<shalom.bresticker@intel.com>
>>>>> To: Surya Pratik Saha<spsaha@cal.interrasystems.com>,
>>>>> sv-bc@eda.org<sv-bc@eda.org>
>>>>> Cc: "'Pradip Mukhopadhyay'"<pradip@cal.interrasystems.com>,
>>>>> Subhankar Ghosh<sghosh@cal.interrasystems.com>
>>>>> Date: Monday, June 14, 2010 5:44:29 PM
>>>>>> The LRM says (11.4.12)
>>>>>>
>>>>>> "The concatenation is treated as a packed vector of bits...One or
>>>>>> more bits of a concatenation can be selected as if the
>>>>>> concatenation were a packed array with the range [n-1:0]."
>>>>>>
>>>>>> and (11.8.1)
>>>>>>
>>>>>> "- Concatenate results are unsigned, regardless of the operands."
>>>>>>
>>>>>> Note that 'byte' is signed.
>>>>>>
>>>>>> Shalom
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------
>>>>>> ------
>>>>>>
>>>>>> *From:* owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] *On
>>>>>> Behalf Of *Surya Pratik Saha
>>>>>> *Sent:* Monday, June 14, 2010 3:04 PM
>>>>>> *To:* sv-bc@eda.org
>>>>>> *Cc:* 'Pradip Mukhopadhyay'; Subhankar Ghosh
>>>>>> *Subject:* [sv-bc] Type of a concat expression
>>>>>>
>>>>>> Hi,
>>>>>> What should be the return value of a "type ({b1, b2})"? LRM
>>>>>> section 6.23 (Type operator) mentions following text:
>>>>>> *The type operator applied to an expression shall represent the
>>>>>> self-determined result type of that expression.
>>>>>>
>>>>>> *But I could not find anywhere self-determined result type defined
>
>>>>>> of an expression.
>>>>>> One of the standard simulators which supports type operator works
>>>>>> in its own way.
>>>>>>
>>>>>> Here is a sample example:
>>>>>> module top(input bit in1, input bit[31:0] in2, output bit [7:0]
>>>>>> out1); bit [3:0] f0, f1; bit [3:0] l1; initial begin : blk if(type
>
>>>>>> ({f0, f1}) == type (byte))
>>>>>> out1 = 1;
>>>>>> else out1 = 3;
>>>>>> end
>>>>>> endmodule
>>>>>>
>>>>>> -- Regards
>>>>>> Surya
>>>>>> -- This message has been scanned for viruses and dangerous content
>
>>>>>> by *MailScanner*<http://www.mailscanner.info/>, and is believed
>>>>>> to be clean.
>>>>>> ------------------------------------------------------------------
>>>>>> ---
>>>>>> Intel Israel (74) Limited
>>>>>>
>>>>>> This e-mail and any attachments may contain confidential material
>>>>>> for the sole use of the intended recipient(s). Any review or
>>>>>> distribution by others is strictly prohibited. If you are not the
>>>>>> intended recipient, please contact the sender and delete all
> copies.
>>>>>
>>>>>
>>>>> --
>>>>> This message has been scanned for viruses and dangerous content by
>>>>> *MailScanner*<http://www.mailscanner.info/>, and is believed to be
>
>>>>> clean.
>>>>
>>>
>>>
>>>
>>>
>>
>

-- 
      John Michael Williams
      Senior Adjunct Faculty
Silicon Valley Technical Institute
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.