Showing results for 
Search instead for 
Did you mean: 
Registered: ‎10-07-2016

Inferring Bidirectional or INOUTs, or I/O ports in Block Design

I need to split the GPIO INTERFACE from the Zync PS into differently named ports that better match our system needs. For example GPIO (31 downto 24) need to be named STATUS( 7 downto 0).


I've noticed that if i put an Interface port connected to the GPIO_0, that Vivado will create the wrapper correctly with instantiated I/O cells. But if I take the individual pins on the processor that make up the GPIO Interface, name them with either _t, _i, _o or _tri_t, _tri_i, _tri_o, I'll get 3 separate ports one for the inputs, one for the tristate controls, and one for the outputs.


There doesn't seem to be a GPIO Interface SLICE like there is for regular BD nets.


Right now, I'm splitting the GPIO bus in an HDL block that is instantiated in BD. This HDL instantiates IBUFs and OBUFTs. These instantiations should really be in the BD top level wrapper for best practice. I get a bunch of warnings on the default properties of the I/O cells because they are at a lower level.


Attached is my example BD, io_test.tcl. It currently is breaking out the individual nets that make up the GPIO interface. If the 3 ports starting with emio_gpio_* are deleted, a port named gpio_b will be properly inferred.


What's the solution or work around?

Make a GPIO Interface Slicer?



For what it is worth this is an excerpt from my HDL block.


-- PMOD0 for Software general use GPIO
-- PMOD0 pins 4 thru 0, J55, pins, 2, 7, 5, 3, 1
PMOD0: for n in 68 downto 64 generate
    IBUF_in : IBUF
      port map (
        O => Q(n), -- Buffer output
        I => GPIO(n) -- Buffer input (connect directly to top-level port)
    port map (
      O => GPIO(n), -- Buffer output (connect directly to top-level port)
      T => T(n), -- Buffer input
      I => D(n) -- Buffer input
end generate;


PMOD0_GPIO <= GPIO(68 downto 64);

0 Kudos