Warning: Removed fan-in from always-disabled I/O buffer

Question

Hello Forum! This is my first post/question...

I built a 16 bit register that connects to a tristate bus, but when I try and write to the register I can't. I get a quartus (compiler?) warning that says:

Warning: Removed fan-in from always-disabled I/O buffer controlReg16:inst14|comb~31 to tri-state bus AD~0

Here is my vhdl code:

library IEEE;

use IEEE.std_logic_1164.all;

use IEEE.std_logic_arith.all;

use IEEE.std_logic_unsigned.all;

entity controlReg16 is

port(

nRegRE: in std_logic;

nRegWE: in std_logic;

nClr: in std_logic;

dataBus: inout std_logic_vector(15 downto 0);

cntrl: out std_logic_vector(15 downto 0);

debug: out std_logic_vector(3 downto 0)

);

end controlReg16 ;

architecture controlReg16_arch of controlReg16 is

signal register16: std_logic_vector(15 downto 0);

begin -- controlReg16_arch

reg16: process (nRegWE, nClr, dataBus)

begin

if (nClr = '0') then

register16 <= X"0000"; -- register is used for active high signals

elsif (nRegWE'event and nRegWE = '0') then --if this is a register write

register16 <= dataBus; -- latch bus contents in register

end if;

end process reg16;

dataBus <= register16 when (nRegRE = '0') else

"ZZZZZZZZZZZZZZZZ";

cntrl <= register16;

debug(0) <= nRegWE;

debug(1) <= dataBus(0);

debug(2) <= register16(0);

end controlReg16_arch;

the funny thing is that if I remove the event requirement from the register write, i.e. "elsif ( nRegWE = '0') then" then it does work! but I still get the compiler warning!

So what's going on here? Why does the compiler think the buffer is always disabled? And why does it work if I remove the requirement for a clock edge? thanks in advance for your help!

altera_forum · Answer

I have not checked whether this will solve the problem you described, but remove dataBus from the process sensitivity list.  That list should have just the clock and the asynchronous inputs (asynchronous reset in this case).  See the documentation referenced at http://www.alteraforum.com/forum/showthread.php?p=3369#post3369 for coding guidelines.

altera_forum · Answer

Hi Brad!

Thanks for responding! I tried your suggestion, and removed "dataBus" from the sensitivity list. This didn't eliminate the compiler warning or fix the problem where I can't write to the register. Is there something else I can try? Thanks again for the help!

Tom

altera_forum · Answer

When I compile your code with the sensitivity list fixed, the only remaining issue I see is the warning below, which might or might not matter for your application. You probably have a mistake in the file (which I suspect is a schematic) that instantiates controlReg16. The top-level file must not have another tristate buffer (you already have the tristate buffer inside controlReg16), and the top-level file must not have anything else driving out on AD[0].

--- Quote Start ---

Warning: Output pin "debug_pin[1]" driven by bidirectional pin "AD[0]" cannot be tri-stated

--- Quote End ---

Help for the above warning, which is for debug(1) going directly to output pin debug_pin[1] at the top level in my test case:

--- Quote Start ---

Output pin "<name>" driven by bidirectional pin "<name>" cannot be tri-stated

--------------------------------------------------------------------------------

CAUSE: The specified output pin is driven by both the specified bidirectional pin and tri-stated logic. However, the current device does not support a tri-stated output pin. When the output pin is not driven by either the logic or the bidirectional pin, its output value is undefined.

ACTION: If the output pin is always driven by either the logic or the bidirectional pin, no action is required. Otherwise, insert an extra tri-state buffer before the output pin.

--- Quote End ---

altera_forum · Answer

Hi Brad,

Well, you are right on several counts! : ) First, the top level of my design is a schematic and second, there doesn't appear to be anything wrong with the register vhdl code that I submitted for your inspection.

A little clarification/history. I am reverse engineering an old design done by one of our engineers that is completely in schematic form ( represented as 7400 series IC's). I've been translating these "circuits" into VHDL and then replacing parts of the schematic with the modules I created. That way I can verify my vhdl modules prior to the time I use them in a new design. When I put that register module back into the original design it works! - no compiler warnings and the circuit behaves as expected.

So...apparently there is something wrong with the bus I've got the VHDL module connected to in the new design. But just a point of clarification...there isn't any reason why I shouldn't connect other modules to the same tristate bus right? That's what the tristate is for!

Anyway, thank you very much for your help.

please check back to this thread 'cause I'll either explain what I found wrong or ask for some more advice! :)

Tom

altera_forum · Answer

--- Quote Start ---

But just a point of clarification...there isn't any reason why I shouldn't connect other modules to the same tristate bus right? That's what the tristate is for!

--- Quote End ---

For any particular tristatable pin, be sure all your source files together produce a single tristate buffer. The VHDL code you showed produces its own tristate buffer. If there is another tristate buffer somewhere else for the same device pin, that's a problem. The device does not have an internal tristatable bus, only a single tristate buffer right at the pin. Synthesis might be able to combine multiple tristates in the HDL into a single one in the synthesis result, but it would be much better to write your HDL to describe a single tristate buffer that will map directly to the single one available in the device.

With a single tristate buffer on a particular pin, the input direction on that pin can feed as many things in the design as you want, and as many things as you want can be combined together in logic to feed the output direction. If you have multiple things internal to the FPGA sharing the same tristatable pin, I recommend having the inout VHDL port only in the top-level file.

Forum Discussion

Warning: Removed fan-in from always-disabled I/O buffer

7 Replies

Recent Discussions

USB-BlasterII mounts as "USB-Blaster variant"

Duplicate_hierarchy_depth / duplicate_register

Quartus messages web search goes to Intel

how to reduce clock skew between synchronous clock

Quartus - Users getting license Notification with new license applied