6

I have an ADC sampling at 500MHz (It is collecting data from an Ultrasound sensor). I need to be able to stream this data to my PC (for the time being - this will be done through a wireless unit). I am looking for a computing solution that sits in between the wireless unit and the ADC. I am putting all of this on a robot and I am trying to keep it as small as possible (in terms of dimensions) and hopefully keep the power consumption low.

Is there a solution that is better than using an FPGA? I have read that it is very hard to get an FPGA to run at 500MHz and some kind of Parallel computing might be required? Does that mean I am supposed to use GPUs?

JJT
  • 289
  • 3
  • 8
  • 5
    Are you serious, utra-*sound* at 500 MHz? – Wouter van Ooijen Feb 14 '15 at 14:31
  • Ok, so let us say that you are using a 10-bit ADC and wants to send this data at 500MHz. We arrive at the following rate: 5Gbps. If you are trying to transfer 5Gbps through a wireless link, I think it is a little bit utopic. – gstorto Feb 14 '15 at 14:35
  • It is a 250MHz ultrasound sensor. The sampling is done at a higher rate. Sorry, I haven't thought as far as the wireless link. I was mainly concerned about the ADC link. I might average (to prevent noise) and/or compress the data before sending it via the wireless link. So, I probably would have an intermediate buffering stage. – JJT Feb 14 '15 at 14:51
  • 2
    What are you trying to achieve with such extreme frequencies? The wavelength of 250 MHz in air is about 1.3 microns, and air is extremely lossy at these frequencies. A 250 kHz sensor, sampled at 500 kHz or maybe 1 MHz, would make a lot more sense. – Dave Tweed Feb 14 '15 at 15:15
  • 250MHz is apparently not a typo, there are people using it for skin imaging. It's not hard to get FPGAs to run at 500MHz, in fact I think that's your only realistic option. The ADC will probably output LVDS - what part number are you using? I've been involved in a similar project and warn you that it's neither cheap nor easy. – pjc50 Feb 14 '15 at 15:16
  • @pjc50: But it doesn't make much sense in the context of a robot project. – Dave Tweed Feb 14 '15 at 15:19
  • 1
    @DaveTweed who knows, maybe it's a skin-crawling robot. – pjc50 Feb 14 '15 at 15:21
  • @DaveTweed Yeah, I thought the same but then I saw this: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=1399627&contentType=Conference+Publications – gstorto Feb 14 '15 at 15:22
  • @GleisonStorto: I would be willing to bet that that's about sonar *in water*, where it makes sense. I'm assuming that the OP's robot is in air, since he's talking about using a wireless link (presumably RF). – Dave Tweed Feb 14 '15 at 15:25
  • I'm not sure what the OP is doing, but if it's in a liquid or solid then ultra sonic pulse widths less than 1uS are common, and if you wanted to see the shape of the reflection I can imagine sampling that fast. – George Herold Feb 14 '15 at 15:47
  • What is the 500 MHz ADC connected to now? A custom board, or something that you can provide specifications or a link for? Obviously the data rate is too high for Wifi. But if you don't sample continuously, or if you can perform some data reduction prior to transmission, that will help. 10 years ago I worked with Xilinx VirtexII FPGA's that could run at 400 MHz. I would not rule out FPGA's without independent investigation. – user57037 Feb 14 '15 at 17:09
  • 1
    The sensor may transmit at 250 MHz but its bandwidth is almost surely only a fraction of that, probably less than 10%. You only need to sample at several times that bandwidth which would reduce the data rate considerably. – Barry Feb 14 '15 at 17:28
  • Without going to a custom IC, FPGA might actually be your only option for the initial interface to the ADC. Now you get these bytes of data in the FPGA, coming in at 500MHz, what to do with them. Two choices you have implied, do some processing inside the FPGA, or somehow pass them to some processor array. And then what... None of these are going to be easy. – rioraxe Feb 14 '15 at 18:57

1 Answers1

2

One solution is to use a demux to reduce the ADC sample rate, and take advantage of the large number of pins on the FPGA.

For example, the ADC could be clocked at 500 MHz, and the FPGA at a more reasonable 125 MHz. Then a 4:1 demux can be used - collecting 4 ADC samples for each tick of the FPGA. The bus becomes 4 times wider, so at each tick the FPGA needs to ingest 40 bits, not 10, but that's not difficult to deal with.

In my application, the 2Gsps ADC and 8:1 demux are sold as a pair, so its output becomes 88 bits at 250 Mbps. There's no other way to use the ADC.

I assume you won't be sampling for very long, at that rate. The processing requirements will be determined by how many samples need to be used, and how quickly you need answers. For example, you could use 10GbE fibre to transport the data from your robot to a regular PC, for offline processing, no exotic hardware or software required.

Regular off the shelf wireless links only work to maybe 100Mbps, and only in ideal conditions, not found on a moving robot. Something will need to buffer the whole signal before you download it. DRAM on the FPGA? Embedded PC? Good luck!

tomnexus
  • 7,617
  • 3
  • 19
  • 35
  • 125MHz is REALLY slow for a FPGA. With a Stratix IV, I could reach easily 250MHz. It depends on the kind of operations he is going to do with this data, and the resolution of the ADC. A 32-bit addition is perfectly possible at 250MHz, a 64-bit he would have to split it in two cycles. – gstorto Feb 15 '15 at 06:28
  • Yeah, you can go much faster than 125 MHz. I have a design on a Spartan 6 that works at 250 MHz. And the PCIe gen3 x8 core comes out at 256 bits at 250 MHz. The DSP slices on the Virtex 6 FPGAs can go up to 600 MHz and up to 700 MHz on the Virtex 7. – alex.forencich Feb 15 '15 at 07:31