First, to be blunt that fpga code isn't very good.
There are 8 divisions in the code and these should be stripped out wherever possible. Division is quite expensive and that is why such little code is taking 90+% of the FPGA.
Here is what I have to offer.
You have two x/16 that should replaced with x*2^(-4), same effect but free on the FPGA.
There is scaling done on the FPGA that could be done better on the RTHost, provided you don't need high rates. The pressure input may be a good candidate.
Do you need FP indicators and the FIFO? I would pick one.
I attached a JPEG showing some ideas for optimization in your code. I ran the code clean up tool first.
I may have something further, given more time.
I would attempt to keep datawidths in check wherever possbile. Forcing the output of a function will help, provided you KNOW the value won't overflow the datawidth you choose.
Good luck.
From xflow.log the timing violation seems to come from a fixed point multiply in the loop (as in bold):
Timing Summary:
---------------
Speed Grade: -4
Minimum period: 28.046ns (Maximum Frequency: 35.655MHz)
Minimum input arrival time before clock: 15.567ns
Maximum output required time after clock: 10.653ns
Maximum combinational path delay: No path found
Timing Detail:
--------------
All values displayed in nanoseconds (ns)
=========================================================================
Timing constraint: Default period analysis for Clock 'Clk40'
Clock period: 28.046ns (frequency: 35.655MHz)
Total number of paths / destination ports: 5660726965 / 8321
-------------------------------------------------------------------------
Delay: 28.046ns (Levels of Logic = 38)
Source: window/theVI/n_695/n_694/n_692/n_664/clockDataOutInternal_8 (FF)
Destination: window/theVI/n_695/n_694/n_692/prim_MUL_0172/NiLvFxpEnableHandlerx/NiLvFxpEnableHandlerSlvx/cOut_63 (FF)
Source Clock: Clk40 rising
Destination Clock: Clk40 rising
