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

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.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.