🚀 go-pugleaf

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