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

We did not disregard your comments.

See unapproved meeting minutes:

http://www.eda.org/sv-bc/minutes/sv-bc_08_03_25.txt

Regarding 1769, we agreed with you.  See also:

http://www.eda.org/svdb/view.php?id=1769

Regarding 2269, the committee felt that the semantics are well
defined.

Matt
--
Matt Maidment
mmaidmen@ichips.intel.com
 
 

>-----Original Message-----
>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
>Behalf Of Stuart Sutherland
>Sent: Tuesday, March 25, 2008 12:20 PM
>To: Bresticker, Shalom; sv-bc@eda.org
>Subject: 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.
>
>

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