FPGA Compile Farm 2012 question

[bwv1043]

I was under impression that my LV FPGA code can be compiled by many workers when I purchased and installed FPGA Compile Farm Toolkit.  What I'm experiencing though, is that each compile job can only be compiled by one worker.  I expected a single compile job can be split by many workers.

I see a worker from either computer will compile so both worker computers do work.  It's just that only one worker will compile at a time.

Did I just misunderstand the capabilities of Compile Farm Toolkit or is this a setup issue?

Thanks

[ToeCutter · Accepted solution]

No, a single compile cannot be split between workers. Nature of the beast- FPGA 'compilation' is not something that lends itself to parallelism. You do gain the advantage that the compile tools run considerably faster under linux, though.

[bwv1043]

Doh!  I think I need a refund.  This toolkit is then almost useless to me as I am the only engineer who is working on only one FPGA project.

Thank you for the answer.

Perhaps, NI should make it clear that toolkit is only capable of compiling multiple FPGA projects.  Not parallel compile a single FPGA project.

[Hooovahh]

Yeah contact your local sales rep.  I've never heard of someone getting a refund on software, but then again I've never asked.  NI may be kind given the fact that you just bought it.

And another thing, I've never seen the benefit of the compile farm anyway.  Are there that many companies that are compiling FPGA code, so often, and for so many targets, that they need a dedicated machine for it?  What's wrong with developing on your machine, and compiling there?  Or even use source code control, develop on one machine, compile on another?  I see this product as a waste but again I don't know if I'm in the minority.

[bwv1043]

You have to check this out:

http://forums.ni.com/t5/ideas/v2/ideapage/blog-id/lvfpgaideas/article-id/38/page/2#comments

See the last post by Lorn.  I was able to reduce compile time from 85 minutes to 45 minutes!!!

If you read the post and Intel's description of Turbo Boost, this is a great way of cutting down your compile time.  You can watch Turbo Boost Monitor and CPU Usage history and see how inefficiently the compiler runs by default (it jumps from one core to the next constantly).

[bwv1043]

To add to your other comment, I also doubt this toolkit being too useful in most situations.  I feel misguided to make this purchase...

[T-REX$]

I'm sorry you feel that way... I certainly suspect you will be able to get a refund. Just contact your sales rep and explain the situation.

That said, I would like to figure out how you got to where you are. Did you contact NI before making the purchase? What documentation did you consult... is there any point of confusion I can clear up?

I would suspect that you read this document before making your purchase, as it's the defacto document we have on compilation options and is linked from the Compile Farm product page. Our current "message" is this:

With the LabVIEW FPGA Compile Farm Toolkit, you can create an in-house compile farm that has many workers and can be targeted by multiple developers. The pricing for this toolkit is tiered according to the number of computers you need in the farm. With this toolkit, any number of developers can target the central server. The server is responsible for farming out the compilation jobs to all available workers. Because you have multiple workers, the compiles run in parallel. If there are no available compile workers, the server queues the requests (FIFO) and farms them out when a worker becomes available.

 I would like to avoid specifically calling out "This does not enable you to split one compile amongst multiple machines"... but if there is a lot of confusion, I can get it added somewhere. It just feels wrong (IMHO) to call out what a product doesn't do.

I'd also like to encourage you to request to speak to an Applications Engineer about these sorts of things. They should have been able to clear that up for you before the purchase.

Oh, and finally, there are use-cases that this product fulfills. Many companies do have multiple developers working on the same project (or multiple different projects), and this is a great way to make them more efficient by freeing up resources on their dev computers. It also enables you to fire off a whole batch of compilations to the farm, and have them all go in parallel. This is useful because the compilation process itself is not deterministic, and designs that are very close to being able to compile will sometimes fail and sometimes pass. Basically, this is a useful tool for teams of developers or for a developer pushing the limits of their hardware.

Anyway, sorry for the longwinded response... I just genuinely would like to prevent confusion around this product, which I use everyday.

[T-REX$]

I re-read the pasted paragraph above. Would changing this sentence:

The server is responsible for farming out the compilation jobs to all available workers.

to this:

The server is responsible for farming out each compilation job to an available worker.

 have helped clear this up for you? I'm grateful for any feedback you can provide on how to clear this up for future users.

[ToeCutter]

---

@T-REX$ wrote:

I re-read the pasted paragraph above. Would changing this sentence:

The server is responsible for farming out the compilation jobs to all available workers.

to this:

The server is responsible for farming out each compilation job to an available worker.

 have helped clear this up for you? I'm grateful for any feedback you can provide on how to clear this up for future users.

---

I can see where the confusion arises and it's only that I happened to be chatting to an NI engineer that I found this out, however I think the wording needs clarifying even more. Something like this needs to be crystal clear, e.g.

NOTE: A single compile can only be assigned to one compile worker. It cannot be split between multiple workers.

I was going to attempt to persuade you that the increased speed even on a single compile worker under linux was worth the price of the license, but Lorn's tip has taken the wind out of my sails.

[ToeCutter]

In fact, this little tip totally negates the speed difference between Windows and Linux compile workers!

 

Quote from NI documentation:

"5. Reduce Compile Time With Linux

NI has invested in supporting the FPGA compile worker on the Linux OS. Depending on your FPGA VI complexity and logic, you can expect the Linux compile worker to reduce compile times by approximately 20 to 50 percent, compared to a Windows compile worker. Xilinx originally designed and optimized the compile tools for the Linux OS, which explains this substantial reduction in compile time."