Vivado and Zynq: TRI-STATE help

Hi Jan,

Just create the tristate in an assignment and not in a process. Not sure why what you have isn't working, have you looked at the schematic for what it's creating in Vivado? I guess maybe it's inferred a latch you aren't expecting maybe?

tristate_pin <= '0' when reset_n = '0' else 'Z';
reset_out <= '1' when reset_n = '0' else '0';

Best Regards,

Rachael

It might be a problem with hierarchy with the drag-and-drop stuff. An answer to this support question suggests that you need to set the synthesis to flatten the hierachy so that the tristate-ness can propagate up from the block to the actual IO pin.

https://support.xilinx.com/s/question/0D52E00006iHuBxSAK/tristate-logic-not-implemented-in-20164?language=en_US

My interpretation of that is, what you're describing in the VHDL actually implies an internal tristate line from the block to the output driver, but, if you tell the synthesis to flatten everything, it then fudges things for you so that it's the output pin getting controlled.

An alternative approach to inference, if you can't make that work, is perhaps to try instantiating an IOBUF component. Page 203 of this 7-series guide shows how to do it from VHDL.

https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/7series_hdl.pdf

(Is your Zync a Zync-7000, or is it something else? If it's something else, you'll have to look for another document.)

/members/jancumps  Jan did you forget that tristate is only HIGH Z (not enabled depends on the chip0  then the output will show whatever is on the input. IN your print U2 basically, you have tied P1 to p10, p2 to pin 9, etc. I don't see your control lines if these are buffers (input, output, control). so double-check your logic or just use discreets. 

Hello Jan,

I'm with Rachael on this, do the tristate with some combinatorial stuff outside any process.

And remember that once you do that you can't alter the pin (cnf_rdy in my example) from within  the process.

The example is a bity long winded but illustrates the stuff you need, it's actually a thing for configuring blocks in a big design (but you don't need to worry about what it actually does !)

It did work OK under Vivado.

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.NUMERIC_STD.all;

entity conf_interface is
	 port(
		 clk_80 : in STD_LOGIC;
		 lres : in STD_LOGIC;
		 cnf_dat : in STD_LOGIC;
		 cnf_frm : in STD_LOGIC;
		 cnf_sck : in STD_LOGIC;
		 device_match : in std_logic;
		 accepted : in STD_LOGIC;
		 first_word : out STD_LOGIC;
		 data_ready : out STD_LOGIC;
		 data : out STD_LOGIC_VECTOR(15 downto 0);
		 cnf_rdy : inout std_logic
	     );
end conf_interface;

--}} End of automatically maintained section

architecture conf_interface of conf_interface is 

signal selected : std_logic;
signal cnf_frm_d1 : std_logic;	
signal ready : std_logic;  	
signal got_first_word : std_logic;
signal bit : unsigned(3 downto 0);	 
signal sr : std_logic_vector(15 downto 0);

TYPE t_cnf_state is (CNF_IDLE, CNF_0, CNF_1, CNF_2, CNF_3, CNF_4, CNF_5, CNF_6);
signal cnf_state : t_cnf_state;


begin

	cnf_interface : process(clk_80)
	begin
		if rising_edge(clk_80) then
			if lres = '1' then
				selected <= '0'; 
				cnf_frm_d1 <= '0'; 
				cnf_state <= CNF_IDLE;
			else 
				cnf_frm_d1 <= cnf_frm;
				if cnf_frm = '1' and cnf_frm_d1 = '0' then			-- rising edge always restarts config process
					cnf_state <= CNF_0;	
					got_first_word <= '0'; 
					bit <= "0000";
					ready <= '0';
					selected <= '0';
				end if;
				if cnf_frm = '0' and cnf_frm_d1 = '0' then	
					cnf_state <= CNF_IDLE;
					ready <= '0';
					selected <= '0';
				end if;	
				case cnf_state is 
					when CNF_IDLE =>	
					when CNF_0 =>									-- first word is the device code
						if cnf_sck = '1' then
							sr <= sr(14 downto 0) & cnf_dat; 
							bit <= bit + 1;
							cnf_state <= CNF_1;
							ready <= '0';
						end if;	
					when CNF_1 =>
						if cnf_sck= '0' then
							if bit /= 0 then
								cnf_state <= CNF_0;
							else 
								data <= sr;
								data_ready <= '1';
								if got_first_word = '0' then
									first_word <= '1';
								end if;
								got_first_word <= '1';
								cnf_state <= CNF_2;
							end if;
						end if;
					when CNF_2 =>  
						if device_match = '1'then  
							selected <= '1';
							if accepted = '1' then
								data_ready <= '0';
								first_word <= '0';
								ready <= '1';
								bit <= "0000";
								cnf_state <= CNF_0;
							end if;
						end if;
					
					when others =>	 
				end case;
			end if;					-- if lres = '1' 
		end if;						-- f rising_edge(clk_80)
	end process cnf_interface;

	cnf_rdy <= ready when selected = '1' else 'Z';

end conf_inte

Hope this helps.

MK

I tried it outside of a process too. Just assigned a fixed value 'Z' in the architecture. The effect was the same.

I had read about the flat levels and the IOBUF too. I wasn't able to find how to do these in Vivado. I'm going to check the resources you linked.

The tri-state pin isn't on the top level in my case. It's inside the VHDL of the i2c IP that I placed on that top level. Off to the manual...

On my pin input, I'm trying to put a logic high, by pulling it to 3.3 V with a pullup resistor. However, when I set it to high impedance, it's driven to 0 V by the fpga instead of going open collector as I expected.

It should be this simple, I've done several Xilinx designs recently, two targeting the Zynq Ultrascale+ and the above works for inferring the tri-state for me. There's nothing special I have needed to do in these to get Vivado to figure out the intention. I do always make sure my tri-states are at the top level of the hierarchy though so if the source is in a lower level I'll take an enable out of the lower level to the top level to control the tri-state.

I may need a holiday.

entity tristate_test is
    port ( 
    reset_n      : in std_logic;
    clock_in     : in std_logic;
    tristate_pin : inout std_logic);
end tristate_test;

architecture behavioral of tristate_test is

signal tristate_or_low : std_logic;

begin

clocked: process (clock_in, reset_n) is
begin
  if rising_edge(clock_in) then
    if reset_n = '1' then
      tristate_or_low <= '0';
    else
      tristate_or_low <= '1';
    end if;
    end if;


end process clocked;

tristate_pin <= 'Z' when tristate_or_low = '1' else '0';
  
end behavioral;

Block design: 

I tried a different pin too - the PMOD pin Y18 has protection diodes and I wanted to verify that this isn't interfering.
So I selected T14, the Arduino header signal AR0.

Same symptoms.

When I explicitly set the pin to '1' instead of 'Z', it goes to 3.3 V. But 'Z' gives me 0.0x V. The pull-up doesn't seem to be able to pull it away from 0 V.

I've tried the "flatten hierarchy" option. 

Re-synthesised and implemented. No success.
checking further ...