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.

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 

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.

What does your tristate_test code in the block look like now? Can you show it to us?

The IP code  - one of the many incarnations. I tried different combinations, directions, with and without process:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity tristate_test is
    Port ( 
    reset_n: in std_logic;
    reset_out: out std_logic;
    tri_T : out std_logic;
    tri_I : in std_logic;    
    tri_O : out std_logic);
end tristate_test;

architecture Behavioral of tristate_test is

begin

reset_active: process (reset_n) is

begin
null;
end process reset_active;

 
reset_out <= '1' when reset_n = '0' else '0';
tri_O <= 'Z' when reset_n = '0' else '0';
tri_T <= '1' when reset_n = '0' else '0';

end Behavioral;

The block design - I deliberately do not make ports external or assign a pin to them, because the manual says they need to be unconnected and not external

The wrapper code and the error message generated while wrapping:

--Copyright 1986-2020 Xilinx, Inc. All Rights Reserved.
----------------------------------------------------------------------------------
--Tool Version: Vivado v.2020.2 (win64) Build 3064766 Wed Nov 18 09:12:45 MST 2020
--Date        : Wed Feb  9 11:15:06 2022
--Host        : paradise3 running 64-bit major release  (build 9200)
--Command     : generate_target design_1_wrapper.bd
--Design      : design_1_wrapper
--Purpose     : IP block netlist
----------------------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
library UNISIM;
use UNISIM.VCOMPONENTS.ALL;
entity design_1_wrapper is
  port (
    DDR_addr : inout STD_LOGIC_VECTOR ( 14 downto 0 );
    DDR_ba : inout STD_LOGIC_VECTOR ( 2 downto 0 );
    DDR_cas_n : inout STD_LOGIC;
    DDR_ck_n : inout STD_LOGIC;
    DDR_ck_p : inout STD_LOGIC;
    DDR_cke : inout STD_LOGIC;
    DDR_cs_n : inout STD_LOGIC;
    DDR_dm : inout STD_LOGIC_VECTOR ( 3 downto 0 );
    DDR_dq : inout STD_LOGIC_VECTOR ( 31 downto 0 );
    DDR_dqs_n : inout STD_LOGIC_VECTOR ( 3 downto 0 );
    DDR_dqs_p : inout STD_LOGIC_VECTOR ( 3 downto 0 );
    DDR_odt : inout STD_LOGIC;
    DDR_ras_n : inout STD_LOGIC;
    DDR_reset_n : inout STD_LOGIC;
    DDR_we_n : inout STD_LOGIC;
    FIXED_IO_ddr_vrn : inout STD_LOGIC;
    FIXED_IO_ddr_vrp : inout STD_LOGIC;
    FIXED_IO_mio : inout STD_LOGIC_VECTOR ( 53 downto 0 );
    FIXED_IO_ps_clk : inout STD_LOGIC;
    FIXED_IO_ps_porb : inout STD_LOGIC;
    FIXED_IO_ps_srstb : inout STD_LOGIC;
    btnRst : in STD_LOGIC_VECTOR ( 0 to 0 );
    reset_out_0 : out STD_LOGIC
  );
end design_1_wrapper;

architecture STRUCTURE of design_1_wrapper is
  component design_1 is
  port (
    btnRst : in STD_LOGIC_VECTOR ( 0 to 0 );
    DDR_cas_n : inout STD_LOGIC;
    DDR_cke : inout STD_LOGIC;
    DDR_ck_n : inout STD_LOGIC;
    DDR_ck_p : inout STD_LOGIC;
    DDR_cs_n : inout STD_LOGIC;
    DDR_reset_n : inout STD_LOGIC;
    DDR_odt : inout STD_LOGIC;
    DDR_ras_n : inout STD_LOGIC;
    DDR_we_n : inout STD_LOGIC;
    DDR_ba : inout STD_LOGIC_VECTOR ( 2 downto 0 );
    DDR_addr : inout STD_LOGIC_VECTOR ( 14 downto 0 );
    DDR_dm : inout STD_LOGIC_VECTOR ( 3 downto 0 );
    DDR_dq : inout STD_LOGIC_VECTOR ( 31 downto 0 );
    DDR_dqs_n : inout STD_LOGIC_VECTOR ( 3 downto 0 );
    DDR_dqs_p : inout STD_LOGIC_VECTOR ( 3 downto 0 );
    FIXED_IO_mio : inout STD_LOGIC_VECTOR ( 53 downto 0 );
    FIXED_IO_ddr_vrn : inout STD_LOGIC;
    FIXED_IO_ddr_vrp : inout STD_LOGIC;
    FIXED_IO_ps_srstb : inout STD_LOGIC;
    FIXED_IO_ps_clk : inout STD_LOGIC;
    FIXED_IO_ps_porb : inout STD_LOGIC;
    reset_out_0 : out STD_LOGIC
  );
  end component design_1;
begin
design_1_i: component design_1
     port map (
      DDR_addr(14 downto 0) => DDR_addr(14 downto 0),
      DDR_ba(2 downto 0) => DDR_ba(2 downto 0),
      DDR_cas_n => DDR_cas_n,
      DDR_ck_n => DDR_ck_n,
      DDR_ck_p => DDR_ck_p,
      DDR_cke => DDR_cke,
      DDR_cs_n => DDR_cs_n,
      DDR_dm(3 downto 0) => DDR_dm(3 downto 0),
      DDR_dq(31 downto 0) => DDR_dq(31 downto 0),
      DDR_dqs_n(3 downto 0) => DDR_dqs_n(3 downto 0),
      DDR_dqs_p(3 downto 0) => DDR_dqs_p(3 downto 0),
      DDR_odt => DDR_odt,
      DDR_ras_n => DDR_ras_n,
      DDR_reset_n => DDR_reset_n,
      DDR_we_n => DDR_we_n,
      FIXED_IO_ddr_vrn => FIXED_IO_ddr_vrn,
      FIXED_IO_ddr_vrp => FIXED_IO_ddr_vrp,
      FIXED_IO_mio(53 downto 0) => FIXED_IO_mio(53 downto 0),
      FIXED_IO_ps_clk => FIXED_IO_ps_clk,
      FIXED_IO_ps_porb => FIXED_IO_ps_porb,
      FIXED_IO_ps_srstb => FIXED_IO_ps_srstb,
      btnRst(0) => btnRst(0),
      reset_out_0 => reset_out_0
    );
end STRUCTURE;

The buffer wasn't instantiated. I was expecting that to happen because the pins _I, _O and _T are available

Schematic after synthesis:

Line 25. Just set tri_O to '0' (the level you want at the output of the IOBUF, when it's enabled, to give you your pretend open-drain output). The tristating is done by the external buffer, not at the block's port.

It's possible you might need to do something with the tri_I. Perhaps just take the value that comes from it and then push it back out on another output like you've done with the reset_n. I'm saying that just in case it gets optimised away as not doing anything and then the rest gets upset because it isn't there any longer.