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

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

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.

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.

rachaelp, can you share the constraint file snippet that contains the config for the tri-state pin(s) for one of your Zynq projects?

And if it's no trade secret: an example of where and how you set the state of that pin, in VHDL. 

This is how I tried to implement the assignment out of process:
The LED tied to reset_out works, the tri-state doesn't go to high impedance. 

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity tristate_test is
    Port ( 
    reset_n: in std_logic;
    reset_out: out std_logic;
    tristate_pin : inout std_logic);
end tristate_test;

architecture Behavioral of tristate_test is

begin

reset_active: process (reset_n) is

begin
null;
end process reset_active;

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

end Behavioral;

The constraints file literally has nothing but the IO standard and the pin number assigned to the signal, I don't need to do anything special at all.

I'll see if I can dig out some code snippets tomorrow, usually my control signals will come out of a clocked process, often a state machine.

Have you tried looking in the implementation schematic to see what it's actually created? I've had to dig through that to figure out what it's done previously.

Checking the schematic. Highest level:

Drill down (red square is my annotation):

It indeed does not look like a bidirectional buffer with 3 states ... just a plain output driver with flip-flop in front of it 

What happens if you add to your code a line to also read from the INOUT port (and do something with it so it doesn't get optimised away - perhaps just send it out to another IO pin)? Do you then get an IOBUF on the schematic view or does it leave it with an OBUF and do the readback from before the buffer?

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_1/ug994-vivado-ip-subsystems.pdf

Page 100 of this document talks about a wrapper around the block design, so it looks like this might be Xilinx's approach to dealing with the top-level entity problem which you'd otherwise have with the block designer tool. It looks like the three connections to the IOBUF need to be brought out of the block in a certain form for the tool to recognise properly. You might just try bringing the signals for the IOBUF out of your port with the external pin name and either '_I', '_O', or '_T' appended for the three signals you'll require to connect to the pin buffer and see if it all magically works. If not, you'll need to read up on wrappers and work out how you apply it or access it, or whatever you're supposed to do.

Keep in mind I have absolutely no experience of Vivado, nor the block designer tool, so this could be totally wrong and not helpful at all, but it does kind of make sense that they'd need to do something along these lines.

I'm reading up. There's no IOBUF block that I can add on the block design - been searching for that.

Keep in mind I have absolutely no experience of Vivado, nor the block designer tool,

I have experience with the things that work. Once I get into trouble, I'm not familiar enough yet to self-solve.
Previous mishaps I could fix with a mix of documentation and Google. For this one that path wasn't successful. That's when I branched off into this forum question.

I'll get back when I have the outcome of the experiments above ...

Currently at Tristate Description Using Combinatorial Process Implemented with OBUFT Coding Example (VHDL) 

Page 81

...

--
 port(
 T : in std_logic;
 I : in std_logic;
 O : out std_logic
 );
--
 process(I, T)
 begin
   if (T = '0') then
     O <= I;
   else
     O <= 'Z';
   end if;
 end process;
--

This hasn't brought me farther.... I tried pins with name_T, name_I, name_O and couldn't get the wrapper to auto_generate a buffer.
Read some more, tried to instantiate a Utility Buffer myself. But I could not turn it into a working design. 

Current approach: I cloned Xilinx' PYNQ repository, and I'm regenerating the BASE overlay project.
It implements an I2C on the Arduino header - hoping that I can learn from that.
Not sure though - I thought by reviewing this the last time, that they use a bespoke Xilinx I2C IP...

image: regenerate the PYNQ base overlay project from source, in Windows Sublayer for Linux.

"I tried pins with name_T, name_I, name_O"

What did the schematic view show when you did that? Was there still just an OBUF attached to name_O? Did it do anything with the other two?

When I generated the wrapper - the moment where I was expecting magic to happen -I get errors for unconnected pins.