RE: [sv-bc] RE: email ballot: Due 8am PDT Friday, May 1

Manti 2469 and 1429 bring up more questions on these issues or point out additional aspects, such as it is not even clear that the type of enum value A is the same as that of enum variable e, though I do think that was the intent.

Shalom 

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Mark Hartoog
> Sent: Saturday, May 02, 2009 2:40 AM
> To: Gordon Vreugdenhil; Steven Sharp
> Cc: Mark.Hartoog@synopsys.COM; Maidment, Matthew R; sv-bc@eda.org
> Subject: RE: [sv-bc] RE: email ballot: Due 8am PDT Friday, May 1
> 
> Most designers understand (or think they understand) how 
> expressions are evaluated in an assignment context. Designers 
> are frequently surprised at how expressions are evaluated in 
> self determined contexts. This enum label syntax certainly 
> looks like an assignment context. I am sure designers would 
> expect these expression to be evaluated like in an assignment context.
> 
> This issue mainly comes up when parameters are used:
> 
> parameter P1 = 8;
> parameter P2 = 6'b001000;
> 
> enum [P1-1:0] { A = P2 } e;
> 
> The parameter P2 may need to be a sized to 6 bits because it 
> is used someplace else where it must be sized.
> 
> The user may not even be sure what the size of P2 will be 
> after it is overridden. The user will be forced to do something like:
> 
> parameter P1 = 8;
> parameter P2 = 6'b001000;
> 
> local parameter [P1-1:0] LP2 = P2;
> 
> enum [P1-1:0] { A = LP2 } e;
> 
> Users will not understand why they have to go to this extra 
> work in this one case, when in all other cases verilog does 
> not require this extra coding.
> 
> The case Stu seems to be worried about is the overflow case, 
> when bits are being dropped. I would go along with making it 
> a compile time error or warning for the size of the 
> expression to exceed the size of the enum base type so that 
> bits are dropped in the assignment.
> 
> 
> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> Sent: Friday, May 01, 2009 4:16 PM
> To: Steven Sharp
> Cc: Mark.Hartoog@synopsys.COM; matthew.r.maidment@intel.com; 
> sv-bc@eda.org
> Subject: Re: [sv-bc] RE: email ballot: Due 8am PDT Friday, May 1
> 
> Steven,
> 
> I agree that neither complete context determined rules
> nor self-determined are appropriate.  If someone wants
> to take a shot at writing something that is approximately
> correct, I'd be interested.  It might end up looking
> something similar to some of the coverpoint bin expression
> rules that deal with overflow values, etc. in a special
> manner.  I haven't spent anytime trying to figure out a
> good rule set.
> 
> I do agree with Stu's concerns here too -- there is a
> legitimate concern about enum base type overflow at
> the least and I think we want to be careful about that.
> You've acknowledged that as well, so I think that it
> is likely just some work to find a common rule set.
> 
> Whether or not the changes are within the scope/timeframe
> of what we can do for the ballot issues is a different question.
> 
> 
> Gord.
> 
> 
> Steven Sharp wrote:
> >> From: Gordon Vreugdenhil <gordonv@model.com>
> >
> >> At this point, I think the self-determined context rules 
> are actually
> >> close to the original intent.  In other words, if the 
> self-determined
> >> size is not the same as the enum base, it is an error.  There are
> >> some issues in that rule regarding unsized, but I think the
> >> original intent was to have a stronger certainty about the value
> >> domain (particularly with auto incrementing enums) than is really
> >> possible with general context-determined evaluation.
> >
> > I don't think you can just dismiss the part about unsized.  This
> > rule does not allow the unsized constant case that is apparently
> > allowed, and it is not clear how it could be generalized to do so.
> >
> > I also think there are other problems with trying to use a self-
> > determined context and requiring an exact size match.  What if
> > the user is trying to create an enum with a parameterized base
> > type, perhaps using a parameterized name[N] or name[N:M] syntax
> > for some of the enum literals so that the number of enum literals
> > is also parameterized?  If they want to specify values for some of
> > the literals, this rule would require them to specify a value with
> > a width that exactly matched the parameterized base type.  
> They would
> > have to start jumping through hoops to satisfy that, instead of just
> > providing an expression and letting the context-determined 
> size rules
> > take care of sizing.
> >
> >
> >> So, I am opposed to making the enum exactly like a parameter (with
> >> context determined semantics) but would not oppose some 
> clarification
> >> to the sizing rules that are present and still normative.
> >
> > The present rule refers explicitly to a "different sized constant".
> > In the 2009 LRM, we use the term "literal constant", but the present
> > rule was based on the 1364-2005 LRM.  In that LRM, the "literal" had
> > not been added to the term yet.  This rule is referring to what is
> > now called a sized literal constant.  Any other case was 
> not disallowed
> > by this rule.
> >
> > There is a separate rule that says any value that is outside the
> > representable range of the enum shall be an error.  That covers the
> > case of a larger value that does not fit.  This seems to be the main
> > rule to prevent overflow.  The rule about the "different 
> sized constant"
> > seems to be an additional check for the case where the user 
> was trying
> > to use a literal of the appropriate size, but seems to be wrong.
> >
> > So my understanding of the present rules is consistent with 
> evaluating
> > the values with context determined semantics, but having a check for
> > overflow if there is a truncation, plus a special rule when 
> the expression
> > is simply a sized literal.
> >
> > Steven Sharp
> > sharp@cadence.com
> >
> 
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> 
> 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


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