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

[Altera_Forum]

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]

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]

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]

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]

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]

--- 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.

[Altera_Forum]

Hi Brad, 

 Right up front, I'd better say, again, thank you for helping me. I really do appreciate it! So, let me tell you what I found!  It turns out that the compiler warning that I get (removed fan in from always disabled... etc) when I try to put that register module in my design is being caused by the read enable(not) signal (which is supposed to put the register contents on to the bus). If I replace the register select line that I have the module connected to with one from a different part of the circuit, the compiler error goes away. So, this makes me suspect that there is something wrong with another module that I'm using that routes a signal read(not) on to one of 64 output lines based on an 8 bit address. I'll include the code below and if you see anything suspicious about it please let me know. The crazy part of this whole exercise is that when I model this code using modelsim everything works exactly like I expect it to!   entity registerRdWrSelect is  port  (   nRdIn : in std_logic;  nWrIn : in std_logic;  Addr : in std_logic_vector(7 downto 0);  nRd : out std_logic_vector(63 downto 0);  nWr : out std_logic_vector(63 downto 0)  ); end registerRdWrSelect;  architecture registerRdWrSelect_arch of registerRdWrSelect is   begin -- registerRdWrSelect_arch    readEnableNotSignalDemux:process(Addr, nRdIn)  begin  nRd <= (others => '1');  if nRdIn = '0' then  nRd(to_integer(unsigned(Addr))) <= '0';  end if;  end process;   writeEnableNotSignalDemux:process(Addr, nWrIn)  begin  nWr <= (others => '1');  if nWrIn = '0' then  nWr(to_integer(unsigned(Addr))) <= '0';  end if;  end process;    end registerRdWrSelect_arch;

[Altera_Forum]

Hi Brad! 

 Ok, I found the problem that was causing the "removed fan-in" error message. In another of the vhdl modules in the project I was simultaneously sending a register read and a register write signal. Once I corrected the timing of the register read signal, the error message cleared.  Thanks again for your help, I really appreciated having someone to discuss this with!   :)