11-17-2015 10:31 PM
I have some BRAM memory ip cores within a large custom RTL project that were generated using the using the Block Memory Generator in the IP Catalog. When I try to package up my project as a custom IP core, Vivado issues some critical warnings, but only for two of my BRAM ip cores. It claims that it is unable to constract an IP instance.
When I look at the File Groups section within IP packager, there are two *.xci's listed with a red slash through the icon. It seems that Vivado didn't grab these IP core xci files correctly. Hours of searching (literally) online and in these forums has yielded no quick fixes for my IP woes.
Some more details:
- When I create/package new IP, I do it in a separate directory (i.e., not the parent directory of the project)
- These ip cores use a .coe file with remaining entries set to hex 0. Fiddling with these settings has no effect.
- I have deleted IP generated files, removed them from the project, and recreated them with new block memory generator settings. Still no luck
- I have searched for "BLACK_BOX" attributes in the design - nothing would indicate that this shouldn't work.
- What is weird to me is that I have other BRAM generated ip cores with no issues.
- Kintex7 160T, Vivado 2015.3
- I generated output products and OOC synthesis in the parent project before packaging IP
- The original project using these ip cores was able to synth/implement just fine, which leads me to believe I am missing something in the packaging process.
- I am including .xci files when using the packaging wizard.
- IP packager finishes initializing the project, opens another Vivado window, and then the critical warnings window pops up in the parent project's window (Unable to construct an IP instance ... using VLNV:::.
- Vivado does seem to copy the xci file to the new packaged ip project src directory (I found sub folders there for each IP and I also found corresponding xci files)
- When I am in IP packager, I try to add an existing IP xci file to the project and it results in an error (Vivado is claiming that it cannot find an IP definition in the IP file, the file may be corrupt, and that the file does not contain an identifiable instance.)
Any help or ideas would be greatly appreciated!
11-18-2015 12:09 AM - edited 11-18-2015 12:13 AM
Does top level synthesis complete in the IP packager project?
Try disabling OOC synthesis of IP's and see if it makes any difference.
11-18-2015 05:01 PM
Running synthesis within the IP packager yields the following critical warnings/errors:
IP_Flow 19-3389 - failed to import IP file /some path/../*BRAM.xci: could not find IP definition in IP file. The ip file may be corrupt
Vivado 12-1503 - The IP file cannot be added to the fileset 'sources_1'. (same file as previous bullet)
Common 17-55 'set_property' expects at least one object. Resolution: If [get_<value>] was used to populate the object, check to make sure this command returns at least one valid object.
When I tried to disable the OOC synthesis of IP's, I followed UG 896 (for version 2015.3) pg 27 which describes how to set IPs for Global Synthesis in the gui. I was able to see that the "Generate Output Products" changed from no longer including a dcp to including RTL Sources; I also verified this by looking at the tcl command window and could see "set_property generate_synth_checkpoint false [get_files ..*.xci]. Unfortunately, this approach did not work - same errors as before.
As a side note, I have been meticulous about manually deleting any of the temporary project files in between attempts so that there is absolutely no risk of legacy errors from previous attempts. I am not sure if this is helping or hurting or inconsequential.
My latest attempt was to try packaging the ip with the “Include IP generated files” option. This had a slight bit more success. I didn’t see IP_Flow 19-3933 critical warnings; instead, I now have critical warnings (Vivado 12-1387) for all of my BRAM ip cores: “No valid object(s) found for create_clock constraint with option ‘-objects [get_ports clk*]’. Should I worry about these critical warnings? Synthesis and Implementation eventually finished, but with over 100 critical warnings. I typically saw zero or maybe 1 critical warning when building the project with the custom RTL.
Any ideas for best practices moving forward? Should i use the “Include *.xci” option instead of the “Include IP generated files” option? Ultimately, our repository/revision control method was meant to use .xci based custom ip cores only and I would like to move in that direction.
11-18-2015 05:22 PM
Can you double check that the *BRAM.xci files are not locked? In your project before packaging, tools->report->report ip status. I'm guessing it's not locked since you noted that you can change OOC status and synthesize fine.
Also, what version of vivado are you using?
Any chance you can attach one of the problematic XCI files to this post?
Lastly, try removing the xml file next to the xci file before packaging.
11-18-2015 06:01 PM
Hi @swolf & Deepika,
Thank you both for your patience in helping me work through this issue.
I am using Vivado 2015.3 on a linux CentOS7 machine.
I double checked that the BRAM ip cores are unlocked.
I tried removing the .xml files within the ip folders of the parent project and then tried to proceed with packaging the project as a standalong ip core. Unfortunately, this did not work and produced the same errors. But! ... I tried removing the .xml file from only one of the ip cores. I received the same type of error, but now I received it for a different BRAM ip core.
I did some more digging based on your request for a troublesome xci file. A diff of the xci in the parent project and the same xci in the pacakged temporary project revealed that one of my BRAM instances is, for lack of a better descriptor, copying itself into another BRAM xci file. Please see the attached xci files. The smaller file (~23kB) is from the parent project and the larger file is from the packaged temporary project (I renamed it).
I have started replacing these 'corrupt' files and seeing if the ip packager project will work now. It is a bit of a slow process, it seems, as some new critical warnings are generated for missing files. Thank you, however, for spurring the idea to dive deeper into the xci files. I will keep the issue open until I am sure I can resolve it.
11-19-2015 01:22 PM
Hi @swolf and Deepika,
Unfortunately, I was never able to edit BRAM ip cores within the ip packager successfully. I tried editing the troublesome .xci files directly - no luck. I also tried replacing the files via the command line, but refreshing the source files within the temporary project didn't seem to trigger any "Merge" updates from the file manager. Finally, I tried removing the ip cores and adding in new ones, either in directories I chose or by letting Vivado control where to put the ip cores. Still no luck.
One workaround, which I don't think I should have to do, is as follows:
Once I did it this way, it works (in that there are no more BRAM ip issues or IP_Flow critical warnings). Unfortunately, this process copies the parent project source RTL & xci files. Still not exactly what I want since the whole point of our revision control repository is to keep the source files separate from the custom ip cores directory. Both source and ip cores get checked in, but keeping them in separate directories seems like a best practice. I believe I can probably accomplish the revision control karma I desire by editing the component.xml file and putting in the correct relative paths (or absolute paths) within the repo for where the source files are located. If I do this, can I then remove the source files from the ip custom cores directory? Is there any way to package a custom ip core such that a relative file path is recorded so that I can package from a parent project into a separate directory?
12-06-2015 02:59 PM
I was using Vivado 2015.1 and it would randomly delete my .coe file. I upgraded to Vivado 2015.4 and synthsised my design a couple of times but today just got the "Unable to construct an IP instance ... using VLNV:::." critical warning which I am assuming is 2015.4's way of saying that the .coe file is missing again.
Just my two scents worth.
02-05-2016 03:33 AM
I am coming to the conclusion that the ip packager tool in Vivado 2015.2 is very buggy. We did a simple project for a
Digital Up Converter which contains 7 rational rate filters. The base project synthesizes without issue. However, the packaged version does not. The reason is because the packaging tool corrupts the xci files. For example in the non packaged file the ip filters are named fir_compiler_0 to fir_compiler_6 and all have xci files which are circa 24k in size. However, in the packaged location the xci size increases for each file by circa 24k. So fir_compiler_0 = 24k, fir_compiler_1 = 48k, fir_compiler_2 = 72 k and so on until fir_compiler_6 reaches a whopping 165k.
This is causing us real issues and delaying our projects. Has this issue been fixed in later versions? Do Xilinx regressive test their code because my experience suggests that they do not.
Slowed down due to buggy tools
08-20-2016 05:37 AM
I have the same problem in 2016.2. Moving some legacy code into Vivado 2016.2. Have 2 ROMs with coe files which have been created as New IP in separate directories. ROM1 and ROM2 are used in modules within my_rtl_top.v.
my_rtl_top.v will synth and implement correctly. Now I package my_rtl_top using "package my project". It opens up the temp editing project but when you look in the IP Sources, one of the ROMS is not there (crossed with a red) and of course later on when you use this package it gives trouble. Difference in the ROMS is that ROM1 is 1024 and ROM2 is 64. First wondered if IP Integrator cannot handle packaging LUT ROM. Both ROMS were created with Block Memory Generator.
So I made the small ROM big but that did not help. Once you go to package it, the second ROM (bigger now) came out as red.
Next tried the following a) Used ROM1 (which always worked) in place of ROM2 i.e. where it is instantiated. Remember, the address size was faked out to handle the big vs small ROM story.
b) used ROM2 in place of ROM1.
Both these experiments worked i.e. when you package it, there are no missing (red) ip.
Is it possible, that Vivado 16.2 can only handle one ROM at a time when you are packaging the IP for use elsewhere. Note, my_rtl_top.v along with the entire project will work fine with both the ROMs (two sizes). It is when you go to package it for use elsewhere.