FPGA Compile worker auto-start

[xl600]

I finally got a VM (VirtualBox) based FPGA compile worker (ISE14.7) and CentOS working.  I was pleasantly surprised that my compile times have dropped by almost 50% even when running the VM on the same machine as my original LabView FPGA installation.

Is there a way to get the compile worker to auto-start when the VM is powered on (With no user needing to log into the VM)?

Thanks,

XL600

[JaredT]

Hi XL600,

I don't believe there is any native NI functionality to support this request. There is a chance you can write a script to run on boot-up of the VM to programmatically walk through the steps of running the compilation but there is no information available from NI on how to perform this. 

Why are you looking to recompile your bit-file every time the virtual machine is powered on?

Regards,

Jared T.

[xl600]

You misunderstand the intent.  My development system is host based licensed and different users may need to log on and compile FPGAs.  The VM only has the root logon and I'd like to give the users the ability to simply double-click the VM to start it (Via a VirtualBox icon on each of their desktops), but not have to log into the VM itself to start the compile worker.

[JaredT]

XI600,

Let me make sure I understand. You have a User Based license for a system on a host machine. You have a VM on that host machine that will be accessible to all users who log into the host machine. However, since not all users will have the license permissions needed to run the FPGA compile, you want to automate it on the VM so that simply starting it up will start the FPGA compilation?

Regards,

Jared T.

[xl600]

No, I have a host based license on only the one machine.  All users of the machine can use all labview features the machine is licensed for (One at a time of course.  It's a Windows 10 machine, not a server).  The VM is available to all users who log in and start it, but the users won't have accounts in the VM.

I want the VM to start the compile worker listening (But not compiling) automatically so the users don't have to log into the VM.  The users would just start their compile through LabView after starting the VM.

[JaredT]

Okay, thank you for clarifying that for me. 

Unfortunately as I stated previously, I don't believe there is any native NI functionality to support that. You can try writing a script to run on boot-up of the VM to programmatically walk through the steps of running the compilation but NI doesn't support that functionality. 

Regards,

Jared T.

[xl600]

Actually, there is built in support.  I took a look at the command line which starts up the worker:

/bin/bash -c 'cd /usr/local/natinst/nifpgacompileworker/ && /usr/local/natinst/nifpgacompileworker/cw_wrapper.sh mono /usr/local/natinst/nifpgacompileworker/CompileWorker.exe'

It's a mono application requiring an X server display.  Curious, I looked at the cw_wrapper.sh script and it appears NI has already foreseen this need.  The script will automatically detect if the DISPLAY variable is not defined.  If it isn't, it attempts to run the worker under an Xvfb virtual display for headless operation.  That's exactly what I was looking for, so I installed Xvfb and placed the command line above into my /etc/rc.local (With an ending '&' of course, to prevent rc.local stalling the boot process).

The result?  The compile worker starts and runs with no user interaction other than double clicking the VM!  No user specific logon required for the VM since the worker runs as root.  The worker also appears to shut down cleanly when the VM is powered down.

XL600

[cupora]

At the moment, I am also struggling with autoruning my compile worker. The same, I'm using CentOS to run it, and I also found the command to start the compile worker. But I am experiencing a very strange problem at the moment.

If I ssh to my server and run the compile worker from command line, everything is working well. But as soon as I try to make it autorun (both by rc.local or by creating my own service), compilation fails during synthesize process. It seems that Vivado does not get the proper file name for its compilation job. Here is the output of compile worker:

2018-02-20 09:36:18Z|INFO|SessionId=FBrkhm7|WorkerId=VFjc78z|JobId=XQnuTD5|Running process: /usr/local/natinst/NIFPGA/programs/vivado2014_4/bin/vivado -mode batch -source /usr/local/natinst/NIFPGA/jobs/XQnuTD5_VFjc78z/synthesize.tcl -m64
2018-02-20 09:36:22Z|INFO|SessionId=FBrkhm7|WorkerId=VFjc78z|JobId=XQnuTD5||2|Synthesize - Vivado|DbgStdErr|Vivado process returned error code in step Synthesize - Vivado: 1
2018-02-20 09:36:22Z|ERROR|SessionId=FBrkhm7|WorkerId=VFjc78z|JobId=XQnuTD5|The Unit Of Work (path: /usr/local/natinst/NIFPGA/jobs/XQnuTD5_VFjc78z) did not finish properly because of an exception: The step 'Synthesize - Vivado' errored and we were asked to quit on error.
2018-02-20 09:36:22Z|ERROR|SessionId=FBrkhm7|WorkerId=VFjc78z|JobId=XQnuTD5|NI.LV.FPGA.CompileWorkerUI.UowQuitException: The step 'Synthesize - Vivado' errored and we were asked to quit on error. ---> NI.LV.FPGA.CompileWorkerUI.UowQuitException: Vivado process returned error code in step Synthesize - Vivado: 1    at NI.LV.FPGA.CompileWorkerUI.VivadoStepExecutor.RunAndThrow (IVivadoUowScriptRunner runner, NI.LV.FPGA.CompileWorkerUI.SimpleUowStep step, NI.LV.FPGA.CompileWorkerUI.UowState state, System.String tclScript) [0x00000] in <filename unknown>:0 at NI.LV.FPGA.CompileWorkerUI.VivadoStepExecutor.ExecuteCapabilityStep (NI.LV.FPGA.CompileWorkerUI.UowState uowState, IDictionary`2 globalArguments, NI.LV.FPGA.CompileWorkerUI.SimpleUowStep step) [0x00000] in <filename unknown>:0     at NI.LV.FPGA.CompileWorkerUI.SimpleUowStep.Run (NI.LV.FPGA.CompileWorkerUI.UowStateuowState, IDictionary`2 globalParameterList, IUowStepExecutor executor) [0x00000] in <filename unknown>:0     --- End of inner exception stack trace ---    at NI.LV.FPGA.CompileWorkerUI.SimpleUowStep.Run (NI.LV.FPGA.CompileWorkerUI.UowState uowState, IDictionary`2 globalParameterList, IUowStepExecutor executor) [0x00000] in <filename unknown>:0     at NI.LV.FPGA.CompileWorkerUI.SimpleUowStep.Run (NI.LV.FPGA.CompileWorkerUI.UowState state, IDictionary`2 globalParameterList, IUowStepExecutor executor, System.Collections.Generic.SortedDictionary`2 AllSteps, System.Func`1 shouldAbort) [0x00000] in <filename unknown>:0 at NI.LV.FPGA.CompileWorkerUI.UnitOfWork.Run (IFpgaFarmCapability capabilityObject) [0x00000] in <filename unknown>:0
2018-02-20 09:36:24Z|WARN|SessionId=FBrkhm7|WorkerId=VFjc78z|JobId=XQnuTD5|TotalBytesAttemptedToStream=51146
2018-02-20 09:36:24Z|WARN|SessionId=FBrkhm7|WorkerId=VFjc78z|JobId=XQnuTD5|TotalBytesStreamed=51146
2018-02-20 09:36:24Z|INFO|SessionId=FBrkhm7|WorkerId=VFjc78z|JobId=XQnuTD5|About to upload file
2018-02-20 09:36:24Z|INFO|SessionId=FBrkhm7|WorkerId=VFjc78z|JobId=XQnuTD5|File successfully uploaded.
2018-02-20 09:36:29Z|INFO|SessionId=FBrkhm7|WorkerId=VFjc78z|JobId=XQnuTD5|Job finished successfully.
2018-02-20 09:36:29Z|INFO|SessionId=FBrkhm7|WorkerId=VFjc78z|JobId=XQnuTD5|Finished thread.
2018-02-20 09:36:29Z|INFO|SessionId=FBrkhm7|WorkerId=|JobId=|Setting info that should end up in the UI: Registered Capabilities: ( 'Vivado 2014.4'  'Vivado 2014.4 (64-bit)' )
2018-02-20 09:36:29Z|INFO|SessionId=FBrkhm7|WorkerId=|JobId=|UI info changed: Registered Capabilities: ( 'Vivado 2014.4'  'Vivado 2014.4 (64-bit)' )

Did somebody face this issue? It is really annoying, as after any reboot I need then manually start the Compile Worker.

[xl600]

Unfortunately, I'm only using the Xilinx ISE 14.7 compiler and didn't try the Vivado compiler.  Sounds like it isn't behaving as nicely as the ISE compiler (I've compiled a few design now and it seems to be working fine running from rc.local).