In Bugzilla #131 Peter points out an unexpected situation with VHDL-2002 clause 10.4 case b (VHDL-200X clause 10.4 case c). Here is Peter's comment: ...two potentially visible declarations that are subprograms or enumeration literals are made directly visible, without mention of whether they are homographs or not. If both are explicitly declared and not homographs of something in the using region, then neither a) nor b) applies, so c) makes them both directly visible. I presume that this long-standing rule is what people refer to when they say you can't use homographs from different packages. The common wisdom is that neither becomes directly visible. But it would seem more accurate to say that both become directly visible, and thus a reference to them is ambiguous. If that understanding is correct, would it be clearer to add to the end of c) something like "and they are not homographs"?wo potentially visible declarations that are subprograms or enumeration literals are made directly visible, without mention of whether they are homographs or not. If both are explicitly declared and not homographs of something in the using region, then neither a) nor b) applies, so c) makes them both directly visible. I presume that this long-standing rule is what people refer to when they say you can't use homographs from different packages. The common wisdom is that neither becomes directly visible. But it would seem more accurate to say that both become directly visible, and thus a reference to them is ambiguous. If that understanding is correct, would it be clearer to add to the end of c) something like "and they are not homographs"? I was surprised to see this. I always thought that two potentially visible subprograms were not made directly visible if they were homographs. So I created a small test case (attached) and discovered that the Modeltech implementation does make both visible. This might not be a crucial issue, since it mainly affects the error message produced when a design references such a subprogram. I'm curious about what other tools do (Larry and Ajay?) and also whether we should change the LRM as Peter suggests. Chuck Swart -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. package p1 is function foo return integer; end p1; package body p1 is function foo return integer is begin return 1; end; end p1; package p2 is function foo return integer; end p2; package body p2 is function foo return integer is begin return 1; end; end p2; use work.p1.all; use work.p2.all; entity top is end top; architecture a of top is signal s1 : integer := foo; begin -- a end a;Received on Mon Aug 6 09:04:19 2007
This archive was generated by hypermail 2.1.8 : Mon Aug 06 2007 - 09:04:21 PDT