Faster FPGA compilation times using... FPGA? GPU?

[betocool]

Hey all,

just out of curiosity really, because I couldn't find any information online, not could Chat GPT when I asked them... 

With increasing FPGA project sizes synthesis, fitting and routing take longer and longer. I usually run a compile in a simulator first, only because on a Cyclone V Quartus takes about 2 minutes before it gets to the first syntax error. Also, Windows Quartus GUI is terribly slow compared to a command line Linux build.

Nevertheless, it got me thinking, would it be possible to accelerate the whole build process using an additional FPGA PCI card (or even over Ethernet just for kicks), that returns a binary file? Would it be possible using a PC's GPU for example?

My first thought was, yes, but probably nobody does it because all processes are proprietary. But then I remembered there are a few projects that can do Open Source Xilinx Series 7 and other brands. So why not?

Is it maybe because the synthesis and routing processes are more iterative in nature than a calculation? No idea.

If you guys have clues or know about such a project, I'd be interested in knowing.

Cheers,

Alberto

[AndyC_772]

The main issue with any 3rd party FPGA software, is that producing a functional, guaranteed reliable binary for any FPGA requires a timing model of the device. That model specifies all the best and worst case delays through the part across all possible variations of temperature, supply voltage and part-to-part variability.

Only the device's manufacturer knows all this information.

A 3rd party binary might work on one particular device just fine but fail on another part, or it might work when it's cold but not hot, or vice versa. If the problem is setup time, slowing the clock might help, but you'll never know what the maximum guaranteed speed would be. If it's a hold time violation, no change in clock rate will ever make it work reliably.

FPGA code is *nothing* like a set of instructions which have defined, guaranteed meaning, and can be easily shown to be correct or incorrect. Timing is *everything*.

Advocates of 3rd party FPGA tools don't address this critical issue, and until an FPGA vendor decides to release the complete, guaranteed timing model for a family of parts, it's just not possible to produce a guaranteed reliable binary - whether it's produced using a CPU, or a GPU, or an abacus.

[Scrts]

I would like to see such an accelerated tool that generates binary for a typical room temperature, nominal part scenario for development purposes. I can quickly make a bugfix, compile and run a test on live data (e.g. specific video data).
Once I am happy, I can run a nightly build with a regular synthesis tool for a customer release.

[SiliconWizard]

Looks like a job for quantum computing.

[NorthGuy]

Cyclone V Quartus takes about 2 minutes before it gets to the first syntax error.

Unless your code base is millions of lines, I don't see how can it possibly take more than a second to find all syntax errors.

It is slow because it's bloated, not because it has to be slow. Same goes for Xilinx's Vivado. Nothing you can do about it unless you can write your own.

[tggzzz]

Sensible points from AndyC_772.

I do wonder whether the fpga vendors could use gpus for simulation to verify timing constraints.

[Berni]

A lot of these FPGA tools are so old and full of legacy crud that they still recommend to not have spaces in the path to your project files. So don't think GPU acceleration is on the roadmap anytime soon.

Not sure how suitable GPUs are for the task anyway. Since this is more of a complex sequential task rather than something that is massively parallel. The whole place and route process has to be done for the whole chip since running one signal across the whole chip might affect the available signal paths for all the stuff along that path.

Tho when it comes to developing for FPGAs, it is a massive help to use simulators. They can skip a lot of the steps needed to stuff a HDL design into a chip. Even incremental compiles are possible, so compiling most changes is literally <1 second to compile. It is annoying to have to build testbenches for everything, but it saves time in the long run.

[nctnico]

Somehow I recall being able to spread the load over several computers using the Xilinx tools. But it could be that you need a really high-end, high-cost license for this to work. The largest FPGA designs would take close to a week to complete otherwise.

[tszaboo]

It's an NP complete issue, and the compiler (implementer) is a complex piece of software that is difficult to parallelize because it is full of if/thens and the number of users are dozens of people. And these poeple wat faster compile for free.
I had implement times in hours years ago for a lowly Spartan 3. Honestly, it is much better now.

[luudee]

I don't know about Quartus, haven't used it in many years, but Xilinx tools, as Nico
already pointed out, Vivado allows you to use multiple CPUs and also spread a job
across several computers.

I always run my compiles an all 32 threads I have available. Still some jobs will take
a few days to complete. We do this every day ...

Make sure to properly simulate and verify your design before compiling it ...

Good Luck !
rudi

[luudee]

Once your designs start taking up a day or more to be implemented, it is
essential to invest in proper hardware.

Attached is screen dump of my performance meter on the compile box ...
128 GB main memory, 16 core (32 thread) CPU.

That particular run, was a customer project targeting a very full  XCZU5CG-fbvb900

Good Luck,
rudi

[nctnico]

But there is also some black magic involved. Tweaking the placer cost parameter in Xilinx ISE can make the difference between needing 6+ hours or 25 minutes to 'close' the timing constraints of a design.

[asmi]

Once your designs start taking up a day or more to be implemented, it is
essential to invest in proper hardware.

Attached is screen dump of my performance meter on the compile box ...
128 GB main memory, 16 core (32 thread) CPU.

Your CPU clocks seems rather slow, what CPU is that? I've got an AMD 5950x here with 128GB of RAM, and my CPU holds clocks of ~4.5 GHz under full load. Vivado is very frequency-dependent, so you might get a serious performance boost if you get faster CPU.

Vivado has got synthesis pretty much nailed with OOC runs when it dedicates single IP instance to a core, so larger designs benefit immensely from having more cores as it allows more OOC synthesis to ran in parallel. But implementation is still very much a single-thread task (not entirely, but largely so), this is where you need a CPU which can boost HARD when only one or two cores are loaded.

[pcprogrammer]

.....
Only the device's manufacturer knows all this information.

All this information is available when you have the vendor tools. Getting them in open daylight is a difficult task though.

But this is what some have done for the open sourcing of the different types of FPGA supported by yosys and nextpnr. It requires some reverse engineering of the tools to get an insight in the provided data and a lot of interpreting what it shows.

For the Anlogic FPGA's it has been done by Miodrag Milanović (mmicko on github) and I used a lot of the information to reverse engineer the FNIRSI 1013D FPGA design. Did not use the timing information, but it is there in the data.

[tszaboo]

I don't know about Quartus, haven't used it in many years, but Xilinx tools, as Nico
already pointed out, Vivado allows you to use multiple CPUs and also spread a job
across several computers.

I always run my compiles an all 32 threads I have available. Still some jobs will take
a few days to complete. We do this every day ...

Make sure to properly simulate and verify your design before compiling it ...

Good Luck !
rudi

Oh Xilinx already do threads? Cool.
I was told by several people that this is almost impossible cause the reasons I said.

[asmi]

Oh Xilinx already do threads? Cool.
I was told by several people that this is almost impossible cause the reasons I said.

Kind of. They run OOC synthesis in parallel, dedicating a physical core per component. So each component runs on a single-thread (mostly), but since typical design contain many of them, overall synthesis time get reduced by a lot if you've got many cores. I remember when I upgraded by old 3930K (6 physical cores) to then-top of the line 5950x (16 physical cores), full run time of a typical Microblaze design was reduced by about a factor of 5 - most of it was due to increase in cores count, and the rest was due to higher clocks and more modern architecture with higher IPC.

[Someone]

But there is also some black magic involved. Tweaking the placer cost parameter in Xilinx ISE can make the difference between needing 6+ hours or 25 minutes to 'close' the timing constraints of a design.

There is no black magic, place and route is a stochastic optimiser in a huge solution space. With very few constraints and/or hints the result is highly variable, add appropriate direction to the design and it reliably closes quickly.

I don't know about Quartus, haven't used it in many years, but Xilinx tools, as Nico
already pointed out, Vivado allows you to use multiple CPUs and also spread a job
across several computers.

I always run my compiles an all 32 threads I have available. Still some jobs will take
a few days to complete. We do this every day ...

Oh Xilinx already do threads? Cool.
I was told by several people that this is almost impossible cause the reasons I said.

Its mostly parallel instances running independent attempts (brute force) which you can duplicate on a single multicore machine or across a cluster. There are ways to do that more intelligently but the basic problem is that placement (less so route) is causing highly global effects so it cannot be simply partitioned out into separate tasks.

Oh Xilinx already do threads? Cool.
I was told by several people that this is almost impossible cause the reasons I said.

Kind of. They run OOC synthesis in parallel, dedicating a physical core per component.

OOC can be good for some small components (like IP) but doesn't always save time over a flat design!