[sv-bc] RE: [sv-ec] Interface ports and hierarchical referencing

From: Rich, Dave <Dave_Rich_at_.....>
Date: Tue Jan 08 2008 - 09:38:39 PST
This was mantis 24. Perhaps it was trying to be too simplistic.

> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Vreugdenhil, Gordon
> Sent: Tuesday, January 08, 2008 8:24 AM
> To: SV_EC List; SV_BC List
> Subject: [sv-ec] 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 09:39:05 2008

This archive was generated by hypermail 2.1.8 : Tue Jan 08 2008 - 09:39:27 PST