LV FPGA compilation problem (urgent)

Hi,
I am trying to implment a LV FPGA code in my crio 9074 but it is taking unsusually long time(40 mins and up).
I am trying to implement this example to generate a waveform: http://www.ni.com/example/28209/en/
Till now it is showing "generating cores" message and in the log I am getting repeatedly this message:
aved CGP file for project 'coregen'.
Resolving generics for 'ReallyLongUniqueName_ReallyLongUniqueName'...
Applying external generics to 'ReallyLongUniqueName_ReallyLongUniqueName'...
Delivering associated files for 'ReallyLongUniqueName_ReallyLongUniqueName'...
Generating implementation netlist for
'ReallyLongUniqueName_ReallyLongUniqueName'...
Running synthesis for 'ReallyLongUniqueName_ReallyLongUniqueName'
Release 13.4 - Xilinx CORE Generator O.87xd (nt)
Copyright (c) 1995-2011 Xilinx, Inc. All rights reserved.
All runtime messages will be recorded in
C:\NIFPGA\jobs\W543T9Q_a5T1mXb\coregen.log
Saved CGP file for project 'coregen'.
Resolving generics for 'ReallyLongUniqueName_ReallyLongUniqueName'...
Applying external generics to 'ReallyLongUniqueName_ReallyLongUniqueName'...
Delivering associated files for 'ReallyLongUniqueName_ReallyLongUniqueName'...
Generating implementation netlist for
'ReallyLongUniqueName_ReallyLongUniqueName'...
Running synthesis for 'ReallyLongUniqueName_ReallyLongUniqueName'
It seems that is in some kind of endless loop. Peae guide me how to solve the issue.
Thanks ..
Solved!
Go to Solution.

Those are "normal" output messages from the compilation process (although they are somewhat curious). It is normal to have a number of these modules in the FPGA design if you are using the analysis library functions; each one can take several minutes to synthesize. Did the compile eventually finish?
Luckily, if you make only minor changes in subsequent compiles the compile times should decrease as the compiled results from each of these components is cached.

Similar Messages

Fpga compilation problem (generating cores)

Hello. I am working in a lab trying to compile an FPGA for the cRIO 9074 module. There are no erros when beginning the compilation, and it runs smoothly until it reaches the "generating cores" step. At this point the following message repeats itself
All runtime messages will be recorded in
C:\NIFPGA\jobs\XR923g4_G4EhsMk\coregen.log
Saved CGP file for project 'coregen'.
Resolving generics for 'ReallyLongUniqueName_ReallyLongUniqueName'...
Applying external generics to 'ReallyLongUniqueName_ReallyLongUniqueName'...
Delivering associated files for 'ReallyLongUniqueName_ReallyLongUniqueName'...
Generating implementation netlist for
'ReallyLongUniqueName_ReallyLongUniqueName'...
Running synthesis for 'ReallyLongUniqueName_ReallyLongUniqueName'
This message repeats every 5 min or so for around 29 minutes, at which point the compiler stops, presenting the following error
ERROR:sim - Cannot rename dependency database for library "mult_gen_v11_0", file
   is
   "_cg/_dbg/ReallyLongUniqueName_ReallyLongUniqueName_xsd/mult_gen_v11_0/hdpdep
   s.ref", Temporary database file
   "C:\NIFPGA\jobs\I1wyNri_G4EhsMk\core_NiLvXipFloat32Add\tmp\_cg\_dbg\ReallyLon
   gUniqueName_ReallyLongUniqueName_xsd\mult_gen_v11_0\xil_95296_48" will
   remain. System error message is: File exists
ERROR:sim - Failed executing Tcl generator.
ERROR:sim - Failed to generate 'ReallyLongUniqueName_ReallyLongUniqueName'.
   Failed executing Tcl generator.
ERROR:sim:877 - Error found during execution of IP 'Floating-point v5.0'
I have included the xilinx log. For good measure I compiled an older FPGA we have running on a different chassis and it ran just fine, so it's not a problem with xilinx (at least I don't think it is). I have spent the better part of two days wrestling with this issue and have found no viable solutions. Any and all help would be greatly appreciated. Thanks!
Cheers,
David
Attachments:
compilationfailure_log.txt ‏179 KB

Check out this document from Xilinx. It may be caused by your antivirus not allowing access to the files that Xilinx needs to overwrite while compiling.

FPGA Compiler

Hi All,
Sine Generator - R Series.lvproj is one of the examples in the Example Finder. The example is developed for PXI 7831 R Series card. But it’s mentioned that the example can run on PXI 7841 Series card also. So I created new target and devices (7841) in the PXI system and moved the Items to Move to my new target, then I run the Sine Generator (FPGA).vi but not successful. The compiler is hanging in the following window for hours.(I am using LabVIEW 2010 with xilnix 11.5 FPGA compiler)
Also I am facing the same problem when compiling the attached simple FPGA VI. This VI has only Sine Wave Generator function and I/O node.
Why I couldn't compile the attached simple VI or provided example VI. Please add your inputs/comments
Thanks in advance
Attachments:
test3.vi ‏36 KB

There's a trick here for significantly speeding up the compilation process on certain CPUs: http://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/Multi-core-Compiling/idc-p/2301338#M297
(It looks like your CPU is supported)
Certified LabVIEW Architect, Certified TestStand Developer
NI Days (and A&DF): 2010, 2011, 2013, 2014
NI Week: 2012, 2014
Knowledgeable in all things Giant Tetris and WebSockets

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
Attachments:
XilinxLog.txt ‏3936 KB

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

FPGA Compile Error due to error in mapping process

Received the following error while trying to compile a FPGA VI on a PC. (Refer to attachment for details). My PC has a fresh installation of English Windows 2000 with sp4. No other software is installed except LabVIEW 8.2 & FPGA Module 8.2 & NI-RIO.
I have checked this KB and confirmed that regional settings are English. But the error still exists. I tried compiling the same VI on my laptop with Windows 2000 sp4 and it was successful. Can someone help me? Thank you very much!
FPGA Compile Error When Compiling LabVIEW FPGA VI
Error found in mapping process, exiting...
Errors found during the mapping phase. Please see map report file for more
details. Output files will not be written.
Design Summary
Number of errors : 17
Number of warnings : 8
ERROR:Xflow - Program map returned error code 2. Aborting flow execution...
Message Edited by maimai on 01-08-2007 01:00 AM
Attachments:
FPGA Compile Error.txt ‏8 KB

Hello,
The key will of course be to isolate differences between your machines.
I wonder if the following more specific language setting could be the lingering problem. LabVIEW is a non-unicode program, and there is a language setting in Windows (at least XP) specifically for non-unicode programs. Try the following (or it's Win2K equivalent) if you haven't already:
0. Open "Control Panel"
1. Open the "Regional and Language Options"
2. On the Advanced tab, choose English (United States) from the drop-down menu under the top section "Language for non-Unicode Programs"
- This language setting is different from the setting on the "Regional Options" tab.
Any other differences you can isolate would be potentially insightful - if you have the same software versions installed in the same order on both machines, we may be looking for something a bit subtle, such as the suspected language setting.
Best Regards,
JLS
Best,
JLS
Sixclear

Is it true that bundle by name can cause FPGA compiles to fail?

Dear forum,
I have attached a full log of my experience with this apparent bug, but I will summarize it here:
I attempted to compile a labview robotics project for cRIO 9074. The code was all on the FPGA, and I'd tested it all before attempting to compile--much of it was skeleton code proving that the self test system would turn on blinky lights on the front panel. My first attempted compile received a strange failure message in stage 3 of labview's pre-xilinx compilation interface, and the message was strange mostly because it was so intensely vague. It read "An internal software error has occurred. Please contact National Instruments technical support at ni.com/support with the following information: Error 1000 occurred at an unidentified location. Possible reason(s): LabVIEW: The VI is not in a state compatible with this operation."
It being Tuesday the 6th of July 2010, I was unable to reach either the support staff who were on holiday or the web service, which was down for maintenance, so I began disabling pieces of my code using my debugging conditional disable statements. Eventually I found one skeletal code module, one to interface with analog flood sensors, which did not fail to compile. I compared this with another skeletal code module which did fail to compile, and after several tests noticed that adding a bundle by name from a strict type definition (but not an un-bundle by name or a standard anonymous bundle) would cause the vi to fail the compile. With several more tests I confirmed that while the vi would fail to compile with the bbn, with a standard bundle it would compile successfully all the way to the xilinx stage (by which point I didn't care, the bug was definitively pre-xilinx.)
So tonight I will be going into my code and doing a lot of replacing bundle by name blocks with anonymous bundles, but I am still haunted by the extreme vagueness of the error, and by the fact that bundle by name is usually a solid part of the FPGA development platform. It was clearly intended to work. Why didn't it?
Gray Cortright Thomas
Franklin W. Olin College of Engineering
Engineering: Robotics
Class of 2012
Needham, MA
Gray Cortright Thomas
Franklin W. Olin College of Engineering
Engineering: Robotics
Class of 2012
Needham, MA
Attachments:
gtlog2010-07-06-18-24-00.txt ‏7 KB

So I did as Donovan suggested, and this worked for the code example which I posted. But when I started trying to put more of the bundle by names back in this solution stopped working. I then went on to solve a seemingly unrelated problem with the version that had compiled using only anonymous bundle: it had been unable to run some while loops that were in subvis. When I took the code from these subvis and put the loops on the back panel of the main vi, to my utter horror, they began to function again in the compile (running on the hardware). I was afraid that it was subvis themselves that were causing this failure to run, but was relieved when my next test proved this not to be the case: I took that loop on the front panel where it worked and used edit>create subvi to put it in a subvi. It still worked. Thus I was left to search out the difference between the subvi that successfully compiled, and the subvi which compiled but didn't run--and this was that the failed subvi was part of a library. I placed the new, working, subvi in the same library and the code once again displayed the same symptoms as when it had been tested the first time: the loop would not run even once and the flow of control would never finish with the loop--it just delayed forever. This might be a problem with the way I had used the libraries, but I think everything within them was public. My guess now it that the Libraries don't behave the same way they do on the FPGA as they do on the FPGA simulator, and this is why the vis seemed to work when I simulated them. So... I took all the vis, typedefs, and globals out of the libraries and into virtual folders of the same name and... Everything works! Even bundle by name!
The implementation of project libraries in the FPGA compiler may be suboptimal in some respects, but I probed only as deep as necessary to run my code.
And this code is in 7z format because my zip file did not meet the maximum file size requirements of the forum.
It is also very possible that I misunderstood the functioning of the libraries, and the FPGA simulator was blowing sunshine up my nose when it showed them working properly in simulation. Either way, it is probably worth looking into. This weekend I might try to find the simplest project file that shows these symptoms just to prove I'm not crazy.
Gray Cortright Thomas
Franklin W. Olin College of Engineering
Engineering: Robotics
Class of 2012
Needham, MA

Fpga compilation extremly slow

Hey guys,
Im hoping Im right here. My problem is that when I try to compile my fpga VI, Xilinx 14.4 needs more than 9 hours to compile.
One example is that the program needs for this:
"INFO: [Designutils 20-295] Found reset/set on shift register ending at window/theVI/n_bushold/Clk40Crossing.Clk40ToInterface/BlkOut.SyncIReset/c1ResetFromClk2. Adding 1 LUTs and 3 Flops to estimation."
a few minutes. I think there are thousends of that messages in the log. Why do the compilation need so much time?
My System:
Intel Core i5-3337U CPU @1,8 Ghz
4GB Ram
I have a SSD with round about 30 GB left. I think you need more informations. Please tell me what else do you must know that you can help me.
Thank you

When your FPGA compilation completes, what % of resources does it use on the FPGA (i.e. are you close to filling it)? What device are you compiling for? How complex is your FPGA VI and what sort of functionality does it perform? (FIFOs, complex math?)
I know there are certain conditions that can make routing the FPGA very difficult for the compiler (trying to route lots of signals to physical pins that are far apart) or you might be using operations that make the code very inefficient (such as doing lots of divisions, handling arrays or floating point arithmetic).
I don't expect it to make a lot of difference, but on your FPGA build specification settings (Xilinx Options) are you optimising for compilation speed or resources?
As is normally the case - if you could post your VI it may help to identify the cause of the issue. The error seems to be related to a shift register but without seeing what you're trying to do with it it's difficult to assist.
Certified LabVIEW Architect, Certified TestStand Developer
NI Days (and A&DF): 2010, 2011, 2013, 2014
NI Week: 2012, 2014
Knowledgeable in all things Giant Tetris and WebSockets

Re: [iPlanet-JATO] sp3 jsp compiler problem

Weiguo,
First, Matt is correct, the regular expression tool is perfect for general text
substitution situations, and as a completely independent tool its use is not
restricted to migration situations (or file types for that matter).
Second, I sympathize with the unfortunate trouble you are experiencing due to
Jasper's (perhaps more strict) compilation, but in what way did the iMT
automated translation contribute to these inconsistencies that you cited?
1. Changed the case of the tag attribute to be the same as what's
defined in tld.
example: changed OnClick to onClick
The iMT does not generate any OnClick or onClick clauses per se. In a
translation situation, the only way "OnClick" would have been introduced was if
it had been part of the pre-existing project's "extraHTML" (which was written
by the original customer and just passed through unchanged by the iMT) or if it
was added manually by the post-migration developer.
2. Removed attributes which are not defined in tld.
example: escape attribute only defined in three tags
but in some pages, it's used although it's not defined as an
attribute
of certain tags. The jasper compiler doesn't like it.Can you give soem examples? Is there a definite pattern? Again, this might be
similar to the OnClick situation described above?
3. In an end tag, there can't be any space.
example: </content > doesn't work. </content> works.
Again, the content tag would never have been generated by the iMT. There was no
equivalent in the NetDynamics world, so any content tags in your code must have
been introduced by your developers manually. Its a shame that jasper is so
particular, but the iMT could not help you out here even if we wanted to. The
constants that are used by the iMT are defined in
com.iplanet.moko.jsp.convert.JspConversionConstants. From what I can see, the
only situation of a closing tag with any space in it is
public static final String CLOSE_EMPTY_ELEMENT = " />";
But that should not cause the type of problem you are referring to.
Mike
----- Original Message -----
From: Matthew Stevens
Sent: Thursday, September 06, 2001 10:16 AM
Subject: RE: [iPlanet-JATO] sp3 jsp compiler problem
Weiguo,
Others will chime in for sure...I would highly recommend the Regex Tool from
the iMT 1.1.1 for tackling this type of problem. Mike, Todd and myself have
posted to the group (even recently) on directions and advantages of creating
your own RULES (rules file) in XML for arbitary batch processing of source.
matt
-----Original Message-----
From: weiguo.wang@b...
[mailto:<a href="/group/SunONE-JATO/post?protectID=125056020108194190033029175101192165174144234026000079108238073194105057099246073154180137239239223019162">weiguo.wang@b...</a>]
Sent: Thursday, September 06, 2001 12:25 PM
Subject: [iPlanet-JATO] sp3 jsp compiler problem
Matt/Mike/Todd,
We are trying to migrate to sp3 right now, but have had a lot of
issues with the new jasper compiler.
The following workaround has been employed to solve the issues:
1. Changed the case of the tag attribute to be the same as what's
defined in tld.
example: changed OnClick to onClick
2. Removed attributes which are not defined in tld.
example: escape attribute only defined in three tags
but in some pages, it's used although it's not defined as an
attribute
of certain tags. The jasper compiler doesn't like it.
3. In an end tag, there can't be any space.
example: </content > doesn't work. </content> works.
As I see it, we have two options to go about solving this problem:
1. Write a script which will iterate through all the jsp files and
call jspc on them. Fix the errors manually when jspc fails. Jspc will
flag the line number where an error occurs.
2. Write a utility which scans the jsp files and fix the errors when
they are encountered. We should define what's an error and how to
correct it. It's best if we combine this with solution 1 since we
might miss an error condition.
Actually, there might be another option, which is seeking help from
you guys since you have better understanding of JATO and iAS. Can you
do anything to help us?
We would be happy to hear your thoughts.
At last, I would like to suggest modifying the moko tool so that
these rules are enforced and the generated JSPs work with the new
compiler. This is for the benefit of any new migration projects.
Thanks a lot.
Weiguo
[email protected]
Choose from 1000s of job listings!
[email protected]
[Non-text portions of this message have been removed]

Thanks a lot Matt and Mike for your prompt replies.
I agree completely that iMT doesn't introduce the inconsistencies.
About the three cases I mentioned, the third one happens only in
manually created JSPs. So it has nothing to do with iMT. The first
two are mainly due to the existing HTML code, as you rightly pointed
out.
The reason I made the suggestion is since we know that case 1 and 2
won't pass the japser compiler in sp3, we have to do something about
it. The best place to do this, in my mind, is iMT. Of course, there
might be some twists that make it impossible or difficult to do this
kind of case manipulation or attribute discard.
Weiguo
--- In iPlanet-JATO@y..., "Mike Frisino" <Michael.Frisino@S...> wrote:
Weiguo,
First, Matt is correct, the regular expression tool is perfect for general text substitution situations, and as a completely independent
tool its use is not restricted to migration situations (or file types
for that matter).
>
Second, I sympathize with the unfortunate trouble you are experiencing due to Jasper's (perhaps more strict) compilation, but
in what way did the iMT automated translation contribute to these
inconsistencies that you cited?
>
1. Changed the case of the tag attribute to be the same as what's
defined in tld.
example: changed OnClick to onClick
The iMT does not generate any OnClick or onClick clauses per se. In a translation situation, the only way "OnClick" would have been
introduced was if it had been part of the pre-existing
project's "extraHTML" (which was written by the original customer and
just passed through unchanged by the iMT) or if it was added manually
by the post-migration developer.
>
2. Removed attributes which are not defined in tld.
example: escape attribute only defined in three tags
but in some pages, it's used although it's not defined as an
attribute
of certain tags. The jasper compiler doesn't like it.Can you give soem examples? Is there a definite pattern? Again, this might be similar to the OnClick situation described above?
>
>
3. In an end tag, there can't be any space.
example: </content > doesn't work. </content> works.
Again, the content tag would never have been generated by the iMT. There was no equivalent in the NetDynamics world, so any content tags
in your code must have been introduced by your developers manually.
Its a shame that jasper is so particular, but the iMT could not help
you out here even if we wanted to. The constants that are used by the
iMT are defined in
com.iplanet.moko.jsp.convert.JspConversionConstants. From what I can
see, the only situation of a closing tag with any space in it is
public static final String CLOSE_EMPTY_ELEMENT = " />";
But that should not cause the type of problem you are referring to.
Mike
----- Original Message -----
From: Matthew Stevens
Sent: Thursday, September 06, 2001 10:16 AM
Subject: RE: [iPlanet-JATO] sp3 jsp compiler problem
Weiguo,
Others will chime in for sure...I would highly recommend the Regex Tool from
the iMT 1.1.1 for tackling this type of problem. Mike, Todd and myself have
posted to the group (even recently) on directions and advantages of creating
your own RULES (rules file) in XML for arbitary batch processing of source.
>
matt
-----Original Message-----
From: weiguo.wang@b...
[mailto:<a href="/group/SunONE-JATO/post?protectID=125056020108194190033029175101192165174048139046">weiguo.wang@b...</a>]
Sent: Thursday, September 06, 2001 12:25 PM
Subject: [iPlanet-JATO] sp3 jsp compiler problem
Matt/Mike/Todd,
We are trying to migrate to sp3 right now, but have had a lot of
issues with the new jasper compiler.
The following workaround has been employed to solve the issues:
1. Changed the case of the tag attribute to be the same as
what's
defined in tld.
example: changed OnClick to onClick
2. Removed attributes which are not defined in tld.
example: escape attribute only defined in three tags
but in some pages, it's used although it's not defined as an
attribute
of certain tags. The jasper compiler doesn't like it.
3. In an end tag, there can't be any space.
example: </content > doesn't work. </content> works.
As I see it, we have two options to go about solving this problem:
>>
1. Write a script which will iterate through all the jsp files and
call jspc on them. Fix the errors manually when jspc fails. Jspc will
flag the line number where an error occurs.
2. Write a utility which scans the jsp files and fix the errors when
they are encountered. We should define what's an error and how to
correct it. It's best if we combine this with solution 1 since we
might miss an error condition.
Actually, there might be another option, which is seeking help from
you guys since you have better understanding of JATO and iAS. Can you
do anything to help us?
We would be happy to hear your thoughts.
At last, I would like to suggest modifying the moko tool so that
these rules are enforced and the generated JSPs work with the new
compiler. This is for the benefit of any new migration projects.
Thanks a lot.
Weiguo
[email protected]
Choose from 1000s of job listings!
[email protected]
Service.
>
>
>
[Non-text portions of this message have been removed]

Fpga compilation xilinx error 'Process "Map" failed' - 'unroutable situation'

When I try to compile a Labview fpga project on our new system, it fails with the following error summary (the full Xilinx log is attached):
LabVIEW FPGA: The compilation failed due to a xilinx error.
Details:
ERROR:LIT:536 - IBUF symbol "aUserGpio<1>_IBUF" (output
signal=aUserGpio<1>_IBUF) has the attribute IOBDELAY set to value NONE and it
is driving an IODELAY. If the IOBDELAY attribute is on the driving PAD, it
has precedence over the IBUF one. Either the constraint or the design need
modification to prevent an unroutable situation.
Errors found during logical drc.
Design Summary
Number of errors : 1
Number of warnings : 349
Process "Map" failed
Start Time: 10:31:49 AM
End Time: 10:55:32 AM
Total Time: 00:23:43
Hardware:
NI PXIe-1071 Chassis
NI PXIe-8108 Embedded controller
NI PXIe-7965R FPGA FlexRIO FPGA module
NI 5761 250 MS/s 14 bit Analog input digitizer
Installed software:
Labview 2011 version 11.0
Labview FPGA module 11.0.0
FPGA compilation tools (Xilinx12_4)
NI FlexRIO Adapter Module Support 2.2.0
NI-RIO 4.0 (FlexRIO 2.1.0)
Xilinx DRAM compilation bug fix patch from NI article id 5E4FNCDP
Xilinx clock bug fix patch from NI article id 5GFAB7DP
replaces c:\NIFPGA\programs\Xilinx11_5\ISE\xilinx\lib\nt\libPlXil_Clocks.dll; The installed version is c:\NIFPGA\programs\Xilinx12_4-> Manually copied the dll to the installed version
The Project uses the 5761 low speed clip and a DRAM FIFO.
I tried to compile it before installing any patch, after installing the DRAM patch, and after installing both patches and always got a Xilinx error after ~10 minutes compile time. The error summary shown above and the attached Xilinx log are from compiling with both patches installed.
It compiled correctly on our older system:
Hardware:
NI PXIe-1082 Chassis
NI PXIe-8133 Embedded controller
NI PXIe-7965R FPGA FlexRIO FPGA module
NI 5761 250 MS/s 14 bit Analog input digitizer
Installed software:
Labview2011version10.0.0
LabviewFPGAmodule10.0.0
FPGAcompilationtools (Xilinx11_5)
NIFlexRIOAdapterModuleSupport2.1.0
NI-RIO3.5.1 (FlexRIO1.5.0)
XilinxDRAMcompilationbugfixpatchfromNIarticleid5E4FNCDP
Any help / suggestions greatly appreciated,
Fabrizio
Attachments:
XilinxLog.txt ‏1482 KB

Hi Torpedotown,
Can you tell me what version of FlexRIO Adapter Module Support you are using?
The 5761 Low Speed CLIP has a constraint that doesn't work properly with some versions of the compilation tools. In order to solve this you should be able to upgrade to our latest version of FAM support, or go change the constraint manually.
For the latest version of FAM support, go to http://ni.com/info and enter code "famsoftware"
If you've modified constraint files before and feel comfortable doing it yourself, let me know and I can provide you with the details on how to do that.
Thanks!
National Instruments
FlexRIO & R-Series Product Support Engineer

Servlet Compilation Problem !

Hi,
I am just starting to learn servlets and I got problem in compiling them. I got compilation error in
import javax.servlet.*;statement. Seems that the compiler cannot find the servlet package. I got J2EE 1.4 beta installed on my machine but there is no servlet.jar package. I am using J2SDK 1.4.1_02, J2EE 1.4 beta and Tomcat 4.1.24.
Can anyone help me with my servlet compilation problem?
Thanks in advance!
Josh

servlet.jar is here :
<tomcatdir>\common\lib
add it to your compiler classpath

Compilation problem in a JSP page

Hi all,
I'm trying to write a jsp page and some java stuff in it.
It goes something like this -
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<%@ page contentType="text/html;charset=windows-1255"%>
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=windows-1255"/>
    <title>Michael</title>
</head>
<body>
<%
          String strError="";
%>
</body>Now the problem is that I get compilation problem about the use in java -
"String cannot be resolved to a type"
I know for sure that in other computers it's work, the question is what I'm missing?
I have Java VM installed and I've downloaded and installed the latest JDK, what else?
thanks,
Michael.

Michael4488 wrote:
BalusC wrote:
Then you should be using JSTL/EL.I don't familiar with this technology, any way - Its work on one computer so in my understanding it should work on the other as well.It is not related to the actual problem. It was just a comment on your code. Using scriptlets is considered as bad practice.
I understand that of course, but I don't use any configuration file or set any special parameters in my computer.
What exactly does the compiler need in order to recognize the Java code in the JSP page? If i manually add the JAVA_HOME environment variable it will work?
where should I refer it to? "..\Java\jre1.6.0_07\lib" will do?It must point to the root installation directory of the JDK (thus not the JRE!).

Xilinx version availability for labview fpga compile

While trying to compile a Labview vi for target NI PXI 7831R, at first I didn't have
any Xilinx compile so I asked my network guy to instal it. Now it complains
that it needs 10.1 when 11.5 is available. I asked him to install the 10.1 and
he did but it isn't available to the NI FPGA compile worker. How do I solve
this?
thanks

Hi DonQuixote,
You are correct in that the PXI 7831R requires Xilinx Compile Tools 10.1. This is because this card has a Vertex II chip. You can read more about Xilinx requirements here: http://ae.natinst.com/public.nsf/webPreview/A4B20D58C051DFB386257A56007BB0B2?OpenDocument .
Have you uninstalled version 11.5? What version of LabVIEW do you have? Are you recieving an error or some other message? If so, please post a screenshot.
Thanks!
Dayna P.

FPGA: compilation error: size of concat operation is different than size of the target

Today I got an error, for which I couldn't find a solution.
I use the PXI-7813R FPGA, with Xilinx tools 10.1
At compilation, the error I get is:
Compilation failed due to a Xilinx error.
Details:
ERROR:HDLParsers:804 - "C:/NIFPGA/jobs/TESY1S8_X4PR8hn/NiFpgaAG_000000ce_CaseStructureFrame_0000.vhd" Line 301. Size of concat operation is different than size of the target.
ERROR:HDLParsers:804 - "C:/NIFPGA/jobs/TESY1S8_X4PR8hn/NiFpgaAG_000000ce_CaseStructureFrame_0000.vhd" Line 372. Size of concat operation is different than size of the target.
-->
Total memory usage is 185944 kilobytes
Number of errors : 2 ( 0 filtered)
Number of warnings : 0 ( 0 filtered)
Number of infos : 0 ( 0 filtered)
Process "Synthesis" failed
Start Time: 18:25:26
End Time: 18:28:54
Total Time: 00:03:27
What can cause a concat size difference?

This is by the way the configuration:
Project: FPGAWrapperMG100125AOD.lvproj
Target: FPGA Target (RIO0, PXI-7813R)
Build Specification: fpga_integrator_AOD_random_access
Top level VI: fpga_integrator_AOD_random_access.vi
Compiling on LabVIEW FPGA Compile Cloud Service
Compilation Tool: Xilinx 10.1
Start Time: 05.07.2011 19:06:12
Run when loaded to Fpga: FALSE
Xilinx Options
Design Strategy: Custom
Synthesis Optimization Goal: Area
Synthesis Optimization Effort: Normal
Map Overall Effort Level: Default Xilinx setting
Place and Route Overall Effort Level: High
JobId: FNW72uPWorking Directory: C:\NIFPGA\compilation\FPGAWrapperMG100_FPGATarget_fpgaintegratorAO_9D5B4237
The Xilinx log is attached.
Attachments:
XilinxLog.txt ‏80 KB

Why is the FPGA compiler server so slow?

FPGA Cloud compiler is faster because NI servers are high performance, right????
Well, my Windows 7 PC is high performance, but no luck there!
Total CPU usage is never more than 25% and total memory usage (including other applications) is less than 16%.
Why does the compile server not use all available resources? has it been restricted?
How can I leverage more power from my PC?
If NI Servers can compile code quicker, there must be plausible explanation / reason?
Please advise, how to make the compile server run faster locally?
Solved!
Go to Solution.

Try this if you haven't yet:
http://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/Turbo-Boost-the-speed-of-FPGA-compiles-under-Wind...
In my experience, taking advantage of Intel's Turbo Boost (my PC has i5) reduced compile time from 85 minutes to 45.
I'm currently testing Cloud Compiler and it took 110 minutes. How can Cloud Compile Server be the slowest compile?

Compilation problem on solaris9 x86

I am working on JAVA/J2EE . Am new to solaris9 . My requirement is to compile a source distribution of MOD-JK 1.2.21 (apache 2.0 server connector)and to produce binary distribution (*.so file) in solaris9 X86 box. But i got only source distribution of solaris10 X86 platform . Even with this source i tried to compile in solaris9 box its giving some error message and i can't able to make a executable file. Below i pasted the error message .
# ./configure -with-apxs=/usr/apache2/bin/apxs
checking build system type... i386-pc-solaris2.10
checking host system type... i386-pc-solaris2.10
checking target system type... i386-pc-solaris2.10
checking for a BSD-compatible install... scripts/build/unix/install-sh -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... no
checking for gcc... no
checking for cc... cc
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.
Can any body help me in this regards. Even i don't know, am proceeding in right direction to compile this file. If any body having the binary distribution for the same MOD-JK1.2.21 on solaris9 or solaris10 X86 platform for apache2.0 . please help me to compile this file .I given below the config.log file entries also.
Thanks in advance..........
karthikeyan.u
[email protected]
AIM or AOL :: karthikeyanu
CONFIG.log entries......
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by configure, which was
generated by GNU Autoconf 2.59. Invocation command line was
$ ./configure -with-apxs=/usr/apache2/bin/apxs
## Platform. ##
hostname = Solaris
uname -m = i86pc
uname -r = 5.10
uname -s = SunOS
uname -v = Generic_118844-26
/usr/bin/uname -p = i386
/bin/uname -X = System = SunOS
Node = Solaris
Release = 5.10
KernelID = Generic_118844-26
Machine = i86pc
BusType = <unknown>
Serial = <unknown>
Users = <unknown>
OEM# = 0
Origin# = 1
NumCPU = 1
/bin/arch = i86pc
/usr/bin/arch -k = i86pc
/usr/convex/getsysinfo = unknown
hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /usr/sbin
PATH: /usr/bin
PATH: /usr/openwin/bin
PATH: /usr/ucb
## Core tests. ##
configure:1546: checking build system type
configure:1564: result: i386-pc-solaris2.10
configure:1572: checking host system type
configure:1586: result: i386-pc-solaris2.10
configure:1594: checking target system type
configure:1608: result: i386-pc-solaris2.10
configure:1640: checking for a BSD-compatible install
configure:1695: result: scripts/build/unix/install-sh -c
configure:1706: checking whether build environment is sane
configure:1749: result: yes
configure:1814: checking for gawk
configure:1843: result: no
configure:1814: checking for mawk
configure:1843: result: no
configure:1814: checking for nawk
configure:1830: found /usr/bin/nawk
configure:1840: result: nawk
configure:1850: checking whether make sets $(MAKE)
configure:1874: result: no
configure:2085: checking for gcc
configure:2114: result: no
configure:2165: checking for cc
configure:2181: found /usr/ucb/cc
configure:2191: result: cc
configure:2355: checking for C compiler version
configure:2358: cc --version </dev/null >&5
/usr/ucb/cc: language optional software package not installed
configure:2361: $? = 1
configure:2363: cc -v </dev/null >&5
/usr/ucb/cc: language optional software package not installed
configure:2366: $? = 1
configure:2368: cc -V </dev/null >&5
/usr/ucb/cc: language optional software package not installed
configure:2371: $? = 1
configure:2394: checking for C compiler default output file name
configure:2397: cc conftest.c >&5
/usr/ucb/cc: language optional software package not installed
configure:2400: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE "mod_jk"
| #define VERSION "1.2.21"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2439: error: C compiler cannot create executables
See `config.log' for more details.
## Cache variables. ##
ac_cv_build=i386-pc-solaris2.10
ac_cv_build_alias=i386-pc-solaris2.10
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_CXXCPP_set=
ac_cv_env_CXXCPP_value=
ac_cv_env_CXXFLAGS_set=
ac_cv_env_CXXFLAGS_value=
ac_cv_env_CXX_set=
ac_cv_env_CXX_value=
ac_cv_env_F77_set=
ac_cv_env_F77_value=
ac_cv_env_FFLAGS_set=
ac_cv_env_FFLAGS_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_host=i386-pc-solaris2.10
ac_cv_host_alias=i386-pc-solaris2.10
ac_cv_prog_AWK=nawk
ac_cv_prog_ac_ct_CC=cc
ac_cv_prog_make_make_set=no
ac_cv_target=i386-pc-solaris2.10
ac_cv_target_alias=i386-pc-solaris2.10
## Output variables. ##
ACLOCAL='${SHELL} /export/home/dump_208/workspace_SB_563/modjk/ModJK1/modjk/jkk/tomcat-connectors-1.2.21-src/native/scripts/build/unix/missing --run aclocal-1.9'
AMDEPBACKSLASH=''
AMDEP_FALSE=''
AMDEP_TRUE=''
AMTAR='${SHELL} /export/home/dump_208/workspace_SB_563/modjk/ModJK1/modjk/jkk/tomcat-connectors-1.2.21-src/native/scripts/build/unix/missing --run tar'
APACHE20_OEXT=''
APACHE_CONFIG_VARS=''
APACHE_DIR=''
APXS=''
APXSCFLAGS=''
APXSCPPFLAGS=''
APXSLDFLAGS=''
AR=''
AUTOCONF='${SHELL} /export/home/dump_208/workspace_SB_563/modjk/ModJK1/modjk/jkk/tomcat-connectors-1.2.21-src/native/scripts/build/unix/missing --run autoconf'
AUTOHEADER='${SHELL} /export/home/dump_208/workspace_SB_563/modjk/ModJK1/modjk/jkk/tomcat-connectors-1.2.21-src/native/scripts/build/unix/missing --run autoheader'
AUTOMAKE='${SHELL} /export/home/dump_208/workspace_SB_563/modjk/ModJK1/modjk/jkk/tomcat-connectors-1.2.21-src/native/scripts/build/unix/missing --run automake-1.9'
AWK='nawk'
CC='cc'
CCDEPMODE=''
CFLAGS=''
CP=''
CPP=''
CPPFLAGS=''
CXX=''
CXXCPP=''
CXXDEPMODE=''
CXXFLAGS=''
CYGPATH_W='echo'
DEFS=''
DEPDIR=''
ECHO='echo'
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EGREP=''
EXEEXT=''
F77=''
FFLAGS=''
GREP=''
INSTALL_DATA='${INSTALL} -m 644'
INSTALL_PROGRAM='${INSTALL}'
INSTALL_SCRIPT='${INSTALL}'
INSTALL_STRIP_PROGRAM='${SHELL} $(install_sh) -c -s'
INSTALL_TYPE=''
JAVA_HOME=''
JK_JNI_WORKER=''
LDFLAGS=''
LIBOBJS=''
LIBS=''
LIBTOOL=''
LIB_JK_TYPE=''
LN_S=''
LTLIBOBJS=''
MAKEINFO='${SHELL} /export/home/dump_208/workspace_SB_563/modjk/ModJK1/modjk/jkk/tomcat-connectors-1.2.21-src/native/scripts/build/unix/missing --run makeinfo'
MAKE_DYNAMIC_APACHE_FALSE=''
MAKE_DYNAMIC_APACHE_TRUE=''
MKDIR=''
OBJEXT=''
OS=''
PACKAGE='mod_jk'
PACKAGE_BUGREPORT=''
PACKAGE_NAME=''
PACKAGE_STRING=''
PACKAGE_TARNAME=''
PACKAGE_VERSION=''
PATH_SEPARATOR=':'
PERL=''
RANLIB=''
RM=''
SED=''
SET_MAKE='MAKE=make'
SHELL='/bin/bash'
STRIP=''
TEST=''
VERSION='1.2.21'
WEBSERVER=''
ac_ct_AR=''
ac_ct_CC='cc'
ac_ct_CXX=''
ac_ct_F77=''
ac_ct_RANLIB=''
ac_ct_STRIP=''
am__fastdepCC_FALSE=''
am__fastdepCC_TRUE=''
am__fastdepCXX_FALSE=''
am__fastdepCXX_TRUE=''
am__include=''
am__leading_dot='.'
am__quote=''
am__tar='${AMTAR} chof - "$$tardir"'
am__untar='${AMTAR} xf -'
apache_include=''
bindir='${exec_prefix}/bin'
build='i386-pc-solaris2.10'
build_alias=''
build_cpu='i386'
build_os='solaris2.10'
build_vendor='pc'
datadir='${prefix}/share'
exec_prefix='NONE'
host='i386-pc-solaris2.10'
host_alias=''
host_cpu='i386'
host_os='solaris2.10'
host_vendor='pc'
includedir='${prefix}/include'
infodir='${prefix}/info'
install_sh='/export/home/dump_208/workspace_SB_563/modjk/ModJK1/modjk/jkk/tomcat-connectors-1.2.21-src/native/scripts/build/unix/install-sh'
int32_t_fmt=''
int32_value=''
int64_t_fmt=''
int64_value=''
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localstatedir='${prefix}/var'
mandir='${prefix}/man'
mkdir_p='$(install_sh) -d'
oldincludedir='/usr/include'
prefix='NONE'
program_transform_name='s,x,x,'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
target='i386-pc-solaris2.10'
target_alias=''
target_cpu='i386'
target_os='solaris2.10'
target_vendor='pc'
uint32_t_fmt=''
uint32_t_hex_fmt=''
uint64_t_fmt=''
uint64_t_hex_fmt=''
## confdefs.h. ##
#define PACKAGE "mod_jk"
#define PACKAGE_BUGREPORT ""
#define PACKAGE_NAME ""
#define PACKAGE_STRING ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define VERSION "1.2.21"
configure: exit 77

You need to make sure the source is for the same version i.e. if you run apache 2.0.52 you need the source of 2.0.52. I successfully ran mixed installs, but I would not recommend it. You can download the required source from Apache.
As for your compiler problem, make sure you have �/usr/ccs/bin/� in the your path, if you do not have it installed you will have to add the pkg �SUNWsprot�. You do not have 'make' in yout path.
Make sure you have the following packages installed:
SUNWbtool, SUNWsprot, SUNWtoo
SUNWhea, SUNWarc, SUNWlibm, SUNWlibms
SUNWdfbh, SUNWcg6h, SUNWxwinc, SUNWolinc,
SUNWxglh,SUNWarcx, SUNWbtoox, SUNWdplx,
SUNWscpux, SUNWsprox, SUNWlmsx, SUNWlmx
SUNWlibCx, SUNWtoox, SUNWsra, SUNWsrh

LV FPGA compilation problem (urgent)

Similar Messages

Maybe you are looking for