Subject: Re: Enumerated Types Proposals
From: Kevin Cameron x3251 (dkc@galaxy.nsc.com)
Date: Fri Mar 29 2002 - 15:19:22 PST
> From owner-vlog-pp@eda.org Fri Mar 29 14:18:17 2002
>
> Hi, Cliff,
>
> Thanks for the clarifications.
>
> I am afraid I completely disagree with your X and Z assignment proposal. To
> me, this destroys the concept of an enumeration, which is a set of named
> alternatives, and replaces it with a set of constant values. How are
> values containing X or Z to be incremented?
> Your proposal implies that X or Z can overlap 0 or 1. How can an exhaustive
> case on such an enumeration be synthesizable?
>
> The range and part-select proposals add convenience rather than any
> functionality which cannot be achieved with other SystemVerilog constructs,
> so I do not object to them.
>
> Peter.
>
> At 04:39 PM 3/28/02 -0800, Clifford E. Cummings wrote:
> >Hi, All - (proposals also attached as Enumeration_proposals_20020328.pdf)
....
Enumerations in C are just sets of constant values. Using an enum as a type
implies that a limited set of values are valid for a given variable (and
lets you see the values in the debugger by symbolic name rather than an integer
value). So, I'm not sure what you mean "named alternatives".
4-Value logic (0,1,X,Z) is actually a tuple of value (0,1,X) and strength (driven,
and undriven [Z]), so Z can overlap 0,1 or X. So you may want drop Z from enums
to avoid the extra complexity, and then consider bits as three valued (assigning
X the value '2') so that you can get a C-like progression if X is used e.g.:
enum {
A = 3'b000,
B = 3'b00X, // Needs to be explicit
C, // 3'b010 - by auto increment
D, // 3'b011 - 'X' skipped in auto increment
E = 3'b10X,
F // 3'b110
} Enm;
Kev.
This archive was generated by hypermail 2b28 : Fri Mar 29 2002 - 15:21:19 PST