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

>Date: Wed, 16 Jun 2010 15:13:04 -0700
>From: John Michael Williams <john@svtii.com>

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

I am not sure what your point is here. An expression has a collection
of properties that determine the values it can take on, how those values
are interpreted, and what types that expression is compatible with. That
corresponds rather closely to the concept of a type, and the rest of us
are calling that the type of the expression. It is perfectly reasonable
terminology.

The type of a particular expression in Verilog source code may be
dependent on the context where it appears. If it is in a context where
it is not affected by the context, it is called "self-determined". If
we want to talk about these properties without having to account for
the context, we can talk about the properties when the expression is
self-determined.

> Similarly,
>
>bit a;
>logic[3:0] b;
>reg[3:0] A, B;
>
>compare a = A & B; to b = A & B;.

They have different types. That is fine, since they are different
expressions. They appear at different places in the source code,
with different contexts. They happen to be represented with the
same characters, but they are not the same instance of an expression.

You seem to be trying to discuss the type of some abstract concept of
an expression that is independent of its context in the source code,
instead of the type of specific expressions in the source code. You
can't do that in Verilog.

In fact, you can't do it in other languages either. Expressions
represented with the same characters may have different types in other
languages too, if they appear in the different context of different
scopes where the names refer to different variables. I'm sure you have
no problem accepting that kind of context-sensitivity, so I don't know
why this kind is giving you trouble.

There is actually a way in which you can discuss the type of an expression
in Verilog in a more abstract way, independent of the exact context in
which the expression appears (but dependent on scopes of course). That
is to discuss what type it would have in a self-determined context. Which
is why the LRM talks about the self-determined type of an expression.

>"type( A & B)" is meaningless.

It is perfectly meaningful. It tells you the type of that expression in
that context. And since an operand of the type operator is self-determined,
it tells you the self-determined type of the expression. It doesn't tell
you the type of a similar expression appearing in a different context, such
as an assignment to b. I don't know why you think that makes a difference,
and renders this meaningless.

Actually, if we are going to be pedantic here, the type operator doesn't
"tell" you anything. It has certain behavior when it appears in the source
code, and that behavior can be described without saying that an expression
has a type. If it is used in a comparison, it compares the properties of
the expression with the other side of the expression, to see if they satisfy
the rules listed for matching types. If the LRM specifies this behavior
for an expression, then this construct is meaningful, whether you consider
an expression to have a type or not.

Your reference to type() returning an empty string suggests that you have
confused it with $typename(). That does actually "tell" you something.
The description of $typename() in 20.6.1 definitely allows expressions,
and definitely says that the expression has a type. It describes what
to return based on that type, and it is not an empty string.

If you are unable to accept the meaning of the term "type" as it is being
used in the LRM, and use that to understand the specified behavior for
type() and $typename(), that is not the fault of the LRM. Terminology
means what it was defined to mean in this context, even if that does
not match a meaning you are accustomed to elsewhere.

Steven Sharp | Architect | Cadence

P: 508.459.1436 M: 774.535.4149 www.cadence.com

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