Diffenrential I/Os in Virtex-4

Hi *,

I'm having some issues understanding certain limitations regarding differential inputs/outputs:

  1. In the "Virtex-4 Packaging and Pinout Specification UG075 (v2.4) September 30, 2005" in table 1-3 on page 14 it is stated that LC, CC and GC pins do not support LVDS outputs. But obviously, they support other differential outputs like DIFF_SSTL18. At least that's what is stated in the "Virtex-4 User Guide UG070 March21, 2006" in table 6-38 on page 289. Is this correct or are there problems to be expected? The tools at least don't seem to mind. If I put LVDS_25-Outputs on CC/LC/GC-pins, I get ERROR:1107 during par (see Answer record #20092,
    formatting link
    , if I use DIFF_SSTL18, the flow finishes without errors.

  1. In an earlier Virtex-II Pro-design I had LVDS_25_DT-inputs in a bank powered with VCCO=3.3V that had LVTTL outputs as well. I asked about this here before I did the schematic and was told this was OK, since the LVDS input buffers are not powered by VCCO, but by VCCAUX, which is always 2.5V. So you can put 2.5V-LVDS-inputs with differential termination enabled in any bank without problems. This in fact works, meaning that neither do the tools complain nor are there any problems "in real life" in the hardware; everything works as expected.

In Virtex-4 this seems to have changed. According to the user guide (see note (2) for table 6-38 on page 290) LVDS input buffers are still powered by VCCAUX, so you can still have them in banks powered with

3.3V. But it seems you can only use the differential termination when your VCCO is 2.5V: "The VCCO of the I/O bank must be connected to 2.5V ±5% to provide 100? of effective differential termination. DIFF_TERM is only available for inputs and can only be used with a bank voltage of VCCO = 2.5V." (page 282).

Why is that and what exactly does it mean? The tools don't seem to mind if you enable DIFF_TERM on banks with LVTTL-IOs, there is no error message or anything. So is the passage in the documentation wrong, or does it mean that if VCCO!=2.5V, you don't get 100R of effective differential termination but a different value? What would that value be?

I'd be glad if Austin or someone from Xilinx could clear this up for me...

cu, Sean

Reply to
Sean Durkin
Loading thread data ...

Sean,

I will comment below,

Austin

-snip-

formatting link
,

Those pins do not have LVDS outputs. This was done to reduce the input capacitance, as these pins can use the extra lower capacitance to improve signal integrity and lower jitter.

Yes.

Yes.

Yes.

What would that value be?

Since we don't recommend to use it this way, we have done no characterization, so I can't tell you. It will be terminated, by a resistance, but how much that will vary is unknown.

Reply to
Austin Lesea

This will be flagged as an error in ADEPT. The tool is freely available at

formatting link

HTH, Jim

Reply to
Jim Wu

Yes, actually I stumbled upon this issue only by accident because I read the ADEPT release notes today, not by reading the Xilinx documentation.

Unfortunately it's too late now, I didn't know about ADEPT when I was doing the schematics. I'll probably have to solder 0402 100R-resistors directly to the balls.

BTW: thanks for this great tool, really useful. I should've know about it a few months ago.

cu, Sean

Reply to
Sean Durkin

Hi Sean, I wonder, have you tried simulating your design? You might find that it performs OK even with resistors that are wildly different from 100R. As I'm sure you know, it depends on speed, trace length blah, blah, blah, but if your design can already cope with the ~10pF Cpin of the FPGA, you've got a fair chance of getting away with it! Another idea: if you're AC coupling the signal near its source, you could attempt to bodge on some source termination. Brian Davis published some stuff a while back here on CAF which featured attenutators that might also be of interest.

Surely, almost anything is better than soldering directly to your balls. Good luck, Syms.

Reply to
Symon

Well, I did the same thing in a Virtex-II Pro, and it seems to be the same there (i.e. you're not supposed to use the differential termination when VCCO=3.3V), even though it's not that explicitely stated in the documentation. On that board it works perfectly, even though the termination must be off there as well. Back then I did measurements with a scope (at the balls) and didn't notice any obvious reflections or weird behaviour because of impedance mismatch. On some IOs I had external resistors and did comparisions between external and internal termination, didn't make much of a difference. The only thing different now is the FPGA. So, it might work there as well.

Yes, I read that thread, very interesting, and did some simulations with HyperLynx afterwards and concluded that I should be able to get away without attenuators and AC-coupling, but always under the assumption that I have decent 100R-termination inside the FPGA. The effect that the resistance varies when you have a different VCCO is not included in the simulation models, so what I simulated is not the "real world case". I'll do some more sims with different resistor values to see how that really affects it.

Yes, especially since I'm not exactly RoHS-compliant. :)

But seriously: There will be a small redesign of that board for other reasons anyway, so should the need arise I can add pads for the resistors then.

cu, Sean

Reply to
Sean Durkin

Hi Sean, I checked an old prototype design of my own, and I used the same thing as you for V2PRO. The problem was that I wanted to use the differential clock inputs on bank 4, but this was the same bank as my config pins which came from a 3.3V bus, so it had Vcco = 3.3V. All worked fine on the clock inputs. (Although maybe data inputs would have been a better test.) In the production version, I put a level translator on the bus and changed Vcco to

2.5V, but only for peace of mind. It always seemed to me rather odd that the receivers are powered from Vccaux, but the Rterm depends on Vcco. I wonder what's going on there? Cheers, Syms.
Reply to
Symon

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.