Running Xilinx Vivado HLS from in the Cloud - Can it be done?

[pascal_sweden]

My computer is not fast enough to run the Xilinx Vivado HLS toolset.

This means that I have to buy a new and more powerful computer.
Doing a rough calculation I would have to spend between 1000-1500 USD to get a decent setup that is future proof in the years to come.

But I was thinking about a different solution, given that we are 2016 now.
Can the Xilinx Vivado HLS toolset be run from the Cloud, still having access to USB, Ethernet and other necessary ports locally to connect my Xilinx target board (e.g. Xilinx Zybo FPGA board)?

The plan is to run the IDE from a virtual desktop, have access to all the necessary physical ports, but rely on the (massive) horsepower provided by the Cloud architecture on which the actual toolset is installed.

Ideally Xilinx should provide pre-installed Cloud instances for this, to speed up the process.
Why haven't they already thought about that? We are 2016 now... the era of Cloud computing.

Hard to imagine that all Xilinx Vivado users have to spend $$$ on new computer architectures ranging from a desktop Intel Pentium i7 powered computer to a server rack with multiple Intel Xeon processors.

Xilinx.. where are you and the Cloud? What about that strategic partnership with Microsoft (Azure) or Amazon (AWS EC2)?

[daqq]

If it's just for compilation, simulation and development there should be no problem. Ethernet ports might be possible via some creative IP routing, but the USB and similar (COM ports) are a different matter in my opinion.

You could probably get away with running the programmer, debugger and such locally and do the 'heavy lifting' in the cloud.

If you want to try it out, Amazon provides some cloud services for free for a limited time: https://aws.amazon.com/free/

[Lukas]

Most FPGA toolchains include some kind of server functionality to make JTAG programmers available on the network. Xilinx does so as well. http://www.beyond-circuits.com/wordpress/2015/01/remote-jtag-with-vivado/ You just need to setup some kind of tunnel like SSH.

I can really recommend tigervnc as a remote desktop solution: good latency, headless X11 server changes resolution as you resize the vncviewer window. When going fullscreen on the client and having multiple screens connected, the server knows multiple screens as well.

[pascal_sweden]

I really believe that active partnerships between an EDA toolset vendor and a Cloud provider makes sense for the educational market.

If I only had some decision power in this segment, I would make pre-configured instances of EDA toolset Cloud workhorses, where all these challenges in terms of installation, configuration, licenses, and physical port routing and tunneling are solved upfront.

It seems so straightforward and basic common sense, still it doesn't exist yet.

I am not talking only about Xilinx Vivado here. They could add all relevant software into the Cloud that covers an entire Electrical Engineering and Computer Science curriculum.

No hazzle with local installation and configuration issues. Moreover licensing fees could be included and bundled with the overall monthly Cloud service fees.

[dferyance]

Distributed compilation is quite common in the software world, it would make sense in the hardware world. Not only do we have compilers that distribute the job to other computers on the network to do the work, there are tools such as Atlassian Bamboo that offload the entire build process.

As someone who as worked at a hardware company that provided software tools, the general mindset is generally very conservative and slow to change. Vivado using TCL is a simple example of that.

Rather than run the IDE on the cloud, maybe see if you can get the backend engine running there instead. I expect it would take quite a bit of hacking unless you can get Xilinx support to take you seriously.

No way to just upgrade CPUs instead of replace the entire computer?

[hamster_nz]

Distributed compilation is quite common in the software world, it would make sense in the hardware world.

Compilation isn't that much of a problem, it's the place and route that is a killer, as quite a few of the decisions made during the P+R process have global impacts.

I've seen some research that recursively bisects the design's netlist into partitions, and then floor-plans these partitions such that each block has sufficient logic, DSP and BRAM resources to implement that piece of the design. If you were to follow that approach, each piece could be farmed out to a different CPU for local place and route within its allocated area.

However, you then get (at least) two new problems

- how can you ensure that you can efficient connect partitions together?

- The resulting design is less space efficient efficient overall - with 64 partitions it can take up to 150% more die area (as spare resources in one partition can't be and used by the others)

Would you be wanting a design that clocks slower (due to the less efficient interconnects) and requires an FPGA that is 2.5x larger, but allowing you to spread the bulk of the Place + Route over 64 CPUs?  I guess some people might...

That research was http://www.eecg.utoronto.ca/~kmurray/hetris/fpt2015_hetris.pdf

[Someone]

Distributed compilation is quite common in the software world, it would make sense in the hardware world.

Compilation isn't that much of a problem, it's the place and route that is a killer, as quite a few of the decisions made during the P+R process have global impacts.

A lot of the implementation stages are still poorly threaded so it does not map well onto highly parallel systems.

Distributed compilation is quite common in the software world, it would make sense in the hardware world. Not only do we have compilers that distribute the job to other computers on the network to do the work, there are tools such as Atlassian Bamboo that offload the entire build process.

As someone who as worked at a hardware company that provided software tools, the general mindset is generally very conservative and slow to change. Vivado using TCL is a simple example of that.

Rather than run the IDE on the cloud, maybe see if you can get the backend engine running there instead. I expect it would take quite a bit of hacking unless you can get Xilinx support to take you seriously.

No way to just upgrade CPUs instead of replace the entire computer?

It sounds like you have very little familiarity with the FPGA tools, they can be run as any other build process using make and integrate well with many of the established software development tools. You can have regression testing and builds being run automatically distributed across build farms, but not many projects reach those scales to warrant the investment.

My computer is not fast enough to run the Xilinx Vivado HLS toolset.

This means that I have to buy a new and more powerful computer.
Doing a rough calculation I would have to spend between 1000-1500 USD to get a decent setup that is future proof in the years to come.

But I was thinking about a different solution, given that we are 2016 now.
Can the Xilinx Vivado HLS toolset be run from the Cloud, still having access to USB, Ethernet and other necessary ports locally to connect my Xilinx target board (e.g. Xilinx Zybo FPGA board)?

The tools run well on very little resources, a virtual machine with just a few GB of ram allocated will happily build nontrivial systems in realistic amounts of time (less than an hour), running that natively instead on a bleeding edge CPU might only reduce the build time by half at best. CPU compute performance has come only a short distance in the past years so any computer from the last 5 years should be up to speed and anything from the last 10 will still run it ok if given a little more RAM:
http://www.tomshardware.com/reviews/The-500-Gaming-Machine,1147-9.html

If you're having long build times you'll want to drop back on the utilisation of the device (or move to a bigger device), and slow down the clock rates. Trying to eek out the last few percent can blow out build times by an order of magnitude only to discover that it wont meet timing. With long implementation times you have a big incentive to test and simulate the design, or when it needs debugging in hardware make only the part of the system that needs to be worked on. This goes into classic engineering trade-offs, you can easily complete the project with a larger or faster device competing against the cost savings of making the design fit into a smaller device. For low volume work its usually biased towards just buying larger devices, having an FPGA at 30% utilisation (even some of the resource types at 0%!) is not failure its just being pragmatic.

Finally Xilinx have very simple licensing setups, and they offer great support and options for it. Tying any of it to an online requirement would make me very unhappy, as the tools evolve so rapidly you often need to have legacy versions running to support particular designs or IP. As it is now they can just sit on legacy hardware or in virtual machines with no need to have them exposed to the internet.

[dferyance]

It sounds like you have very little familiarity with the FPGA tools, they can be run as any other build process using make and integrate well with many of the established software development tools. You can have regression testing and builds being run automatically distributed across build farms, but not many projects reach those scales to warrant the investment.

That is good to hear. The only job I had that included FPGAs, the designers not only built everything on their PCs but didn't use version control or bug tracking or much of anything. They just simulated the design and zipped up all the files and placed them on a network share. It renews my confidence to know there are people doing it better than that.

[pacikk]

Hi,

regarding to what dferyance said "Rather than run the IDE on the cloud, maybe see if you can get the backend engine running there instead. I expect it would take quite a bit of hacking unless you can get Xilinx support to take you seriously." it's indeed possible.

Take a look at Appendix A, page 116 of this Xilinx document: http://www.xilinx.com/support/documentation/sw_manuals/xilinx2013_3/ug904-vivado-implementation.pdf
There's an explanation on how to launch runs on remote linux hosts, which could hopefully be run in the cloud.

Regards,
Patrick

[mikeselectricstuff]

My computer is not fast enough to run the Xilinx Vivado HLS toolset.

What do you mean by "fast enough" ?
Presumably you mean not fast enough to compile in what you consider a reasonable time.
FPGA place/route has always been hugely CPU intensive, so you may find that even on the fastest turbo-nutter system, as your design gets bigger it's still "too slow".

ISTR that when Xilinx first launched a free tool, it was web based (possibly the origin of the "webpack" name for ISE).
 
FPGA place/route would seem to be a prime candidate for cloud/remote implementation, as the amount of input & output data is very small, and interaction is minimal. Unfortunately as mentioned it's not very amenable to being done in parallel.

The problem is the FPGA vendors really don't care about customers who can't afford to spend a few K on the latest hardware, as they aren't going to be buying lots of expensive parts.

I think the most pragmatic solution is to have another project to be working on while you're waiting for compilation....
 

[Kilrah]

Yep, are you sure your PC actually isn't powerful enough?

The lack of performance is in the tools, as others pointed out part of it is in the fact that the processes of this particular design flow are very sequential by nature but even for those that aren't Vivado will make no attempt to parallelize anything from what I can see.
Source generation is done sequentially instead of treating each block concurrently, same for synthesis, etc.

Also I can't seem not to think a lot or most actually comes from Vivado being a bloated thing built on top of who knows how many layers of excessively heavy frameworks, as is shown by the appalling performance of each and every operation you do in it regardless of machine. Come on, it shouldn't take 10 seconds just to open a block diagram on an I7...
Given that nowadays most of PC "potential performance" is achieved by adding more cores, and Vivado will only use one or 2 at best you could very well upgrade to the latest and greatest and see virtually no difference.

Let's have a little benchmark, how long does it take you to do the whole thing i.e. generate bitstream from a fresh download of Digilent's reference zybo base system?