Re: [sv-bc] Query on Virtual (parameterized) interface declaration

  Hi Brad,
"assignment compatible doesn't generally require same type", but "same
type" necessarily means they are assignment compatible, so I think it is
redundant. However, I think some more clear text is required here as you
correctly says LRM does not define "same type". I have filed Mantis 3185
for that.

But anyway, can you have answer regarding Kakoli's query? Please let me
know.

Regards
Surya

-------- Original Message --------
Subject: Re: [sv-bc] Query on Virtual (parameterized) interface declaration
From: Brad Pierce <Brad.Pierce@synopsys.com>
To: sv-bc@eda.org <sv-bc@eda.org>
Date: Monday, August 23, 2010 11:23:05 PM
> It's not redundant, because assignment compatible doesn't generally require same type. However, "same type" is not defined, because 6.22 says, "SystemVerilog does not require a category for identical types to be defined here because there is no construct in the SystemVerilog language that requires it."
>
> -- Brad
>
>
> ________________________________
> From: owner-sv-bc@eda.org [owner-sv-bc@eda.org] On Behalf Of Surya Pratik Saha [spsaha@cal.interrasystems.com]
> Sent: Monday, August 23, 2010 6:15 AM
> To: sv-bc@eda.org
> Subject: Re: [sv-bc] Query on Virtual (parameterized) interface declaration
>
> Hi,
> Further on this topic, I need to understand the meaning of following sentence mentioned in page no 686 of SV 2009 LRM:
>
> The actual values and types of those parameters shall match for an interface and virtual interface to be of the same type and to be assignment compatible (see 6.22.3).
>
> If the types of actual values are of the same type then it is redundant to specify "assignment compatible" as they are anyway assignment compatible. Or LRM wants mean something else. An elaborated example will be very much helpful for that. Is there any Mantis corresponding to that?
>
> Regards
> Surya
>
>
> -------- Original Message --------
> Subject: [sv-bc] Query on Virtual (parameterized) interface declaration
> From: Kakoli Bhattacharya<kakoli@cal.interrasystems.com><mailto:kakoli@cal.interrasystems.com>
> To: sv-bc@eda.org<mailto:sv-bc@eda.org>
> Date: Monday, August 23, 2010 12:57:30 PM
>
> Hello,
>
> Consider the following eg. related to virtual interface (parameterized) declaration
>
> interface intf1 #(parameter shortint size = 3,byte val1 = 8'd4,int val2 = 1) ();
>
> ......
> modport M1 (... , ....);
> endinterface
>
> module top (input var reg [1:0][7:0] in1,output reg [4:0] out1);
>
> intf1 #(7,4,2)I1 (); // ordered parameter assignment used for interface instantiation
>
> virtual interface intf1#(.size(7),.val1(4),.val2(2)).M1 virtual1 = I1; // named parameter assignment
> used for virtual interface declaration
>
> ....
> endmodule
>
> In the above example ordered parameter assignment is used for interface instatiation, but named
> parameter assignment is used for virtual interface declaration, however the parameter values
> are same.
>
> Some of the tools are failing at analysis for this.
> If named parameter assignment is used for interface instantiation also then it is passing, i.e
>
> intf1 #(.size(7),.val2(2),.val1(4))I1 ();
>
> If the interface is instantiated as above then passing.
>
> Now in the LRM (Section 25.9) an eg. shows that passing different parameter values is illegal but
> it is nowhere mentioned that the parameters have to be assigned in a similar manner (or have I missed
> any such clause?)
>
> Tools are also failing for the below given declaration form:
>
> intf1 #() I1 (); // interface instantiated using default values
>
> virtual interface intf1#(.size(3),.val1(4),.val2(1)).M1 virtual1 = I1; // declared using default values
> but it has been explicitly mentioned.
>
> How should the tools behave for such cases?
>
> Regards,
> Kakoli
>
>
>
> --
> 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.