Subject: Re: [sv-bc] Proposal for SV-BC-105 aggregate expressions vs concatenation
From: Greg Jaxon (Greg.Jaxon@synopsys.com)
Date: Thu Jan 15 2004 - 11:52:12 PST
Dave Rich wrote:
> Here is my proposal for SV-105 (and 107, 124)
>
> I will not be able to attend Monday's meeting, so I welcome comments
> before then.
>
> Dave
>
Dave's proposal makes many welcome improvements to the aggregate expression
syntax, and resolves several of the design tradeoffs in the most reasonable
way possible. I urge its passage, with one ammendment.
In specifying the behavior of "type:value", Dave has changed from requiring
an "exact match" between the label type and the type of a field, subarray, or
array element to requiring only "equivalent" types.
In an earlier proposal, which I believe has been accepted, "equivalent" and
"castable" relationships were specified in (very welcome) detail. "Exact"
matching was not specified there. I think Dave's urge to simplify this issue
is well-meaning, but mistaken.
Since this change affects the values of constructed aggregates, and not merely
some error behavior, it is important to have a definition which is intuitive
and predictible. So here is a simple example that I believe recommends exact
matching:
`include "pixel.h"
struct packed {
struct packed {
pixel fill;
bit filter;
pixel temp;
bit available;
pixel bluescreen;
} page_reset;
int brightness;
int contrast;
} video_frame;
video_frame = { bit:1'b0, int:0, pixel:WHITE };
In SV 3.1, this statement was an error. Thanks to Dave's proposal
it now parses like its unpacked struct counterpart. It's exact
meaning depends on the definition of pixel, of course.
If pixel is a typedef or type parameter defined as bit, or int, then
all proposals agree that its value (WHITE) overrides for that type.
But pixel is probably another packed struct type:
parameter Red___COLOR_DEPTH = 6;
parameter Green_COLOR_DEPTH = 5;
parameter Blue__COLOR_DEPTH = 5;
typedef struct packed signed {
bit[Red___COLOR_DEPTH-1:0] r;
bit[Green_COLOR_DEPTH-1:0] g;
bit[Blue__COLOR_DEPTH-1:0] b;
} pixel;
const pixel WHITE = '1;
So things go well for the default and for many other choices of
color depth, and variations of the pixel definition.
But we get bad brightness and contrast logic when we elaborate
for Red___COLOR_DEPTH = 11, Green_COLOR_DEPTH = 11, Blue__COLOR_DEPTH = 10.
What happened? a pixel is 32 bits wide, and so the ints for
brightness and contrast are not 0, they're WHITE!
And the whole page_reset logic is ruined when
Red___COLOR_DEPTH = 3, Green_COLOR_DEPTH = 3, Blue__COLOR_DEPTH = 4.
On this chip, a pixel is 10 bits wide. This makes the page_reset field
be 32 bits wide, so it is "equivalent" to the int:0 specification,
and we won't recurse into it.
These glitches do not occur if we continue to use "exact" matching
defined in one of the intuitive ways. Recall that SV 3.1 says "exact"!
I'd rather not leave "exact" undefined, but I don't have the time
or the mindset to produce a perfect proposal, so here is my personal
definition of what I mean by exact match:
----------- EXACT (for type:value MATCHing only!) ------------
In an exact match, array bound values should have the same arithmetic
value and appear in the same order (direction). This is open to some
compromise, but I'm not sure what benefit comes from this compromise.
Both packed and unpacked dimensions should use this definition.
Of course, the packedness of each dimension must agree.
In an exact match, packed struct types are matched structurally, i.e.,
they must both have the same field names, exactly matching field types,
and all in the same order. This is more relaxed than unpacked type matching,
because it allows anonymous structs to be matched, but it means
that you have the same bit width + the same access methods.
Exact matching of unpacked structs and unions is the same as equivalence.
Two exactly matching unpacked structs must have been defined by the same
source text in the same scope, independent of how they arrived in the
current scope.
The built-in types are distinct from each other (but we may define
some "exactly matching" synonyms, I suppose).
Bear in mind that this definition does not replace "equivalent" or "castable"
we still need both of those! But we ALSO need the above definition, or
something like it for aggregate expression, and possibly for other places
where types are matched in more of a C++ style type-signature fashion.
--------------------------
In constructing the above example, I was tempted to put a
pixel[640][480] screen; into video_frame. Notice that the proposal
does not call for type:value recursion into packed arrays, even when they
are arrays of structs. That seems wrong to me, but I don't know what
would behave "right", so I'm happy with the current proposal - which gives
an error due to no match for field "screen".
Greg Jaxon
This archive was generated by hypermail 2b28 : Thu Jan 15 2004 - 11:55:51 PST