Re: [sv-bc] question about the proposal

Right. http://www.eda.org/sv-bc/hm/1705.html is an example
where the generative model of expression evaluation
produces a "pun" between different datatypes. We're trying
to exclude that possibility by distinguishing "assignment-like"
contexts from the usual "operand-like" contexts. Both are
affected by the bit width of their surroundings, but only
assignment-like contexts inherit data structure. [And now
context can only determine structure of explicit '{...} syntax,
so this will never surprise Joe Bittwiddle.]

Punning arises in at least two settings:
"default:..." and "{n{...}}" (i.e repeat concat),
and generally anywhere a single expression is brought into
a one-to-many correspondence with (potentially) different contexts.

There is one further reason that "default:..." is not an
assignment-like context. Although default clauses are
primarily a simple catch-all, they are still triggered by
a "matching criteria". If they had no matching criteria,
this would ruin the usefullness of our "type:..." clauses
when those types match buried substructure - because the first
layer of recursion could always terminate by using its "default:"
clause. So "default" has a matching rule. The MOST USEFUL
rule is to match whenever the unfilled substructure
has the same type as the value supplied as default, or
when both types are simple bit vectors. In this way, default
does not become a "catch-all" until we can recurse no more.
If the rule was really this simple to express, I'm
sure we'd have standardized it sooner, but I haven't gone
into how enum types are matched/not matched, etc...

typedef struct packed {byte r,g,b} color;
const color purple = '{127,0,127};
color [639:0][479:0] screen = '{default:purple};

Here, although all the data types are packed, we are guided
by the type information to deliver a default value to the
"right" level of substructure. The type comparison
that does this uses "strong typing" to decide how to set up
the correspondences, but not when it comes to carrying out
the assignments - where simple bit vector extension or truncation
is still permitted. We don't want "default" to set up situations
where type information is wantonly discarded.

Given that the expression's type is used in the matching rule,
the case never arises where the (varying) context must inform
the production of the default expression's value - if the context
has structure, then it already matches, or else that default clause
cannot be selected to fill the context.

If this incestuous use of type information seems difficult to
implement, I can only say that if you can get V2K signedness and
context-determined expression bit width correctly implemented, then
you already have the infrastructure on which you can hang these
rules - In DCSV, the same pass accomplishes both type computations
simultaneously.

Greg Jaxon

Brad Pierce wrote:
> Francoise,
>
> The following link has an example of the problem --
>
> http://www.eda.org/sv-bc/hm/1705.html
>
> module m;
> parameter a = 1, b = 2;
> typedef struct { byte a, b;} F1;
> typedef struct { F1 f1; byte f2 [10:0];} S1;
> initial begin
> S1 y = {default:{a:20, b:4, default:'0}};
> end
> endmodule
>
> See also --
>
> http://www.eda.org/sv-bc/hm/2030.html
>
> -- Brad
>
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of Greg
> Jaxon
> Sent: Wednesday, February 02, 2005 10:05 AM
> To: Francoise Martinolle
> Cc: sv-bc@eda.org
> Subject: Re: [sv-bc] question about the proposal
>
>
> I think we just have not yet found the right verbiage to express
> what we mean. There are two ways context influences an expression.
> 1) "Type" information can influence constructors,
> 2) "packed width" information can influence operator sizing.
>
> With default:value, I believe others have become comfortable with
> letting the width of each otherwise unmatched field separately
> affect the width of a fresh copy of the value expression. I think
> that's like "punning" - to make one expression mean two different
> things, but I've lost that fight.
>
> However, the notion of "punning" must have irritated folks when
> it came to writing default:'{a:1, b:2} and letting this match up
> sometimes to one substructure with fields named a & b, sometimes to
> another such substructure, and sometimes to an array, for which
> a & b are constant expression index positions.
>
> So in short, we intend that "type" should not be imposed on
> the default's value (that much must be self-determined). But
> so far we're willing to let width affect the operator sizing.
>
> Greg
>
>
> Francoise Martinolle wrote:
>
>>Why is a default correspondence not considered as an assignment like
>>context?
>>
>>Francoise
>> '
>
>
>
Received on Wed Feb 2 15:22:29 2005