0
\$\begingroup\$

I have a 1.8 V, 125 Msps ADC (ADS4125) with an output of 12-bit parallel LVDS or CMOS. The system is operating in bursts: the data is sampled for 8 - 30 us, with a 100 ms wait time in between. I need to get this data onto a PC with the minimum number of ICs (the simplest system), but after searching for possible solutions, I am still not sure of the best option to go around it. The current state and my thoughts are as follows:

  1. An FPGA is a default option, but the development on the FPGA side would likely take a long time.
  2. A FIFO could be an option, but the only one that meets the 12-channel, 125 MHz specification is SN74V245-7PAG, operating at 3.3 V. This would entail adding a level-shifter after the ADC, but I could not find an IC that would meet the speed requirements in a single IC package.
  3. I could use LVDS outputs with a differential line receiver SN65LVDS386DGG. I think it would be able to take the 1.8 V LVDS from the ADC and generate a 3.3 V LVTTL signal. If I then add the FIFO after it, the problem is solved. This option should also work if I need to situate the ADC remotely: I could keep the majority of the system and add an LVDS driver: ADC 12-bit->> LVDS line driver 12-bit->> SN65LVDS386DGG >> FIFO >> MCU.

To summarise, the ideal option for me would be a 1.8 V FIFO or some memory chip directly after the ADC. I could then get the data out using a microcontroller, but the only 1.8 V FIFO I found was CYF0072V33L, and it is already obsolete. I am not familiar with other memory types that could provide the necessary functionality and option (3) currently seems to be the best option.

Questions:

  1. What is the best solution in this case? Have I missed any possible alternatives?
  2. Is my interpretation of SN65LVDS386DGG specification correct, and could it handle the 125 Msps LVDS signal from the ADC?
  3. What type of other memory-type ICs could be used in this system?
\$\endgroup\$

1 Answer 1

1
\$\begingroup\$

I spent a while looking at this problem, digging through open source projects and pulling apart commercial devices to see what was being used. The easiest solution I have found is to use a USB ASIC to stream data to the host PC. The advantage of this is that it avoids the extreme complexity of a full FPGA implementation and that USB is comparatively simple compared to other interfaces like PCIe.

There are a couple different chips you could use, but I would look first at the EZ-USB FX3 since it comes in an extremely inexpensive development board with a parallel CMOS pin header and a large number of relatively simple to adapt programming examples. You can plug your CMOS data and clock lines into the header and then use their example code or GUI application to stream data from the CMOS pins over USB. In one project I used that part to stream 12 bit, 160 MS/s continuously for more than 1 week with no dropped samples, so it should meet your requirements. The downside is that the hardware and its interaction with the host USB stack can be glitchy, and I did occasionally find that I had to unplug/replug the device to get it working normally again, especially after faults.

\$\endgroup\$
2
  • \$\begingroup\$ Hi, this is something I have not been aware of. I appreciate you bringing this to my attention. I have looked into the components, but they only handle 100 MHz input signals. Could you comment on whether you had to customise the system to work at 160 MS/s? \$\endgroup\$
    – Nitrogen
    Commented May 31 at 10:41
  • \$\begingroup\$ @Nitrogen I'm wrong, it can do 32 bit @ 100 MHz, so without some fairly complicated 2:1 deserialization it won't work. There's a faster version announced but not yet shipping. \$\endgroup\$ Commented May 31 at 12:10

Not the answer you're looking for? Browse other questions tagged or ask your own question.