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

Hi Shalom.

I wouldn't mind getting a tool warning because of the different sizes,
but using "strong" typing to reject the construct would eliminate
cases in which it was intended.

Of course, if in a statement, X <= a & b, the MSB pad of 1'b0
would be added automatically, assuming X width was >= 4.

Perhaps expressions of components of divers width should
be adjusted automatically before evaluation by widening
each component to the width of the widest by padding to
the MSB with 0 (or the value of the sign bit)?

This would be consistent with the way statements are adjusted.
It also would not complicate the language further.

On 06/20/2010 02:07 AM, Bresticker, Shalom wrote:
> When I said that we require the self-determined types of expr1 and expr2 to be the same, I was referring mainly to the bit-size. If a is 3 bits and b is 4 bits and the coder writes "a& b", he has likely made a mistake. For example, he may mistakenly think that a and b are the same size. In order to make this check more reliable, we require the coder to explicitly size-extend if he really does want to bit-wise AND two vectors of different sizes.
>
> {1'b0,a}& b
>
> That way, if he wrote "a& b" and they are different sizes, the probability that the coder has made a mistake is very high.
>
> I said nothing about whether the code is legal or not, only about the chance that it is suspicious, i.e., has a bad smell.
>
> Shalom
>
>
>> -----Original Message-----
>> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
>> Behalf Of John Michael Williams
>> Sent: Friday, June 18, 2010 11:55 PM
>> To: sv-bc@eda.org
>> Subject: Re: [sv-bc] Type of a concat expression
>>
>> Hi Shalom.
>>
>> On 06/18/2010 04:01 AM, Bresticker, Shalom wrote:
>>> It's very useful, as in the following where the types of a
>> and b are parameterized:
>>>
>>> var type({a,b}) c = {a,b} ;
>>>
>>>
>>> Note also the following. Consider the expression
>>>
>>> expr1& expr2
>>>
>>> As part of our coding guidelines and code checks, we
>> require that the self-determined types of expr1 and expr2 be
>> the same. Otherwise, it is with high probability a coding
>> mistake. This is despite the fact that when the expression is
>> evaluated, the shorter of expr1 and expr2 will be
>> size-extended to the size of the longer.
>>>
>>
>> I don't understand this. If a is signed and b is unsigned, a& b is
>> perfectly fine coding: The bit patterns are the
>> same for signed and unsigned vectors, and masking a signed object
>> with an unsigned mask (for example to normalize the sign bit)
>> seems to make good sense.
>>
>> Verilog automatically handles this kind of "coding error".
>>
>> The problem with "strong" (viz., intolerant) typing is that it
>> wastes effort in complying with unnecessary rules -- at least
>> in verilog as opposed to some other languages.
>>
>> It is not consistent with good language design to mix guidelines for
>> "strong" and "unstrong" typing. It creates inconsistency
>> and makes for a shallower learning curve for beginners.
>>
>> This was the main reason that C became so popular when
>> compared with, say, Pascal or PL. C was designed to help the
>> programmer to get his or her work done; Pascal was designed to teach
>> students about type differences and to make compiler
>> development simpler.
>>
>> After the ANSI Std, one could write C in "strong" types simply by
>> declaring all variables in tagged structs. No further language
>> constructs or compiler rewrites were required, just application
>> of an existing language construct for the additional functionality.
>>
>>
>> A high probability of a departure from coding guidelines is not
>> the same as a high probability that the compiler will report
>> an error, or that the code will behave badly. One has to
>> take take account of what it is that the coding guidelines have been
>> based upon -- Just take a Bayesian view in that the prior condition
>> is an important factor in the probability under discussion.
>>
>> Excluding the C++-compatibility side of SystemVerilog, verilog is
>> not strongly typed; so, imposing "strong" type assumptions on
>> coding guidelines merely creates complexity, and complexity
>> consumes development time and encourages error.
>>
>>> Shalom
>>>
>>>
>>>> In verilog, and in the scheduled design constructs of
>> SystemVerilog,
>>>> the "type" of an expression is useless, because
>>>> the way an expression is used determines the meaning of
>>>> the expression. It is possible, but very rare, for
>>>> a verilog expression to have a self-determined "type".
>>>> Signed vs. unsigned relational expressions come to mind.
>>>
>> ---------------------------------------------------------------------
>>> 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.
>>>
>>>
>>
>> --
>> 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.
>>
>>
> ---------------------------------------------------------------------
> 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.
>
>

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