Hi, I have a Software Defined Radio application in which I would like to attach an Analog to Digital (ADC) chip directly to the Jetson. Is it possible to do so? could I transfer 1.5Gbps per second? has anyone had experience with using the CSI or HSI Vision interface for such a project?
thanks for your private or public comment/suggestion,
Ken N9VV USA
ADC → EZ-USB FX3 → USB3.0
And you have the advantage that you’re not locked in to a platform that NVidia doesn’t seem to care about supporting.
I’d agree USB3 is probably the way to go. Still, I’m curious what the ADC output format is? Is it a single serial lane (LVDS or TTL?)? 8-bits? Does it have a clock input/output needing sync? This could change construction regardless of interface.
as far as I know the ADC produces 16 bit (“shorts”) samples at 130 MSPS http://cds.linear.com/docs/en/datasheet/2208fc.pdf
the ADC interface can be either CMOS or LVDS according to the data sheet.
Nice chip…that’s some healthy sampling power. Here are some observations…
This chip uses a single 3.3V supply. The tegra124 chip is capable of having its GPIO tethered to 3.3V, with no conversion, but on Jetson it is tied to 1.8V. Direct GPIO would require a level conversion.
This is some serious bandwidth, and since it is 16-bit width, this means RF behavior would require all 16 bits to be available and stable at the same moment. Not hard at lower sample rates, but this is an issue at this speed (trace routing matters). The LVDS format is more immune to issues than the CMOS format (you can pick either on this chip). To use CMOS you would likely have to integrate this on a custom board directly connected and close to the tegra124 (or direct consumer of the 16 bits).
The nature of what you are doing (looks like you are creating an FFT-based radio receiver or spectrum analyzer) means I doubt a small latency would matter to you…the PCIe or USB3 bus should do the job. It might be necessary to add a small amount of buffering, which increases latency, but not by any amount a receiver or spectrum analyzer would care about.
LVDS fits in nicely with USB and PCIe formats, even with additional routing distances. The difficulty is that this is 16 bit parallel, so mandatory serialization before transmission over PCIe/USB is needed, and the conversion will need to be physically close to the chip (meaning you can use CMOS format anyway). USB3 or PCIe transceivers then take over the issue of signal quality.
If you plan to control this device from Jetson, you still have to worry about control signals. These do not look to be an issue for speed, so almost anything will do. If you use USB though you will have to invent a driver which separates out to/from traffic at the sampling chip end. For PCIe there already exists a TX and RX lane for each x1 lane (bidirectional, not just a D+/D- like USB), so if you can afford to do PCIe, this might actually be simpler. Since total throughput (2 bytes * 130M samples/sec ~= 248 MB/sec or 2000 Mb/sec) USB2 is ruled out, but either USB3 or PCIe x1 will probably work. Cost goes up, but I’d think in the long run PCIe is easier.
The mini-PCIe slot on Jetson contains 1 RX and 1 TX PCIe transceiver (making it x1), but the mini-PCIe format gives you another option. This slot also has a USB D+/D- LVDS connection…you can use this slot for USB if your signal behaves “USB correct”, skipping a lot of the peripheral USB complications, but you would still need that parallel-to-serial conversion, and you would still need the sampling chip side to decode control instructions (using USB D+/D- on mPCIe may not be much of a gain)…while losing the ability to just plug it in with a cable. This would also make the mini-PCIe mandatory since you won’t be finding D+/D- on full-sized desktop PCIe. Choosing a purely PCIe x1 solution would mean it could be used in full-sized PCIe slots with nothing more than adapting the physical card slot.
The other poster mentioned “ADC → EZ-USB FX3 → USB3.0”, which I’ve never used before, but looking it up shows it might be inexpensive to test with this…it looks like a contender with this:
http://www.cypress.com/?rID=99917
http://www.cypress.com/fx3/
As for development kits on mini-PCIe I’m not sure what is out there, but it is usually expensive.
Hi there, I am pretty much in the same boat as N9VV. I would like to connect a RF front-end chip to the Jetson: 4 x LVDS ADC output 2 bit@up to 100 MHz each; 1 x LVDS clock lane. How would you guys tackle this in the most elegant/price sensitive way? If I understood correctly using an EZ-USB FX3 without additional components - such as a FPGA - won’t work as the EZ-USB FX3 doesn’t support LVDS natively. Thanks!
IMHO, the right way of doing it would be using an FPGA with PCIe hard IP
I’m with dongie on this one. Jetson is IMO already an orphaned platform, a reality which will become more apparent as soon as Nvidia releases its next shiny (X1-based board), any day now. The main thing Jetson has and competing dev boards don’t, is the GPGPU (CUDA) capability. If you want to use it, though, you’ll be tied to Nvidia’s “Linux for Tegra” forever, which is in turn tied to a somewhat idiosyncratic spin of Ubuntu with a fairly ancient Linux kernel. Thus, unlike the situation with their x86 closed drivers, Nvidia’s Tegra support is effectively locked to a single point in time. Going forward it will be more and more difficult to use (although to be fair, the TRS80 in my closet runs Space Warp now just as well as it did in 1980).
The sort of hardware design you’re contemplating is a significant effort. If it were me I wouldn’t want it tied to a specific platform. BTW if you’re interested in cheap/different direct-sampling SDRs, have you looked at “Hermes Lite”?
Mark KJ6PC
One thing I’ve wondered about is the mPCIe slot’s D+/D- capabilities…regular PCIe does not have this, but mPCIe has an optional pass through of the LVDS for the USB controller (Jetson does have this connected, I’ve not heard of anyone using it).
On the Jetson schematic, mPCIe connector J2D2, you’ll see pins 36 and 38 are labelled USB_Dn and USB_Dp…these are USB LVDS data lanes tied directly to a USB controller. Most mPCIe cards will use the PCIe TX/RX for data, but mPCIe optionally makes the USB available for people who want to port their USB to an mPCIe slot…if you were willing to produce an interface in the form of a simplified half-length mPCIe 4-layer board, you might find this acceptable, but I have no idea what the performance capabilities are for this particular data lane. Very likely (I have not confirmed) this D+/D- would be USB3.0 speed capable if design follows impedance and layout requirements.
For your sample device, does it have an option to use a single USB3.0 LVDS data lane for everything which is speed critical? GPIO could still be used for lower speed data where timing isn’t critical…this would keep cost down even if it isn’t ideal. Wiring to J3A1/J3A2 GPIO would still be practical if speed is not critical. More money could be spent to use the actual PCIe x1 TX/RX data lanes and this would leave the design portable, but designing for a custom PCIe card using the x1 data lane would definitely be expensive.
USB 3.0 uses extra LVDS pairs (that’s what the extra contacts in the USB 3.0 connector are for); thus, D+ and D- still only get you USB 2.0 capabilitiy, even on a USB 3.0 hub.
That makes sense…so for this ADC function USB 2 speeds would have to suffice when using those pins on the mPCIe. I guess it comes down to what speeds the ADC needs. Even if mPCIe would work, it sounds like the ADC in question would need significantly more than just 1 LVDS anyway…which is why the FPGA matters. I think the GPIO could handle this with the right layout, but running at high speeds using the generic J3A1/J3A2 connectors would be difficult…once more pointing back to an FPGA solution.
Hi there - thank you very much for your insights and suggestions. As it turns out the chip also supports CMOS output. So, the EZ-USB-FX3 is an option again.
One other option would be ADC → FPGA → TK1 GMI
But I agree that in any case it would be quite some effort to implement any solution: EZ-USB-FX3 would require some software development for it’s internal ARM9 and FPGA would require some digital design.