cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
hfbroady
Visitor
Visitor
9,480 Views
Registered: ‎12-18-2015

Vivado 2017.3 VERY slow!!!!

Jump to solution

I have noticed since I upgraded to 2017.3 from 2016.4. The application is VERY slow. When I switch between source files it takes about 2 to 6 sec before I can scroll or do anything in the open window. Also when I click program device that also takes a few seconds for the program window to pop-up. This is very annoying. I didn't have any of these issues with 2016.4. 

 

System:

Windows 7 pro

I have 22.3 GB free on HDD

 

Has anyone else experienced this?

 

 

Tags (1)
1 Solution

Accepted Solutions
prathikm
Moderator
Moderator
12,361 Views
Registered: ‎09-15-2016

Hi @hfbroady,

 

>> The application is VERY slow. When I switch between source files it takes about 2 to 6 sec before I can scroll or do anything in the open window.
This might be specific to your design/machine because it may not seem the same for others. Hence I am not sure on generic Vivado QoR but maybe a design specific or machine specific issue which needs more information to debug. Another idea is to try> run the same design and source editing (which is lagging) in a different machine and rule out the possibility of machine specific issue if the behavior seen is same. If you have a test-case to share with community, it becomes much easier on this note.

 

If this comes to design, as @watari suggested, we need to initially debug from memory w.ref to device, check utilization of resources, work on multiple threads etc. and so on. In the end if this is also questionable, then we have a reason to check QoR for 2017.3. This is just an abstract, we can have many good other ideas from community to debug such QoR issues.

 

--------------------------------------------------------------
Please mark the appropriate answer as "Accept as solution" if information provided is helpful.
Give 'Kudos' to a post which you think is useful and reply oriented.
--------------------------------------------------------------

View solution in original post

15 Replies
watari
Teacher
Teacher
9,449 Views
Registered: ‎06-16-2013

Hi @hfbroady

 

Generally, EDA tools request huge free memory, too.

How many size do you prepare DRAM ?

 

Thank you.

Best regards,

0 Kudos
hfbroady
Visitor
Visitor
9,438 Views
Registered: ‎12-18-2015
@watari I have 16GB of system RAM
0 Kudos
watari
Teacher
Teacher
9,423 Views
Registered: ‎06-16-2013

Hi @hfbroady

 

Could you change "Use core" value on your synthesis and implement flow ?

It may be useful that this setting depends on your environment (CPU core, cpu patch and your design) and quality of Vivado.

 

Thank you.

Best regards,

0 Kudos
hfbroady
Visitor
Visitor
9,420 Views
Registered: ‎12-18-2015

I can try. Not sure how that relates to text editing issues and moving from source file to source file.

 

How do I do that?

I will try and look it up in the mean time.

 

Thank you

0 Kudos
prathikm
Moderator
Moderator
12,362 Views
Registered: ‎09-15-2016

Hi @hfbroady,

 

>> The application is VERY slow. When I switch between source files it takes about 2 to 6 sec before I can scroll or do anything in the open window.
This might be specific to your design/machine because it may not seem the same for others. Hence I am not sure on generic Vivado QoR but maybe a design specific or machine specific issue which needs more information to debug. Another idea is to try> run the same design and source editing (which is lagging) in a different machine and rule out the possibility of machine specific issue if the behavior seen is same. If you have a test-case to share with community, it becomes much easier on this note.

 

If this comes to design, as @watari suggested, we need to initially debug from memory w.ref to device, check utilization of resources, work on multiple threads etc. and so on. In the end if this is also questionable, then we have a reason to check QoR for 2017.3. This is just an abstract, we can have many good other ideas from community to debug such QoR issues.

 

--------------------------------------------------------------
Please mark the appropriate answer as "Accept as solution" if information provided is helpful.
Give 'Kudos' to a post which you think is useful and reply oriented.
--------------------------------------------------------------

View solution in original post

hemangd
Moderator
Moderator
9,380 Views
Registered: ‎03-16-2017

Hi @hfbroady,

 

1. Can you apply a tcl command set_param general.maxThreads 8 and check whether it helps to overcome your issue or not? 

2.  If above point does not help it, try to delete .Xilinx directory from the User Home and reboot the system. (It will be found here C:\Users\hemangd\AppData\Roaming\Xilinx )

 

Regards,

hemangd

Regards,
hemangd

Don't forget to give kudos and mark it as accepted solution if your issue gets resolved.
0 Kudos
hfbroady
Visitor
Visitor
9,365 Views
Registered: ‎12-18-2015

Hi @prathikm 

    Thank you. I opened a different design I made using 2016.4, that has like 30 different modules. This design worked fine and showed no lag.

 

 

****Why is it that the design I have with 2 modules has so much lag?

  The design that is experiencing lag I'm using the Digilent Nexys 4 development board, with an Artix-7 FPGA

 

I'm going to create the project again and see if I still experience the same issues.

 

***Solution: I created an new project and that seamed to fix the problem. Still unsure why I had issues with the other project. Thanks again for the help!!

 

Thank you for your comments and suggestions.

 

0 Kudos
nschroer
Visitor
Visitor
8,398 Views
Registered: ‎10-12-2015

I have the same issue, switched from 2016.1 to 2017.3. Besides the optical changes which I don't like at all, the lag is unbearable. Progress bar is lagging from left to right, files (with ~100 lines) take seconds to open => I'm back with 2016.1 for now. When I have the time to migrate/create projects new as hfbrody suggested I'll give it another try (due to that horrible look I'm not looking forward to that though). 

0 Kudos
fransschreuder
Adventurer
Adventurer
7,405 Views
Registered: ‎08-12-2010

I am experiencing similar problems with recent vivado (2017.1 and later) versions on Linux.

* It takes a long time for the source tree to get updated

* After saving a file, the source tree is updating, then quickly pres synthesis, the command will fail because if an invalid top module (after the source is updated synthesis will work again).

* Synthesis in general takes a lot longer on 2017.4 than 2016.4. For an Artix7 200T design that took 45 minutes on 2016.4 it takes 1 hour and 25 minutes on 2017.4

 

0 Kudos
jack1977
Explorer
Explorer
5,886 Views
Registered: ‎09-26-2014

I join with every new veris, it becomes more slow.
Everything is slower the GUI. It is practically impossible to work.
Can it be enough to invent excuses? I can definitely say that GUI vivado is much worse and slower than ISE.
It's just impossible to listen, that it can be anything but VIVADO.

VIVADO - failed project. Can roll back to the ISE?

0 Kudos
kkoorndyk
Contributor
Contributor
5,863 Views
Registered: ‎02-12-2009

Keep in mind the memory requirements for the device you're targeting and the amount of FREE memory your system has.  

 

https://www.xilinx.com/products/design-tools/vivado/memory.html

 

Sure, you might have 16GB of RAM, but if 14GB is consumed by hundreds of browser tabs and other applications, that doesn't leave much for Vivado to use.  

 

DornerWorks
https://goo.gl/LNexn5



Xilinx Alliance Program - Premier Tier
0 Kudos
mckinjo4
Explorer
Explorer
5,610 Views
Registered: ‎05-22-2008

I'm having a similar problem with Vivado 2017.3. My machine has 64GB of RAM, 12 Cores.

 

I generated an FFT core and that got done, and then I clicked on the arrow to expand the hierarchy and it has literally been at least 5 minutes and it's still updating.

 

running HTOP,  there are at least 13 vivado processes and each sitting doing nothing most of the time. The total RAM in use by all executing processes is 5.00G.

 

I'm not synthesizing, implementing, or simulating. What is Going On?

0 Kudos
franzforstmayr
Contributor
Contributor
5,555 Views
Registered: ‎09-20-2017

I have the same issue on Vivado 2018.2.1, also with a lot fft cores in my design. I'm over ssh on the build server with 16 Cores and 256G RAM, so i don't think this should be a problem. When i only work with the GUI, changing some values or add blocks, vivado is awfully slow and needs about 20G RAM.

Please fix this xilinx!

0 Kudos
kbeld
Visitor
Visitor
5,023 Views
Registered: ‎10-22-2016

This is probably because of srcscanner. This process is a nightmare. It runs every time you change a file. Even if you only add a space to a file.

A new srcscanner is started with every change you make to your source code and it is not uncommon to have 4 or 5 processes running at the same time all doing the same thing and all using 100% cpu. When you do a synthesis the first thing Vivado runs is srcscanner. It just ran 4 already. Why run it again?

My design is pretty big and has an encrypted Verilog core. An hierarchy update takes anywhere between 5 to 10 minutes. And that happens with every file change.

It takes 5 minutes before the synthesis even starts. The whole build runs for about 75 minutes. 

Switching off the hierarchy update helps but srcscanner is still run every time a synthesis is started. 

I am using Vivado 2017.4. Xilinx please improve this because the Vivado GUI performance absolutely sucks if I can walk away from my desk, make tea, have a pee and it is still updating the hierarchy when I come back.

 

 

jack1977
Explorer
Explorer
4,580 Views
Registered: ‎09-26-2014

That's just terrible. I don’t even try the new versions, as the colleagues say they are just as slow.
Years passed, and Xalinx didn’t try to fix something. I can not normally work with this VIVADO.
I have a small project, but for some reason it slows down, and this is a discouragement to work with this product.

 

0 Kudos