🚀 go-pugleaf

> 
> I compiled them on VANTAGE spreadsheet and Model Technology V-System
> and got different results.
> 
> -EXAMPLE 1
> **********
> 
> LIBRARY ieee;
> USE ieee.std_logic_1164.ALL;
> 
> PACKAGE bizarre IS
> 
> CONSTANT X : std_ulogic:= std_ulogic'(to_x01(bit_vector'("00"))(1));
> 
> CONSTANT Y : std_ulogic:= to_x01(bit_vector'("00"))(1);
> 
> END bizarre;
> 
> One of the tools gives the report below while the other compiles it OK.
> 
> Error: LINE 6 * More than one interpretation found for this indexed expression
> Error: LINE 8 * More than one interpretation found for this indexed expression
> 
> My opinion is that there is no ambiguity.
> At worse the indexing operation needs to explicitly know the type and then only
> line 6 is OK.

The above IS ambiguous. Explanation follows -
Here are the few lines included from ieee.std_logic_1164 VHDL file
to help explain the problem.

-- 1    FUNCTION To_X01  ( s : std_logic_vector  ) RETURN  std_logic_vector;
-- 2    FUNCTION To_X01  ( s : std_ulogic_vector ) RETURN  std_ulogic_vector;
-- 3    FUNCTION To_X01  ( s : std_ulogic        ) RETURN  X01;
-- 4    FUNCTION To_X01  ( b : BIT_VECTOR        ) RETURN  std_logic_vector;
-- 5    FUNCTION To_X01  ( b : BIT_VECTOR        ) RETURN  std_ulogic_vector;
-- 6    FUNCTION To_X01  ( b : BIT               ) RETURN  X01;
 
Of these you are choosing 4, 5 explicitly by using type qualification -
ie bit_vector'("00"). 5 returns std_logic_vector and 4 returns std_ulogic_vector.
The first one when indexed gives you an element of std_ulogic, and the latter
gives std_logic. Now, std_logic is a subtype of std_ulogic, which implies
both have the same base type which is std_ulogic. Hence, you end up
with two interpretations, which is erroneous. The final type qualification
doesn't help in line 6 - std_ulogic'...  In fact that is redundant, 'cos
the LHS type is std_ulogic, and can be used to resolve overloading.

So, one of the systems is showing incorrect behavior (bug!). Our (Viewlogic)
full VHDL analyser caught this ambiguity correctly.

A workaraound -

PACKAGE bizarre IS

   CONSTANT X_ARR : std_ulogic_vector := to_x01(bit_vector'("00"));
   CONSTANT X : std_ulogic:= X_ARR(1);

END bizarre;



> 
> -EXAMPLE 2
> **********
> 
> -----------------------------------------
> ENTITY circuit IS 
> END circuit;
> 
> -----------------------------------------
> ENTITY framegen IS 
> PORT (
>       dclreg  : IN bit_vector(7 DOWNTO 0)
>      );
> END framegen;
> 
> -----------------------------------------
> ARCHITECTURE cpu68302 OF framegen IS
> 
> BEGIN --architecture
> END cpu68302;
> 
> -----------------------------------------
> ENTITY micint IS 
> PORT (
>       dclreg  : OUT bit_vector(7 DOWNTO 0)
>      );
> END micint;
> 
> -----------------------------------------
> ARCHITECTURE structural OF circuit IS
> COMPONENT micint
> PORT (
>       dclreg  : OUT bit_vector(7 DOWNTO 0)
>      );
> END COMPONENT;
> 
> FOR c1:micint USE ENTITY WORK.micint(structural);
> 
> COMPONENT framegen
> 
> PORT (
>       dclreg  : IN bit_vector(7 DOWNTO 0)
>      );
> END COMPONENT;
> 
> SIGNAL dclreg  : bit_vector(7 DOWNTO 0);
> 
> BEGIN
> 
> C1 : micint
> 
> PORT MAP(
>        dclreg   =>  dclreg
>         );
> 
> C2 : framegen
> 
> PORT MAP(
>        dclreg   =>  dclreg
>         );
> 
> END structural;
> 
> -----------------------------------------
> ARCHITECTURE structural OF micint IS
> BEGIN --architecture
> END structural;
> 
> -----------------------------------------
> CONFIGURATION conf68302_0 OF circuit IS
> FOR structural
>     FOR c2 : framegen 
>         USE ENTITY WORK.framegen(cpu68302);
>     END FOR;
> END FOR;
> END conf68302_0;
> 
> DESCRIPTION
> 
> I have a testbench named circuit made of 2 components
> framegen and micint.
> The component c1 is bound to the entity micint by a 
> configuration specification.
> 
> The component c2 is bound to the entity framegen by
> a configuration declaration.
> 
> For one tool i notice that if i reanalyze the architecture
> of micint, then the configuration declaration must be reanalyzed,
> whereas the other tool does not recompile the configuration.
> 
> Now per LRM PARAGRAPH 11.4 a given library unit is potentially
> affected by a change in any library unit whose name is referenced
> within the given library unit....
> If a library unit is changed,then all library units potentially
> affected by such changes must be reanalyzed before they can be 
> used again.
> 
> HERE micint is not referenced at all in configuration
> called conf68302_0.
> To my opinion there is no need to reanalyze the configuration
> after a change in a design unit which does not affect it.
> 

YOU ARE RIGHT!! In fact if you have a configuration specification 
(not declaration), the enclosing design unit doesn't depend on the 
architecture at all (even if you name the architecture) according to 
new VHDL92 rules. This makes more sense, 'cos you didn't step inside 
the architecture to configure it. And this is the way we support it.


-- 
Sunder Singhani
Viewlogic Systems,
ssinghani@viewlogic.com

-- 
-- 
Sunder Singhani
Viewlogic Systems,
ssinghani@viewlogic.com

In article <1993Jan4.225957.26359@viewlogic.com> sunder@viewlogic.com (Sunder Singhani) writes:
>
>The above IS ambiguous. Explanation follows -

IMHO, there is NO ambiguity.  Sufficient information is available.
 
>-- 4    FUNCTION To_X01  ( b : BIT_VECTOR        ) RETURN  std_logic_vector;
>-- 5    FUNCTION To_X01  ( b : BIT_VECTOR        ) RETURN  std_ulogic_vector;
> 
>Of these you are choosing 4, 5 explicitly by using type qualification -
>ie bit_vector'("00"). 5 returns std_logic_vector and 4 returns std_ulogic_vector.

So far, so good.  Yes, there are two candidates with the same parameter and
result profile.

>The first one when indexed gives you an element of std_ulogic, and the latter
>gives std_logic. Now, std_logic is a subtype of std_ulogic, which implies
>both have the same base type which is std_ulogic. Hence, you end up
>with two interpretations, which is erroneous. The final type qualification

Not so fast.  Just because the parameter/result profiles match doesn't mean
the declaration is ambiguous.  According to LRM 10.5 (The Context of Overload
Resolution) there is a list of rules to be considered along with syntax and
scope/visiblity rules.  The first of these is:

  "1. Any rule that requires a name or expression to have a certain type,
      or to have the same type as another name or expression."

Since this is a constant declaration with a default expression, the following
rule for interface objects (LRM 4.3.3) seems applicable:

  "...The type of a default expression must be that of the corresponding
   interface object."

This narrows the search down to a single choice.  Unless I've missed 
something, Model Technologies appears to be doing the right thing here.

Gary Beihl (gary.beihl@columbiasc.ncr.com)

Since this topic has raised up interest i include all answers i
received.

As you will notice there are various interpretations of the LRM.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: bgriffin@wv.MENTORG.COM (Brian Griffin)
------------------------------------------------------

There is an ambiguity here but it is not with the index expression it self (as
the error message would seem to imply) but rather with the function call within
the whole expression.  There are two possible to_x01 functions that would work
here.

    FUNCTION To_X01  ( b : BIT_VECTOR        ) RETURN  std_logic_vector;
    FUNCTION To_X01  ( b : BIT_VECTOR        ) RETURN  std_ulogic_vector;

The compiler does not have enough information to determine which function to
call.  Our compiler complains that:

// [Line:    6] Error: Ambiguous expression. Unable to resolve overloading.
//     One conflicting operation is:
//         Type is std_ulogic.
//     The second conflicting operation is:
//         Type is std_ulogic.
//     (from: Analysis/System-1076_semantic 0138)

// [Line:    8] Error: Ambiguous expression. Unable to resolve overloading.
//     One conflicting operation is:
//         Type is std_ulogic.
//     The second conflicting operation is:
//         Type is std_ulogic.
//     (from: Analysis/System-1076_semantic 0138)


Granted these error messages are no more clear then what you got with the other
analyzer, but the clue here is "overloading".  Overloading is only done with
subprograms and type literals.  Both of these functions return the same base
type but different subtypes.  The expression requires this base type but does
not disambiguate the SUBtype.  

I hope this helps.

>-EXAMPLE 2
>**********

I don't have an answer to your second question.  Sorry.


USE STD.DISCLAIMER.ALL;
--                                           __
-- bgriffin@mentorg.com                     /__)      . __
-- brian_griffin@mentorg.com               /___)_/-,_/_(_(_/V/_
--                                        /

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

FROM : VANTAGE

-------------------------------------ooOoo-------------------------------------
                                Vantage(Europe)

    Grove Court Business Centre            phone            +44 753 516464
    Hatfield Road,                         answer machine   +44 753 572450 
    Slough,                                fax              +44 753 571639
    Berkshire, SL1 1QU                     e-mail           johnw@vntguk
    UK                                     customer support support@vntguk

                               ------ooOoo------
100% IEEE-1076 VHDL  Source Code Debugger  Concurrent Compiler  Network License 
Integrated VHDL Schematics/Simulator  Read & Write Mentor/Valid/EDIF Schematics 
Logic Automation & ASIC libraries   Hardware Modeller   Gate Level Acceleration
-------------------------------------ooOoo-------------------------------------


Dear Pierre,

     I saw your email on comp.lang.vhdl about the dependencies  created  by
reanalyzing an architecture within a design hierarchy.

     I believe your understanding is correct except that the  configuration
'conf68302_0' *IS* potentially affected by the change to the architecture.

     In your example, you have part  of  the  component  binding  specified
within the architecture, and part within the configuration.  There are many
rules controlling the actions for binding (i.e.  checking  that  components
are  bound  uniquely).  In  this  case,  the  configuration  is potentially
affected by the change to  the  architecture  because  conflicting  binding
indications  may  have been added to the architecture that would affect the
configuration.

     Therefore, if the architecture is reanalyzed, the configuration has to
be looked at again.

     As an experiment, before you analyze the architecture, add the follow-
ing line to the architecture declarative part :-

                  FOR c2 : framegen USE ENTITY WORK.framegen(cpu68302);

After reanalyzing the architecture, you will now find that  the  configura-
tion  cannot be successfully analyzed because of non-unique binding indica-
tions. This is an example of  a  change  to  the  architecture  potentially
affecting the configuration - hence the requirements for reanalysis.

     I would be interested to hear if there are different  points  of  view
from other VHDL users.  Perhaps you could post this onto comp.lang.vhdl for
other people to comment on.

     Best Regards ( and Happy New Year!)

                                  John Wilson

beihl@ncrcol.ColumbiaSC.NCR.COM (Gary Beihl) writes:

> In article <1993Jan4.225957.26359@viewlogic.com> sunder@viewlogic.com (Sunder Singhani) writes:
> >
> >The above IS ambiguous. Explanation follows -
> 
> IMHO, there is NO ambiguity.  Sufficient information is available.
>  
> >-- 4    FUNCTION To_X01  ( b : BIT_VECTOR        ) RETURN  std_logic_vector;
> >-- 5    FUNCTION To_X01  ( b : BIT_VECTOR        ) RETURN  std_ulogic_vector;
> > 
> >Of these you are choosing 4, 5 explicitly by using type qualification -
> >ie bit_vector'("00"). 5 returns std_logic_vector and 4 returns std_ulogic_vector.
> 
> So far, so good.  Yes, there are two candidates with the same parameter and
> result profile.
> 
> >The first one when indexed gives you an element of std_ulogic, and the latter
> >gives std_logic. Now, std_logic is a subtype of std_ulogic, which implies
> >both have the same base type which is std_ulogic. Hence, you end up
> >with two interpretations, which is erroneous. The final type qualification
> 
> Not so fast.  Just because the parameter/result profiles match doesn't mean
> the declaration is ambiguous.  According to LRM 10.5 (The Context of Overload
> Resolution) there is a list of rules to be considered along with syntax and
> scope/visiblity rules.  The first of these is:
> 
>   "1. Any rule that requires a name or expression to have a certain type,
>       or to have the same type as another name or expression."
> 
> Since this is a constant declaration with a default expression, the following
> rule for interface objects (LRM 4.3.3) seems applicable:
> 
>   "...The type of a default expression must be that of the corresponding
>    interface object."
> 
> This narrows the search down to a single choice.  Unless I've missed 
> something, Model Technologies appears to be doing the right thing here.

You didn't include the declaration containing the reference, so I have to infer
things from some of your statements:

* I assume that the type mark of the constant is std_logic or std_ulogic.

* I assume that the initial-value expression consisted of an indexed name whose
	prefix was a function call.

Then:

I think the reference is ambigious because the overload resolution rules 
don't apply to indexed names.

Section 10.5 begins with "Overloading is defined for subprograms and for
enumeration literals."  The next paragraph reinforces that overload resolution
determines the meaning of occurences of operators and enumeration literals,
but not indexed names, slice names, etc.

The rules about "Any rule that requires a name or expression..." is involved
here, but not enough to resolve the function reference.  The expression must 
be of the same base type as the constant, but that only constrains the result 
type of the indexed name.  A known indexed name result type does not constrain
the indexed name prefix type (many array types could have the same element 
type).

Also, you said, "This narrows the search down to a single choice."  Again, I 
can't see the original code, but even if resolution address indexed names, 
would it make a difference?  Aren't Sunder's comments correct:

	"The first one when indexed gives you an element of std_ulogic, and 
	the latter gives std_logic. Now, std_logic is a subtype of std_ulogic,
	which implies both have the same base type which is std_ulogic."

What seemed to "narrow the search to a single choice"?

(By the way, in VHDL 1992, overload resolution applies to the "basic 
operations" of indexing, slicing, aggregation, assignment, etc., so an
analyzer will be able to resolve more cases.)
--
------------------------------------------------------------------------------
Daniel S. Barclay                    --who's still searching for a good 
CAD Language Systems, Inc.           signature, not liking any of his recent
Suite 101, 5457 Twin Knolls Rd.      feeble attempts to improve on the whiny:
Columbia, MD  21045  USA             Why can't _I_ think of a good signature?