The particular example you have given below has to be illegal, because the override of the parameter 'T' is the parameter 'T' itself and 'T' has no default value. I see no reason to restrict interface port actuals more just because you can create loops in parameter overrides by misusing hierarchical references in the actuals. There are already many other ways of creating loops in parameter/type resolution. In test benches it is useful to use hierarchical references to interfaces in interface port actuals. -----Original Message----- From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Gordon Vreugdenhil Sent: Tuesday, January 08, 2008 8:24 AM To: SV_EC List; SV_BC List Subject: [sv-bc] Interface ports and hierarchical referencing The current LRM doesn't place any restrictions on the actuals for interface ports in an instantiation. I think that there has been an implicit assumption that interface flow is "downwards", but that has never been explicitly stated in the LRM. Consider the following: interface intf_def #(parameter type T); endinterface module top; child c(c.intf); endmodule module child(intf_def intf_inp); typedef intf_inp.T T; intf_def #(T) intf(); endmodule I don't think there is anything in the LRM that I can appeal to in saying that this is illegal. In general, how tight does everyone think the restrictions need to be? Should an interface port actual be required to be a simple name (meaning that it is either declared in a visible scope or is itself an interface port)? At a minimum, due to the type issues, when used as an interface port actual, I don't think you should be able to reference anything below the reference point. In addition, there would likely need to be restrictions regarding references through generates and array instances as well. Gord -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Jan 8 10:48:57 2008
This archive was generated by hypermail 2.1.8 : Tue Jan 08 2008 - 10:49:29 PST