any way to avoid warnings about unused outputs in XST?

[Ken Cecka]

I think this has been asked before, but I haven't found a satisfactory answer. If I instantiate a component and leave some of the outputs unconnected, XST issues a warning about it. I like that behavior as it might indicate an output I forgot to connect.

However, if I explicitly connect that output to 'OPEN', I'm telling the compiler that I want to leave that output open, yet it still issues a warning. Are there any tricks to work around this?

(and no, ISE's Message Filtering feature is not the answer I'm looking for)

Ken

 

[Mike Treseler]

I'm telling the compiler that I want to leave that output open, yet it still issues a warning.
Are there any tricks to work around this?

I avoid this annoyance by using a direct instance
instead of a component.

-- Mike Treseler

 

[Ken Cecka]

I avoid this annoyance by using a direct instance
instead of a component.

-- Mike Treseler

I'm not sure I understand the difference - how do I go about using a direct instance?

Ken

 

[Ken Cecka]

I'm not sure I understand the difference - how do I go about using a
direct instance?

Ken

Does direct instance refer to when you us a library that declares the component so that you can create an instance without having to explicitly delcare the component in your architecture? I just noticed that I don't get warnings when I'm instantiating xilinx components that are declared in unisim, so I'm guessing I can put my components in a package and achieve the same result?

Ken

 

[Mike Treseler]

I'm not sure I understand the difference - how do I go about using a direct instance?

here's one:

dut : entity work.uart
generic map (char_len_g => tb_char_g, -- for vsim command line
overload
tic_per_bit_g => tb_tics_g)
port map (
clock => clk_s, -- [in] -- by tb_clk
reset => rst_s, -- [in] -- by tb_clk
address => address_s, -- [in] -- by main
writeData => writeData_s, -- [in] -- by main
write_stb => write_stb_s, -- [in] -- by main
readData => readData_s, -- [out]-- by uut
read_stb => read_stb_s, -- [in] -- by main
serialIn => serialIn_s, -- [in] -- by main,loopback destination
serialOut => serialOut_s -- [out]-- by uut, loopback source
);

 

[Mike Treseler]

Does direct instance refer to when you us a library that declares the component so that you can create an instance without having to explicitly declare the component in your architecture?

No, that's an indirect instance, correctly bound.

I just noticed that I don't get warnings when I'm instantiating xilinx components that are declared in unisim,
so I'm guessing I can put my components in a package and achieve the same result?

Thats how Xilinx does it.
Works fine if I don't mind
maintaining two interfaces
instead of one.

-- Mike Treseler

 

[Ken Cecka]

I'm not sure I understand the difference - how do I go about using a
direct instance?

here's one:

dut : entity work.uart
generic map (char_len_g => tb_char_g, -- for vsim command line
overload
tic_per_bit_g => tb_tics_g)
port map (
clock => clk_s, -- [in] -- by tb_clk
reset => rst_s, -- [in] -- by tb_clk
address => address_s, -- [in] -- by main
writeData => writeData_s, -- [in] -- by main
write_stb => write_stb_s, -- [in] -- by main
readData => readData_s, -- [out]-- by uut
read_stb => read_stb_s, -- [in] -- by main
serialIn => serialIn_s, -- [in] -- by main,loopback
destination
serialOut => serialOut_s -- [out]-- by uut, loopback source
);

Just found a previous post from you on the subject:
http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/6776632c8f686e91#c951a3ca8311ccc4

Apparently I've been spending all this time keeping component declarations synced up with my entities out of pure masochism

I'll definitely be making more use of direct instantiation, but it doesn't seem to solve the unused output warning. The example below (with or without the z line commented) generates an unconnected output warning.

Ken

LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;

ENTITY foo IS
PORT
(
x : IN STD_LOGIC;
y : OUT STD_LOGIC;
z : OUT STD_LOGIC
);
END foo;

ARCHITECTURE model OF foo IS
BEGIN
y <= x;
z <= NOT x;
END;

LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;

ENTITY tmp IS
PORT
(
x : IN STD_LOGIC;
y : OUT STD_LOGIC;
z : OUT STD_LOGIC
);
END tmp;

ARCHITECTURE model OF tmp IS

BEGIN

FOO1 : ENTITY WORK.foo
PORT MAP
(
x => x,
y => y
--z => OPEN
);
z <= '0';

END;

 

[Andy Peters]

I avoid this annoyance by using a direct instance
instead of a component.

Are you saying to do a direct instantiation and simply leave out the
unused (open) ports?

-a

 

[Mike Treseler]

Are you saying to do a direct instantiation and simply leave out the
unused (open) ports?

Yes.
I was assuming that the warning is due
to a mismatched component declaration.

-- Mike Treseler

 

[Ken Cecka]

Yes.
I was assuming that the warning is due
to a mismatched component declaration.

-- Mike Treseler

Unfortunately not. The Xilinx tools generate a warning any time there's an unused output, and it doesn't seem to matter whether I use a component or direct instantiation. I finally gave up and turned on a message filter.

Ken

 

[Andy Peters]

Unfortunately not.  The Xilinx tools generate a warning any time there's an unused output, and it doesn't seem to matter whether I use a component or direct instantiation.  I finally gave up and turned on a message filter.

Ken

I just confirmed what Ken says. The warning is the simple

WARNING:Xst:753 - "C:/Projects/foo/fpga/src/jack.vhdl" line 420:
Unconnected output port 'mdValid' of component 'meter'.

I'll continue to use the open keyword, which naturally causes XST to
throw the SAME EXACT COMPLAINT.

Yes, I created WebCase 674970 to address this stupidity. I even had to
create a simple project that showed this, and it's been entered as an
Enhancement Request, meaning it was routed to /dev/null/.

-a