RE: [sv-bc] part selects on arbitrary expressions

Greg (and by the way I had some small part in your simulator's
implementation of 1364-1995), this isn't so much about how one could
implement this upon the AST, but towards how one could make such an
addition to the language standard in a way that would appear natural to
someone (a) coming new to the language today, and (b) to one who is
already familiar with the language.  

{As an aside, with this post I believe I have made my point, and I will
leave it to you folks to take it or leave it from here, and I will go
bother other people for a while :-) } 

Section 4.4.1 through 4.5.4 of 1364-2001-C of the standard set out the
way expressions with mixed width and signedness shall be treated.  For
us to change this meaning means we have to change the wording on these
pages.   Right now Table 29 does not have an entry for an ()[] operator;
this would need to be added.  In truth, it doesn't have an entry for the
[] operator either; Verilog instead treats these as a form of an operand
(in Section 4.2), which may no longer be tenable, given this proposed
enhancement. 

Michael (Mac) McNamara wrote:
> Yulik, the problem is that as defined, the width of the stuff inside a

> parenthesis _is_ affected by stuff outside.  So your desire to instead

> get the "original" type as is requires a change to the language.

Greg responds gj>
gj> The propagation of widths and signedness occurs long after the
expression has been parsed.  
gj> Once it has been parsed, the left operand of a select lies "below"
it (i.e. leafward) in the parse tree.
gj> Such locations are /not/ context-determined.  Adding selects of
arbitrary expressions would not 
gj> require any change to existing practice in this regard.

But part and bit selects are not today defined as operators; they are
defined as operands (Section 4.2).  As such the operand value is found
first, and then the result of that is width & sign coerced.  Making
selects into operators (so they can operate on expressions) would
require a change in the spec, and also a definition of that change, so
that implementations would be consistent with each other.

gj> The problem of moving expressions from one source site to another
and preserving their meaning is 
gj> utterly hopeless in Verilog - because this language extension
increases the "self-determined" 
gj> space, I regard it as healthier than many of the alternatives
proposed for this feature.

I am not sure where this is coming from, but if you are looking for a
way to "inline" an expression from one source site to another and
preserve width and sign properties of the source expression in the
target expression, the {} operator is your ticket:

a = b + c;
...
d = a + e;

can be rewritten as

d = {b + c + $width(a)'b0} + e;


>   The
> change isn't per se breaking backwards compatibility, because 
> currently no standard compliant code does (a&b)[i].  However, 
> constructing the wording in the manual so that
> 
> assign y = x + (r&s);
> 
> retains the sign, size, and type coercion of r and s by x and y, while
> 
> assign y = x + (r&s)[5:3];

gj> Not a problem.  The same mechanism which prevents  assign y = x +
s[5:3] from coercing s before extracting
gj> the [5:3] part will halt the width coercion of (r&s)[5:3].

The mechanism that prevents coercion of s[5:3] in the standard is that
[] is currently defined as an operand.  This change makes [] an
operator, and then requires work in Table 29 to define the coercion
rules for this new operator, and removal of the [] as an operand from
4.2, et cetera.  What is done inside of VCS and DC and NC and MTI in
sizing the expression for 1364's allowed use of part and bit select
operands will need no change to reflect this (assuming the standards
body honors its duty to backwards compatibility), but that lack of work
is a boon to the engineer - the work I am describing is that for this
committee. (And don't send the lawyers at me but my recollection was
that we indeed treated partsel and bitsel as operators in VCS)

gj> But now that you've raised this point, let's be clear that the
signedness coercions would ALSO stop at 
gj> the selection node.

> does not will be a real challenge, especially in the very situations 
> where the expression is even more complex stretching over a few lines,

> and hence where not requiring assigning through a temp is most
valuable.
> 
> So:
> 
> reg [127:0] x,y;
> reg signed [31:0] r,s;
> integer i,j,k;
> 
> ...
> assign y = x + (r+s)[63:0];
> 
> have r and s extended to be 128 bits wide due to the "x +" part of the

> expression, so selection of bits
> 63 through 0 is legal, and would return known bits (the top bits would

> have the sign extended & overflow results of the addition)

gj> What?!

gj> I simply don't see what arithmetic fidelity is preserved by such a
madhouse of width coercions.  
gj> This view is also inconsistent with the treatment of  assign y = x +
s[63:0];  Unless I am 
gj> horribly mistaken, s is not first extended to 128 bits and then
truncated.  If I /am/ wrong about 
gj> this, I need to know immediately so I can correct our implementation
pronto.

Again, it is the fact that [] is currently defined as a form of operand
which delivers simultaneously the behavior which is consistent with your
view, and with what is described in the standard.  Making [] into an
operator will require re-writing the standard to become completely
consistent with what is currently your view of what happens, so this is
good, yes?

As for why there is this width coercion in the first place, we will have
to leave that at the feet of our favorite Kaufman award winner, as
perhaps one of his few mistakes, or maybe as a too-simple-solution for a
corner case encountered newly by language designers delivering one of
the first continuous-width-spectrum languages.




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