Subject: Re: Enumerated Types Proposals
From: Michael McNamara (mac@verisity.com)
Date: Mon Apr 08 2002 - 14:10:13 PDT
This is actually quite consistant with Verilog 1364-1995's strength
concept. Vectors and scalars were assumed to be 4 value unless
someone drove one with an entity that had a strength specified.
Clifford E. Cummings writes:
> Peter -
>
> I really like the enum [data_type] proposal but would like to suggest one
> small change. I don't want to be required to make the explicit logic
> declaration when the context is clearly 4-state.
>
> Proposed wording?
> In the absence of a data type declaration and if no values are assigned,
> the default data type shall be int. If only binary values are assigned to
> the enum names, the default data type shall be int, If no data type is
> assigned and the enumerated names have assigned values that include x's and
> z's, the default data type shall be logic. This means that an enumeration
> that defaults to a data type of int because the enum names were either
> unassigned or were originally assigned binary values will default to a data
> type of logic, after the design is recompiled, if x-assignments or
> z-assignments are added to the enumeration when the design file is
> modified. Any other data type requires an explicit data type declaration.
>
> We still need to comment on what should happen if an unassigned enum name
> follows an enum name with x or z assignments. Is this a syntax error or do
> names S1 and S2 take on consistent defined values?
>
> // IDLE=2'b00, XX=2'bx, S1=??, S2=??
> enum {IDLE, XX='x, S1, S2} state, next;
>
> Otherwise, I really do like this proposal.
>
> Regards - Cliff
>
>
> At 12:05 PM 4/8/02 +0100, you wrote:
> >Kevin,
> >
> >If a value is not specified, then the following from Cliff should apply:
> >
> >Draft 4, Section 3.6 - page 8
> >Section 3.6 - Paragraph #2 Clarification Proposal
> >PROPOSAL: modify the second paragraph as follows:
> >The named values can be cast to integer types, and increment from an
> >initial value of 0. This can be over-ridden. If integers are assigned to
> >some but not all of the named values, unassigned named values are
> >implicitly assigned an increment of the previous explicitly or implicitly
> >assigned integer.
> >enum {bronze=3, silver, gold} medal; // silver=4, gold=5
> >enum (a=3, b=7, c) alphabet; // c=8
> >
> >Peter.
> >
> >At 10:30 AM 4/5/02 -0800, Kevin Cameron wrote:
> >>
> >>
> >>Peter Flake wrote:
> >>> Cliff,
> >>>
> >>>We have considered your proposals, and we have a counter-proposal which
> >>>we think should satisfy your requirements.
> >>>
> >>>We propose an optional data type with the enum. The default data type
> >>>is int
> >>>
> >>>enum [data_type] { enum_member {, enum_member} }
> >>>
> >>>The data type is limited to integer data types, 2 state or 4 state. The
> >>>4 state data types can have constant values containing X or Z.
> >>>For example:
> >>>enum logic [1:0] { S0=2'b00, S1=2'b01, S2=2'b11, XX='x } state, next;
> >>>
> >>>Peter.
> >>What values get assigned if a value (or part of it) is not specified?
> >>
> >>Maybe want a default:
> >>
> >> enum [data_type] [ = <default value>] { enum_member {, enum_member} }
> >>
> >> e.g.:
> >> enum logic [1:0] = 2'b00 { S0=1'b0, S1=1'b1, S2=2'b11, XX=2'bxx }
> >> state, next;
> >>
> >> which extends as:
> >> enum logic [2:0] = 3'b100 { S0=1'b0, S1=1'b1, S2=2'b11, XX=2'bxx,
> >> BAD } state, next;
> >>
> >>// BAD takes default ==3'b100
> >>
> >>Note: since enums in C always allocate specific numbers (regardless of
> >>the compiler)
> >>mixing code from different compilers does not cause a problem (wrt
> >>enums). The
> >>same should (IMO) be true for SystemVerilog enums.
> >>
> >>Kev.
> >>
>
> //*****************************************************************//
> // Cliff Cummings Phone: 503-641-8446 //
> // Sunburst Design, Inc. FAX: 503-641-8486 //
> // 14314 SW Allen Blvd. E-mail: cliffc@sunburst-design.com //
> // PMB 501 Web: www.sunburst-design.com //
> // Beaverton, OR 97005 //
> // //
> // Expert Verilog, Synthesis and Verification Training //
> //*****************************************************************//
>
This archive was generated by hypermail 2b28 : Mon Apr 08 2002 - 14:12:17 PDT