cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
2,222 Views
Registered: ‎10-07-2016

Vivado 2019.x Hardware Manager GUI very slow.

Collogues and I noticed that the Hardware Manager GUI to capture ILA waveform is now very slow to react to mouse clocks and commands.

You select a signal, and will take several seconds before it highlights, same for zoom, resize, run, … very annoying.

This started with Vivado 2019.1, I am using it in Windows 10, and we tried in different systems, same problem.

I also noticed that the *.ltx file format did change, used to be in XML, so my guess is that a lot was changed from 2018.x versions.

Anybody else is experiencing the same?

16 Replies
Highlighted
Newbie
Newbie
2,072 Views
Registered: ‎08-29-2018

I also suffer from this problem.

It's too slow.

 

Plz. Fix this bug.

 

------------------------

Windows 7 64bit

Xeon E5-2620 / 80GB RAM

Highlighted
Observer
Observer
2,025 Views
Registered: ‎12-04-2014

I second this, it is really a pain to work with...

BTW: I have other ILA usability issues, e.g.:
- capture waveforms disappear when the target is powered down
- when you start a compilation, you cannot restart the hardware manager, because the .ltx files are deleted at the start of a compilation

Regards,

Thomas

Highlighted
Visitor
Visitor
1,647 Views
Registered: ‎07-31-2018

Same here

Win10, 6820HQ + 16GB DDR4.

Thought of making any change inside waveform widget is terrifying

Problem is really annoying and takes time of analysis from tens of sec.onds to more than few minutes.

 

edit: @tentner true, just triggering all logic analyzers before interaction helps a bit

 

0 Kudos
Highlighted
Observer
Observer
1,642 Views
Registered: ‎12-04-2014

In the meantime I found out that the worst case is when there is no waveform captured at all.
Therefore I always click ">>" first to make an immediate capture - than the GUI appears to be more responsive.
(But still the whole user interface of Vivado feels very slow, a click here, wait 10 seconds, then a click there, wait another 10 seconds,... When I work on older projects with Quartus, especially SignalTap, it is such a contrast...)
Highlighted
Observer
Observer
1,605 Views
Registered: ‎10-07-2016

Providing an update on this issue, I had a skype conference call with Xilinx and they were able to verify the problem and narrow down the area where to fix. They opened the Change Request CR-1057087 and requested it to be resolved in Vivado 2020.1.

 

 

Highlighted
Observer
Observer
1,238 Views
Registered: ‎08-31-2016

Greetings, 

I am still experiencing the same issue now that I've upgraded to Vivado 2020.1. 

Anybody else?

 

0 Kudos
Highlighted
Moderator
Moderator
1,162 Views
Registered: ‎06-14-2010

Hello @scott.powell ,

Would you be able to provide us with a test case what we can use to reproduce this problem at our end? It's not possible for us to fix or even diagnose the issue until we can reproduce it. So far, we can't reproduce this behaviour in house.

Therefore, can you please share a test case and the exact steps that we need to follow to be able to reproduce this behaviour? 

You can send the above to me directly via email. It is my_username you see in the post and just add "at xilinx.com'. 

Thanks in advance.

Kind Regards,
Anatoli Curran,
Xilinx Technical Support
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Observer
Observer
1,131 Views
Registered: ‎10-07-2016

I already had a Skype session with Xilinx developers months back and they were able to see the issue, see CR-1057087 or SR 10483626, "Hardware Manager in Vivado 2019.2, ILA not responsive to mouse control"

0 Kudos
Highlighted
Moderator
Moderator
1,114 Views
Registered: ‎06-14-2010

Hello @cm16xilinx ,

Thanks for letting me know.

The problem is, this behaviour isn’t reproducible with smaller test cases, so it seems like it is happening with larger specific projects only. That is the reason I’ve asked to see if it would be possible to zip up the reproducible design and share this with us, so that we can use it at our end and try to reproduce this issue in house.

You see, from our side since the Development team can’t reproduce this behaviour, they can’t create a patch as it's not possible for us/them to fix something or even diagnose the issue until we can reproduce it. They have access to the videos of this behaviour (i.e. the ones that another Product Application Engineer has recorded from other users with the same issue (I believe one of the videos were recorded with the Webex meeting you had with PAE?)). However the Xilinx Development team can’t reproduce this behaviour with a smaller test case.

The good news is, based on other users feedback, the issue is seen only while using the GUI to program and setup the ILA. This delay does not happen when TCL commands are used instead, to interact with the ILA core, and it only occurs when interacting with the cores through the GUI.

Attached, you can find the script with the list of commands which are used instead of the GUI flow, to program and setup the ILA.

You’d need to modify these commands according to your device and design. These commands are usually issued when using the GUI.

We have seen users seeing much better output when using TCL commands instead, to interact with the ILA core.

Can you please give this a try and see if you see a better outcome that way?

Kind Regards,
Anatoli Curran,
Xilinx Technical Support
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Observer
Observer
1,080 Views
Registered: ‎10-07-2016

Hi Anatoli,
The commands you sent me is to start the ILA and loading the bit and ltx, I do not have a problem with that, even if faster would be better.
The issue that concerns me is the GUI slow in responding when interacting with the waveforms, Zoom, Pan, adding, moving, organizing and grouping the signals and so on.
Yes my designs are big and the ILA includes many signals and busses totaling several 100's.
I cannot provide the design easily, company rules, and also it may not be useful sending you the bit and ltx file as they would work on the specific FPGA and HW I am using, I am sure that there at Xilinx you can get a big design with some of your eval boards, that should do.
P.S. 2018.X did not have this problem.

Carlo

Tags (1)
0 Kudos
Highlighted
Adventurer
Adventurer
883 Views
Registered: ‎10-19-2012

Any update to this issue?  I had been on 2018.2 with no problems.  I had to upgrade to 2019.2 as part of a new project I'm on.  I'm running the Lab Edition 2019.2 to interact with my chipscope core, and as others have mentioned, it's unbearably slow.

0 Kudos
Highlighted
Visitor
Visitor
843 Views
Registered: ‎06-02-2015

Hi Anatoli;

This is Shahin from IAI. I had the same issue, and as tentner suggested I tried Run Trigger Immediately. Now the CUI is more responsive. I also should mention that when you have a larger number of signals on the probe this will happen. I hope this info helps you to resolve this issue.

Highlighted
Moderator
Moderator
784 Views
Registered: ‎06-14-2010

Hello @shahinsl and other users on this thread,

We are still working on this matter, as we have tried to reproduce the issue in house, with no success.
In your case, do you see this behaviour with one of the Xilinx Evaluation boards or is it on a custom board?
The problem is, this behaviour isn’t reproducible with a smaller test cases, so it is happening with larger specific projects only.
If this is reproducible on a Xilinx Eval board, what exact eval board is in your case?
If this is a custom board in your case, do you have a very basic design (something like a simple counter or something similar) that will reproduce this behaviour on your hardware?


You see, from our side since the Development team can’t reproduce this behaviour, they can’t create a patch for e.g. Vivado 2019.x or 2020.1, or even to be able to fix this in the newer version of Vivado, as it's not possible for us to fix something or even diagnose the issue until we can reproduce it in house.
We have access to the videos of this behaviour from other users (thanks @cm16xilinx) with this delayed issue, however the Xilinx Development team can’t reproduce this behaviour with a smaller test case on a Xilinx board.

If this is happening to you on one of the Xilinx Evaluation board, would it be possible for you to zip up your reproducible test design and share this with us, so that we can use it at our end and try to reproduce this issue in house, using the same eval board that is used in your case?

Lastly, in the notes it has been mentioned that in 2018.2 this wasn't an issue. 
You see, with 2018.2 or earlier versions of Vivado, Vivado tools come with Java 8. However, we have upgraded Java to version 9 from Vivado 2018.3 onwards. So, from Vivado 2018.3 and newer releases, Vivado uses and comes with Java version 9. And it will look for the Java version from within its own installer (e.g. /Xilinx/Vivado/2019.x/tps/lin/jre/).
Perhaps this could be somehow a Java related issue, as this behaviour is seen with the GUI, which uses Java?
Again, this is just my assumption and can't be concluded as a root cause until we can reproduce this at our end. I just wanted to share this info with you, since you've indicated that this issue wasn't there with 2018.2.

FYI - Vivado GUI based products (Vivado, Labtools, etc.) have been migrated to Java 11 with 2020.2 release.

It would be good if we can identify (with your help please) an actual root cause of this issue, as this is also happening to other users, but we can't reproduce this at our end,so can't fix this or create a patch.

We really appreciate your help on this matter.

Thanks in advance and have a nice day.

Kind Regards,
Anatoli Curran,
Xilinx Technical Support
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Adventurer
Adventurer
756 Views
Registered: ‎10-19-2012

I'm not able to send my design, but for your other questions...

- I'm using the ZCU102 eval kit

- I have a single ILA with 300 probes.  I have about 150 of those probes connected to signals, the others are just 1'b0

- I too found that if I do an instant trigger, that after that point the speed returns to normal

- I'm running the 2019.2 version of Vivado lab tools in Windows; I built my design using 2019.2.1 in Linux.

0 Kudos
Highlighted
Observer
Observer
532 Views
Registered: ‎08-04-2008

I am having this same problem on a 30% full Zynq020 with a couple dozen probes. Win10, Vivado19.1. When it gets super sluggish, I find if I delete all the probes then add them back it seems to fix the sluggishness somewhat.

I also noticed the probe names start out with just their leaf names when you add them, but after a capture or when you click pretty much anything, they turn into long pathnames with the leafs not even visible. I have to make the name area very wide to see them.

0 Kudos
Highlighted
Observer
Observer
527 Views
Registered: ‎12-04-2014

Have you seen my tip above with the ">>" (Run trigger immediate) button? When I press this as the first thing I do in the ILA, things appear to get a bit more responsive, too.

0 Kudos