Compiling FPGA code numerous times has different results

[labviewman]

I have been experimenting with compiling my code on different computers, virtual machines, and cloud compiling. Using the exact same code, I get different results...most compiles fail (usually timing violations) with a few successfully completing.

I don't really understand why this happens...digital computers working with the exact same code...compiling should give the exact same results.

I have burned probably 10 hours with this trying to get code to compile, which compiled 6 months ago (same software versions).  When it did compile w/o errors, the code was downloaded and worked perfectly.  I added a constant to the diagram, then deleted it and accidentally saved the code...LabVIEW wanted to recompile...since my code was already running, I didn't need it compiled, but I did it anyhow...which failed.

Now, I'm characterizing this some more, burning another 20 hours by testing on different computers, multiple virtual machines, and cloud compiling.  I am 100% confident it's not because I am pushing the size limits of the FPGA since I cut out 66% of the code and it had the same problems.

Has anyone else seen such odd behavior?

BTW, LabVIEW 2012, all software loaded from 2012 Developer Suite 1.

Thanks,

Todd

[nanocyte]

FPGA compiling includes pseudorandom steps so you probably will never get the same bitfile twice. It sounds like one of your loops has a combinatorial path that's pushing your timing constraint. You can try and break up the logic using pipelining or you can relax the timing constraint. 

[Terry_ALE]

When logic is mapped to an FPGA, I imagine it is like the game Simcity.  If you have the same 'city' but start building it on the same 'terrain map' from different places, you will get a different layout.  In some cases, where you start could impact the compile results.

Note: an FPGA bitfile that you generate is a valid one.  It means that the compiler 'found' a way to fit the design on the particular FPGA part.

[labviewman]

It's strange that FPGA compiling has pseudorandom steps...seems like any compiler (but this is compiling for hardware) should have the same result each time.

I already have the code pipelined to the max, no other opportunities but I will check it over.  I have one SCTL, but I get the same random compile results if it's a simple while loop.

Clicking 'show element' on any timing violation only shows the main while loop.  I could get rid of the single case statement in the while loop (selects either the calculated value or a constant) that checks the EtherCAT mode...I will try getting rid of it (I guess I don't really care if it's not in operational mode).

Thanks for the feedback.

[Terry_ALE]

Software mindset compared to FPGA mindset is almost always different.

There are many ways the same logic can be placed onto the same FPGA.  It would be a shortcoming if the FPGA tried only one way and then told you it failed.  It actually will try many approaches which is why a full design will take very long to compile.

Part of the reason the newer FPGA compile tools are faster is because they have more and better predictive tools so they do not do a whole place and route only to realize it does not fit.  Saying it is random is an oversimplification but generally is the reason why things could/will be different after each compile.  It is always best to note the compile results but to understand there is some uncertainty in those numbers.

Purist FPGA designers do not even like the term compiler because technically it is not compiling.

[nanocyte]

If you're seeing timing issues using without any SCTL and only  LabVIEW code (no VHDL), that raises some flags and could indicate a "full" problem. Can you isolate it to any component? What hardware are you using? Sometimes if there's a timing issue, there's and investigate option and it might tell you what labview code is causing it.

[labviewman]

I had changed the one SCTL loop to a while loop one time and still had a timing violation.  I suspect the timing violation may have to do with the single quotient call I make, but I use pipelining everywhere possible.

The main top-level loop is set for 20 ticks/loop.  When it compiles and runs, it works perfectly.  I just don't understand why sometimes it compiles and other times it doesn't.

The hardware is an EtherCAT chassis, NI-9144.

I just made a bunch of changes, mainly using 'discrete delays' instead of feedback nodes everywhere for the pipelining, combined some operations into a SCTL (shouldn't matter since it was already pipelined) and all additions/subtractions to the optimized 'AddSub' from the 'high-throughput math' palette...I have it compiling in 4 different virtual machines now...will see how it works in the morning.

If still NG, will start cutting out blocks of code to see if I can find where the timing problem is.

Is there a way to determine how many ticks each block of code takes?  Such as how many ticks for a divide or quotient (integers)?

[nanocyte]

The high throughput nodes will tell you in the configuration how many cycles they'll take. 

Like I said, if you have a timing violation with a non-SCTL, that implies the design is getting full. Try cutting stuff out and see if that helps to confirm or reject that theory. Don't forget to check out your timing analysis. http://zone.ni.com/reference/en-XX/help/371599K-01/lvfpgadialog/fpga_time_violation_db/

[James_McN]

If this is on an etherCAT chassis I guess that means you are running in hybrid mode (using user-defined variables). This means that even if your design isn't so large it also has to compile in the scan-engine logic onto the FPGA which will significantly increase the logic size.

When the design gets full effectively there are less options on how to route the design so even though the logic can fit onto the chip the connected parts are so far away that the signal can't propagate between then. It sounds like you are just on the wrong side of this but if you check the report you can also see 1. the size data and 2. if it is the 40MHz top level clock that is in violation. Also in the investigate timing violation display it should show that it is a large routing delay rather than logic delay causing the issue (though this dialog isn't perfect in non-standard violations so not sure what it will show)

SCTLs can be a way to reduce utilisation and you can add multiple registers/feedback nodes between them to aid routing (i.e. make it delay 2 or 3 times, that way it only has to span 1/2 to 1/3 the distance between clock cycles at the cost of latency).

Thats the only main thing I can think of off the top of my head - if you have the compile report and we can confirm size as an issue then there are some good first steps (reducing large functions, reducing data types). If it show size really isnt an issue (low routing delay and low % utilisation) then it is possibly a specific bug/section of code causing the issue and we would have to track it down.

[labviewman]

Still NG.

Took out the quotient out, compiles 80% of the time.  Moved quotient operations from the 6 identical paths to a single parallel loop using block RAM (boolean to indicate data ready, U64 for the data). Amount of resources didn't change (estimated 104%, actual 85%), but I don't know if it will compile to the end reliably (doing 4 parallel compiles in VMs and a clould compile).  I may have to live with compiling in multiple VMs and use the one that finishes the compile.

Most all the timing violations point to non-diagram elements, which really doesn't help find the source.  A few pointed to the added 'discrete delays', which was strange.  Took them out and went back to feedback nodes.