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

From: Gordon Vreugdenhil <gordonv@model.com>
Date: Tue Jun 15 2010 - 08:28:28 PDT

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.
>>
>
>
>
>

-- 
--------------------------------------------------------------------
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 15 08:28:52 2010

This archive was generated by hypermail 2.1.8 : Tue Jun 15 2010 - 08:31:35 PDT