[sv-bc] RE: virtual interface mantis items

Yes I agree.
The case that is an issue is when the parameter target of the defparam is not a parameter on the port
list of that interface or is a parameter of a sub instance of the interface.

I will rework the wording.

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

This case for example is not an issue:

interface intf#(p = 4);
  logic [p-1:0] x;
endinterface

module top;
intf#(8) i8();
intf#(8) i16();
defparam i16.p = 16;

virtual intf#(8) vi8 = i8;
virtual intf#(16) vi16 = i16;

initial
begin
  $display("size of vi8.x = ", $bits(vi8.x));
  $display("size of vi16.x = ", $bits(vi16.x));
end
endmodule

As long as the virtual interface is declared with the final parameter value of the instance, it makes no difference how the interface instance parameter value got set.

The problem case is when the defparam goes to a sub instance of the interface which is the virtual interface type.

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

Hi Mark,

regarding your first comment.
Which scenario do you think would be made illegal by my proposal in 2845 but should be fine?

It shall be illegal to assign an interface instance to a virtual interface if there is a defparam to a parameter of that interface instance or interface hierarchy and that defparam statement is declared outside the interface.
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.