Re: [sv-bc] Manti 1457, 2374 revisited

>From: jonathan.bromley@doulos.com

>1457 (EC):
>Associative arrays with [*] wildcard index type - the handling
>of keys of diverse length has been altered since 1800-2005 
>in a way that may break some existing code.  In 1800-2005 the 
>two keys 2'b00 and 3'b000 would address different elements;
>Mantis 1457 says they address the same element.  Was this
>change intentional?

I recall a time when I thought that these would address different
elements.  1800-2005 says

"Because the indices can be of different sizes, the same numerical
value can have multiple representations, each of a different size.
SystemVerilog resolves this ambiguity by detecting the number of
leading zeroes and computing a unique length and representation for
every value."

I think that the change was a clarification of what this was
intended to mean.

The phrase "detecting the number of leading zeroes and computing a
unique length and representation for every value" was intended to
mean the same thing as "removing the leading zeros and computing
the minimal length and using that representation for the value."

There may be code and tools that expect these to address different
elements, but there is apparently also code and tools that expect them
to address the same elements.  The text was unclear, and resulted in
divergence.  The best we can do at this point is clarify it to match
the intent and/or the more usable functionality going forward.


>2374 et al (BC): 
>enums are now permitted as members of packed arrays, unions,
>and structs.  This has a self-evident and useful meaning 
>for hardware design, and matches de facto tool behaviour. 
>But there remains an issue about copying a regular vector
>to a packed what-have-you that contains an enum.
>It's an unchecked cast by the back door:
>
>  typedef enum logic [1:0] {A = 2'b10, B = 2'b01} AB;
>  typedef struct packed {AB ab; logic [5:0] c;} S;
>  S s;
>  s = 8'b0;       // legitimate???
>  s[7:6] = 2'b11; // legitimate???
>  s.ab = 2'b10;   // definitely illegal!
> 
>I know there was some discussion about this and I even have 
>a recollection that, at one time, some tool(s?) forbade 
>such usage.  Is everyone agreed that the copying of a 
>vanilla vector to the packed struct 's' is legitimate? 

I am.


>If so, doesn't it render the type safety of enums
>rather toothless?

It is already missing several other teeth.  I don't think this one
affects that significantly.

Note that a packed struct is effectively an implicit union between the
struct and a vanilla vector, with a defined bit correspondence.  A
union already lets you bypass the type checking.  So this is almost the
same as another tooth that was already missing.

Since the start, there has been conflict between the desire for enums
to be abstract for software-like usage, and more concrete for hardware-
like usage.  The current definition is a compromise.  It seems to me
that packed structs are intended for hardware-like usage, so those
needs should win here.  If you want an abstract enum type with strong
typing, why would you be putting it in a packed struct?


Steven Sharp
sharp@cadence.com


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