09-26-2019 02:59 PM - edited 09-27-2019 09:33 AM
Running into an issue with opening projects in Vivado 2018.2. One of the IP cores I am using takes 15 minutes to get through the "Registering IP" part of opening a project. I've regenerated the core from just an XCI file, but nothing seems to help. I even regenerated the whole project from just the XPR file because that has fixed the odd corruption in the past. The core is a 10G/25G Ethernet Subsystem, version 2.4.
It was really bad today because I had a bug somewhere that would cause Vivado to just shut off with no error message or indicator, so I had to keep reloading the project with a 15 minute wait each time as I tried to find the bug.
Using a different version of Vivado is not an option at this time, and I'm stuck using this core as it is. Other people using the same core do not experience this issue. Tried different Linux machines. Nothing helps. It just seems to not like me. :-\
09-27-2019 01:49 AM - edited 09-27-2019 01:49 AM
Hi @mjholmes99 ,
As you have mentioned 'Other people using the same core do not experience this issue', in that case, this seems to be dependent on your design.
Have you tried checking if same issue shows up even when you try to reload example design for 10G/25G Ethernet Subsystem?
09-27-2019 08:56 AM - edited 09-27-2019 08:57 AM
If I add the core to a fresh project, it gets through the open project process quickly. I dug around more and found others who have experienced this hanging of the "registering ip" process on random cores here and there. It's a core we share in a repo, so I don't have the example design. I could try to regenerate that.
My design compiles and works in hardware. That tells me my code and the core are both fine. That's why I'm looking for some transparency into what the registering ip process is doing. If it's just looking at each IP to see everything is where it needs to be, my surrounding code should not affect that process. Or if it is, then how? It just hangs without any feedback to work with. Nothing in any log file I can find. Where's the hidden variable?
09-27-2019 09:25 AM - edited 09-27-2019 09:32 AM
I appear to have fixed it, but I'm not sure why.
It was taking longer to open the project this morning, so I opened the XPR file in a text editor and nuked the entry for the IP core. Project opens fine and squawks that the core is missing because there's OOC runs. I re-add the core, and now the project opens fine. It zips right through the registering process.
I did a delete and reimport of the core previously from within Vivado and that didn't work. No idea why editing the project XML would do anything different.
Is it bad form to accept my own solution if I don't know why it worked? :)
09-30-2019 01:52 PM
And it's happening again. :( I had a couple quick project opens Friday after doing the "fix" described above, and generated a successful BIT file. Got in this morning, opened the project, and it's hung registering that same 10 GbE core again. Ten minutes and counting as I type this.
I don't know how to fix this. I have zero visibility into what Vivado is doing during that long pause. Something happens after the core is imported into the project and the design is run through at least synthesis. After that, it hangs for a long time when "registering" at opening the project. It's almost like it's regenerating the core and its various files everytime the project opens.
11-04-2019 09:57 AM
I'm seeing the same issue with 2018.2. It's extremely frustrating. As far as I can tell vivado is using no CPU, and I have massive memory and IO bandwidth on all our machines, not that any of it appears to be used while this lengthy delay is occuring.
Xilinx folks, has a resolution to this problem been found? Is vivado calling home via webtalk by any chance?
11-19-2019 07:40 AM
I have noticed that the console output gives me the following syslogd message:
kernel:NMI watch: BUG: soft lockup - CPU# stuck for 22s! [vivado: ######]
Any ideas? This is really hurting me - it happens every time I try to load the project.
11-25-2019 11:26 AM
Similarly at the start of both synthesis and implementation there's a prolonged delay where nothing appears to be happening for about 30 minutes...so an hour total.
This is what was in the implementation log window. First an 11m 14sec delay while add_files was executed, then the 20 or so minute delay with this displayed.
No implementation logfile updates occur until about 20 minutes later when I finally see:
Command: link_design -top ourprojectgoeshere -part xcvu9p-flga2104-2L-e
Any help appreciated. There's only so many hours in the day.
01-10-2020 02:05 PM
The same thing happened to me (and many people in our lab.) It was fine 30 minutes ago, and suddenly no one can open the Vivado project because it is stuck at "Registering IP".
01-11-2020 10:33 PM
Sounds like an issue for sure but we can't fix old versions of the tool. Can you not use the core container? That would the XCIX. Then there is no need to regeneratre anything. The whole IP is available. I know some people have an issue with core container because it is a binary file. But you can pull the XCI out of the core container. That makes it quite a bit easier to use core container because you have a text representation of your binary XCIX file.
You do this with the following command: set_property coreContainer.alwaysCreateXCI 1 [current_project]
Then you have a bit easier way to check in an IP into revision control. It is 2 files. A text based settings file that shows what your IP looks like. And a binary file that has all the guts of your IP which saves lots of time on generation and implementation.
01-20-2020 11:37 AM
Core containers have multiple problems, not the least is when the tools modify the file without explicit user intervention, resulting in merge conflicts in a binary file when we have many people working on a project.
Also, it's unclear that core containers will solve this problem. The IP is already generated, I can see numerous cached files sitting in folders created by the tools that match the IP names. This problem occurs when opening an already built project, and I don't see any IP generation occuring on the CPU during that time.
The message preceding the lengthy delay is "Registering IP", not "regenerating IP".
Is this issue fixed in the most recent version of Vivado?
01-20-2020 08:02 PM
Using the XCI outside of the XCIX helps a bit in that you can track differences of the core with just the XCI (text file), but yes you must check in the bulky XCIX with it.
Benefits in this way is that you can track changes, you have an ability to upgrade Vivado without forcing an uprade of the IP (that is the biggest benefit and often biggest problem people face with checking in minimal files for IP).
I know it is not a perfect solution all around but it does solve some big revision control challenges.
03-02-2020 01:46 AM
here it's solved by removing double-entry of licence for the same module.
"xxv_eth_mac_pcs" check whether it's presently more than 1 in the licence manager.
if its more than one time just remove that entry in the licence file and restart the licence manager(licence Server side).
03-02-2020 07:40 PM
I have the same issue when opening a project: it sits there "registering IP" for many minutes. This is with 2019.2, the core that it's waiting on is the MIPI core.
Xilinx: could you please answer the question: what exactly is it trying to do when it's "registering" the IP?
I have tried removing duplicate licenses etc and nothing seems to change. It's impossible to find what is causing the issue if we don't know what is causing it!
03-03-2020 09:11 AM
@peterw_cuvos In general, registering IP should be fast. If there is a lot of design runs, Vivado spends a lot of time looking into the various run directories for status on IP runs. I am curious if you clean out your run directory what happens.
If you see a long time on registering IP without a run directory . . . I would say that is a bug worth looking at. But we would need a test case to reproduce and work on.
03-09-2020 03:04 AM