Capturing ADC Data using LVDS interface

[ali_asadzadeh]

Hi,
This is my first time connecting a LVSD ADC (AFE5816) to an Spartan 6 device, I want to make sure I'm doing everything just right,
This is the schematic for the ADC, it’s connected to Bank 0 of the FPGA,



So I want to use the coregen  for capturing the ADC, DATA, this is the tricky part, what settings should I put in here? Is these setting in the Picture, correct?
Any help or sample project or code can really comes in handy.

[ali_asadzadeh]

Any one with another LVDS ADC experience in here?

[aandrew]

I used the LTC2387 which is a 1- or 2-lane DDR output ADC (I used only one lane) with a MAX10. The tricky bit for me was using the returned clock along with the data lane and do the DDR to SDR conversion in the FPGA.

For you, I suspect that as long as you make sure that your LVDS inputs are all actually going to pins that are a) correctly paired and b) can be constrained to meet timing, you'll be golden. It looks like you're using the FPGA to serialize the data, rather than use it in the FPGA itself. I was doing the opposite (deserializing the ADC data and embedding it in gigabit ethernet frames along with other information).

Just double and triple check the FPGA datasheet, configure all the pins in Vivado, write the timing constraint file and make sure that the FPGA will actually do what you ask it to do; I've been surprised by "special cases" where an LVDS input pair could not be used because I was using some other I/O standard on the same bank (even with the same VDDIO), or that an LVDS input pair was actually emulated LVDS, which meant that its timing was worse than the rest of the pairs and made timing closure trickier, that perhaps the PLL I was using couldn't actually send its output to that specific GCLK, etc., etc. Test everything before going to layout. :-)

Oh - I don't see any termination resistors; does your FPGA have internal termination? I had to sprinkle my LVDS lines 100R 0201 resitors just outside the FPGA's courtyard.

[ali_asadzadeh]

For you, I suspect that as long as you make sure that your LVDS inputs are all actually going to pins that are a) correctly paired and b) can be constrained to meet timing, you'll be golden. It looks like you're using the FPGA to serialize the data, rather than use it in the FPGA itself. I was doing the opposite (deserializing the ADC data and embedding it in gigabit ethernet frames along with other information).

Thanks for the info, I'm doing exactly something like you, Capturing ADC data and sending them using Ethernet, ANy hint on how to deserilize the ADC, this is the first time I'm using LVDS and I have no experience in there.

[Bassman59]

For you, I suspect that as long as you make sure that your LVDS inputs are all actually going to pins that are a) correctly paired and b) can be constrained to meet timing, you'll be golden. It looks like you're using the FPGA to serialize the data, rather than use it in the FPGA itself. I was doing the opposite (deserializing the ADC data and embedding it in gigabit ethernet frames along with other information).

Thanks for the info, I'm doing exactly something like you, Capturing ADC data and sending them using Ethernet, ANy hint on how to deserilize the ADC, this is the first time I'm using LVDS and I have no experience in there.

LVDS simply defines the I/O standard or type: it means a differential pair of wires carries the signal, and the signal swing is 300 or so millivolts about a DC offset of 1.25 V. It says absolutely nothing about what sort of information is carried on the wire pair. It says nothing about whether the wires carry serial data or one bit of a parallel data bus or a clock or even whether the data are coded in an interesting way or not.

So your question is really, "how to deserialize the ADC data, given the data format documented in the device data sheet."

[BrianHG]

I used the LTC2387 which is a 1- or 2-lane DDR output ADC (I used only one lane) with a MAX10. The tricky bit for me was using the returned clock along with the data lane and do the DDR to SDR conversion in the FPGA.
......
Oh - I don't see any termination resistors; does your FPGA have internal termination? I had to sprinkle my LVDS lines 100R 0201 resitors just outside the FPGA's courtyard.

The limited quantity true LVDS inputs available on all MAX10/Cyclone devices do have a software programmable internal 100 ohm terminator.  The emulated LVDS_E_3R available on almost all IOs do not.  Though, with 16 differential channels, you probably had to use the emulated LVDS inputs.

[ali_asadzadeh]

BrianHG, Thanks for the feedback, I'm using spartan6, do you have any input on spartan6, any help would be appreciated.

[ali_asadzadeh]

LVDS simply defines the I/O standard or type: it means a differential pair of wires carries the signal, and the signal swing is 300 or so millivolts about a DC offset of 1.25 V. It says absolutely nothing about what sort of information is carried on the wire pair. It says nothing about whether the wires carry serial data or one bit of a parallel data bus or a clock or even whether the data are coded in an interesting way or not.

So your question is really, "how to deserialize the ADC data, given the data format documented in the device data sheet

There is nothing fancy about the ADC, it just put data @ 1Gbps at outputs, and I should use SEREDES inside the Spartan 6 IO to convert them to parallel data at lower frequency, and since I have not done it before, I do not know how to do it yet. so have you any experience and are you willing to help?

[RoGeorge]

It's SERDES, stands for data serialiser/deserialiser block, not SEREDES.

What do you call a SEREDES?



LATER EDIT:
It felt like a deja vu while typing the above, so googled to check if indeed I've said that before.

Turned out indeed I've wrote that before, and guess to whom?   
https://www.eevblog.com/forum/projects/why-we-can-not-have-more-than-5ghz-processors/msg3461062/#msg3461062

[aandrew]

The output of his ADC is already parallel, he doesn't need to serialize anything. Bring in the IO, synchronize and use it in the FPGA.

edit: I'm an idiot, I did not read the datasheet correctly. This does need to be deserialized.

[NorthGuy]

It's all in the figure 1 of the datasheet.

The ADC gives you two clocks - FCLK (start of the frame at the rising edge). DCLK which is 7 times faster than FCLK and is used to transmit DDR data (14 bits per one tick of FCLK).

To parallelize the data you would need 1:14 SERDES. You would feed FCLK, DCLK and the DOUT to it and it would produce 14 lines of parallel data in FCLK domain.

I don't think Spartan-6 has 1:14 ISERSDES (but I think Spartan-7 does). So, you may need to improvise - such as one 1:7 SERDES for rising edges of DCLK and one 1:7 SERDES for falling edges of DCLK. Or 1:7 DDR ISERDES (but it'll require FCLK/2 clock) followed by 1:2 SERDES in the fabric. Such solutions may or may not be routable. It's up to you to explore.

[NorthGuy]

Or you may try to work directly in DCLK domain. Instead of ISERDES, you use IDDR input element which deserializes DDR data 1:2 and then you deserialize the rest in the fabric. You also sample FCLK to figure out where the frame starts. It is easy, but will work only if DCLK is slow enough to clock the fabric.

[asmi]

Or you may try to work directly in DCLK domain. Instead of ISERDES, you use IDDR input element which deserializes DDR data 1:2 and then you deserialize the rest in the fabric. You also sample FCLK to figure out where the frame starts. It is easy, but will work only if DCLK is slow enough to clock the fabric.

Did you look at the datasheet? It's got 16 independent serial LVDS channels, up to 1 Gbps each. No way you will do anything with IDDRs. Even much faster Spartan-7 won't be able to keep up. So using ISERDES is mandatory. I don't remember if S6 can do 1:12 or 1:14 deserialization, if it can't, you will have to use some sort of gearbox and intermediate frequency.

The more interesting question is what OP is planning to do with all this data. We're talking about a continuous 16 Gbps data stream, so not even 10G Ethernet is going to be fast enough to stream it out unless some preprocessing with significant data reduction is going to be performed inside FPGA. Also - I seem to recall that S6 can only run DDR3 at 333 MHz (unless you get your hands on rare SG3 devices), so you will need to use 64 bit DDR3 interface if you want to do some buffering, anything less won't allow simultaneous reading and writing. Of course all of that is based on assumption that you will have to max out sampling rate and actually use all 16 channels simultaneously.

[NorthGuy]

Did you look at the datasheet? It's got 16 independent serial LVDS channels, up to 1 Gbps each. No way you will do anything with IDDRs.

1 Gbps requires 500 MHz clock. But the actual rate depends on the ADC speed. Say, if ADC samples at 50 Ms/s, DCLK is only 350 MHz. Spartan-6 should be able to run BUFG at 350 MHz. Thus the IDDR solution might be in reach.

[asmi]

1 Gbps requires 500 MHz clock. But the actual rate depends on the ADC speed.

Of course.

Say, if ADC samples at 50 Ms/s, DCLK is only 350 MHz. Spartan-6 should be able to run BUFG at 350 MHz. Thus the IDDR solution might be in reach.

Yeah, well, you might as well run that ADC at 1 MHz too. But what's the point of using such overkill ADC in the first place?
BTW, as per datasheet, max rate for IDDR is 750 Mbps for SG2. But since the actual data size is 12 or 14 bits, you will have to have some sort of gearbox to further deserialize the data into actual data words, with all complexities it brings along, like additional clock domain. So using IDDR in this case makes even less sense, because ISERDES does it all out of box with no custom logic required, and no messing with CDC.

[langwadt]

Or you may try to work directly in DCLK domain. Instead of ISERDES, you use IDDR input element which deserializes DDR data 1:2 and then you deserialize the rest in the fabric. You also sample FCLK to figure out where the frame starts. It is easy, but will work only if DCLK is slow enough to clock the fabric.

Did you look at the datasheet? It's got 16 independent serial LVDS channels, up to 1 Gbps each. No way you will do anything with IDDRs. Even much faster Spartan-7 won't be able to keep up. So using ISERDES is mandatory. I don't remember if S6 can do 1:12 or 1:14 deserialization, if it can't, you will have to use some sort of gearbox and intermediate frequency.

it's been a while since I used an S6 but I seem to remember max for iserdes is ~700Mbps (In my case 50Msps * 14bit)

[NorthGuy]

So using IDDR in this case makes even less sense, because ISERDES does it all out of box with no custom logic required, and no messing with CDC.

IDDR and ISERDES is the same thing - ILOGIC. The difference is when it's configured 1:2 it's called IDDR, and when it's configured 1:n it's called ISERDES and requires separate CLKDIV.

[ali_asadzadeh]

It's SERDES, stands for data serialiser/deserialiser block, not SEREDES.

What do you call a SEREDES?

It's a serializer inside each IP pin

[ali_asadzadeh]

Did you look at the datasheet? It's got 16 independent serial LVDS channels, up to 1 Gbps each. No way you will do anything with IDDRs. Even much faster Spartan-7 won't be able to keep up. So using ISERDES is mandatory. I don't remember if S6 can do 1:12 or 1:14 deserialization, if it can't, you will have to use some sort of gearbox and intermediate frequency.

The more interesting question is what OP is planning to do with all this data. We're talking about a continuous 16 Gbps data stream, so not even 10G Ethernet is going to be fast enough to stream it out unless some preprocessing with significant data reduction is going to be performed inside FPGA. Also - I seem to recall that S6 can only run DDR3 at 333 MHz (unless you get your hands on rare SG3 devices), so you will need to use 64 bit DDR3 interface if you want to do some buffering, anything less won't allow simultaneous reading and writing. Of course all of that is based on assumption that you will have to max out sampling rate and actually use all 16 channels simultaneously

I need to do it inside spartan 6, that's a requirement from customer, also I should average ADC readings to reduce it to about 1MSPS, so the data rate is low enough.

[ali_asadzadeh]

Thanks guys for the feedback, specially NorthGuy and asmi, do you have some sample code or code snippets? maybe I can talk to customer to lower sample rate to say 40 or 50MHz.

[NorthGuy]

If you cannot summon 1:14 hardware ISERDES, making your own is very easy. The serdes is just a shift register. Something like this:

Code: [Select]

  parallel: unsigned(13 downto 0);
  serial: unsigned(13 downto 0);

  process(fclk)
  begin
    if rising_edge(fclk) then
      parallel <= serial; -- or use it directly (e.g. connect to FIFO clocked by fclk)
    end if;
  end process;

  process(dclk)
  begin
    if rising_edge(dclk) then
      serial <= serial(11 downto 0)&iddr_q0&iddr_q1; -- for MSB
    end if;
  end process;
If you only want 1 MSps rate, it's better to take a slower ADC.

[langwadt]

Thanks guys for the feedback, specially NorthGuy and asmi, do you have some sample code or code snippets? maybe I can talk to customer to lower sample rate to say 40 or 50MHz.

12 or 14 bits?

[ali_asadzadeh]

If you only want 1 MSps rate, it's better to take a slower ADC.

Thanks for the sample code, The costumer needs this ADC, He wanted to capture with higher data rate and then Make some averages,

12 or 14 bits?

14 bit