02-14-2019 07:10 AM - edited 02-15-2019 01:19 AM
I use vivado 2018.3, on a ZCU102 board.
Following regression from my previous version 2017.2 to 2018.3, i decided to build a basic block design, with a Zynq, a reset system, an AXI interconnect, an axi BRAM controller and a BRAM.
While running the BRAM synthesis, I always faced the following problem, here is the BRAM OOC log:
source design_1_blk_mem_gen_0_0.tcl -notrace
INFO: [IP_Flow 19-234] Refreshing IP repositories
INFO: [IP_Flow 19-1700] Loaded user IP repository '/home/slabussiere/svn/base/'.
INFO: [IP_Flow 19-2313] Loaded Vivado IP repository '/CAO/XILINX/VIVADO2018.3/Vivado/2018.3/data/ip'.
update_ip_catalog: Time (s): cpu = 00:00:03 ; elapsed = 00:00:09 . Memory (MB): peak = 1455.285 ; gain = 0.000 ; free physical = 5951 ; free virtual = 85146
WARNING: [Vivado 12-818] No files matched '/home/slabussiere/svn/base/fpga/vivado2018test/project_1/project_1.srcs/sources_1/bd/design_1/ip/design_1_blk_mem_gen_0_0/design_1_blk_mem_gen_0_0_ooc.xdc'
ERROR: [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.
INFO: [Common 17-206] Exiting Vivado at Thu Feb 14 15:55:27 2019...
I didn't understand why vivado doesn't find the .xdc file, it is auto generated and it exists in the directory...
Anyone have an idea how to solve this problem ?
Thanks a lot
02-14-2019 01:25 PM
I'm having the same problem, I have no clue to what property they are talking about but it seems specific to the block memory generator, hopefully the more peoples talk about it the higher the chances xilinx will actually answer
02-15-2019 01:18 AM
in fact, for the OoC synthesis, vivado execute the .tcl script of the block. In my case for the BRAM, the script is:
In this .tcl script, you have the following line that fails:
set_property used_in_implementation false [get_files -all vivado2018test/project_1/project_1.srcs/sources_1/bd/design_1/ip/design_1_blk_mem_gen_0_0/design_1_blk_mem_gen_0_0_ooc.xdc]
my interpretation is that it looks for the file design_1_blk_mem_gen_0_0_ooc.xdc and try to set the property "used_in_implementation" for this file.
This line fails because vivado doen't find the file (while it exists in my case) and then the set_property command is applyed to an empty list, which makes the command fails.
If Xilinx members could have a look at this problem, it would be great.
02-15-2019 03:58 PM
I have the same problem not only with the bram IP, but also with xadc.
in the file
I find the line
set_property used_in_implementation false [get_files -all /home/Projects/ADC2USB/ADC2USB.srcs/sources_1/ip/xadc_wiz_0_4/xadc_wiz_0_ooc.xdc]
which causes the error.
But the file
got written correctly during IP creation.
02-16-2019 05:59 AM - edited 02-16-2019 06:02 AM
I have exactly the same Problem with the BRAM Generator. I want to generate a 576 bit wide (72*8) and 512 word deep memory. It fails with exactly the same error message. When I reduce the width to 256 (72*4 + rest) it works, but 288 (72*4) it does not. The project is new andy completely empty except for a main vhdl with an empty entity/architecture.
Edit: I am using Vivado 2018.3 (64-bit, build 2405991, IP build 2404404) on Ubutu 18.04.
02-16-2019 07:43 AM
Unfortunately the only solution, while waiting for xilinx to respond (I'm not holding my breath, and I would be surprised if they did without someone with a payed license asking or sending a ticket) I found was to downgrade to vivado 2018.2, there I have no problems whatsoever
02-16-2019 07:47 AM
I also tried this on a 2018.2 on a Windows machine, but had the same issue. Maybe I am doing something really stupid wrong. I just started doing FPGA stuff, after doing it just a bit like 10 yeas ago.
I also tested some more combinations of width and depth of my memory, and all other combinations I tried also failed.
02-16-2019 05:04 PM
While sitting in front of the TV, is created the IP for an A7-35T and regulary tried the combination of "Reset Output Products" followed by "Generate Output Products".
The result: for 100 tries I got three times success. So the error is a bit non deterministic. This is the same for BRAM and XADC for me. (nice to know, but 3% success probability is nothing to work with)
I am using Vivado 2018.3 with SuSE Linux Leap 15 on two systems: one is a notebook with 4 cores i7 and 16 GB, the other is a XEON server with 40 cores and 512 GB showing the same result. I was using ISE 14.7 for S6 designs on the same machines before.
The Download for Vivado 2018.2 is currently in progress. I will try the downgrade tomorrow and report.
02-17-2019 09:01 AM
I downgraded to 2018.2 today and made several tries without any problems. I used the 2018.2 Version without the updates, as the devices I currently want to use are already covered.
So this is a doable workaround for me at this moment.
I still have version 2018.3 installed on an additional system, so I am ready to test any suggestions. I hope that the bugfix comes soon with 2019.1
I wish you all a fine day.
02-17-2019 09:05 AM - edited 02-17-2019 09:09 AM
Thats strange. Maybe its because of the updates.
I also found a workaround for my case by not using the IP core generator to create block memory, but instead writing directly in VHDL. Works like a charm and is even more flexible.
Edit: I attached the source, maybe it also can help the one who asked the question. It is primarily copied from rams_sp_rf.vhd, but expanded to support variable width/depth.
02-18-2019 12:38 AM
that is a good solution. Thank you for sharing the code.
It only has two minor drawbacks:
1st: the implementation is not be done out of context which needs more time during the implementation of the whole design
2nd: if the IP core changes with a new version of Vivado, the code will not be updated automatically to the new syntax.
But both is acceptable for small designs.
02-18-2019 12:45 AM
Thanks Fabian for your code, but in my case, the BRAM is for use in the Vivado Block Design, connected to the interconnect and a BRAM controller.
I confess that I have no wish to package an IP for just a memory, it is the role of vivado do to it (and correctly will be better !)
However it seems that many person have the problem, so waiting for a response from Xilinx guys asap.
02-21-2019 02:55 PM
I do have the same problem with the synthesys of a Block Ram Generator. I am using ubuntu and Vivado 2018.3
02-21-2019 03:48 PM
at this moment the only solution I found was: downgrading to 2018.2 WITHOUT the updates.
Let us hopte that 2019.1 will fix this bug.
03-07-2019 11:35 PM
On my system (Ubuntu 18.04.2, LANG=de_DE.UTF-8) it helped to export LANG=en_US before running Vivado.
03-08-2019 12:09 AM
that sounds very promising. I am also located in Germany, so I have the same LANG=de_DE.utf8 environment variable as defailt.
It would be easy to put the "export LANG=en_US" into a small startup script. I already hat to put a
into the startup script in oder to get the simulation running. Vivado were not able to work with the system wide libncurses library, but provides its own one.
As I am currently working with Vivado today, I can not change the "running team" right now. I will see, if I find some time during the weekend, but latest next week and then report the result.
Have a fine day
03-09-2019 12:28 PM
I can confirm that with "export LANG=en_US"works correct with out of contents IP generation. I tried about 20 time different IPs.
I still have to "export LD_LIBRARY_PATH=/tools/./Xilinx/Vivado/2018.3/lnx64/tools/gdb_v7_2/" in order to get simulation running.
That is a good workaround for me at this moment.
03-28-2019 03:07 AM
03-28-2019 03:16 AM - edited 03-28-2019 04:55 AM
Did you generate the en_US locales before starting Vivado (locale-gen en_US)?