Re: [sv-ec] Mantis 1067 proposal uploaded

Shalom

Many thanks for the careful review. I wanted to get
something in writing immediately on my return from
vacation, and lacked time and energy to be so thorough.

> 1. Table 7-1 should move from 7.8.6, which is specific to associative arrays,
>to 7.4.6 (Indexing and slicing of arrays), which is general.

I think I agree; I balked at the labour :-) I'll look at that during this week.
 
> 2. The proposal distinguishes between unpacked arrays, saying that they return
>the value shown in Table 7-1, and bit-selects/part-selects, that return x for
>4-state values and 0 for 2-state values. I think the wording in the proposal
>leaves unclarified cases of multiple packed dimensions, where there is an x/z
>or out-of-bounds index in a packed dimensions that is not the least significant
>dimension.

OK. My original intent was to leave the packed-array
behaviour undisturbed, but I agree it doesn't say
enough about multiple dimensions.
 
> 3. If Table 7-1 is going to have special entries for variable-size arrays and
>for fixed-size arrays, then what about structs and unions? Table 6-7 does not
>have special entries for arrays.

The original table clearly was written without consideration
of the possibility of arrays of aggregates, and I'm convinced
that needed to be fixed. I don't think that 1800-2009 makes
it clear what should happen if you do...

  logic [7:0] A[10][10];
  logic [7:0] B[10];
  B = A[12];

But you're clearly right that other aggregates need
defined behaviour, and I'll add some entries for that.
 
> 4. In 7.10.1, the proposal changes "with X's or Z's" to "has one or more X or
>Z bits". The latter should be colored blue.

Oops, thanks.

> 5. 11.5.1 contains, "or the bit-select is x or z". This should probably be
>changed to "or any bit of the bit-select is x or z", to be more precise and
>more consistent with other places.

Yes, I was a little unhappy with phrases like
"the index is x" and tried to change them to
"has one or more X bits" or similar. Clearly
I missedthis one :-(

> This paragraph, describing bit-selects, should also say what happens if such a
>bit-select is written as well as read.

My intent was that this should be covered by the 7.4.6 text
"Writing to an array with an invalid index...", where "an array"
is taken to mean either packed or unpacked. But I agree
it needs clearing up and there should be specific mention
in 11.5.1.
 
> 6. There is also another paragraph in 11.5.1 that needs to be modified:
>
> "A part-select that addresses a range of bits that are completely out of the
>address bounds of the vector, packed array, packed structure, parameter or
>concatenation, or a part-select that is x or z shall yield the value x when read
>and shall have no effect on the data stored when written. Part-selects that are
>partially out of range shall, when read, return x for the bits that are out of
>range and shall, when written, only affect the bits that are in range."

OK.
 
> 7. Some changes in the proposal delete the word "address", as in 11.5.1. In
>11.5.2, the word remains. Is that deliberate?

Not deliberate, but probably appropriate. I felt that "address"
was used without proper definition in various places, and it
was better to stick with "index" everywhere, so I tried to
get rid of such uses of "address". On the other hand,
11.5.2 really reflects the special case of "memories" in
traditional Verilog, and in that special context perhaps
"address" makes sense and is well-defined.
 
> 8. 7.9.11 says, "If a default value is specified, then reading a nonexistent
>element shall yield the specified default value, and no warning shall be
>issued. Otherwise, the default initial value as described in Table 7-1 shall be
>returned."
>
> However, Table 7-1 does not describe default initial values, certainly not
>after this proposal.

That's another oversight that needs fixing, thanks.

Regards
Jonathan

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