$sv-ec Re: SVTestbench.pdf


Subject: $sv-ec Re: SVTestbench.pdf
From: sv-xx@grfx.com
Date: Sat Nov 16 2002 - 12:02:03 PST


David Smith wrote:

>Greetings,
>I have posted a new document up on the SV-EC website at
>http://www.eda.org/sv-ec/SVTestbench.pdf .
>
Comments:

 1) Reference Syntax (Classes,Semaphores,Mailboxes..)
 
    The syntax for declaring many objects which are created dynamically
would
    clash with declaring elaboration-static objects. Since the
Test-bench introduces
    'var' I would suggest that all dynamically allocated objects are
declared using
    the syntax : "var <type> <name>", rather than just "<type> <name>",
e.g.:

        myClass obj = new;

     becomes

        var myClass obj = new;

     "myClass obj" would permanently allocate a class object at
elaboration time
    in a module scope.

    Note: I still think that "var" should not become a keyword, and
that references
    should be declared with a C++ style syntax:

        myClass &obj = new;

    Failing to make a syntactic distinction between references and
 (scope) permanent
    objects will probably cause major problems with later language
extensions. E.g.
    you can't be sensitive to changes in dynamic objects, so if you
wanted to be sensitive
    to a class member it would be necessary to declare it statically
in $root or a module.

2) Mailboxes (and Channels)

    I'd like to be able to be sensitive to mailboxes being "ready" (a
message has arrived)
    using the @ syntax - otherwise I'd have to poll it, which makes it
synchronous. I'd
    also like to optionally type the data sent through the mailbox:

        mailbox byte &mychan = b_pipe;
         byte data;

        always @(b_pipe) begin
            b_pipe.get(data);
         end

    I would also like to be able to bind a mailbox to a (Unix) file
descriptor as per the
    channel proposal, i.e. add the method "bind", e.g.:

        mychan.bind(0,1); // bind channel to standard I/O

    [I would also like to be able to use assingment operators directly
on mailboxes, but
     I think we can address that in 3.2; maybe as part of general
operator overloading.]

3) Events

    Is there a way to declare the various values used with events
(ALL,ANY,ORDER...,
    ONE_SHOT...) as enums in an optionally included header file so that
they don't
    become kewords?



This archive was generated by hypermail 2b28 : Sat Nov 16 2002 - 12:03:51 PST