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

Hi Mac,

Here are examples of expressions returning complex data types. If these
expressions are put in {} and their data type is normalized to [N-1:0],
it will be impossible to apply "complex" part selects, such as
"expr[i][j+:4].m", on them.

1. A simple identifier. This is already allowed, so there is no problem.
2. A simple identifier in parenthesis. It is not currently allowed to
apply part select on an identifier in parenthesis, but there should be
no problem to allow that.
3. A part select (in parenthesis or not). It may be very handy to apply
a part select on another part select. One good example is Dmitry's
example in the beginning of this mail thread.
4. A type operator. Applying a part select on a type operator may also
be very useful.
5. A conditional operator, whose then/else operands have the same type,
which can be a complex type. It may be nice to extend the language to
specify that the type of such conditional operator is the same as the
type of the then/else operands. Then, applying a part select on them may
be quite useful.
6. An assignment pattern.
7. An assignment operator.

This is not a complete list; it is just what came to my mind without
thinking too much.

--Yulik.

-----Original Message-----
From: Michael (Mac) McNamara [mailto:mcnamara@cadence.com] 
Sent: Wednesday, March 07, 2007 4:54 PM
To: Feldman, Yulik; Steven Sharp; Arturo.Salz@synopsys.com; Bresticker,
Shalom; sv-bc@eda.org
Subject: RE: [sv-bc] part selects on arbitrary expressions

I will look for this explaination when I get into my office, as this
does makes sense to me.  What expression can be in () that cannot be in
{}, for which a part or bit select makes sense?

Even if there is some small interesting class of such expressions, I
would submit that it would still be more reasonable to use {} for the
majority, and require assigning to a temp and selecting from that for
these complex datatype expressions you describe - for many reasons
including  enabling clear understanding of these complex expressions.

-mac   

mcnamara@cadence.com

 -----Original Message-----
From: 	Feldman, Yulik [mailto:yulik.feldman@intel.com]
Sent:	Wednesday, March 07, 2007 05:31 AM Pacific Standard Time
To:	Michael (Mac) McNamara; Steven Sharp; Arturo.Salz@synopsys.com;
Bresticker, Shalom; sv-bc@eda.org
Subject:	RE: [sv-bc] part selects on arbitrary expressions

As Shalom has already pointed out, concatenation will not work for
expressions that have a complex data type.

W.r.t. new modeling capabilities/succinctness, the main benefit this
feature will provide is the ability to perform arbitrary slicing in a
single expression tree, without introducing artificial variables and
assignments. As of now, Verilog expressions provide means to express
very complex logic, but for some reason they do not provide a way to do
a simple slicing operation of another expression.

--Yulik.

-----Original Message-----
From: Michael (Mac) McNamara [mailto:mcnamara@cadence.com] 
Sent: Wednesday, March 07, 2007 2:25 AM
To: Steven Sharp; Arturo.Salz@synopsys.com; Bresticker, Shalom; Feldman,
Yulik; sv-bc@eda.org
Subject: RE: [sv-bc] part selects on arbitrary expressions

I agree that this enhancement adds no new modeling capability - it just
delivers some succinctness. (most every language feature after turing's
Mark and Advance commands are of this form) 

To restate my point succinctly, were folks to still wish to deliver this
enhancement, I would guide to using the concatenate rather than defining
a new meaning for a parentetical grouping.

-mac

mcnamara@cadence.com

 -----Original Message-----
From: 	Steven Sharp [mailto:sharp]
Sent:	Tuesday, March 06, 2007 04:02 PM Pacific Standard Time
To:	Steven Sharp; Arturo.Salz@synopsys.com;
shalom.bresticker@intel.com; yulik.feldman@intel.com; sv-bc@eda.org;
Michael (Mac) McNamara
Subject:	RE: [sv-bc] part selects on arbitrary expressions


>Are you suggesting we dispense with slicing altogether? 
>Shifting, masking, and casting are tedious and error prone.

Based on the discussion, there are complex issues that would
need to be resolved before allowing part selects on arbitrary
expressions.  Given that there is already a way of getting the
proposed functionality, I don't think the effort to work this
out is a high priority at this time.

In procedural code, an intermediate variable can be used to
hold the expression value and allow a part select.  In any
situation where an intermediate variable is not a possibility,
the functionality can still be obtained with a shift and cast.

Steven Sharp
sharp@cadence.com

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