Actions
Forum Thread Details
  • State Not Answered
  • +1 person also asked this people also asked this
  • Replies 31 replies
  • Subscribers 545 subscribers
  • Views 14352 views
  • Users 0 members are here
Related

Vivado and Zynq: TRI-STATE help

Jan Cumps

I'm trying to write i2c code for Zynq, in VHDL.
I have difficulties creating a TRI-STATE pin.

The output logic should be: the pin is either pulled down to 0, or open-collector.
I have a pull-up resistor between that pin and VCC (3.3 V).
I'm expecting that if I write '0', it is low. When I write 'Z', it's open collector and pulled high by my pullup.
But in my design, the pin stays low. 0.62 V.

I thought, from reading up, that I should be done by:

  • defining the pin as INOUT
  • when you want to drive it low, assign '0'.
  • when you want to drive it open collector, assign 'Z'.
  • put an external pullup between pin and VCC

I created a testbed that puts the pin in "Z' mode, except when reset is asserted (via an external button).
In my testbed I also added a test pin, that I attach to an LED, that is high when the reset is asserted.
I connected a multimeter to the output.

The LED behaves as expected. It lights up when I assert the reset.
But the tri-state pin stays low, whether I write '0' or 'Z' to it. 

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
  if (reset_n = '0') then
    tristate_pin <= '0';
    reset_out <= '1';
  else
    tristate_pin <= 'Z';
    reset_out <= '0';
  end if;
end process reset_active;

end Behavioral;

Here is how I set the constraint:

image

set_property PACKAGE_PIN Y18 [get_ports tristate_pin_0]
set_property IOSTANDARD LVCMOS33 [get_ports tristate_pin_0]
set_property DRIVE 12 [get_ports tristate_pin_0]

Schema:

image

PMOD A pin 1 is PACKAGE_PIN Y18

What am I doing wrong?

Parents
  • 0

    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

  • 0 in reply to rachaelp

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

  • 0 in reply to Jan Cumps

    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.

  • 0 in reply to 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;

  • 0 in reply to Jan Cumps

    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.

  • 0 in reply to rachaelp

    Checking the schematic. Highest level:

    image

    Drill down (red square is my annotation):

    image

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

  • 0 in reply to Jan Cumps

    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?

Reply Children
No Data