RE: [sv-ec] virtual interfaces restriction

Dave,

There was one additional concern. If we allow dynamic handles (classes and virtual interfaces) as part of the implicitly generated sensitivity lists, we have one undefined issue:

-       Is the process triggered when the class becomes null? Presumably, it should but that will likely result in fatal error (indeterminate behavior according to the LRM).

In addition, we had concerns regarding evaluation of sensitivity list with multiple variables, where one may be a null (or un-initialized) class handle. For example:

always_comb y = vi.a + b;

If b changes while vi is null, should that result in an error as well. This one may be difficult for users to code in a way that guarantees the virtual interface is properly initialized before the (first) evaluation of the sensitivity list. Similar for continuous assignment: assign y = via. + b;

Other than these issues, I agree with your assessment.

Arturo

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Rich, Dave
Sent: Thursday, January 15, 2009 10:53 AM
To: Daniel Mlynek; sv-ec@eda.org
Subject: RE: [sv-ec] virtual interfaces restriction

I believe the restriction is the same as what's written in 6.21, "References to automatic variables and elements or members of dynamic variables shall be limited to procedural contexts."

The text mentioned in mantis 1441 is really referring to implicitly generated sensitivity lists created in non-procedural contexts. All it really need to say is "limited to procedural contexts"

always @(vi,a) $display(vi.a);

is equivalent to

always begin
            @(vi.a);
            $display(vi.a);
            end

And both are currently legal.

What's not currently legal is

always_comb $display(vi.a);
assign X - vi.a

The reason for the restriction is purely one of caution on the part of the SV-EC committee members at the time. They did not want to open up the functionality until gaining some experience with dynamic variables. I have seen the desire to connect class members to ports or continuous assignments and have been frustrated by this restriction.

A plausible case for relaxing this restriction is where the dynamic variable is statically initialized as a const and null handle reference are unlikely.

Dave



________________________________
From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On Behalf Of Daniel Mlynek
Sent: Thursday, January 15, 2009 6:11 AM
To: sv-ec@server.eda.org
Subject: [sv-ec] virtual interfaces restriction

Mantis 1441 complatins that sensivity list in virtaul interface usage restriction is not well defined.
http://www.verilog.org/mantis/view.php?id=1441
That is true that sensivity list should be defined.

But imho there is no sense for forbiding virtual interfaces on sensivity list as this is hard to define. The 2nd restriction about assign is ok - as vi was not added for design construct and assign is purely design one.
Summarizing I do not see the reason to forbid the code:

module top;
        iface if1();
        iface if2();
        virtual iface vi=if1;

        always @(vi.a) begin //vi on sensivity list
                $display($time);
        end

        initial
                forever @(vi.a)
                $display("2 %d",$time);
endmodule


--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

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