Re: [sv-ec] Questions/Issues on classes


Subject: Re: [sv-ec] Questions/Issues on classes
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Wed Mar 12 2003 - 12:04:05 PST


Message> The "parameter" declaration issue came from the new Verilog 2001 parameter list mechanism as opposed to the older method.

Yes, but in the case of parameterized classes, the in-line syntax makes a lot more sense since classes are not likely to contain as many parameters as modules, and this syntax is much closer to the one used by C++ templates :
    template <class parameter> class name ...
or Java generics:
    class name <parameter> ...

Thus, it is evident from the class header declaration that the class is parameterized.

 Arturo
  ----- Original Message -----
  From: Jay Lawrence
  To: Arturo Salz ; sv-ec
  Sent: Wednesday, March 12, 2003 11:37 AM
  Subject: RE: [sv-ec] Questions/Issues on classes

  See, I knew that wouldn't take long. Thanks for the response.

  The "parameter" declaration issue came from the new Verilog 2001 parameter list mechanism as opposed to the older method.
  Jay

  ===================================
  Jay Lawrence
  Architect - Functional Verification
  Cadence Design Systems, Inc.
  (978) 262-6294
  lawrence@cadence.com
  ===================================

    -----Original Message-----
    From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
    Sent: Wednesday, March 12, 2003 2:20 PM
    To: Jay Lawrence; sv-ec
    Subject: Re: [sv-ec] Questions/Issues on classes

    Jay,

    My comments are interspersed below in blue.

        Arturo

    ----- Original Message -----
    From: "Jay Lawrence" <lawrence@cadence.com>
    To: "sv-ec" <sv-ec@eda.org>
    Sent: Wednesday, March 12, 2003 4:57 AM
    Subject: [sv-ec] Questions/Issues on classes

    In the process of trying to write some examples of classes I found the
    following other nitty-picking problems with the current class
    definition that should be fixed and should be a quick vote or
    explanation.

    -------------------------------
    Declaration of class parameters
    -------------------------------

    The current syntax for class parameters in the examples is

    class Foo_c #(parameter type p_t);
    ...
    endclass

    This should be changed to be like module, interface, and program
    parameters:

    class Foo_c;
    parameter type p_t;

    ...
    endclass

        The current syntax for class parameters IS the same as for modules and interfaces.
        The examples use the same synatx as shown in section 18.6 (parametrized interfaces)
        and section 19 (Parameters).

    ---------------------------
    Declaration of 'new' method
    ---------------------------

    None of the examples show a type on the declaration of the "new" method

    class Foo_c;

    function new;
    enclass

    Is this OK or should we require/allow a type?

    class Foo_c;
    function Foo_c new;
    endclass

        The current syntax is intentional. The new method is the object constructor, not
        the object allocator. We could have chosen "function void" which would be more
        semantically appropriate (the constructor doesn't return a value, it only initializes
        the object). However, new is called as a function (it invokes the allocator which
        calls the constructor) so the declaration as a function is less confusing. C++ also
        uses special grammar for the declaration of constructors (it mandates no function
        return type, not even void) so SV's usage of new is consistent with that approach.

    -----------------------------
    Setting return value from new
    -----------------------------

    Is the "new" method allowed/required to set the return value?

    None of the examples show it.

    class Foo_c;

    function new;
    begin
    ...
    new = this;
    endfunction

    endclass

        See the comments above.
        In particular the statement "new = this;" is unnecessary (and illegal).

    ----------------------------
    Sensitivity of class objects
    ----------------------------

    Will a change on the value of 'x' or 'x.i' wake up the following event
    control?

    class C;
    int i;
    endclass

    C x;

    ...
    @(x)
    ...

        The donation explicitly disallows waiting on an object handle (this is
        documented in section 12.9:

            "The variables variable1,..., variableN can be any one of the integral data types
                  (see section 3.3.1) or string. Each variable may be either a simple variable, or a var
                  parameter (variable passed by reference) or a member of an array, associative-array,
                 or object (class) of the aforementioned types. Objects (handles) are not allowed."

        The reason why this is not allowed is to avoid the ambiguity raised by
        the statement above. There is no construct to wait for all of the elements of
        a class, but it can be written explicitly as @(x.a , x.b, x.c, ... ).
        Currently, the statement @(x) is illegal. If that were to be allowed, I would
        suggest that the consistent interpretation must be to wait for the handle to
        change and not the object's contents. Currently @ cannot be used to wait for
        agregates (unpacked structs and unpacked arrays), so not being able to wait
        on the object's contents is consistent with that usage. There are obvious
        performance reasons why that is not cirrently allowed.
        [ As an aside, section 12.9 needs to be reconciled with 8.9. $wait_var should
          be removed, and it's functionality folded into the event control ]

    ===================================
    Jay Lawrence
    Architect - Functional Verification
    Cadence Design Systems, Inc.
    (978) 262-6294
    lawrence@cadence.com
    ===================================



This archive was generated by hypermail 2b28 : Wed Mar 12 2003 - 12:03:06 PST