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.

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.

Yes, the traditional individual OBuffer / IBuffer depending on direction, if I manually made them external.
Input grounded and buffer not connected to anything (nc) if I left them flapping in the breeze.

This is how the PYNQ team does it. It's a snippet from the PMOD hierarchy of the BASE (proof of concept) overlay.

The output pin (pmoda_gpio) is Xilinx specific, a MASTER interface pin of Xilinx predefined type gpio_rtl. I know how to make that.
The block on the left of that (io_switch_xxx) is a custom PYNQ IP. I believe that I'll be able to find the source code. Most likely Verilog - but I may be able to understand it ...

This is how the PYNQ team does it. It's a snippet from the PMOD hierarchy of the BASE (proof of concept) overlay.

The output pin (pmoda_gpio) is Xilinx specific, a MASTER interface pin of Xilinx predefined type gpio_rtl. I know how to make that.
The block on the left of that (io_switch_xxx) is a custom PYNQ IP. I believe that I'll be able to find the source code. Most likely Verilog - but I may be able to understand it ...