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

Shalom writes --

>Normalized ranges are used in several places in the standard, notably
in
>the DPI. The normalized range for packed dimensions in [n-1:0], whereas
>for unpacked dimensions it is [0:n-1]. I personally find *that*
>confusing, but I understand the desire for compatibility with C.

That's why the following Mantis request was rejected

  logic [P] id; should mean logic [P-1:0] id;
  http://www.eda-stds.org/svdb/view.php?id=325

That reminds me of another rejected Mantis request

  Add unpacked-to-packed cast
  http://www.eda-stds.org/svdb/view.php?id=1401

-- Brad

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Bresticker, Shalom
Sent: Wednesday, March 26, 2008 2:31 AM
To: stuart@sutherland-hdl.com; sv-bc@eda.org
Subject: RE: [sv-bc] E-mail Ballot: Respond by 8am PDT, Tuesday, March
25

Stu, 

> [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.

As Matt wrote, the committee agreed that it would be better for the two
versions of $fatal to have exactly the same syntax. The reason that the
run-time $fatal has a finish_number argument is that $fatal calls
$finish and passes the argument to $finish. (The disadvantage is that
$fatal then has a different syntax from $error and the other severity
tasks, but that is already true for the run-time tasks.)

> Another already approved Mantis item does allow bit and 
> part-selects of
> abstract expressions.  

I believe you are referring to Mantis 1197. It does not allow selects on
abstract expressions, only on concatenations. We were unable to achieve
consensus on selects on arbitrary expressions, but allowing them on
concatenations covers most of the useful cases.

That is what I wrote that {foo[0:47]} is a [47:0] vector.

Normalized ranges are used in several places in the standard, notably in
the DPI. The normalized range for packed dimensions in [n-1:0], whereas
for unpacked dimensions it is [0:n-1]. I personally find *that*
confusing, but I understand the desire for compatibility with C.


> 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.

Basically, that is the same argument, part of it anyway, that we had
about selects on arbitrary expressions and we did not achieve consensus
on.

Remember that the argument of the size cast is not necessary a single
variable, it can itself be an expression. What about 32'(a+b)? 32'((a))?
32'(a[3:0][0:7])? It starts to be extremely confusing. It is much easier
to define a single rule that holds for all cases.

It was also agreed that in practice today, it makes almost no practical
difference, except for $typename(), because you can't make a select on
an arbitrary expression. But it was also agreed that in the future, it
is likely to be more important and it is desirable to specify the result
types precisely now in order to avoid problems in the future.

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.