From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

High-Speed Digitizers

cancel
Showing results for 
Search instead for 
Did you mean: 

FlexRIO 5781 Timing Violation

Hello,

I am having trouble with timing violations popping up whenever I try to compile my code, and it is driving me a bit crazy.

The FlexRIO module I am using is NI 7953R with NI 5781 high speed I/O module. The aim is to perform some real-time control and estimation in an optics experiment.

The controller is to be realised as a cascade of second order sections, with reasonably high internal precision: +/-<24,4> for inputs, coefficients and outputs of sections, with +/-<48,8> for intermediate results. Obviously, the final output is truncated to 16 bits for the DAC.

The initial simple project is just a single biquad, just to test the behaviour, before moving on to the full controller and estimation. However, this is where I got stuck 😞

Initially, I tried using the system-synchronous CLIP for 5781, with IO Mod Clock 0 driving ADC, DAC and the SCTL containing the biquad at 100MHz. Unfortunately, the compiler reported a timing violation of about 3ns over the required 10ns in the SCTL containing the biquad (consistent with the 100 MHz clock).

As the 100MHz is a bit of an overkill for the bandwidth of the experiment, I turned to clock-division in order to run everything at a lower clock rate. 50MHz and 25MHz would satisfy the requirements, but I could not go lower than that because the I/O delay would become unacceptable. So the only lower achievable frequency of 10MHz was not an option, but that didn't matter anyway. As clock division can only be achieved with standard CLIP, I had to forget about using the system-synchronous CLIP and flip-flop FIFOs. Unfortunately, the only FIFO I could use across different clock domains was the block-memory, which would increase delays to borderline acceptable.

Unfortunately, I never really got to the point of checking the delay for the biquad implementation, since I could not get past the compilation stage.

The project (attached) uses the code from LabVIEW 'clock division' example in both host and FPGA VIs. The modifications were the SCTL containing the biquad, and input clock division (the example only divides the output clock). All coefficients are created as constants, and all arithmetic operators' output configurations are set manually to +/-<48,8>, 'truncate' and 'wrap', in order to avoid making the logic in the FPGA more complex.

The FIFOs are block-memory and minimum length, while the IO Clock 0 and IO Clock 1 were set to compile for frequencies between 1 and 25 MHz (I wanted to check it working at a lower clock rate before moving to higher, and 1MHz was put in there just to relax the timing restrictions). Considering that the total delay inside the loop in the previous case was 13ns, I thought 40ns should easily accommodate two, maybe even three biquad sections.

I was wrong.

Now the compiler reports timing violations for non-diagram components! Whatever those are...

I have also attached window captures of all the reports as well as the Xilinx log. The Xilinx log shows that my code is still checked against a 10ns timing constraint, although there are no 100MHz clocks included in the project, and the loops use clocks that should be compiled for the range between 1 and 25MHz!

BTW, I tested the same project without the biquad section (replaced the biquad with a wire connecting Data In and Data Out FIFOs), and it does not do anything but it compiles and works. I tested it with a second-order FIR (basically removed all the feedback) and it fails with 6ns over 10ns constraint. So I guess that the problem lies in that SCTL.


Based on the above, I see only two possible explanations:

1. I am doing something really stupid, and am not aware of it, so that messes up my project (wouldn't be the first time).

2. Whatever the clock frequency I select, the SCTL will work only if the code in it executes in 10ns (which seems to defeat the purpose of clock division and SCTLs, since you apparently cannot do very much in 10ns, not even a second order FIR).

I honestly hope number 1. is the case.

Apologies for the length of this post, but I figured it was best to provide all the information I could right at the start.
If anybody can help I would be very grateful.

Download All
0 Kudos
Message 1 of 3
(5,827 Views)

I'm getting similar problem.

I'm using NI 5751 digitizer with PXI flexrio 7954 

I will reply as soon as I have some clues.

0 Kudos
Message 2 of 3
(5,809 Views)

Hi Aleks,

 

It sounds like this issue may pertain to the FlexRIO you are using.  You may want to try posting this question on the Real-Time Measurement and Control board, as that board is dedicated to answering questions that pertain to the FlexRIO.

 

Hope this helps,

Andrew

National Instruments
0 Kudos
Message 3 of 3
(5,784 Views)