LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Labview FPGA compile stuck at "Place and Routing"

 

I am using LabVIEW 2010 SP1 32-bit FPGA module.  I've built a very large program that was first done back using LabVIEW 8.6, so I have several years experience on LabVIEW FPGA.

 

When I say it's a large program, I mean that a several times over the last couple years I've tried to add more functionality that has failed to compile do to not enough space on the target or timing restraints.  My target has mostly been the PCI/PXI NI-7813R.  Due to the nature of our product, a lot has to be done on one FPGA board.

 

When I do go "over the limit" the compile (after a couple hours) fails and tells me that there's just not enough room on the 7813.

 

Recently, however, I added some more code, thinking the odds were good that it might push me over the edge.  However, the compile never fails.  Unfortunately, it never stops either.  It gets to the "Placing and routing" portion of the compile and just stays there.  When I say stays there, I mean I've run it over night, and when I check it the next morning, the "Elapsed time" is over 10 hours, and still counting up.  The device utilization and estimated timing numbers are all under max.  And I see no errors in the report so far that I'm used to seeing.  Like I said, it just keeps compiling.

 

I've attached the Xilinx log.  It looks much like the log before I added the extra code, except it just stops logging with reporting any useful error.

 

Anyone have an idea what I could be doing wrong?

 

Thanks,

Rick

0 Kudos
Message 1 of 12
(5,033 Views)

Hi RPluth,

 

I have looked through the Xilinx log and you are right; everything looks like it has completed successfully. Have you been able to reproduce this behavior more than one time? Does it hang in the same place? I would be curious to see the compilation hangs in the same place. Also, as you mentioned you are extremely close to utilizing all of the FPGA resources. It is possible that the compiler thinks it has enough room when in fact it cannot place and route everything. It would also be helpful to know what you changed from when it last successfully compiled.

 

Best,

 

tannerite

Tannerite
National Instruments
0 Kudos
Message 2 of 12
(4,994 Views)

 

tannerite,

 

Thanks for your response.

 

I added code that measures the "on time" of incoming DIO pulses.  If the pulses are HIGH for one given amount of time (eg. 60[+/- 5] usecs) it means one thing, if HIGH for a different amount of time (eg. 120[+/- 5] usecs) it means something else.  Generally speaking, I just keep a tick count between the rising and falling edge of the pulse, and use the "In Range and Coerce" from the Comparison Functions palette to check where the count lies.

 

When it compiled successfully, I duplicated the above code for 10 seperate DIOs.  Then I realized I needed to monitor 20 DIOs.  It was when I added the code for these extra 10 DIOs that I got the "forever" compile.  The compile problem occurs everytime I try to compile with the extra 10 DIO code in place.  As an experiment, I just added 4 extra DIOs, i.e. code to monitor a total of 14 DIOs.  This causes the same compile problem.

 

And yes, the compile seems to hang in the same place every time it hangs.  Like I said, I wouldn't be surprised if I'm just beyond the available resources available.  But when I've done this in the past, the compile does finally fail, and I get a useful error message.  I've never seen it go "forever".

 

Thanks ahead of time for any insight you might have.

 

- Rick

0 Kudos
Message 3 of 12
(4,987 Views)

Hi Rick,

 

If you are able to post a zip file of the project in question and post it I can try to compile your FPGA VI and see if it hangs during the placing and routing stage of the complilation process. It does seem like you have added a considerable amount of code to the project, and as you had mentioned you expected it to fail as well. It is very odd that it is hanging after all of the subsequent compilation steps are successful, however.

 

tannerite

Tannerite
National Instruments
0 Kudos
Message 4 of 12
(4,959 Views)

tannerite,

 

I've attached a zip file of the project in question.

 

After you unzip, you'll find the LabVIEW project file if you drill down to the Transmission sub-folder.  It is called BauerPCSTransmission.lvproj.  The main vi is called AVR32FPGA DEV.vi

 

Again, thank you for your help.

 

Regards,

Rick

0 Kudos
Message 5 of 12
(4,947 Views)

RPluth,

 

I was able to reproduce the same behavior using the same software versions as you do. Mine was hanging in Placing and Routing for 14+ hours. Currently, I am attempting to reproduce this behavior using LabVIEW 2012. I also spoke with our liason to our R&D department and we think it is likely a Xilinx compiler error that is not being properly sent to the compile worker to display a failed compilation. I will keep you updated with the LabVIEW 2012 compile using Xilinx 10.1.

 

Warm regards,

tannerite

Tannerite
National Instruments
0 Kudos
Message 6 of 12
(4,935 Views)

Someone here reported a hang in PAR when using a local variable who's control/indicator was inside of a diagram disable structure (speculates). I haven't had time to take an in-depth look at your code, but this may be something to look for.

Cheers!

TJ G
0 Kudos
Message 7 of 12
(4,897 Views)

Actually, I just decided to delete all of your diagram disable structures to see which local variable broke. Looks like the "Feedback Position 1" FXP indicator is disabled at the top-center of your top-level block diagram. Haven't confirmed the fix, but you are in the same scenario as Tidus in the linked thread.

Cheers!

TJ G
0 Kudos
Message 8 of 12
(4,894 Views)

Made a simple test to attempt to validate the behavior. It does not hang PAR like your code does, though I compiled for a newer target in 2012. I'll try a few more things and report back as soon as I get a chance.

 

PAR Hang Test.png

 

Cheers!

TJ G
0 Kudos
Message 9 of 12
(4,886 Views)

So none of the test's I've tried have been successful in narrowing down the issue, or fixing the PAR hang. I'm currently checking to see if it may be related to the sheer number of conrols on your front panel (385).

Cheers!

TJ G
0 Kudos
Message 10 of 12
(4,864 Views)