FPGA compilation time: how to accelerate?

[Pierre_F]

Hi!

Despite the fact I'm working in an intel core i7 16 cores, my compilation delays of my cRIO-9049 takes very long (7 minutes for a simple VI, 12-13 min for a big one)
When I look at the windows task manager -> tab "performance" the cores are used slightly.

is there a way to accelerate the compilation time in order to exploit as most CPU resources as possible?

see you 🙂

[Bob_Schor]

I remember being in a class at NIWeek on sbRIOs.  We developed our first FPGA code (quite simple) and submitted it to the Compiler, then the Instructor said "Go get lunch -- it should be done when you come back".

You didn't say what Compiler (and Version) you were using.  Have you tried using the "Compiler Farm"?  [My compilations typically run 5-7 minutes, so I go get a cup of tea ...].

Bob Schor

[MichaelBalzer]

Those times are pretty normal. I expect at least a 10 minute compile for basic code, 20-30 for more complex designs, an upwards of an hour for really resource intensive designs. I don't think the xilinx compile tools really take advantage of multiple cores, hence why you're seeing very little CPU use in task manager - the biggest speedup is raw CPU clock speed and lots of RAM.

You might try changing the compiler options to optimize for speed, but I think that's the default: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019KTySAM&l=en-US

Using the Linux based compile tools also offers a small reduction in compilation time, but I've never been able to get it to work properly: https://www.ni.com/en/shop/electronic-test-instrumentation/add-ons-for-electronic-test-and-instrumen...

If you can, use the cloud compilation option as it's usually the quickest.

[deceased]

In a counter intuitive move, I found FPGA compiles faster if I push them towards a single core.

Admittedly I'm not using the latest LabVIEW version, so not sure if this will help you.

I have the following in a batch file that I run to start the compile worker, before starting the compilation in LabVIEW

C:\Windows\System32\cmd.exe /C START " " /HIGH /AFFINITY 0X02 "C:\Program Files (x86)\National Instruments\FPGA\CompileWorker\CompileWorker.exe"

pause

0xDEAD

[Pierre_F]

Hi bob schor

I'm using the vivado compiler included within labview 2020

---

@MichaelBalzer  a écrit :

Those times are pretty normal. I expect at least a 10 minute compile for basic code, 20-30 for more complex designs, an upwards of an hour for really resource intensive designs..

How do you manage the code test and modifications if you need to recompile 1 hour each time? I have the feeling that it way of working doesn't really help developers

thanks for your documentation

My recruiter worked a lot on xilinx systems, and he has been stunned when I explained him labVIEW, compilation cannot take less than 7 minutes. It seems that, in standard FPGA compilers, it's faster.

I think this aspect can gives a negative feeling fom non-NI users

[santo_13]

We should definitely consider that this LabVIEW code is translated to VHDL and passed onto the Xilinx compiler for further processing. The translation is not trivial and given that LabVIEW also has to ensure Dataflow paradigm, there is another level of complexity in the translation process along with the other constraints such as resources connected to FPGA at the hardware level.

In a raw FPGA VHDL implementation, the compiler does not do any of these, the expertise of the developer is important and the developer has to consider all of these during implementation.

I believe all NI FPGA instruments support external VHDL and need not be LabVIEW.

[MichaelBalzer]

---

@Pierre_F wrote:

How do you manage the code test and modifications if you need to recompile 1 hour each time? I have the feeling that it way of working doesn't really help developers

---

There's simulation mode, which doesn't require compilation and uses simulated I/O. Obviously it limits testing with real devices, but is still a useful development tool. There's also component-level IP (CLIP) which can be used to integrate VHDL directly, and I believe cuts down on compile time.

Personally I'm willing to forego a shorter compilation time if it means I don't have to use VHDL. LabVIEW FPGA is probably one of LabVIEW's best features - it's pretty cool the same language can be used to write web, desktop, embedded, and FPGA applications.

[Intaris]

---

@MichaelBalzer wrote:

---

@Pierre_F wrote:

How do you manage the code test and modifications if you need to recompile 1 hour each time? I have the feeling that it way of working doesn't really help developers

---

There's simulation mode, which doesn't require compilation and uses simulated I/O. Obviously it limits testing with real devices, but is still a useful development tool. There's also component-level IP (CLIP) which can be used to integrate VHDL directly, and I believe cuts down on compile time.

Personally I'm willing to forego a shorter compilation time if it means I don't have to use VHDL. LabVIEW FPGA is probably one of LabVIEW's best features - it's pretty cool the same language can be used to write web, desktop, embedded, and FPGA applications.

---

This, use simulation mode.

Test your code piece by piece to help get through it.

Only actually compile a bitfile when you're fairly certain you've caught most bugs already.

[James_McN]

Hi Pierre,

The advice given else where is very good. use simulation mode and I even use some unit testing tools around logic destined for the FPGA (but this runs as desktop code so is not always a good test).

The compilation has two stages:

1. Generating Intermediate Files - This converts the LabVIEW code to encrypted VHDL.

2. Xilinx Compilation - This is the same Xilinx compiler as used for other systems.

The first stage is always a local process. The second stage can be offloaded to other servers but the compilation process doesn't scale with CPUs so there is a limit to what can be done. Your times so far sound on par with what I expect.

It's worth noting that one of the reasons they can seem long compared to VHDL is because it is not only your code that gets compiled but also NI's PCIe interface logic for DMA and register-transfer and so that is where you get a minimum time for even the smallest VIs.