We've run into another issue with types and virtual interface handling that we think warrants a restriction in the LRM. The basic issue is that the "type" of a virtual interface is not sufficient to permit compile/elab time type checking for assignments; run-time type checking is required even for non-class objects. The basic reason is that for types such as structs, each *instance* of the interface produces a new type which is NOT assignment compatible with other instances of the same interface. Example: interface viface12_iface; typedef struct { int a; } S; S a,b; endinterface module top; viface12_iface if2(); viface12_iface if1(); virtual viface12_iface ifv1, ifv2; initial begin ifv1 = if1; ifv2 = if2; ifv1.a = ifv2.b; // (A) ifv2 = if2; ifv1.a = ifv2.b; // (B) end endmodule It is clear that assignment (A) "ifv1.a = ifv2.b" should be illegal since ifv1 and ifv2 are not the same interface instance and therefore the structs are not compatible. Assignment (B), with the current LRM, should be legal since ifv1 and ifv2 are now *the same* interface instance and therefore ifv1.a and ifv2.a are now the same type. In general, any assignment through a virtual interface that involves a type defined by the interface with "type identity" rules for assignment compatiblity is going to be legal if and only if the virtual interfaces refer to the same interface. Worse, one would also have to dynamically check for other situations such as "ifv1.a = top.if1.b" which would only be legal if ifv1 happened to currently refer to "if1". It isn't obvious to us that the extra simulation complexity and performance cost is worthwhile considering that only the trivial cases would end up begin valid. So, we would like to gather some feedback about disallowing access through a virtual interface to values whose types are defined by the interface and where the types have "type identity" compatibility rules. In the example above this would mean that both (A) and (B) would become illegal. One would have to lift the type "S" out into a package (or pass it via a type parameter) in order to have the assignments be permitted. 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.Received on Fri Jan 5 07:29:11 2007
This archive was generated by hypermail 2.1.8 : Fri Jan 05 2007 - 07:29:41 PST