FlexRio data delay (generate IO Delay)

[mar_just_one]

Hello,

I am using PXIe-7961R+NI 6583 module. I want to implement synchronous digital communication IPs and I need control the data-out delay from the master clock.

To communicate with an external master IP, I am using the timed loop struc with a source clock the strobe line where I connect the clock singal. The result is satisfying: At each Master Clock rising edge, data is generated with a precise constant delay.

I need control that delay (within the single cycle timed loop). This delay do not exceed 1 Master Clock cycle.

In this situation, the best is to include buffers in the IO path to make the path longer... How can I implement this in LV FPGA...

Note: Master clock is not contineous.

Thank you.

Marwen.

[BauerPower]

Hi Marwen,

Based on my understanding of your problem, I'd recommend taking a look at the IODELAY Xilinx FPGA primitives. We do not expose the IODELAY resources to LabVIEW FPGA for the 6583 so utilizing them will require some unsupported modification to the 6583 component-level IP. Specifically, you will have to modify the VHDL to instantiate and configure the IODELAY primitive on any lines that you wish to delay. The IODELAY is capable of delaying the signal in increments (taps) of ~78 picoseconds all the way up to a 5 ns period.

We do use the IODELAYs on the NI 6587 adapter module so if you have access to that adapter modules and all of your signals are LVDS, that would be the simplest route. Alternatively, you could take a look at the VHDL for the 6587 CLIP to help in your efforts of modifying the 6583 VHDL. 

I would also recommend taking a look at the Virtex-5 FPGA user manual for more information on IODELAY primitives starting at page 325: http://www.xilinx.com/support/documentation/user_guides/ug190.pdf

Again, I'd like to reiterate that while this is possible, modifying the VHDL to make use of IODELAY primitives is not something that is directly supported by National Instruments. If this is critical to your project and you are running into issues, I would recommend getting in contact with your local field engineer and we can see what our options are moving forward.

Do you have experience with VHDL and do you think you'd be able to make this modification yourself?

[mar_just_one]

hello,

Thank you for your prompt reply.

Delay function is a must for my application. I do have basic knowleage of VHDL coding, but I am not sure that I can do this 100% correct at the first attempt.

Is there any hardware risks ??

Best regards,

Marwen.

[BauerPower]

Hi Marwen,

The 6583 has buffers to protect the FPGA GPIO so there should not be any hardware risk. While it is unsupported, we'd like to do what we can to help you succeed so please keep us updated on your progress!

[mar_just_one]

Hi Rob,

I succeded to instanciate  IODelay primitive on the strobe IO (input). Now I am able to control the delay as you described. Now I want to go further. 5ns max is not sufficient...Is there a way to obtain more delay (maybe several block in a chain).

The single cycle timed loop allows me to generate on the rising edge of the strobe line. How can use the SCTL to generate on the falling edge of the strobe line? I can't see haw I can configure this. Should I modify some vhdl file? I want to control the delay but with data generated on the falling edge of the strobe.

Regards,

Marwen.

[BauerPower · Accepted solution]

Hi Marwen,

Unfortunately the maximum number of taps will limit the overall range to 5ns max, however 5ns is one clock period so at that point, you should be able to delay your data in the SCTL in LV FPGA.

As for generating on the falling edge, you have a couple of options.

The first can be done in LV FPGA but it is a little difficult to explain. To generate on the falling edge, we would first want to put the module in double data rate mode. Then, it will generate on rising and falling edges. In order to not change samples on the rising edge, the output on the rising edge should match the falling edge value of the previous clock iteration.

For example, let's say you wanted to output the following values in this order: T, F, F, T. You would have to give a value for the rising edge and falling edge each iteration of the SCTL.

Iteration 1:

Rising - F

Falling - T

Iteration 2:

Rising -T

Falling F

Iteration 3:

Rising - F

Falling - F

Iteration 4: 

Rising - F

Falling -T

The one caveat to this approach is that you could only generate at 150MHz because the max DDR is 300 Mb/s.

Another approach would be to invert the polarity of the strobe in the 6583 CLIP. That would require some VHDL work but it would definitely make the implementation in LV FPGA a little easier. Inverting the strobe clock in VHDL would also allow for the 200MHz update rate.

Hope this helps!

[mar_just_one]

Hello Rob,

I was considiring the first approach, however, I though that this is not a wise way.

Finally I modified once again the CLIP by adding a new signal that makes me selected between the strobe or the inverted strobe. I can control this through the front panel. This is working perfectly.

Thank you for help,

After my first week for LVFPGA, I am starting to love it!

Regards,

Marwen.

[mar_just_one]

Hello Rob,

I have another question regarding almost the same topic.

When using the same timed loop (synchronized with an external clock), and without IODelay primitive, the time needed to see an output change after a clock rising edge is ~25ns. Can I reduce this time? I tried to use a VHDL process instead, but it's still the same result... 25ns if I want to use external clocks above 50Mhz...

Regards,

Marwen.

[mar_just_one]

Maybe I have the answer. This is the round trip propagation delay of the cable used...Any suggestion? I'll try to use shorter cables...

Thanks.

[tcap]

Hello Marwen,

So from what I understand, you have an external clock at triggers the front-end to output a value change. The time between the front-end change and the clock trigger is 25ns.

How are you measuring this delay?
What is the rate of your external clock?
What performance are you expecting to achieve?

The front-end delay of this module is not specified, but I think that this might be part of the problem. In this case, we cannot reduce this further, but you can still output a signal at faster rates. The output would not occur during the clock cycle you specify the change; it will always be delayed by 25ns.

Regards,