RE: [sv-bc] E-mail Ballot: Respond by 8am PDT, Tuesday, March 25

Shalom,

I know its long after the meeting (2 or 3 hours after), so my remarks might
me moot at this point.  Never-the-less, they are embedded, below.

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
+1-503-692-0898

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Bresticker, Shalom
> Sent: Tuesday, March 25, 2008 8:36 AM
> To: stuart@sutherland-hdl.com; sv-bc@eda.org
> Subject: RE: [sv-bc] E-mail Ballot: Respond by 8am PDT, Tuesday, March
> 25
> 
> Hi, Stu.
> 
> > > SVDB 1769 ___Yes   _X_No
> > I vote no because the syntax for an elaboration $fatal task
> > is not the same as for a run-time $fatal task. The former
> > does not have a "finish_number"
> > argument.  I will change my vote to yes if the two versions
> > of $fatal are made consistent (and backward compatible).
> 
> There is no backward compatibility problem because the run-time $fatal
> is not being changed. The reason the elab $fatal omits the finish
> number
> argument is that it has no meaning at elab time. What would you
> suggest?

[SS] My concern is having two different syntax definitions for $fatal.  The
same system task name should have the same syntax whether executed by the
elaborator or at run time.  I personally find no value in $fatal having a
"finish_number" argument, but removing this argument from the run-time
version of $fatal would not be backward compatible.  Therefore, I will only
vote yes on 1769 if the elaboration-time version of $fatal also requires a
"finish_number" argument.

> 
> 
> > >SVDB 2269 ___Yes   _X_No
> > The proposal would have any size cast result in an [n-1:0]
> > size.  I do not think this rule is intuitive or what users
> > would want every time. Consider the following:
> >
> > logic [0:47] foo;
> > 32'(foo) // results in an expression of [31:0] -- which bit
> > of foo goes to which bit of the operation result?
> 
> result[31:0] = foo[16:47].
> 
> But remember that there is no variable called "result". 32'(foo) is
> just
> an abstract expression. You can't directly access its bits. If you
> wrote
> {foo}[0], {foo} is a [47:0] vector, so you will get {foo}[0] ==
> foo[47].
> 

Another already approved Mantis item does allow bit and part-selects of
abstract expressions.  Therefore it is important that the standard does
define the bit numbering of a size cast (which the proposal does), and that
the bit numbering be intuitive (which I feel the proposal fails to do).

What I think is intuitive is:
- A size cast of a little-endian expression (e.g. logic [47:0] foo;) should
return a little-endian expression (e.g. 32'(foo) returns an expression the
bit numbering [31:0]).  Note that the LARGEST-numbered LEFT-most bits (the
MSB's) of foo are what is affected by the cast.

- A size cast of a big-endian expression (e.g. logic [0:47] foo;) should
return a big-endian expression.  What I am undecided on is if a size cast of
a big-endian expression affects the SMALLEST-numbered LEFT-most bits (e.g.
32'(foo) returns an expression with the bit numbering [16:47]) or the
LARGEST-numbered RIGHT-most bits (e.g 32'(foo) returns an expression with
the bit numbering [0:31]).

I am open to discussion on what is most useful and intuitive.


> 
> struct packed { logic [0:47] foo; } will also give you a [47:0] entity.
> This is no different.

I agree that this example turns a big-endian vector into a little-endian
representation.  However, I think it is extremely rare that users will
reference packed-structures by bit number instead of member name.  I think
it is even more rare that users will create a structure with a single
member.  Thus, this is a corner case that will seldom, if ever, come up in
real code.

On the other hand, size casting of a single expression will be used very
often to eliminate warnings from lint programs and synthesis compilers about
size mismatches in assignment statements or port connections.

My main concern, once again, is when a user does do a bit- or part-select of
an expression, thinking the expression is big-endian, and the cast result is
actually little-endian.

> 
> Regards,
> Shalom
> ---------------------------------------------------------------------
> 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.
> 



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