RE: [sv-ec] Access to class parameters in constant expressions and self class specialization

From: Mark Hartoog <Mark.Hartoog_at_.....>
Date: Thu Nov 08 2007 - 12:25:18 PST
I am basically ok with your ideas, although I have some comments
below. I would like to hear from some users to see if they agree with
this.
 
> > parameter p3 = $bits(C#(p0)::sx);
> 
> Probably -- the "::" allows access to statics.  I think one
> could reasonably argue that this is the same as $bits on
> a package declaration or other class declaration.
> 
> I don't like $bits in situations like this due to the
> interaction between variable decls and the interactions
> with their types.  In general, I wouldn't mind restrictions
> on $bits in this area, but I think that currently this
> should be legal.

There is no question this adds a lot of complexity to elaboration,
so I am sure tool developers don't like it, but users seem to 
like it. 
 
> > parameter p2 = v.Q;
> > parameter p4 = $bits(v.sx);
> > parameter p5 = $bits(v.x);
> > parameter p6 = v.y.QB;
> > parameter p7 = v.sy.QB;
> 
> I would prefer to not consider these as static.  I know that
> the LRM permits access to statics through a null handle but
> I think that it is more reasonable to say that the use
> via a handle is never considered constant.  Since the
> "::" accessing is a perfectly reasonable alternative, I
> don't think that this is an unreasonable approach.

I think there is an argument that you cannot access non-statics,
because the handle is null or not even null yet, but you are suppose
to be able to access static memebers through objects. We allow $bits
on struct field references. On the other hand we do not allow downward
parameter references into generate block parameters. 

It would simply implementations to not allow this, and you can always
use the :: reference to the statics.

Are users ok with forbidding all "." accesses through class handles
in constant expressions?

 
> > Combining these two, one could write:
> > 
> > class E #(P = 10);
> >    E #(P >1 ? P-1 : 1) x;
> >    localparam QE = x.QE;   
> > endclass
> > 
> > E#(E#(20)::QE) x;
> 
>
> I'm not sure which part you are troubled by.  I
> think the:
>     E#(E#(20)::QE) x;
> part is fine.  But the overall example isn't.
> 
> Consider the anchor case of E.  When you have E#(1), you get:
>       E#(1) x;
>       localparam QE = x.QE;
> but that is a problem because you effective have:
>       localparam QE = <self>::QE
> 
> I consider the example illegal for that reason.

Yes, you could rewrite it something like:

class E #(P = 10);
    E #(P >1 ? P-1 : 1) x;
    localparam QE = (P > 1 ? E #(P-1)::QE + 1 : 1);   
 endclass
 
 E#(E#(20)::QE) x;

Then it is possible to evaluate the parameter expression.
I'm not sure this type of expression is very useful, and
it probably introduces even more ways to create loops in
parameter evaluation which will be hard for users to 
understand, but I would not expect people to try to use
this very often either. 





-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Nov 8 12:25:42 2007

This archive was generated by hypermail 2.1.8 : Thu Nov 08 2007 - 12:25:56 PST