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

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.

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;

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

Thank you!

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.

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

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

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.