RE: [sv-ec] reference to class definition nested in module/program /interface

Hi,

It's a pity that there is no legal general way in a language to refer
externally type definition nested in some unit scope. This makes the
language inconsistent (in some extent) at the fundamentals.

SystemVerilog has its roots in Verilog, and in Verilog all the scopes are
'transparent' - any item declared in any scope has by default 'public'
visibility from any other point of code. The limitation for types access
breaks up this basic rule.

Language disallows hierarchical references to types, but do not provide any
other alternative for types access across hierarchy. There are constructs in
a language that could provide an alternative but they are locked too.


1) the '::' scope resolution operator

While in Verilog almost all declarations defined design-items, the
SystemVerilog introduces number of pure semantic items like: complex data
types, typedefs, class types, properties. Thus the SV design content can be
seen from two different prespectives:
    - the design stucture (hierarchy),
    - the code structure (ie.: classes hierarchy, scopes).

Currently LRM defines only limited version of the '::' - the 'class scope
resolution operator'.

By introducing a general purpose '::' scope resolution operator an
additional syntax and semantic power would be added to the language in a
clear way:

    - paths following design stucture (hierarchy) shall use '.' operator
    - paths following code structure shall use '::' operator,

    - also the '::' operator shall preserve it's role for accessing items of
packages and classes if only scope name is used on left side (it is code
structure again) - as it currently states in LRM 

in this way the path style would also explicitly denote the intent and the
compiler could report errors in case of missuse (additional code
validation).

(see how this is done in C++)


The general purpose '::' scope resolution operator and ierarchial reference
to type issues are even more general:

    SystemVerilog combines capabilities of advanced, modern SW languages
(C++, Java) and HW languages (Verilog, Vera, PSL).

    - there is number of (C++) good coding styles known from class and
template based libraries (ie.: STL), which cannot be easily re-used in SV
with design units, because of the lack of general '::' operator,  and at the
same time you can do the things with SV classes, one could argue that the
design units are not intended for these coding styles, but ...

    - SV design unit have been equipped with number of class features:
            - nesting,
            - typedefs,
            - type parameters,

        which makes design units almost equal (in semantic power) to the
classes and even the parametrized classes, while preserving their different
nature from classes : no dynamic allocation - rather than they build static
structure of design.

    Once you equipped design units with all these features, allowing '::'
operator too is just a consequence, and a lack of it is a kind of another
inconsistency in a language.

    General purpose ':: operator opens a bag of other problems in language
at the edge of parametrized design units and classes - they were discussed
recently in depth - but I think the right direction is to exclude them in
other ways than just restrict '::' operator use to the classes and packages
only.

    Could be that it is too late for 2008 revsion of the language to start
such change now, but if next revisions are planned than this issue shall be
addressed again ...


2) local redefinition of hierarchically referred type as described in 4.9
P1800-2005

unfortunatelly this construct is limited only for interfaces :(

moreover it require to refer the (far) type thru the port (of interface
type) - which is a design item (the port) - in order to access the code item
(the type) finally, 
it is like you would need to declare class variable only for be able to
refer to the typedef nested in a class, but of course you do not need to do
this, 
and this make one more inconsistency in a language rules.

Regards,
Mirek 

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: 11 października 2007 15:48
To: danielm
Cc: sv-ec@server.eda.org; 'Mirek Forczek'
Subject: Re: [sv-ec] reference to class definition nested in module/program
/interface

Neither case is legal.

As you correctly note in (2), the "::" can't be used with module design
units.  (1) is illegal since the LRM explicitly disallows hierarchical
references to types (See 4.9 in P1800-2005 or
6.18 in 2008 draft 3).

There are two ways to address this in your example -- move class C into the
compilation unit or move it into a named package.

If "tb" was a child instance, you could also pass the type C as a type
parameter.

Gord.

danielm wrote:
> I wonder if it is legal to define variable based on class type nested 
> in other module  - example:
>  
> 
>     module top;
>         class C; int i; endclass
>     endmodule
>      
>      
>     module tb;
>         top.C c=new;  //1 declaration of C type object via '.'
>     //vs
>         top::C c=new; //2 declaration of C type object via '::'
>     endmodule
> 
>  
> 2nd is imho explicitly forbidden by LRM because :: can be used only on 
> class packages.
>  
> but what about 1st case? is it legal?
>  
>  
> DANiel
> 
> --
> This message has been scanned for viruses and dangerous content by 
> *MailScanner* <http://www.mailscanner.info/>, and is believed to be 
> clean.

--
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


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