An important warning confused me--tri-state nodes do not directly drive top-level

[Altera_Forum]

Hi all, 

Recently I compile a project in Quartus 9.0 and make some changes.  The results comes out with some strange warnings:  Tri-state nodes do not directly drive top-level.  I look up in the project  {  entity bidir is  port(  clk : in std_logic;  enable:in std_logic;  data: inout std_logic_vector(7 downto 0)  );  end bidir;  architecture behavior of bidir is    component test  port(  datain :in std_logic_vector(7 downto 0);  clk : in std_logic;  enable :in std_logic;  dataout:in std_logic_vector(7 downto 0)  )  end component;  signal data_reg : in std_logic_vector(7 downto 0);  begin    u1: test  port map(  datain => data,  clk => clk,  enable => enable,  dataout =>data_reg --data_reg is tri-state register  );  data <= data_reg when (enable = '1') else (others = 'Z');    end behavior;  }  I simulate the code in the ModelSim platform and the result doesn't give such warning.  I'm not sure whether the warning will affect the real hardware function.  Could anyone give me some advice?(It's better not to change the codes)    Best Regards.

[Altera_Forum]

you wouldnt get this warning in modelsim, because it's to do with the physical chip you are compiling for. 

 Quartus has decided that you have logic internal to the FPGA that uses tri-state buffers. For some time now no FPGAs have internal tri-state drivers, they only exist on the device pins. If it detects internal tri-states from your code, it converts them to muxes, hence the warning.  It might be because you have dataout declared as an "in" on your test component. But without seeing the code for "test" thats about as much as I can gather.

[Altera_Forum]

also, you cannot declare an internal signal as in or out.

[Altera_Forum]

Thanks a lot. The 'test.vhd' as list 

LIBRARY ieee; USE ieee.std_logic_arith.all; USE ieee.std_logic_1164.all; USE ieee.std_logic_unsigned.all; ENTITY test IS  PORT(  reset : IN std_logic;   clk : IN std_logic;   enable : IN std_logic;   datain : IN std_logic_vector (7 downto 0);   dataout : OUT std_logic_vector (7 downto 0)   );   END test; ARCHITECTURE behavior OF test IS begin  process(reset,clk)  begin  if( reset = '1' ) then  dataout <= (others => '0');  elsif (clk 'event and clk = '1') then  if(enable = '1') then  dataout <= datain ;  else  dataout <= (others => 'Z');  end if;  end if;  end process;    END behavior;

[Altera_Forum]

Theres your problem. You're trying to tri-state your data out from the test component. It is just an output, so doesnt need tri-stating. The tri-stating is done at the top level.

[Altera_Forum]

I got it, but I still wonder whether this method will influence the final result. 

Thank you!

[Altera_Forum]

Declaring a signal type inconsistently in a component prototype and the actual entity code can result in strange unspecfic compilation errors and should be strictly avoided. (in versus out for dataout in the original code) 

 In the present design, there's no real purpose for tri-stating dataout of test, because it's the exclusive driver of the connected net in the design hierarchy.  Basically there are two purposes of tristatable signals in lower design entities; - driving an external tristate pin. No warning will be issued - driving an internal "virtual" tristate signal. This can be reasonable to implement bus-like bidirectional interconnecting signals, but has to be translated to muxes by the compiler, as said. Will usually give some warnings.  If you are interested to know how your behavioral code is implemented, look at the RTL and gate level netlist schematic view in Quartus.

[Altera_Forum]

--- Quote Start ---    In the present design, there's no real purpose for tri-stating dataout of test, because it's the exclusive driver of the connected net in the design hierarchy.   Basically there are two purposes of tristatable signals in lower design entities; - driving an external tristate pin. No warning will be issued - driving an internal "virtual" tristate signal. This can be reasonable to implement bus-like bidirectional interconnecting signals, but has to be translated to muxes by the compiler, as said. Will usually give some warnings.  --- Quote End ---     Thank you for help.   The 'test' model is a common module used many times in my project. The 'dataout' port should be set as 'Z' when the enable signal is '0'. or it will get errors. such as list u1: test port map( sel => enable1, dataout =>data_reg, .... ); data <= data_reg when (ebable1 = '1') else (others => 'Z'); u2:test port map( sel => enable2, dataout =>data_reg,  .... ); data <= data_reg when (ebable2 = '1') else (others => 'Z'); ....   if I set dataout as '0' when 'sel' is '0' or keep the value as same as before.The compiler will give errors: can't be assigned more than one value.   Best Regards.

[Altera_Forum]

the thing is, data out from test is decared as an OUT so tri-stating it is useless, as nothing can drive into it.

[Altera_Forum]

--- Quote Start ---  the thing is, data out from test is decared as an OUT so tri-stating it is useless, as nothing can drive into it.  --- Quote End ---   Honestly, I'wasn't sure about the effect of defining dataout as output but tristating it. Apparently the compiler doesn't complain about. But I never use out type for a tristate port, always inout.    --- Quote Start ---  if I set dataout as '0' when 'sel' is '0' or keep the value as same as before.The compiler will give errors: can't be assigned more than one value.  --- Quote End ---   This will surely happen, if the connecting signal data_reg is driven otherwise. But it isn't in the code you have presented. So you are apparently talking about different code.  That's the problem when presenting only snippets for the discussion. People can only refer to things, that are shown within. If you have any open questions related to your code, please provide a full example, that reproduces the problem.

[Altera_Forum]

Thank you very much. 

I try to run in the hardware and watch the result. Then I'll provide a whole code of my project later. Thanks again.

[Altera_Forum]

Hello,  

I dont know if this the right place to this quetion, but some one know how obtain the capacitance of instances in a netlist file from Quartus II tool.  I need to use the netlist file from Quartus tool, in the Nanosim tool from Synopsys, because there isn't any Altera tool to obtain the capacitance of a instance (resistor, transistor, capacitor, etc) of a FPGA design.  Thank you for help.

[Altera_Forum]

yes it they are really confusing, but some of them can be ignored, and will not make any effect in the program running