FPGA, Constraining IO timing in sbRIO9606/5 Mezzanine connector?

[heel]

sbRIO9605/6 has a Mezannine IO connector for custom circuitry. There is a note about design and timing for RIO Mezzanine Card (RMC) connector and it is faily clear and well written - but unfortunately also faily conservative.

I am designing a streaming input from an ADC and want to optimize it for maximum speed.

What are the options for affecting the timing of the IO registers? I could think of the following:

1. Will adding synchronization registers in the I/O property settings (right-click in LV project's IO item) ensure that a Flip-flop will be placed in the periphery IO block (IOB=true). IOB in the periphery will optimize the timing for low setup and hold or clock to output delays.
2. Could one “patch” the constraint file “….\source_files\toplevel_gen.ucf” located in the FPGA compile sub folder and add a constraint like this (for the DI0)
   INST "DI0" IOB=TRUE; ?  xilinx contraints guide
   But is this possible, as it requires to “halt” the compile process, then patch the file and finally restart the xilinx compiler? Not sure how to do that.
3. Would it be possible to control the IO timing by designing the IO part in CLIP file, because in there one could apply the constraint as a VHLD attribute: attribute iob of di0 : signal is true;

Thanks for any ideas on this subject

Henning

[Andrew_E]

Hello,

I just wanted to clarify that the synchronization registers are used in the I/O nodes by default. This is specified in the linked document:

"FPGA Sample Clock to DIO Out is the maximum time that it takes a DIO line to change state at the RMC connector after the FPGA sample clock’s edge.This specification is valid only if synchronizing registers are used in the I/O Node. These are turned on by default." This ensures that a Flip-flop will be placed in the IOB.

We (in NI R&D) would really like to hear more about your application and the types of rates your are looking to accomplish. We would like to discuss your application more directly. The best way to do that would be to call in to NI Support (1-866-ASK-MYNI) and have the applications engineer route you to R&D for the sbRIO-9605/9606.

It would also be nice if you could post a description of your application and the type of rates you are trying to accomplish.

Regards,

Andrew Eddleman

[heel]

Our application should sample continuous streaming data from a couple of ADC’s at a sample rate of minimum 25MS/s. The FPGA will do the data reduction before sending the data further on to the RT-LV or the PC host. I see the data bus between the RT controller and the FPGA is 33MHz, so 25MHz should be possible as well.

Thanks Andrew, Indeed, it says that the IOB can be placed in IO cells by selecting the right IO properties – I overlooked that. This actually answers the specific questions I posted. Thanks for that.

I will elaborate a bit on our ideas for the benefit of other users, and pose new questions

Having the IO registers firmly fixed in the FPGA removes the variance in delay due to FPGA routing from compilation to compilation. That was my prime concern - to have timing that changes from one FPGA compilation to the next. Then there remains the delay skew in the different IO paths on the PCB’s, connectors and external gates. Part of this will vary with operating conditions such as temperature.

As there is no way to use the IO'port signals as a clock signal inside LV-FPGA (am I right?), I was thinking of using a data strobe and a fast sample clock in the FPGA to sample this strobe and the parallel input data and then select the proper sample which falls in the centre of the eye-pattern of the parallel data stream.

If the strobe is coming from the ADC itself (many adc’s provides this) and is passing the same gates as the data, then delay variations due to voltage and temperature are also matching up.

There remains a fairly constant delay skew which unfortunately narrows the eye window width. A procedure to measure this eye pattern should be easy to make in an offline manner (just acquire a stream of data and analyze the content) and subsequent one can adjust the sample point and set it for future compilations.

Doing this window tracking in an automatic way could be nice, but will have to be figured out.

Finally this brings me to these suggestions and questions: In LV-FPGA it would be useful to have 

1. Ability to control the IO standard of the RMC mezzanine IO’s (both level and drive strength). Many newer high performance ADC’s have 1.8V output standard which will not drive a 3.3V FPGA input.
2. Ability to control the IODELAY elements present in the Xilinx IO blocks. This could help widening the eye window by lowering the static data skew.
3. Abilty to push the IO port out of the grips of LV-FPGA and into the users control in a kind of CLIP file context. I.e. In that way one could posibly adress point 1 and 2 in this list. Maybe thats what is called a socketed IP?

Are there currently a way to do this? In particular control of the IO standard would be really useful as 3.3V IO eliminates a lot of the more recent ADC.

Best regards

Henning

[Bassett_Hound]

Hi Henning,

Thanks for the suggestions and questions.  To answer your third question first, the sbRIO platform does not currently support socketed clips but thanks for providing the feedback to help better the product.  

Before diving into the rest of your feedback and questions, can you tell us a little more about the planned interface to your ADC?  (i.e is it parallel, QSPI, etc?)   You might be able to use your strobe method described, but we would like to understand your planned interface better.

Regards,

Bassett Hound

[heel]

Hello,

We appreciate that you take time to consider our questions and suggestions.

For modern high speed ADC’s there are various mixes of output standards, notably differential LVDS (low voltage differential signaling) combined with DDR (double data rate with clocking on both rising and falling edge). The LVDS scheme has the advantage of lower switching noise and common mode immunity.

As previously mentioned, many recent ADC’s have 1.8V Digital IO standard, and converting this to the sbRIO-RMC with 3.3V standard, is possible, but excessively clumsy. So having the ability to switch the sbRIO inputs to 1.8V digital level would be an advantage.

The IODELAY blocks present in Xilinx IO’s could be useful to fine-tune the matching of the path delays between the different data bit’s.

With these statements I just want to illustrate what features it could be practical to have available in sbRIO-RMC.

Note that, as far as I can tell, it is not the FPGA or Xilinx compiler which prevents this to happen, but the LabVIEW-FPGA software. 

Given the various constrains, the implementation I plan to use –– is a simple parallel data lane at 3.3V standard and the ADC’s are ++25MS/s, 14bit. This is the best match to the width and data rate currently offered by the sbRIO9606 RMC port.

Attached is the design foundation I plan to use having this plain vanilla parallel ADC interface.

Best regards

Henning

[Bassett_Hound · Accepted solution]

Hi Heel,

Thanks again for the feedback and suggestions.  The sbRIO-9605/9606 boards are limited to singled ended 3.3V IO. Both the IODELAY blocks and Socketed Clips are interesting features we will look at for the future.  

Regarding your implementation below, assuming your VI compiles, you'll want to make sure the skew between the strobe and data lines is accounted for.  We should note that the skew numbers in the white paper are at the RMC connector and account for the FPGA and board skew.  

Regards,

The Hound

[heel]

Hello,

Appreciate your comments. You dont mention what is the reason for the IO being limted to 3.3V. Is it the hardware (typically IO supplies will set output drive capabilty) or is the software? Just curious.

I  want to add, that the vi did compile with the clocks shown. Albeit without anything else in the vi. So I watch out for slowdowns and don't make anything complicated in the resync loop. The 240MHz is really more than will be required, but it gives good fleksibilty in the phase maching. Once I get my sbRIO and some electronics hooked to RMC I will, as I also mentioned previously, make a dump of the data from the ADC at full speed (240MHz) into a large fifo and offload onto LV host for post analysis. It is then a simple matter to determine the optimum sample instant by doing some switching statistics. Hint: This also works on a individual bit level and at 240MHz offers delays of 4ns*N. I.e. kind of coarse IODELAY! This knowledge will then be hardcoded into the final version. Because the timing between the RMC and the IO FF's wont change in future compilations once the register is locked in the IO buffer's, this should ensure a consistent timing - and I am back to where I started in this post.

I am very anxious to test it.

best regards

Henning

[Bassett_Hound]

Sorry...I should have mentioned we do not provide the 1.8V support for the IO as the limitation for the Hardware.