Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
17 years ago

Internal LVDS for between-board communicatino

Hello,

Suppose that I have two boards with Stratix II FPGAs. The boards sit close to each other, and lines from one FPGA reach the other, via a connector. The total length is circa 20 cm (8 inch).

I want the two FPGAs to communicate with LVDS. Can I use the built in Altera LVDS IO for this purpose ? I'm concerned about speed / distance. The communication isn't too fast (40 MHz), but there's the distance and connector. Can I somehow know for which distance the internal LVDS drivers / receivers are good at this speed?

Additionally, should I send both clock and data as separate LVDS pairs and recover with Altera megafunction at the receiving end ? Do I need a DPA here ?

thanks in advance

16 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    A problem may arise, when the LVDS signal ground is the only ground connection between the two systems or even the only existing ground connection at all. Then high intereference currents are attracted by this connection. An additional ground connection and a common mode choke including all data lines and the signal ground (e. g. a ferrite core around the cable) may be advisable.

    --- Quote End ---

    I don't understand - how does this work out with distant enclusures connected with LVDS between them ? They have absolutely no common ground (except Earth), and no other signals except the LVDS between them.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Whoa let's not make this too complicated. If your grounds are seperated with no way of making them common, then yes your best bet is to run differential. If your grounds are not related to each other in some way, then you have absolutely no way of knowing what the potential between the two is.

    However remember we're only talking 40Mbps here. Run four traces (a differential clock and a differential data signal). Use AC coupling caps on the traces (preferably close to the receiver). And use a simple DC-biased termination scheme.

    If you provide the clock, there is absolutely no need to encode the data. Encoding schemes like 8b/10b are designed to provide a maximum number of transitions to allow for easier clock data recover at the receiver. Just provide the clock.

    I assume that your boards have been layed out with differential traces?

    Jake
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Whoa let's not make this too complicated. If your grounds are seperated with no way of making them common, then yes your best bet is to run differential. If your grounds are not related to each other in some way, then you have absolutely no way of knowing what the potential between the two is.

    However remember we're only talking 40Mbps here. Run four traces (a differential clock and a differential data signal). Use AC coupling caps on the traces (preferably close to the receiver). And use a simple DC-biased termination scheme.

    If you provide the clock, there is absolutely no need to encode the data. Encoding schemes like 8b/10b are designed to provide a maximum number of transitions to allow for easier clock data recover at the receiver. Just provide the clock.

    I assume that your boards have been layed out with differential traces?

    Jake

    --- Quote End ---

    Yes, if I provide the clock I don't need to encode the data. No bad effects will happen if a AC-coupled line stays high for too long ?

    My boards are in the design phase, and we plan to use differential traces, yes.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I don't claim to know your system enviroment in detail, but a LVDS connection without a acompanying signal ground has a high risc of catching interferences, with or without AC coupling. Also possible damage to the FPGA IOs must be feared.

    You have to consider also higher frequecy interferences, not only DC and mains frequency potential differences. Would be different when using a transformer coupling, e. g. by ethernet magnetics. But this also requires 8b/10b, as suggested.

    Another (DC capable) solution is to use digital isolators from NVE or Analog.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    I don't claim to know your system enviroment in detail, but a LVDS connection without a acompanying signal ground has a high risc of catching interferences, with or without AC coupling. Also possible damage to the FPGA IOs must be feared.

    You have to consider also higher frequecy interferences, not only DC and mains frequency potential differences. Would be different when using a transformer coupling, e. g. by ethernet magnetics. But this also requires 8b/10b, as suggested.

    Another (DC capable) solution is to use digital isolators from NVE or Analog.

    --- Quote End ---

    Thanks for all the help :)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Yes, if I provide the clock I don't need to encode the data. No bad effects will happen if a AC-coupled line stays high for too long ?

    --- Quote End ---

    In most AC coupling schemes, it is important for the time average of the signal to be equal (or nearly equal) to the common mode voltage (ie. the same number of zeros and ones over some time span). If a constant value is held for too long, it will behave like DC, and will be filtered by the coupling circuit so that the receiver sees 0V differential.

    One way around this is to use 8b10b or similar encoding (yes, even if you are not doing clock recovery), as it guarantees DC balancing. This encoding scheme is not that complicated, and at your frequency, does not require any dedicated hardware. The complicated part would be the clock recovery, but you are not doing that.