[sv-bc] RE: virtual interface mantis items

I agree that interfaces with interface ports are problematical, especially generic interface ports like you used. I believe this could be fixed by making interface ports into full blown types, including the parameter overrides. Then the type of the interface port could be passed to the interface as a type parameter. This would allow you to specify the interface port type on the virtual interface as well.

There are some corner cases where hierarchical references are probably an issue. Clocking block expressions can be a hierarchical references and the clocking block signals have no declared type but instead infer their type from the expression. That might cause problems. However, the vast majority of hierarchical references that are now legal in the LRM do not cause any problems.

If you believe that hierarchical references to parameters are allowed in instance overrides (rather than this just being an error in the BNF), and you have some kind of upward resolving hierarchical references to a parameter in a sub interface instantiation, then that could cause the same problem that a defparam to an interface sub instance does.

If we allow hierarchical references to parameters in general constant expressions, as some people have proposed, then obviously that will completely blow up the idea of virtual interface types. That clearly cannot be allowed in an interface used with a virtual interface type, assuming we allow it at all.

From: Francoise Martinolle [mailto:fm@cadence.com]
Sent: Thursday, May 26, 2011 3:03 PM
To: Mark Hartoog; sv-ec@server.eda.org; SV-BC
Subject: RE: virtual interface mantis items

Mark,

Actually our tools do error out on those kind of interfaces when you have an interface port
or the interface contains a xmr.

Here is a testcase where I think we should error out because vi3 and vi2 are not equivalent virtual interface types.
But since the virtual interface types does not take into account the interface port, we cannot check that.

interface IFC (interface i);
   typedef i.typ mytyp;
   bit [0:$bits(mytyp) -1] v;
endinterface

module top;
   i #() i3();
   i #(2) i2();

   IFC IFC3 (i3);

   IFC IFC2 (i2);

   virtual interface IFC vi3 = IFC3;
   virtual interface IFC vi2 = IFC2;

   initial begin
     $display ("%b", vi3.v); // this should print 0000
      vi3 = vi2;
     $display ("%b", vi3.v); // this should print 000
   end

endmodule // top

interface i #(parameter p = 3);
   typedef logic [p:0] typ;

endinterface // i

I still have to come up with a similar example for hierarchical references inside the interface to show that it should be disallowed.

Francoise
       '

________________________________
From: Mark Hartoog [mailto:Mark.Hartoog@synopsys.com]
Sent: Thursday, May 26, 2011 2:33 PM
To: Francoise Martinolle; sv-ec@server.eda.org; SV-BC
Subject: RE: virtual interface mantis items
I think it would be useful to discuss this, but we need to be practical about this. For example, there is a proposal for 2845 which in my opinion is too restrictive. It makes illegal some cases that work perfectly fine and cause no problems. That will almost certainly cause more confusion about what is legal with virtual interfaces.

Interestingly the text right next to the new proposed restriction is:

"Although an interface may contain hierarchical references to objects outside its body or ports that reference
other interfaces, it shall be illegal to use an interface containing those references in the declaration of a
virtual interface."

Are there any tools that actually disallow hierarchical references in interfaces used as a virtual interface?

There are a number of serious problems with virtual interfaces. Our previous discussion have bounced back and forth between totally new language constructs that make virtual interfaces completely obsolete and overly restrictive changes that vendors will never be able to enforce because of backwards compatibility problems. I don't think either of those kind of changes are worth discussing. The totally new constructs to replace interfaces is not going to happen in this next revision and the overly restrictive changes don't help because vendors can't really enforce those restrictions.

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Francoise Martinolle
Sent: Thursday, May 26, 2011 10:46 AM
To: sv-ec@server.eda.org; SV-BC
Subject: [sv-ec] virtual interface mantis items

Have we given up on discussing the issues with virtual interfaces?
We have spent a few meetings brainstorming about it, we have gone in circles
and not concluded anything. Customers use virtual interfaces and interfaces today.
I would really like to pick this back up in the next meeting, because we have outstanding issues
described in mantis items 2848 and 2845 that contradict the virtual interface type definition compatibility.

If at all, since this version of the standard is supposed to resolve ambiguities and issues in the LRM
we should be putting restrictions on what an interface connected to a virtual interface
can contain as a measure of safety.

Mehdi, I would really like to put this for discussion on the agenda for next meeting.

Francoise
       '

--
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.