My company is looking at the possibility of building an RMC for sbRIO-9607 that will communicate with multiple high resolution ADCs. The ADCs in question only offer a serial interface and therefore this RMC will need to support two or three ~80MHz SPI interfaces.
When playing with the CLIP generator I noticed that the 9607 doesn't include any differential pin pairs, as opposed to the 9651 which has multiple differential pairs. Since both 9607 and 9651 utilize the Zynq-7020 can this really be correct? Or am I missing something?
I am uneasy about our ability to achieve 80MHz SPI without differential signaling. If the 9607 doesn't include differential pairs I think we need to look at using the 9651 instead. Does anyone have any thoughts on this?
Solved! Go to Solution.
The sbRIO-9607 is essentially a functional upgrade of the sbRIO-9605 and sbRIO-9606 products. The sbRIO-9605/6 devices included series termination resistors in the original design to facilitate well-behaved, single-ended DIO signals. When NI built the sbRIO-9607, we wanted to maintain a high degree of compatibility with RIO Mezzanine Cards that may have been designed for the older sbRIO-9605/6 controllers. Therefore, we included series termination resistors on the sbRIO-9607, which precluded the ability to use the FPGA DIO pins as differential pairs.
Excerpt from sbRIO-9607 manual:
The sbRIO-9651 SOM took a different approach than the sbRIO-960x single-board computers. The SOM wanted to expose the FPGA as flexibly as possible, with the caveat that carrier board designers would need to be more conscious of board-level design considerations. This includes connecting the FPGA pins directly to the SOM mass-termination connector without any protection or signal conditioning. Without that protection, the carrier board design must determine if buffers, termination, or other circuitry is needed for reliable operation, and the FPGA can be used to the full capability of the Xilinx Series 7 Select IO primitives, including differential signaling.
Excerpt from sbRIO-9651 manual:
The default timing parameters of the sbRIO-960x RMC DIO are contained within this white paper.
RIO Mezzanine Card Digital I/O Capabilities for Single-Board RIO
If you use the CLIP generator for the DIO of the sbRIO-9607 or the sbRIO-9651, then you do gain additional flexibility to define your own timing constraints which could be higher performance than the defaults contained in the white paper, at the expense of potentially being more difficult to successfully compile.
Spex: thanks for the reply. I always enjoy learning about the engineering decisions made behind the scenes as they help me better understand the tradeoffs between these products.
One more question if we do decide to pursue 9607 instead of SOM:
Seeing as the series termination resistors are, well, in series, I believe we should be able to account for this impedance in our layout and our termination resistors (on our RMC board) to get a differential pair using two single-ended DIO lines.
Is there any way (using CLIP or otherwise) to instruct the compiler to keep routing delays matched between two DIO pins? If so, we could potentially drive a pair of pins with opposite signals (one pin high, the other low) to create a pseudo-differential signal.
The CLIP generator spits out human readable VHD and timing constraint files. The CLIP generator applies some filters and limits to what it allows you to specify and generate in order to prevent users accidentally or unknowingly creating some undesirable or mis-understood behavior. The generated files are intended to be a starting point for advanced users who may want to make more custom changes or implementations.
The Zynq-7020 is still capable of all the 7 Series Select IO capabilities, the CLIP generator just won't automatically instantiate the primitives you are asking for because we limited it. You can always open the files scripted by the CLIP generator and make your own modifications to override the NI behavior and instantiate a differential or pseudo-differential with matched routing timing IO buffer. You could even tie the pseudo-differential pair together in the CLIP so that LabVIEW only sees a single boolean IO node and the CLIP translates that one pin should be driven high with the other being low.
When you enter the CLIP domain, you need to understand the methods and verbiage of the Xilinx compile tools to ensure the constraints and functionality you desire are actually being implemented. There is very little to no documentation directly from NI on how to manipulate the CLIP VHDL and timing constraints. As a bit of a horror story, I've also seen instances when different versions of the Xilinx compile tools may treat constraints slightly differently (hence the updates to the CLIP generator), so you will also be responsible for validating your code if you update LabVIEW or Vivado versions. When relying on custom timing constraints, it can be valuable to review the detailed Xilinx compile log to ensure your constraints are being correctly applied.
Lastly, I should warn that if you manually modify a text file created by the CLIP generator, the CLIP generator will not try to maintain or merge any of your custom changes if you need to return to the CLIP generator to make changes and script out a new set of files. If you don't change the name of the CLIP, the generator will overwrite any custom modifications you made to the CLIP files.
A colleague (who spends his time deep in the HDL & timing constraints world) pointed out that my last reply overstepped a bit. When I mentioned you could manually modify the CLIP files to override the CLIP generator, I should not have used the "differential" mode term. Pseudo-differential could be implemented as described, but if you attempt to use a true "differential" IO buffer in the CLIP, your compile will fail. This is because the power supply rail connected to all the DIO lines on the FPGA is fixed at 3.3V. All the Xilinx Select IO differential standards require 2.5V or lower, depending on the standard. This is another difference with the SOM (sbRIO-9651), which exposes the IO bank power supply rails to the developer. Each FPGA IO standard has their own power supply requirements. The power supplies on the sbRIO-9607 are fixed at 3.3V, so only the IO standards that work at 3.3V can be supported.
You may have already considered this as well, but the more common tactic/solution I have seen to this challenge is parallelizing the data. You can put some circuitry in between the ADC and the FPGA that will break the differential serialized data into multiple single-ended lines that go back to the FPGA and operate at slower speeds (likely 40 MHz switching rate).
Spex: I really appreciate the details you have provided here. It seems that I will need to re-work my plan a bit. I will try to do some testing with sbRIO to see what kind of performance I can achieve using pseudo-differential signaling, but I really need to build a real board to test this idea out because bread-boarding doesn't work well at these speeds. It is 2017 - why don't we have 3D printers that can build complex PCBs from raw materials!?
Eric-M: Yes, that is a good idea. We have actually done something similar in the past (we used a Lattice part to interface directly with other hardware via high speed serial and then sent parallelized data back to the sbRIO). However I had hoped to do this without the Lattice as it is an extra part, adds cost, has a different toolchain that must be maintained, etc. Plus the sbRIO will be very under-utilized in this particular application, and this type of serial interface is within the capabilities of the Zynq-7020 itself.
At this point I am either going to: 1) do as Eric-M suggested and add an intermediate FPGA to deserialize the ADC data, 2) use the SOM, or 3) find an alternate ADC with a parallel interface.
Thanks again for all of your comments.