Grrr... Xilinx compile failures

[Daklu]

I appreciate the effort NI has put into making FPGA programming available to the unwashed masses.  When things work correctly it's slicker than a greased seal in an oil factory.  When things go bad it's extremely frustrating with few clues about how to fix the problem.

I've been struggling with intermittent compile failures on a cRIO-9074.  The latest problem when I added code to make the fpga LED flash while the fpga is running.  That generated a compile error, so I removed that code.  Now it still won't compile, even though it's the exact same code as before.

I've attached the Xilinx log file.  There are several different types of errors, each of which is repeated multiple times.  Links are to the Xilinx KB articles:

---

ERROR:coreutil - ios failure

ERROR:sim:928 - Could not open destination 'PkgBeatleTypedefs.vhd' for writing.

ERROR:ConstraintSystem:58 - Constraint <INST "*oInputFalling*" TNM =
   "CcInputFallingRegs";> [toplevel_gen.ucf(141)]: INST "*oInputFalling*" does
   not match any design objects.

ERROR:ConstraintSystem:59 - Constraint <TIMESPEC "TS_AsynchMite30"= FROM
   PADS(mIoHWord_n) TO PADS(mIoDmaReq<*>) 0 ns;> [toplevel_gen.ucf(703)]: PADS
   "mIoHWord_n" not found.  Please verify that:
   1. The specified design element actually exists in the original design.
   2. The specified object is spelled correctly in the constraint source file.

---

According to Xilinx, the first error should be ignored--the design will load and run fine.  Is that possible when compiling within Labview?  Is there a way to run the compiler tools directly, and would that even help?  The second error requires modifying the UCF file, and the third requires various tools and options not available (afaik) to LV developers.

I've been fighting the FPGA compiler for about a month.  Its unpredicability is deadly for small businesses trying to deliver something to a customer.  I'm about ready to throw the whole thing in the trash and go in another direction, simply because I can more accurately estimate how long it will take me to implement on a different platform.

[Edit]

I just tried recompiling the fpga vi again.  This time I receive a new error:

LabVIEW FPGA:  An internal software error in the LabVIEW FPGA Module has occurred.  Please contact National Instruments technical support at ni.com/support.

Click the 'Details' button for additional information.

Compilation Time

---------------------------

Date submitted: 11/28/2012 9:28 AM

Last update: 11/28/2012 9:30 AM

Time waiting in queue: 00:05

Time compiling: 01:55

- PlanAhead: 01:50

- Core Generator: 00:00

- Synthesis - Xst: 00:01

- Translate: 00:01

[GregFreeman]

So, I can't remember if I received the same error or not, but one of my VIs has had issues before where I got some sort of strange error when it originally worked. I created a new VI, copied all the code from the existing one and pasted it on the other BD and then it recompiled fine. I would definitely try doing this. What version of LV is this happening in?

[T-REX$]

So, when those errors pop up in the Translate stage, we do work around them. You can see in the log that you successfully complete "Map"... and it just stops there. Not sure if this is an incomplete log or if Place and Route crashed as soon as it started. Anyway you could post the code? I'll give it a go and see if it happens for me too.

[Daklu]

Thanks for the suggestion Greg.  That appears to have done the trick.  Oddly, the new vi, which I created via copy and paste, is 200 kB while the old one is 233 kB.

T-REX,

That is the complete, unedited log generated by the tools.  I've attached the fpga vis if you want to look at them.  "FPGA Main (DMA)" is the original that would not compile.  "FPGA Main 2 (DMA)" is the new one that does compile.  Incidentally, I did open service request #1941067 after receiving Error 7.

[GregFreeman]

---

@Daklu wrote:

Thanks for the suggestion Greg.  That appears to have done the trick.  Oddly, the new vi, which I created via copy and paste, is 200 kB while the old one is 233 kB.

T-REX,

That is the complete, unedited log generated by the tools.  I've attached the fpga vis if you want to look at them.  "FPGA Main (DMA)" is the original that would not compile.  "FPGA Main 2 (DMA)" is the new one that does compile.  Incidentally, I did open service request #1941067 after receiving Error 7.

---

Glad it helped. I would keep an eye on it though, as this problem has reared its ugly head again some time after making a new VI. I'd definitely have T-Rex look into it if he can. I'd be curious as to what is going on to see if I can get a fix also. It's been so long since I worked on that project, though, that I never thought to follow up.

[T-REX$]

Could you also post the configuration info for your C-Series modules? Trying to reproduce on my end, and it looks like you might have 2 modules in the project, but I'm not sure which ones. The documentation in the VI suggests a 9233, but I'd rather be positive. Also, if you have made any changes to the module properties in the project, I'd appreciate the warning.

[Daklu]

I'm using a 9237 in slot 3 and setting the sample rate to 1.613 kS/sec.  Slots 1 and 2 have a 9411 and 9422 that I will read using the scan engine.  (Some of my RT test code uses the 9422, some doesn't.  It doesn't seem to be related to this problem.)

Interestingly, I added a small bit of code again to try and get the LED to flash while the FPGA is running.

...and I got all sorts of new compile errors, such as...

---

ERROR:HDLCompiler:806 -
   "C:/NIFPGA/jobs/Rtxj7d7_KSw9nkc/NiFpgaAG_00000000_WhileLoop.vhd" Line 208:
   Syntax error near "downto".
ERROR:HDLCompiler:806 -
   "C:/NIFPGA/jobs/Rtxj7d7_KSw9nkc/NiFpgaAG_00000000_WhileLoop.vhd" Line 224:
   Syntax error near "3".
ERROR:HDLCompiler:806 -
   "C:/NIFPGA/jobs/Rtxj7d7_KSw9nkc/NiFpgaAG_00000000_WhileLoop.vhd" Line 240:
   Syntax error near "}".
ERROR:HDLCompiler:806 -
   "C:/NIFPGA/jobs/Rtxj7d7_KSw9nkc/NiFpgaAG_00000000_WhileLoop.vhd" Line 244:
   Syntax error near "`".

---

At the very end of the log it says, "Sorry, too many errors.."  I guess it just gave up.  I know the feeling.

I tried deleting that code and recompiling the vi, and it still won't compile.  I assume if I create another new vi via copy and paste it will work again, but something weird is going on.

[T-REX$]

Of course there were no problems with the compilation on my side (Grrr... indeed). The latest log looks awfully fishy:

Line 218: <stl_logic_vector> is not declared.

yeah, that's wrong... should be <std_logic_vector>.  This theme of "not quite right" VHDL syntax repeats throughout.

Could you double check that service request number (1941067) that you posted above? I don't get anything when I search it. 

[Daklu]

Here's the title of the support email, brought to you via copy and paste.  🙂

RE: (Reference#1941067) Phone Support E-Mail

On the suggestion of the AE helping me with this, I created a new project, cRIO, FIFO, etc and added Main 2.vi to it.  (Main 2 failed to compile after adding and removing the flashing LED code.)  To the best of my knowledge Main 2 didn’t get resaved.  In other words, it was the exact same code that wouldn’t compile in my original project.  Of course, this time it did compile.  Then I went back and tried to compile it from the original project and it worked.

He also added the code to flash the LED and it compiled fine for him, so I put it back in Main 2 and tried to compile it on my computer.  It worked. 

At this point I'm leaning towards something being corrupted on my pc.  I did reboot my pc between the time yesterday morning when it didn't work and this morning when it did work.  But this problem has been occurring frequently enough that I think the corruption is due to something I'm doing, not just a random occurrence.  At least now I have an apparent work around to the problem.  I'll pay closer attention to what steps I'm taking and wait for the compile failures to happen again.

[T-REX$]

Alright...

I did speak with the AE you are working with through that SR, so he'll keep me up to date if you run into anything else. It would be great to be able to track down the corruption for anyone else that runs into it in the future, but without an in-house reproducing case, "fixes" are often a shot in the dark based off of some crazy theory... I'm not saying I hope it happens to you again, but I would like help track down the bug if it does  

Edit: On a hunch... Are you operating out of a DropBox or other auto-syncing web/network magic folder?