Advertisement

Blog

LVDS Is Dead? Long Live LVDS & JESD204B

As I was sitting listening to a presentation on JESD204B recently, I reminisced back a few years ago to a period where LVDS (low-voltage differential switching) began overtaking CMOS.

I thought to myself that JESD204B looks to be on a similar path today. First, a quick overview. A CMOS I/O interface consists of individual single-ended logic signals. LVDS changes these to a pair of signal lines operating 180° out of phase (hence, differential). Differential signaling results in better noise immunity and can therefore typically operate at lower power levels for an equivalent signal-to-noise ratio. The JESD204 standard addresses sending and receiving data over a serial link, typically from an ADC to an FPGA or an ASIC. Additional revisions addressed details regarding the clock and multiple data signal paths (“lanes”) and issues regarding lane synchronization.

Obviously, there is a bit of reluctance out there on the part of system designers to make such a large change in the interface between the converter and their FPGA or ASIC. After all, this is part of the design that should be a given, right? It is often taken for granted that it should work, and well, that is should work pretty easily. Looking at the bigger picture, making this change requires engineering effort, time, and money.

However, as technologies push forward and system bandwidth requirements get higher and higher, converter sample rates must also push faster. There comes a point where LVDS is no longer practical. While the current and power consumption remain relatively flat for LVDS, the interface has an upper speed bound. This is due to the driver architecture as well as the many data lines that must be synchronized to a data clock.

With a 12-bit converter running at 200 MSPS, Table 1 show that CML (current mode logic) output drivers used in JESD204B start to become more efficient in terms of power consumption. CML requires less number of output pairs per a given resolution than LVDS and CMOS drivers due to the serialization of the data. The data in the table assumes a synchronization clock for each channel for CMOS and LVDS outputs and a maximum data rate of 4.0 Gbits for JESD204B using the CML outputs (less than half the limit of 12.5 Gbits for JESD204B). The reduction in pin count using JESD204B is significant.

Table 1

Pin Count Comparison - 200MSPS Converter

Pin Count Comparison – 200MSPS Converter

Now, let's take this one step further and look at a 12 bit converter running at 2.0GSPS. Table 2 gives us an even better picture of the advantage of using JESD204B. For this example, we won't even look at CMOS because it is just completely impractical to try to use a CMOS output interface with a gigasample converter. In this case, we'll limit the number of converter channels to four. In order to keep the data rate within the limits of most FPGAs available today, two LVDS output pairs are needed for each bit. As you can see, the complexity in the output routing is much reduced for JESD204B due to the reduction in the number of output pins.

Table 2

Pin Count Comparison - 2.0GSPS Converter

Pin Count Comparison – 2.0GSPS Converter

So, is LVDS really dead? Probably not. There is still a large market for MSPS range converters, but LVDS beware, JESD204B is coming fast!

9 comments on “LVDS Is Dead? Long Live LVDS & JESD204B

  1. green_is_now
    May 8, 2013

    You forgot to mention that the advantages of JEDEC standard do not solve the exponentail noise generation as densities increase.

     think you are mostly right for short distances in hte relm of the IC that has been designed with noise margins.

    But for longer runs and other IC's and other types of circuits in the mix this is not so easy to predict.

    Short fast serial runs to close IC probably ok.

    for other longer runs once outside of imediate area of driver IC a LVDS translation from serial input to // output will be needed.

    But that drives up costs and complexity.

     

    Shrinking the IC and having to add another to compensate not so elegant a solution.

     

  2. jonharris0
    May 8, 2013

    Great points.  Thanks for the comment. The 204B interface is mainly intended for short runs.  The physical interface spec calls out up to 20cm and one connector so it is not for long runs.  Typically designs usually place the FPGA/ASIC near the converter.  There are cases where this isn't true, but largely it is preferable to keep the two close even if 204B is not the protocol being use.

  3. green_is_now
    May 8, 2013

    Thanks Jonathan for the clarification.

    I did not appriciate that this is recommended for short runs only.

    But it does reinforce my hunch/statement that it would cause problems if long runs are used.

    To add to the discussion can you comment on using guard rings and/or layer shielding in terms of high density packing and if this can extend the length of the runs?

     What is the limiting factor in the short run recommendation?

    Is it crosstalk coupling to other JESD204B traces?

    Radiation and EMI issues raise their ugly heads?

    Are IC venders putting both on for I/O flexibility?

    Are they making I/O pins programmable for both approaches for designer flexibility?

    As an example one could use all JESD204B for side by side runs between chips and program the side on the wrong side of the IC's to be LVDS?

     

  4. jonharris0
    May 13, 2013

    Hi, these are are good questions.  The physical layer specification for 204B only calls out 20cm of routing and one connector and does not include provisions to try and increase the length.  Converter and FPGA vendors can use techniques such as variable driver strengths (varying the output level) as well as pre-emphasis or de-emphasis to help mitigate the issues seen with poor interconnect and possibly for longer interconnect, but the specification does not govern these per se.  Instead, it governs measurements like the eye diagram.

    Differential traces by nature are much more immune to cross talk than singled ended, but this is always a concern regardless of the interface being used as would be EMI (which 204B has scrambling capabilities to help with).

    As for programmability usually, the high speed serdes drivers are separate drivers because of the design requirements for the high speeds associated with these signals.

    You can also go to http://ez.analog.com/ and ask questions from a community of engineers.

  5. Juergen1
    May 17, 2013

    Dear Jonathan,

    it's called Low Voltage Differential Signaling and not Low Voltage Differential Switching. Anyhow thanks for the alternative!

  6. Brad Albing
    May 19, 2013

    Juergen – don't blame Jonathan for that. Someone else along the way had a brain cramp and mistyped.

  7. jonharris0
    May 23, 2013

    Thanks Brad, indeed, it was an edit that I overlooked.  It should have read low voltage differential signaling instead.

    Jeurgen, thanks for pointing out the error.

  8. eafpres
    June 26, 2013

    Hi Jonathan–your blog today caused me to read the prior blog again which caused me to read this one again and I thought I would mention that LVDS is used in Automotive, where EMI is a big issue, as well as safety and reliability.  Data rates are often low (but getting higher all the time).

    I note your company makes parts for this market, like:

    ADN 4667 LVDS driver

    This came to mind becuase I just mentioned this in a blog over on the sibling site The Connecting Edge:

    High Speed Data in Cars

    There I was looking at different technologies and LVDS has the advantage of better immunity and supporting fairly high data rates in some instances.

    Thanks for all your articles, very helpful.

  9. jonharris0
    July 1, 2013

    @eafpres Great comments.  Thanks for the kind words as well.  I am not as familiar with the automotive market, so thanks for the insight.  With high speed converters, the push is for a faster interface which I imagine eventually will make its way into automotive applications.  Indeed, EMI is something to consider regardless of the interface and the interface alone does not make the system immune.  It is imperative to have good design practices and be aware of return current paths to help with EMI.  Thanks again!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.