Has Vivado unlearned to do type inference?

Question

I have masses of entity instances like that:

GPIO : entity L_PicoBlaze.pb_GPIO_Adapter
  generic map (
    [...]
  )
  port map (
    Clock    => CPU_Clock,   -- Clock : in STD_LOGIC;
    Reset    => '0',         -- Reset : in STD_LOGIC;  -- line 645
    [...]
  );

The code from above is working with:
- ISE XST 14.7
- Quartus II 13.x
- ISE iSim 14.7
I'm also sure, I successfully compiled my design with Vivado 2013.x !!!

Vivado (2014.4) Synth complains, that there are 3 possible type resolutions for '0':
[Synth 8-2396] near character '0' ; 3 visible types match here ["D:/git/.../PicoBlaze/System.vhdl":645]

Reset is declared as following:
Reset : in STD_LOGIC

I can solve this problem by using a qualified expression:

GPIO : entity L_PicoBlaze.pb_GPIO_Adapter
  generic map (
    [...]
  )
  port map (
    Clock    => CPU_Clock,
    Reset    => STD_LOGIC'('0'),  -- line 645
    [...]
  );

I think this (a) looks bad and (b) is a bug in Synth.

I think ISE XST and other tools are doing reverse/backward type inference to determine the correct literal type.

Has anyone encountered this problem, too?
Is my coding style so bad, if I write '0', x"00..00" or "00..00" in port maps?

Edit 1 - Minimal and Complete Example:

library IEEE;
use     IEEE.std_logic_1164.all;

entity top is
  port (
    Clock   : in  STD_LOGIC;
    Reset   : in  STD_LOGIC;
    OUTPUT  : out  STD_LOGIC
  );
end entity;

architecture rtl of top is
begin
  toggle : entity work.TFF
    port map (
      Clock    => Clock,
      Reset    => '0',            -- line 17
      Q        => Output
    );
end;

-- a simple toggle flip flop
library IEEE;
use     IEEE.std_logic_1164.all;

entity TFF is
  port (
    Clock   : in  STD_LOGIC;
    Reset   : in  STD_LOGIC;
    Q       : out  STD_LOGIC
  );
end entity;

architecture rtl of TFF is
  signal Q_r    : STD_LOGIC    := '0';
begin
  process(Clock)
  begin
    if rising_edge(Clock) then
      if (Reset = '1') then
        Q_r    <= '0';
      else
        Q_r    <= not Q_r;
      end if;
    end if;
  end process;
  Q    <= Q_r;
end;

Vivado 2014.4 Error message:
[Synth 8-2396] near character '0' ; 3 visible types match here ["D:/Temp/OverloadTest/overload.vhdl":17]

Edit 2:

I found a working example: I just put the declaration of entity tff in front the top-level declaration. It seams that a [Synth 8-2396] near ..... visible types match here error message from Vivado just a clumsy way to tell us, it can't find a reference to an entire component / file?

I'll need some time to recheck my file list (>300) for missing files/components.

Answer 1

This doesn't necessarily answer your question but does address your question in the comment chain:

So Vivado 2013.4 has the same problems :( ... I used an empty project and added one source file (see above). After that I hit 'Run Synthesis'. I also tried to enable VHDL-2008 with this TCL command: set_property vhdl_version vhdl_2008 [current_fileset] and run synthesis again -> no change. How can I contact Xilinx? Webcases are abolished ... the forum?

See AR# 62291, it appears you can still open new webcase questions via the open Webcase action.

The test case I wrote from your original snippet coincidentally has the declaration/specification order correct between the test case and it's direct entity instantiated unit under test (labelled GPIO):

library ieee;
use ieee.std_logic_1164.all;
-- use ieee.numeric_std.all;

entity pb_GPIO_Adapter is
    generic (foo: natural := 42);
    port (
    Clock:  in      std_logic;
    Reset:  in      std_logic;
    dummy:  out     std_logic
    );
end entity;

architecture foo of pb_GPIO_Adapter is

begin
DUMB:
    process (Clock, Reset)
        variable dumbit:    std_logic := '0';
    begin
        if Reset = '1' then
            dumbit := '0';
        elsif rising_edge(Clock) then
            dumbit := not dumbit;
        end if;
        dummy <= dumbit;
    end process;
end architecture;

library ieee;
use ieee.std_logic_1164.all;

entity fum is
end entity;

architecture fie of fum is
    signal dummy:       std_logic;
    signal CPU_Clock:   std_logic := '0';
    signal Reset:       std_logic;
begin
GPIO: 
    entity work.pb_GPIO_Adapter -- work substituted for L_PicoBlaze
        generic map (
           foo => 42
        )
    port map (
        Clock    => CPU_Clock,         -- Clock : in STD_LOGIC;
        Reset    => '0',               -- Reset : in STD_LOGIC;
        dummy    => dummy
    );
CLOCK:
    process
    begin
        wait for 10 ns;
        CPU_Clock <= not CPU_Clock;
        if Now > 200 ns then
            wait;
        end if;
    end process;
end architecture;

Notice I naturally (to me) got the analysis order correct. I meant to raise the order in your Minimum Verifiable and Complete example but that got snipped for length in the comment. You could also note long comment question and answer chains aren't searchable, anything garnered there is of no benefit to other stackoverflow users.

Looking at AR# 62291 (incidentally for Vivado 2014.3) We see under Solution -

The error occurs because an RTL file is out of sync and the type of a signal is not properly declared.

Notice the language isn't in VHDL terminology.

This qualifies right up there with Xilinx's previous arcane XST error messages and indicates there is still a need to at least analyze and elaborate design specifications before synthesis. We could have hoped for better. At least it's easier to find information by Xilinx's error code (e.g. [Synth 8-2396]) than for some competitors.

Anyway, that you got the same thing in your MVCe and the contents are in the wrong analysis order tells us it's fixable through drudgery.

You could also note in the AR# 62291 link there's an action item labelled open Webcase which will lead you to the WebCase Support Page where you can login and open a new Webcase question.

I think once you find the analysis order issue in your design and correct it you'll be back in business.

And the moral of this story is that Xilinx support on the web should be the point of first contact for relatively new Vivado issues.

To build up questions with answers with the vivado tag you could also answer your own questions. There are currently only six questions with the tag, it might help to attract more questions and answers. (None of the six Vivado tagged questions have accepted answers).

Answer 2

The wrong type overload resolution is caused by an earlier or later syntax error in the same source file.

Look for errors around the instance. Fixing all type overload problems will unveil that it's not related to types, but to another error. When you fix that error, you can revert all fixes for the type overloads and they will now work.