LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FPGA: Compilation failed : unique control sets

According to Xilinx help: Control sets are the collection of control signals (Clock, CE and SR) for slice registers and LUTRAM.

 

Slice pakcing can only be performed for "code" which shares the same control set.  If I am using a Timed Loop with Clock X (whereby at least the Clock part of my control set is clear), how are the other two to be best implemented in order to facilityte optimal slice packing during compilation?  Is clock Enable required? Any Synchronous reset? I'm using LabVIEW 2015.

 

To Elaborate slightly, we use a lot of Xilinx IPCores in our code and I suspect that we have chosen incompatible Control Sets so that the efficiency of the register and LUT sharing when compiling is severely compromised.

0 Kudos
Message 1 of 4
(2,087 Views)

I've continued reading up on this and came across an old topic : "Remove Implicit Enable" settings for Timed Loops.

 

Only if clocks support gating can we remove the implicit ce input for LV nodes.  Since our CLIP clocks don't support gating, we can't remove these and as a result, all of our LV nodes will have their ce ports wired.  Option one would be to change the clocks from CLIP so that they support gating or make sure that all IPCores have ce ports included.

 

A quick look in the log of our compiles shows approximately 2100 unique control sets in our design with 7% of registers lost due to control set restrictions.  This total number of control sets seems very high given that we certainly don't have more than 50 loops running at any time.  Any further ideas?

0 Kudos
Message 2 of 4
(2,042 Views)

Hmm, I may be barking up the wrong tree here.  I can't provoke a compilation of a test VI of mine to change the number of reported unique control sets by enabling or disablind ce or sclr ports. I've also tried enabling and disabling reset of feedback nodes, but that doesn't do anything either.

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

Speaking of barking up the wrong tree. It might not even have been a tree. I might not even have been barking.  If nobody's listening, can I even bark? If it sounds like I'm losing my mind, there's a reason for that.

 

My mysterious "Overmapping" errors have apparently dissolved into the ether.  Last several compiles worked a charm, no real changes made to code.

 

I know that FPGA compilations are not deterministic, but they're giving me a lot of grey hair.  While I expect the odd Timing Violation when compiling, being told I have Overmapping when barely using over 50% of LUTs and 60% Registers is a bit alarming.  Perhaps more worrying is that any attempt to localise the issues are hampered by the fact that the issues just disappear the closer I look at them.  Quantum physics (an area we work in) is less weird.

 

None of my tests have shown and effect ont he number of unique control sets at all.  It seems to simply scale linearly with the amount of code on the FPGA, irrespective of how it is configured.  Neither resets on LV primitives nor re-configuring IPCores have had the slightest influence ont his metric....

0 Kudos
Message 4 of 4
(2,027 Views)