Subject: Re: Enumerated Types Proposals - Responding to Kevin and Peter
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Sun Mar 31 2002 - 08:37:23 PST
At 03:19 PM 3/29/02 -0800, Kevin Cameron x3251 wrote:
> > 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.
I agree with Kev on this. Since we are talking about Verilog constants,
there will be times when Verilog users will want named alternatives for
patterns that include X's and Z's.
>How are
> > values containing X or Z to be incremented?
Kev has given one method below. Alternatively, I could easily live with the
requirement that adding X's and Z's to any enumerated definition requires
the subsequent enumerated definition to be explicitly defined. This is not
unlike:
enum {a=7, b, c=8} alpha;
In this case, b must be user defined to remove the syntax error that would
occur from auto-incremented enumerated values.
> > Your proposal implies that X or Z can overlap 0 or 1. How can an
> exhaustive
> > case on such an enumeration be synthesizable?
This technique is extremely important to synthesizable RTL design (I use
this frequently in RTL design and I use it all the time in RTL FSM design).
Synthesis tools treat X-assignments (not Z-assignments) as don't cares. By
assigning the next variable to all X's and following up later in the code
with next = <actual state>, you have just informed the synthesis tool that
next is a don't care except for specific input conditions. Now the
synthesis tool does not have to insure that all undefined binary patterns
are unreachable ad the synthesized result is optimized (full_case informs
that synthesis tool that the case statement as defined is "full" and all
other cases can be treated as don't cares - same effect bug with sometimes
dire consequences).
From a simulation perspective, this adds debug value because the next =
X's will show up in the simulation if the engineer neglected to make a
required next state assignment elsewhere in the code.
This is a really cool technique. Helps to identify bugs during simulation
and helps optimize the design during synthesis. Way cool!!
> >
> > 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.
//*****************************************************************//
// 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 : Sun Mar 31 2002 - 08:38:48 PST