sbrio-9651 IO length matching

[abadobid]

We are considering interfacing a high speed ADC (1GS/s x8bit) that uses a 16bit wide (two samples) LVDS interface to an sbRIO-9651.  Is there a resource that provides information about the sbRIO-9651 module layout details such as worst case line length mismatch within differential pairs and between differential pairs that exists on the module (independent of our own board layout)?

Since the interface uses a common differential clock and 16 bit wide interface, I am trying to get an idea of the worst case skew there could be between seperatate differential pairs.

I can use they Zynq date sheet to have some idea of maximum data rates, but are there constraints on the module itself that will limit the date rates?

[Spex · Accepted solution]

Hi abadobid,

The sbRIO-9651 Specifications Manual (Table 😎 should have the on-module trace length info details you are looking for.

In addition, I recommend reviewing the SOM Carrier Design Guide for detailed techniques, guidelines, and requirements for carrier board design.

Lastly, for future questions that are hardware design specific for the SOM, we have set up a dedicated community/forum that will probably be the best location to get help.

Hardware Developers Community for NI Single-Board RIO and System on Module

Resources for NI System on Module

Regards,

[abadobid]

Thanks Spex,

I can't believe I didn't see that in the specifications manual.  That's very helpful.

[Spex]

No problem Abadobid,

You mentioned constraints in your first post, so I'll add another point of information. With the SOM, the FPGA IO is exposed at a lower level than many NI FPGA devices. You can edit the HDL for the FPGA IO on SOM to get the high performance IO, including applying timing constraints or taking advantage of Xilinx IO primitives. Editing these constraints may be necessary for your design to achieve your targeted IO rates and guarantee to meet timing.

Regards,

[abadobid]

Thanks Spex,

What I am currently investigating, and am hoping perhaps you can tell me if I am wrong, is the ability to have direct DMA from the FPGA to DDR memory.

Essentially I need to aquire data from a high speed 8bit 1GS/s ADC for a burst aquisition of approx. 6MSamp.  Nothing would be consuming this data while it is aquired, but it would just be streamed into DDR memory as a single shot measurement, then accesses later.

 I am very new to LabView FPGA, but from what I do know I imagine this would mostly have to be implemented using an HDL to make use of xylinx primatives and the resulting HDL would have to be part of a socketed CLIP.

I'm just trying to get an idea, from a hardware standpoint, if there is anything in the SOM itself that would prevent me from doing this even if the ZYNQ is capable.

Thanks,

[Spex]

Nothing on the FPGA IO side should get in the way.  You are correct regarding the socketed CLIP and HDL, and at the rates you need, probably will need to take advantage of the Xilinx SERDES.  The starting point for the socketed CLIP HDL would be generated by the sbRIO CLIP Generator utility (to create the framework), then you can modify and customize to use the Xilinx primitives as needed.

After the data is actually aquired with the CLIP HDL, you will have to use the LabVIEW DMA capabilities to send the data to the processor DDR memory. The throughput of the LabVIEW DMA engine is about 300MB/s, so it obviously couldn't continuously stream the amount of data you are capable of generating, but that may be fine with your limited record length. The FPGA to host memory throughput could easily be tested with simulated data before going through the process of interfacing to your high speed ADC.

Regards,

[David-A]

If you're looking for a more off the shelf solution that lends itself well to an embedded enviroment, you could consider going with a 7931R and a 5771.

The 793xR Controller for FlexRIO will have a larger footprint then the SOM but it offers access to a portfolio of high performance IO that may already provide you what you are looking for. 

[abadobid]

Thanks David,

In our case we need the compact form factor of the sbRIO9651.

[abadobid]

Thanks Spex,

I'm trying to get an idea if it is possible using a socketed clip to use the ZYNQ PL to directly stream to DDR using the HP AXIS port as described in http://www.xilinx.com/support/documentation/white_papers/wp459-data-mover-IP-zynq.pdf

This would be incoherent for the PS, but since we are just interested in burst acquisition, I think the coherency can be handled after the fact.

As I said, I'm not too familiar with LabView FPGA yet.  Is it possible to allocate a larger buffer on the PS side (12MB) or smaller chunks using scatter/gather, and make the physical address(es) of those buffers available to IP on the PL side and then access those buffers later from LabView on the PS side?

I know I'm talking high level here and leaving out lots of details.  I'm not sure what the labview DMA is using behind the scenes and whether there is some work that can be done in IP in the CLIP that will allow us a higher burst data rate for the fixed number of samples we need.

What is the primary limiting factor for the 300MB/s DMA?

Thanks,

[Spex]

Hi Abadobid,

The LabVIEW DMA engine is using the cache coherent AXI interface, and the primary limiting factor for the 300MB/s is the clock rate of the DMA engine.  NI clocked the DMA engine arbitrarily at 40MHz because 320MB/s (64-bit x 40MHz) was more than sufficient for the C Series IO interfaces used with CompactRIO, and 40MHz has a high likelihood of compiling in a reasonable time across a wide variety of customer scenarios.

I'd like to talk in more detail about methods of overcoming the 320MB/s limitation (and confirm that it is a limitation since you only need 6MB of data per burst).  What we have discussed so far is very straight forward, but there may be methods to get higher throughput via non-LabVIEW implementations.  I'll send you a private message with contact information so we can sync up, and determine if other members of my team (my knowlege is focused on LabVIEW and the system-level hardware) can help contribute to a solution.

Regards,