AR# 8187

Virtex-E, Spartan-IIE LVDS/LVPECL - How do I use LVDS/LVPECL I/O Standards?

Description

How should one design Virtex-E/Spartan-IIE LVDS or LVPECL I/Os?

Solution

When using LVDS IOSTANDARD, a UCF or NCF file with complete pinLOC information must be created to ensure that the I/O banking rules are not violated. If a UCF or NCF file is not used, PAR will issue errors. There are two ways to use the LVDS IOSTANDARD:

1. Use the IOSTANDARD attribute in the UCF file.
2. Instantiate LVDS input and output buffers.

LVDS Input buffer:

An LVDS input buffer may be placed in a wide number of IOB locations. The exact locations are dependent on the package that is used. The Virtex-E/Spartan-IIE package information lists the possible locations as IO_L#P for the P-side, and IO_L#N for the N-side, (where "#" is the pair number).

Using the UCF file:

The following syntax can be used in the UCF file to set the IOSTANDARD as LVDS:

NET <input net name> IOSTANDARD = LVDS;
NET <input net name> LOC=P(pin name);

The above is an example for just one LVDS input pin. In a real design, users must lock down all the I/O pins in the UCF file. Otherwise, PAR will issue errors.

HDL Instantiation:

Only one input buffer is required to be instantiated in the design and placed on the correct IO_L#P location. The N-side of the buffer will be reserved, and no other IOB is allowed to be placed on this location.

In the physical device, a configuration option is enabled that routes the pad wire from the IO_L#N IOB to the differential input buffer, located in the IO_L#P IOB. The output of this buffer then drives the output of the IO_L#P cell or the input register in the IO_L#P IOB. In FPGA Editor, it will appear that the second buffer is unused. However, any attempt to use this location for another purpose will cause a DRC error in the software.

-- VHDL instantiation:
data0_p : IBUF_LVDS port map (I=>data(0), O=>data_int(0));

-- Verilog instantiation:
IBUF_LVDS data0_p (.I(data[0]), .O(data_int[0]));

Location constraints:

All LVDS buffers must be explicitly placed on a device. For the input buffers, this may be done with the following constraint in the ".ucf" or ".ncf" file.

NET data<0> LOC = D28; # IO_L0P

Creating a LVDS Output Buffer

An LVDS output buffer may be placed in a wide number of IOB locations. The exact locations are dependent upon the package that is used. The Virtex-E/Spartan-IIE package information lists the possible locations as IO_L#P for the P-side, and IO_L#N for the N-side (where "#" is the pair number).

Using a UCF file:

The following syntax can be used in the UCF file to specify the LVDS IOSTANDARD for outputs.

Note: Both outputs must be specified in the UCF file and locked down to positive and negative output pins.

NET <output pad net name_positive> IOSTANDARD=LVDS;
NET <output pad net name_negative> IOSTANDARD=LVDS;
NET <output pad net name_positive> LOC=P22;
NET <output pad net name_negative> LOC=P23;

The above is an example of just one pair of LVDS outputs. In a real design, users must lock down all the I/O pins. Otherwise, PAR will issue errors.

HDL Instantiation

Both output buffers are required to be instantiated in the design and placed on the correct IO_L#P and IO_L#N locations. In addition, the output (O) pins must be inverted with respect to each other (one HIGH and one LOW). Failure to follow these rules will lead to DRC errors in the software.

-- VHDL instantiation

data0_p : OBUF_LVDS port map (I=>data_int(0), O=>data_p(0));
data0_inv: INV port map (I=>data_int(0), O=>data_n_int(0));
data0_n : OBUF_LVDS port map (I=>data_n_int(0), O=>data_n(0));

-- Verilog instantiation

OBUF_LVDS data0_p (.I(data_int[0]), .O(data_p[0]));
INV data0_inv (.I(data_int[0], .O(data_n_int[0]);
OBUF_LVDS data0_n (.I(data_n_int[0]), .O(data_n[0]));

Location constraints

All LVDS buffers must be explicitly placed on a device. For output buffers, this may be done with the following constraint in the ".ucf" or ".ncf" file:

NET data_p<0> LOC = D28; # IO_L0P
NET data_n<0> LOC = B29; # IO_L0N

Synchronous vs. Asynchronous Outputs

If the outputs are synchronous (registered in the IOB), then any IO_L#P|N pair can be used. If the outputs are asynchronous (no output register), you must use one of the pairs that is part of the same IOB group at the end of a ROW or COLUMN in the device.

The LVDS pairs that can be used as asynchronous outputs are listed in the Virtex-E or Spartan-IIE pin-out tables. Some pairs are marked as asynchronous-capable for all devices in that package, and others are marked as available only for that specific device in the package. If the device size might be changed at some point in the product lifetime, then only the common pairs for all packages should be used.

Adding an Output Register (synchronous output)

All LVDS buffers may have an output register in the IOB. The output registers must be in both the P-side and N-side IOBs. All the normal IOB register options are available (FD, FDE, FDC, FDCE, FDP, FDPE, FDR, FDRE, FDS, FDSE, LD, LDE, LDC, LDCE, LDP, LDPE). The register elements may be inferred or explicitly instantiated in the HDL code.

Special care must be taken to insure that the D pins of the registers are inverted, and that the INIT states of the registers are opposite each other. The clock pin (C), clock enable (CE) and set/reset (CLR/PRE or S/R) pins must connect to the same source. Failure to do this will lead to a DRC error in the software.

The register elements may be packed in the IOB using the IOB property "TRUE" on the register, or by using the "map -pr [i|o|b]" (where "i" is inputs only, "o" is outputs only, and "b" is both inputs and outputs).

The following is an example of VHDL code using LVDS registered outputs and LVDS input "a", targeting v100epq240. It uses both the LVDS instantiation and UCF IOSTANDARD attribute:

library ieee;
use ieee.std_logic_1164.all;

entity mux is

port (a,b,c,d,e,f,g,h, clk, reset : in std_logic;
S : in std_logic_vector (2 downto 0);
q, q_n : out std_logic);
end entity;

architecture mux_arch of mux is

component OBUF_LVDS port (
I : in std_logic;
O : out std_logic);
end component;

signal a_int, q_int, mux_out, mux_out_n, muxout_n_reg : std_logic;

begin

process (a,b,c,d,e,f,g,h,s)
begin

case S is
when "000" =>
q_int<=a;
when "001"=>
q_int<=b;
when "010" =>
q_int<=c;
when "011" =>
q_int<=d;
when "100" =>
q_int<=e;
when "101" =>
q_int<=f;
when "110" =>
q_int<=g;
when "111" =>
q_int<=h;
when others =>
q_int<='X';
end case;
end process;

process (clk, reset)
begin
if (reset='1') then
mux_out<='0';
elsif (clk'event and clk='1') then
mux_out<=q_int;
end if;
end process;
mux_out_n <= not q_int;

process (clk, reset)
begin
if (reset='1') then
muxout_n_reg<='1';
elsif (clk'event and clk='1') then
muxout_n_reg<=mux_out_n;
end if;
end process;

U1 : OBUF_LVDS port map(I=>mux_out, O=>q);
U2 : OBUF_LVDS port map(I=>muxout_n_reg, O=>q_n);

end mux_arch;

Here are the UCF constraints:

net q LOC=P20;
net q_n loc=P21;
net a IOSTANDARD=LVDS;
net a LOC=P27;
net b LOC=P168;
net c LOC=P167;
net d LOC=p163;
net e LOC=p162;
net f loc=p161;
net g loc=p160;
net h loc=p159;
net clk loc=p210;
net reset loc=P157;
net s(0) loc=p156;
net s(1) loc=p155;
net s(2) loc=p154;

Make sure map -pr o option is used to ensure that the FFs are being pushed inside the I/O block.

Designing with the LVPECL IOSTANDARD is the same as designing with LVDS. Users must instantiate the I/O buffer names in the HDL codes.

For more detailed information, please refer to the Xilinx Virtex-E data sheet, available at:
http://www.support.xilinx.com/xlnx/xweb/xil_publications_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=-18776&iLanguageID=1

or

Xilinx Application Note "Using the Virtex SelectI/O Resource" (Xilinx XAPP133):
http://www.xilinx.com/support/documentation/application_notes/xapp133.pdf

For more detailed information, please refer to the Xilinx Spartan-IIE data sheet, available at:
http://www.support.xilinx.com/xlnx/xweb/xil_publications_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=-18778&iLanguageID=1

or

Xilinx Application Note "Using SelectI/O Interfaces in Spartan-II and Spartan-IIE FPGAs" (Xilinx XAPP179):
http://www.xilinx.com/support/documentation/application_notes/xapp179.pdf

Was this Answer Record helpful?

AR# 8187
Date	12/15/2012
Status	Active
Type	General Article

Page Bookmarked