UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Explorer
Explorer
5,658 Views
Registered: ‎09-26-2014

Why Xilinx programs work very slowly?

This understood in Xilinx? To do something to improve the software?

The slogan - "Multiply Productivity"  sounds mockingly.

0 Kudos
2 Replies
Xilinx Employee
Xilinx Employee
5,550 Views
Registered: ‎06-14-2012

Re: Why Xilinx programs work very slowly?

@jack1977 Do you have concerns on any specific tool or process? Please let us know.

I will be glad to take this up and investigate for you.

 

I will be looking forward to your response.

 

Regards

Sikta

0 Kudos
Scholar u4223374
Scholar
5,491 Views
Registered: ‎04-26-2015

Re: Why Xilinx programs work very slowly?

The Vivado GUI can be painfully slow at times (eg. asking it to connect all the clock pins on a complex project can be "time to go and get a coffee while Vivado considers this extremely difficult problem") but the underlying tools (synthesis, implementation, etc) are pretty quick considering the amount of work they do.

 

If you're comparing it to a C compiler, then the reason the Xilinx tools are so slow is because they're doing a completely different task. It may look vaguely similar (ie you write a bunch of code, hit "build", and the tools give you 400 pages of largely incomprehensible text followed by a useful output file) but that has nothing to do with the underlying processes being the same.

 

Unfortunately many of the tasks needed for FPGA implementation are really difficult. If I remember correctly the place-and-route step is an NP-hard problem, which means that until we get quantum computers working well it'll remain impractical to do optimal place-and-route for non-trivial designs. The best we can do is a sub-optimal approximation, which may occupy a lot of time (hours for all those "rip up and re-route" steps in heavily-congested designs) but is still a lot quicker than a true optimal version.

0 Kudos