02-11-2019 06:56 AM
Host OS: Replicated under Ubuntu Linux 16.04.4 x64-bit, Ubuntu Linux 18.04.2 x64-bit
Vivado Version: v2018.3 (SW Build 2405991, IP Build 2404404)
TRD Bundle: rdf0428-zcu106-vcu-trd-2018-3.zip (MD5SUM: 7b704ca012ed0e0f5656eed655fa40e7)
I'm unable to build the v2018.3 VCU TRD design using the vcu_trd_proj.tcl script included in the TRD bundle, seeing the same timing problems under both Ubuntu 16.04.4 and 18.04.2 with the implemented design. I have not made any modifications to the provided TRD bundle. I'm able to successfully build all other design modules in the TRD.
Is anyone else seeing this? I'm unsure how to go about resolving this issue, so any help you can provide is appreciated.
Logs and timing report are attached.
Thanks in advance,
02-13-2019 05:46 AM
I tried to generate the design and I am not getting any timing violation:
With that said, if I do a report of the Timing after synthesis, I get a lot of timing violations (both hold and setup).
You might want to check the Strategy for the implementation and make sure Performance_ExtraTimingOpt is selected:
But even if we have the same settings it can still be machine/runs dependant.
If you have this setting, you can try to re-run implementation, you might get different results.
02-13-2019 03:37 PM - edited 02-13-2019 03:39 PM
I spent a few hours today setting up a clean OS install with Ubuntu 16.04.4 and Vivado 2018.3. I downloaded the TRD bundle and kicked off a build of the top-level project with the vcu_trd_proj.tcl script. I verified that the implementation strategy is the same as you mention below (this is setup by the tcl script).
Again, I get the exact same timing problems (same error message, same affected Paths 21-30 on clk_out2_vcu_trd_clk_wiz_1_0] that I reported earlier on the first pass for implemetation. I attempted to re-run implementation and had the same exact results.
I can build all the other design modules without issue on this same setup.
This prevents me from exporting the hardware definition with bitstream - where do I go from here?
Thanks in advance,
02-14-2019 12:41 AM
I sent you a link to our EZmove platform. Could you send you full vivado project?
In the meantime, you can use the pre-built hdf file:
02-14-2019 10:22 AM
The pre-built HDF works but we're trying to use this as a starting point for a demo and need to be able to modify and re-generate the design. We want some degree of confidence in the top level design - as none of the other design modules exhibit these timing errors.
02-15-2019 05:39 AM
Thank you for sharing your project. I will try to investigate with the team who built it.
Note that I am not sure about the expectation to set here. The TRD is mainly here to show what is possible to do. The vivado design might be here more for reference (note that it meets timing in my case, so it should also be the case in the bitstream inside the pre-built hdf).
The other design are not showing any error because the device is less full. This is easier to meet timing ;)
02-19-2019 06:19 AM
Some updates over the long weekend. I was able to do a clean install under Ubuntu 18.04.2 64-bit and was successful building the top-level project (vcu_trd_proj.tcl) without errors on the same machine.
I then went and rolled back to 16.04.4 64-bit and the errors return, so it seems related to Ubuntu 16.04.x specifically and not my machine.
I've been reading a lot of forum posts regarding glibc issues in previous verisons of Vivado under Ubuntu 16.04.x on newer core-i7 based machines and wondering if there isn't something else lingering that's a problem here.
The problem with moving to 18.04.x is that there are compatibility issues with glibc and Yocto/Petalinux.
How extensive is compatibility testing with Vivado and the listed, supported versions of Ubuntu?
02-19-2019 06:26 AM
02-19-2019 07:53 AM - edited 02-19-2019 07:55 AM
I'm aware of the version support list in your reference. Ubuntu 16.04.4 is specifically listed, which is what I'm having trouble with. I was hoping to get some additional insight into the level of testing and/or the configurations of these host OS's - a package list with versions perhaps?
When resolving Vivado dependencies in Ubuntu 16.04.4 using the perl script called out in AR # 66184, GLIBCXX_3.4.22 support is missing from the base Ubuntu 16.04.4 installation, so I'm curious how Xilinx resolved this dependency with the Vivado 2018.3 release under Ubuntu 16.04.4.
** /opt/Xilinx/Vivado/2018.3/lib/lnx64.o/librdi_common.so: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by /opt/Xilinx/Vivado/2018.3/lib/lnx64.o/librdi_common.so)
This may point to some other differences that just aren't documented...
I resolved this by pulling the latest libstdc++6 package from ppa:ubuntu-toolchain-r/test which adds support for GLIBCXX_3.4.22 (up to GLIBC_3.4.25) - maybe this differs from the Xilinx configuration of Ubuntu 16.04.4 for testing purposes?
02-19-2019 08:03 AM
Could you comment on the vivado support for Ubuntu?
02-21-2019 08:51 AM - edited 02-25-2019 08:48 AM
Florent / Anatoli,
Just to confirm that the issue indeed follows Ubuntu 16.04.4 and isn't related to natively running Linux on my machine, I setup a Virtualbox image with Ubuntu 16.04.4 and tested building the top level project vcu_trd_proj.tcl in this Virtual Machine on both a Windows 10 and Ubuntu 18.04.2 Host OS. This resulted in the exact same timing failures with the clk_out2_vcu_trd_clk_wiz_1_0 path that I initially reported.
To be clear, the failures occur in an Ubuntu 16.04.4 environment (both natively and as a Virtual Machine).
02-27-2019 03:29 AM
Hi @rjmoss ,
Discussing with the team which did the TRD I believe this is a testing issue as the design was only tested on few configuration (OS/Machine). I am working with them to have more validation for future versions.
03-01-2019 08:34 AM
Just to clear up confusion, were you able to build this on an Ubuntu 16.04.4 Host or were you building on a different host OS?
Thanks in advance,
03-01-2019 08:35 AM
03-05-2019 09:02 AM
Is there any way you can share the output of the following commands on your system?:
1. lsb_release -a
2. apt list --installed
I'd like to double-check and see if there are version differences that might be contributing to the issue.
03-05-2019 09:26 AM
Hi @rjmoss ,
Thank you for continuing investigating on this. I will share the details offline.
Note that I still believe the change should come from the design itself as there is lot of timing failure after synthesis. The repeatability of the result a guarantied only if you have exactly the same inputs:
If one change, as the OS, you might not get the same results and the timing might fails.