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

Hi Jonathan,

I didn't suggest normalizing all sub-types to [N-1:0]. I suggested
leaving the "original" type as is. So to select the leftmost bit of the
return value of the function in your example, I would want to write
something like func()[50].p[5][20], which I think is clear both
syntactically and semantically. The type of first operand of the part
select (the func()) would be the original "Thing".

The "normalized" [N-1:0] type is only necessary for expressions that are
operators (with the possible exception of the conditional operator). For
expressions like "a", "(a)", "func()" or "smth[5][25]", the type should
match the type of the corresponding declaration, or, in case of the part
select, should match a corresponding "slice" of the selected type
(without "normalization").

--Yulik.

-----Original Message-----
From: Jonathan Bromley [mailto:jonathan.bromley@doulos.com] 
Sent: Wednesday, March 07, 2007 4:13 PM
To: Feldman, Yulik; Bresticker, Shalom; sv-bc@server.eda.org
Subject: RE: [sv-bc] part selects on arbitrary expressions

[Shalom]
From those points of view, using concatenations, i.e., allowing 
bit-selects and part-selects of concatenations, is much less 
ambiguous. It is only a partial solution, in that it would 
only deal with 1-D arrays
[Yulik] 
...For me, a solution that will not account for complex 
data types will not be really a solution.

As Mike McNamara has wisely suggested, you could
reasonably use concatenation braces {} to imply flattening
of a self-determined expression so that its outermost subscript
range is of the form [N-1:0], although it's important to note
that this would represent a subtle change of the data type of
the expression.  But Yulik seems to want to similarly flatten
*all* subscript ranges, right the way down through the whole
structure of the expression.  

I find this completely unacceptable unless we have some new 
syntax to do this subscript-normalisation explicitly.  For
example, we could borrow the style of bitstream operators
and do this (only an example, I'm not advocating this
specific syntax):

  {[]{ expression }}

where the [] "operator" is taken to mean "create a primary 
having the same data type as expression, but with all its
subscript ranges normalised to [N-1:0]".  You could then
do arbitrary subscripting and selection like this...

  typedef struct 
    logic [20:21] p[5:7];
    byte q;
  Thing [50:48];

  function Thing func(...) ... endfunction

Given those declarations, the expression

  {[]{ func(...) }} [2].p[2][1]

would now reliably represent the extreme leftmost
bit of the struct returned by func().

Without some completely new syntax, slicing and
selection on expressions is always going to be 
a mess and it must be rejected.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: +44 (0)1425 471223                   Email:
jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web:
http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

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