LabVIEW
Is there an obvious way to prevent an FPGA multiply from using DSPs?
@Dragis wrote:
you'll have to work with NI customer support to make that change.
I've raised a technical support request with NI, just waiting to hear back.
@J_Oneill wrote:
Does this allow you to compile your code?
I'll go ahead and try this in the mean-time (or is this what my technical support engineer will be about to recommend I try?)
I'll report back once I've retried the compilation - which normally takes a few hours...
Well, not great news. I set the flag, started LabVIEW 2012, loaded the Project and started a compile and it still fails. What I don't undersatnd though is why. The Device Utilization report shows that nothing is at or near 100%, and the Timing report shows that everything can run within the clock requirements. So why did it fail? I've attached the Xilinx log, which seems to end with a positive "Generate Programming File completed successfully" message.
Hey Thoric,
Here is the error in the log:
----------------------------------------------------------------------------------------------------------
Constraint | Check | Worst Case | Best Case | Timing | Timing
| | Slack | Achievable | Errors | Score
----------------------------------------------------------------------------------------------------------
* COMP "dio69" OFFSET = IN 5.5 ns VALID 11 | SETUP | 12.620ns| -7.120ns| 0| 0
ns BEFORE COMP "Clk40" | HOLD | -4.497ns| | 1| 4497
----------------------------------------------------------------------------------------------------------
* COMP "dio79" OFFSET = IN 5.5 ns VALID 11 | SETUP | 12.589ns| -7.089ns| 0| 0
ns BEFORE COMP "Clk40" | HOLD | -4.474ns| | 1| 4474
----------------------------------------------------------------------------------------------------------
* COMP "dio66" OFFSET = IN 5.5 ns VALID 11 | SETUP | 12.574ns| -7.074ns| 0| 0
ns BEFORE COMP "Clk40" | HOLD | -4.446ns| | 1| 4446
----------------------------------------------------------------------------------------------------------
* COMP "dio76" OFFSET = IN 5.5 ns VALID 11 | SETUP | 12.569ns| -7.069ns| 0| 0
ns BEFORE COMP "Clk40" | HOLD | -4.441ns| | 1| 4441
----------------------------------------------------------------------------------------------------------
What modules do you have in slots 7 and 8? I'm guessing they're the same? Basically, the interface to those modules is failing timing. You may have to turn off the ini Token (it does say that timing performance may be degraded in that KB). Does manually setting the HT Multiply's pipelining options to LUTs help?
Hi TJ,
The modules in slots 7 and 8 are NI one-axis servo drive interface modules (9516). From these I read two encoder signals and use them to control a hydraulic actuation system.
In the FPGA code I read from these at 100kHz, and the code has been pulled from an NI 9516 example so it's presumably solid.
I'll remove the .ini key and modify my High Throughput Mutlipliers to use LUTs and recompile. However, it's getting late here in the UK and it won't finish before I have to leave so I'll get back to you on Monday. Thanks for you assistance so far! 
P.S. I probably ought to add that this exact same project compiles perfectly fine in LV2009. It's an on-going project for a device that is continually manufactured (one or two per year) and with each machine we look to make small upgrades/updates in features/performance. We started in 2009 (hence LV 2009), but in every LabVIEW release since this project always fails to compile. So we're still developing in 2009 (which is a slow and painful process), and would very much like to get this working in one of the latter releases to take advantage of all the improvements. We find it baffling that identical code will compile in an older release and not in the newer releases, but we've been told this is simply down to the Xilinx compiler and there's not much we can do to interfere with that. But pretty soon LV2009 will no longer be supported so we'll be left in limbo if we don't get this working in a newer LV release soon! 
It still fails to compile. Same error details in the Summary view of the Compilation Status window. The Xilinx Log is attached again.
It shows the same errors, so this means they are not related to the LabVIEW token I removed.
----------------------------------------------------------------------------------------------------------
Constraint | Check | Worst Case | Best Case | Timing | Timing
| | Slack | Achievable | Errors | Score
----------------------------------------------------------------------------------------------------------
* COMP "dio69" OFFSET = IN 5.5 ns VALID 11 | SETUP | 12.620ns| -7.120ns| 0| 0
ns BEFORE COMP "Clk40" | HOLD | -4.497ns| | 1| 4497
----------------------------------------------------------------------------------------------------------
* COMP "dio79" OFFSET = IN 5.5 ns VALID 11 | SETUP | 12.589ns| -7.089ns| 0| 0
ns BEFORE COMP "Clk40" | HOLD | -4.474ns| | 1| 4474
----------------------------------------------------------------------------------------------------------
* COMP "dio66" OFFSET = IN 5.5 ns VALID 11 | SETUP | 12.574ns| -7.074ns| 0| 0
ns BEFORE COMP "Clk40" | HOLD | -4.446ns| | 1| 4446
----------------------------------------------------------------------------------------------------------
* COMP "dio76" OFFSET = IN 5.5 ns VALID 11 | SETUP | 12.569ns| -7.069ns| 0| 0
ns BEFORE COMP "Clk40" | HOLD | -4.441ns| | 1| 4441
----------------------------------------------------------------------------------------------------------
Does this indicate that the reason this isn't compiling in 2012 (or 2011 and 2010) is because of timing violations on the single axis servo drive interface modules?
To test this I'm cloning the FPGA code and stripping out everything unrelated to these two modules. Let's see what occurs when it's compiled...
OK, so I stripped the code down by 80% to just the selection that deals with modules 7 and 8, the 9516 modules, and it still failed with timing violations. This is good - I'm honing in on the problem!
The Xilinx log is attached again, but the usual table is extracted here:
----------------------------------------------------------------------------------------------------------
Constraint | Check | Worst Case | Best Case | Timing | Timing
| | Slack | Achievable | Errors | Score
----------------------------------------------------------------------------------------------------------
* COMP "dio74" OFFSET = OUT 11.25 ns AFTER | MAXDELAY | -0.058ns| 11.308ns| 1| 58
COMP "Clk40" | | | | |
----------------------------------------------------------------------------------------------------------
So the errors are different, and that might be because the inter-process comms with the other sections of FPGA code are no longer in play. There are a few local variables used to pass info (encoder counts etc.) between this remaining section and the removed DMA section that sends data up to the real-time code, and without that it looks like it got a lot closer to succeeding.
I wonder if there's something not right about my code, so I'm going to check out the latest NI examples for the 9516 FPGA code...
OK, so now it compiles, and pretty quickly too. I removed the 10us Loop Timer from the while loop that contains the 9516 interface code. This raises two questions in my mind:
1. I record positional information from both 9516 card encoder inputs at 100kHz. This we've shown to work perfectly well with the code compiled in LabVIEW 2009 by scrutinizing the recorded data, but without this loop timer function how can I be sure that the acquisition is being continually performed at least 100kHz? If there's the odd slow logic execution (for any reason) then no change will be seen between two identical values in the 100kHz acquisition data - this we cannot have.
2. According to the Loop Timer express VI help, "if an execution instance is missed, such as when the logic in the loop takes longer to execute than the specified interval, the Loop Timer Express VI returns immediately", indicating that it won't fail to compile if the contained logic cannot occur within the defined loop rate. Therefore, can I assume that the above failures in LV2012 are not because it cannot execute the code within 10us, but for some other reason?
You can see from this snapshot of the us loop timer before I removed it that I was at one stage monitoring the loop rate by comparing the difference in counter values between iterations, to confirm it wasn't over-running. It's been absolutely reliable when the code is compiled in LV 2009. I'd prefer to keep this in if it means I get absolutely solid 100kHz repeat rates, but if the code isn't compiling then what are my options?
