ulpi tri-state buffer

[jack4041313]

The upli_data_io[7:0] in the ulpi interface is composed of ulpi_data_i, ulpi_data_o and ulpi_data_t.
Why is there no ulpi_data_t in the ulpi interface here?

[till-s]

I'd think you are supposed to use the ULPI DIR signal to control an IO buffer. In xilinx and vhdl speak

G_BUF : for i in ulpi_data_out'range generate
  U_BUF : IOBUF ( I => ulpi_data_in_o(i), O => ulpi_data_out_i(i), IO => ulpi_data_pin_io(i), T => ulpi_dir_pin);
end generate G_BUF;

[jack4041313]

in ulpi_wrapper, I use IOBUF create inout port
like this

But i have a problem with vivado:
[opt 31-305] Invalid connectivity on net ulpi_dir_i connected to port ulpi_dir_i. It drivers some loads that need a buffer, and other loads that do not need a buffer. This configuration cannot be placed.

If dir is used as the original dir and the IOBUF T pin, this problem will occur
Can you give me some advice?
thanks

[till-s]

Can you post the entire file, please?

[till-s]

I have tested the following configuration:

• top_level that instantiates ulpi_wrapper
• top level has 'input' ports for 'dir', 'nxt'; 'output' port for 'stp' and 'inout' ports for 'data' these are connected to the pads (in the constraints file)
• top level instantiates IBUFs for 'dir' and 'nxt', OBUF for 'stp' and IOBUFs for 'data'; the 't' line of these IOBUFs is connected to the output if 'dir's IBUF

   port (
     ...
      ulpiStp      :  out   std_logic := '0';
      ulpiDir      :  in    std_logic;
      ulpiNxt      :  in    std_logic;
      ulpiDat      :  inout std_logic_vector(7 downto 0);
     ...

   );

  ....
   signal ulpi_data_in_o    : std_logic_vector(7 downto 0);
   signal ulpi_stp_o        : std_logic;

   signal ulpi_data_out_i   : std_logic_vector(7 downto 0);
   signal ulpi_dir_i        : std_logic;
   signal ulpi_nxt_i        : std_logic;


  ....
   U_DIRBUF : IBUF port map ( I => ulpiDir,    O => ulpi_dir_i );
   U_NXTBUF : IBUF port map ( I => ulpiNxt,    O => ulpi_nxt_i );
   U_STPBUF : IBUF port map ( I => ulpi_stp_o, O => ulpiStp    );

   G_IOBUF : for i in ulpi_data_out_i'range generate
      U_DATBUF : IOBUF port map ( I => ulpi_data_in_o(i), O => ulpi_data_out_i(i), T => ulpi_dir_i, IO => ulpiDat(i) );
   end generate G_IOBUF;

   U_ULPIIO : component ulpi_wrapper
   port map (
      -- Inputs
      ulpi_clk60_i      => ulpiClkOut,
      ulpi_rst_i        => ulpiRstLoc,
      ulpi_data_out_i   => ulpi_data_out_i,
      ulpi_dir_i        => ulpi_dir_i,
      ulpi_nxt_i        => ulpi_nxt_i,
      utmi_data_out_i   => utmi_data_out_i,
      utmi_txvalid_i    => utmi_txvalid_i,
      utmi_op_mode_i    => utmi_op_mode_i,
      utmi_xcvrselect_i => utmi_xcvrselect_i,
      utmi_termselect_i => utmi_termselect_i,
      utmi_dppulldown_i => utmi_dppulldown_i,
      utmi_dmpulldown_i => utmi_dmpulldown_i,
      -- Outputs
      ulpi_data_in_o    => ulpi_data_in_o,
      ulpi_stp_o        => ulpi_stp_o,
      utmi_data_in_o    => utmi_data_in_o,
      utmi_txready_o    => utmi_txready_o,
      utmi_rxvalid_o    => utmi_rxvalid_o,
      utmi_rxactive_o   => utmi_rxactive_o,
      utmi_rxerror_o    => utmi_rxerror_o,
      utmi_linestate_o  => utmi_linestate_o
   );

This synthesizes just fine but never makes timing on my low-end (7series artix speed-grade 1) device. The combinatorial paths are just too long.

HTH

• Till

[jack4041313]

This information is very helpful to me, thank you

[yinpanqiang]

hi, why am I getting a "segmentation fault (core dumped)" when I run the test? I use iverilog/11.0 and gcc/4.8.5