Potential difficulty with USE clauses

From: Chuck Swart - MTI <cswart_at_.....>
Date: Mon Aug 06 2007 - 09:03:59 PDT
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