11-21-2019 04:04 PM - edited 12-02-2020 07:15 PM
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?
Good news, latest release 2020.2 fixed this issue, you can use Lab edition too.
01-19-2020 02:47 AM
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
04-01-2020 02:40 AM - edited 04-01-2020 02:51 AM
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
04-01-2020 02:47 AM
04-02-2020 11:36 AM
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.
06-16-2020 07:49 AM
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.
06-16-2020 11:50 PM
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"
06-17-2020 05:06 AM
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?
06-19-2020 03:19 PM
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.
07-07-2020 05:47 AM
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.
07-08-2020 09:17 AM
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.
07-15-2020 05:32 AM
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.
07-16-2020 04:02 AM
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.
08-11-2020 12:04 PM
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.
08-11-2020 12:16 PM
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.
10-08-2020 12:15 AM
I am facing the same behavior.
I am running a huge design on xc7v2000 with multiple ILAs. This was no problem up to Vivado 2018.
Now I am working with 2019.2. Nearly every mouseclick causes a couple of seconds to react.
it's a I7core 8th generation with 32GB with win10. In common a fast machine.
10-29-2020 01:44 AM - edited 10-29-2020 01:45 AM
Having same issue with Vivado 2019.2 running on W10.
Processor Intel Xeon 2.2GHz, 10 Cores, 16 GB RAM.
System connected to two ZCU106 boards.
On Ubuntu 18.04.2 I do not have this issue.