Compiling FPGA code numerous times has different results

[Terry_ALE]

Did you try commenting out parts to figure out which part it is?

Even when it is non-diagram elements, some part of the code is contributing.  I do not like getting this kind of a compiler response but this is really one of the key ways of figuring out the issue.

[Intaris]

Click on the entries in the timing violation window to see where the problem is occurring (especially the ones with high routing times).  While this only gives you the symptom, not the root cause, it might be enough to indicate in which direction your code optimisation needs to be performed.

FPGA resources are often fixed as to their locations (IO Pads and so on).  If your code is trying to access different portions of the hardware which are physically dispersed, especially if there are multiple such paths, the compiler TRIES to balance them all but may eventually fail due to routing congestion.  It's like a great big game of "Twister" where a whole town is playing on a 1km x 1km mat.  Telling people to make awkward connections will eventually lead to tangles and failure.

It's amazing what strategically placed Feedback nodes can do for a compilation.  The problem is finding out with any degree of certainty WHERE to put them (and make sure the delays aren't messing up your functionality either).

[labviewman]

I will get back and try this again...now that it compiles 75% of the time, will be more difficult to trace down.  I will first convert SCTLs to while loops and verify it's fast enough, then do the compiling test...maybe that will help in more successful compiles.

[labviewman]

I do use feedback nodes for pilelining, but some compiles complain about the feedback nodes as having a timing violation.

I suspect the problem has something to do with the compiler version...I have far more complicated code in LV2016 that never had a compile issue, though, I wasn't using a fully loaded EtherCAT chassis, which probably contributes to the problem.

[Terry_ALE]

How many loops does your program have?

You could place each loop into its own VI (and put dummy read or writes for the FIFOs and other things to make it 'work') and try compiling at different rates.

This can help you get a feel for what is breaking things.

Of course timing on the individual loops may be ok on an empty VI but when put together the compiler has a hard time meeting timing because of the congestion.

[labviewman]

Main VI: 1 main loop, calls 6 identical sub VIs.

Main Sub VI: 1 sub VI has 1 SCTL (digital filter) and 1 SCTL in the sub VI #1. 

Parallel (to main loop) Sub VI: 1 loop.  There are a total of 6 of these Parallel Sub VIs.

The reason I went with globals for passing data from one loop to another is the Block RAM was very slow (>70 ticks).  I didn't try FIFO since the globals worked very fast.  I'm not sure FIFOs would help but I'm not opposed to trying.

Purpose of the code: calculate the mean-period of a pulse-train based on configured update rates.  Uses all 6 inputs of the 9411.

[James_McN]

Great to see your code - I haven't had a chance to digest it all yet but a cursory glance doesn't show anything too obvious. Globals are good on FPGA (over locals) and will help with compiling but the way you are using them with a read flag I can't help but feel that a FIFO of the right type could handle the job better. However I doubt that would be causing the timing violations.

Can you share a failed compile report as well? Would really help to understand a bit better.

Also don't forget you are using the scan engine (for user variables) so it is not just your VI compiling but also the scan engine FPGA logic which can be quite large

[James_McN]

I would break out the EtherCAT state monitoring into another loop. There is no need for it to be that fast or tied to the other logic.

Without seeing more of the reported issues it is hard to say what is driving the failure. I would be inclined to focus on the measure/calc mean period VI:

1. If I wanted to make this easier to compile I might consider putting a pipeline stage after the digital filter (though you are running at 6 ticks in a 20 tick target so speed isn't a concern).

2. I would naturally be inclined to remove the channel index from this VI. Have it return the four items and in the top level code wire to each of the global variables to remove the cases and indexing in the digital filter.

Looking at update user variables and the rest of the code you are using remainder quotient which can be big on logic. Can you not recalculate after a fixed number of periods so you can use mutiply by power of 4? (e.g. recalculate every 4 periods). This would reduce logic - again if it looks like this is the stressor. If size is not an issue though I don't blame you for leaving it.

I can say though your not doing anything stupid! The code looks sound and I can't explain any violations by looking at it. I would start by moving the etherCAT state to a slower loop (since that is the only less common thing you are doing) and work from there.

[labviewman]

Globals seem quite fast which is why I stuck with them.

I just changed the code to FIFOs and will try various implementations to see what is faster (flip-flops, LUT, or block memory) but I suspect block memory will be slow based on prior experience.

I figured the rest of the EtherCAT modules and the scan engine are coming into play, but hoped they wouldn't be a problem since I'm only using about 50-55% of the FPGA.

Will will attach a failed compile report when I can...I need to get back to other tasks now that this code is functional,100% tested and in-use...but I have OCD and want to get to the bottom of this, so, I will find the time.

[labviewman]

Changed to FIFOs...3/4 virtual computers failed to compile.  An error log and screen-shot are attached