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?