LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Compliation Timing VIolations at 200 MHz

Dear All,

I am trying to compile my FPGA at a faster clock-cycle (200 MHz) than the default 40 MHz. Unfortunately I get a Timing Compilation Error on the standard NI PID SubVI attached below.

Could someone give a suggestions on how I can overcome this problem.

I am using LabVIEW 2016 and my FPGA Target is 7853 R.

Download All
0 Kudos
Message 1 of 4
(2,587 Views)

Why are you increasing the clock rate?

 

In short - to run at 200MHz the code requires quite a bit of optimisation which obviously hasn't been done on the PID block - there isn't much need for PID loops running at this rate!

 

What are you trying to achieve? The board you are using only has 750kS/s input so it doesn't seem like you should actually need a PID loop running faster that 750kHz - is there some other reason for running this fast?

James Mc
========
Ask me about Rust & NI Hardware
My writings are at https://www.wiresmithtech.com/devs/
0 Kudos
Message 2 of 4
(2,585 Views)

Dear James,

Thanks for your suggestion.

Finally I laid my hand on FlexRIO 7962 card that will run my PID code. I intend to excite a cantilever at higher modes, in the tune of several MHz, that's why I need my PID to run at a much faster rate. 

Thank you.

 

Best,

Ben

0 Kudos
Message 3 of 4
(2,556 Views)

Ah so that makes more sense for the rates!

 

The short version is that NI's PID is going to have been coded to be flexible to different applications. Compiling anything at 200MHz is going to require something heavily optimized which means NI's PID block may not work at 200MHz. Looking at what you have sent it looks like it's limit is going to be around 80MHz.

 

There are standard routes to optimizing it which is reducing logic and adding pipelines. I don't have 2016 on this machine so I cant look right now at what you have done but basically:

 

* Reduce any un-needed logic.

* Reduce data types to the minimum width - especially with multipliers when you reduce passed the width of them you remove whole multiplier requirements (these are 25x18 so keeping to 16 bit data types might be a good approach). 

* For data processing we would then add pipelines - these introduce latency though which will affect PID performance. I suspect you can tune it to account for this to an extent but I've never tried.

 

I'll try and look at your code directly but it may not be for a couple of days.

James Mc
========
Ask me about Rust & NI Hardware
My writings are at https://www.wiresmithtech.com/devs/
0 Kudos
Message 4 of 4
(2,549 Views)