Package Details: vivado 2021.1-3

Git Clone URL: (read-only, click to copy)
Package Base: vivado
Description: FPGA/CPLD design suite for Xilinx devices
Upstream URL:
Licenses: custom
Submitter: xiretza
Maintainer: xiretza
Last Packager: xiretza
Votes: 11
Popularity: 0.039355
First Submitted: 2019-06-18 22:23
Last Updated: 2021-07-20 08:51

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »

aklsh commented on 2020-09-14 03:38

Retrieving sources...
  -> Downloading Xilinx_Unified_2020.1_0602_1208.tar.gz...
curl: (37) Couldn't open file /Xilinx_Unified_2020.1_0602_1208.tar.gz
==> ERROR: Failure while downloading file:///Xilinx_Unified_2020.1_0602_1208.tar.gz
error downloading sources: vivado

I get this... How do I proceed?

xiretza commented on 2020-06-09 20:22

Updated to 2020.1 and moved the digilent utilities to optdepends, thanks yuyichao.

yuyichao commented on 2020-06-09 12:38

Also note that at least digilent.adept.runtime digilent.adept.utilities and fxload should be optional dependencies. They should only be needed for anyone that want to use this to manipulate digilent devices.

xiretza commented on 2020-05-19 09:26

@leuko: yeah, the installer does some weird shenanigans with LD_LIBRARY_PATH, those warnings show up even without the custom LD_PRELOAD trickery this package uses. From what I can tell they can be safely ignored, all files in the package are still owned by root.

leuko commented on 2020-05-19 08:46

FYI: After Starting package()... I got the following errors, but the installation completed successfully:

ERROR: object 'ERROR: object '' from ' from LD_PRELOADLD_PRELOAD cannot be preloaded ( cannot be preloaded (cannot open shared object filecannot open shared object file): ignored.
): ignored.
ERROR: object '' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: object '' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
Running in batch mode...

4VRDriver commented on 2020-05-15 21:44

Something I have noticed while building this package (just in case someone has the same problem): because of the huge size of the package I hadn't enough space on my ext4-drive and thought it would be a good idea to run "makepkg" on a second NTFS drive that had enough space - the build will fail saying you have run out of space regardless of the real free space. So building on a NTFS drive is not a good idea at all.

yuyichao commented on 2020-05-11 17:30

exactly which executables should receive this special handling?

the ones

that have the associated desktop entry

i.e. vivado, docnav (and vivado_hls that is missing the desktop entry).

xiretza commented on 2020-05-11 15:49

@yuyichao: I understand your usecase, but I'm hesitant to add wrapper scripts to /usr/bin (symlinks aren't enough) - exactly which executables should receive this special handling? Everyone's usecase is probably a little different. Instead, I can suggest creating your own wrappers in /usr/local/bin, which should be on the PATH by default, maybe even with a separate sourced file that defines the current version to make upgrading easier.

yuyichao commented on 2020-05-11 14:08

sourcing the setting file puts a bit too many scripts on PATH and creating a few wrapper scripts serves as a intermediate level of command line support. It's at least useful in my workflow (not necessarily general I guess) since I launch almost everything for a project from command line but I don't really need more than the "default programs" that have the associated desktop entry.

xiretza commented on 2020-05-11 13:48

@yoyichao: ah, thanks, I hadn't noticed the SDK disappearing. I applied the change locally, but since it only removes a useless file, I won't push a package update yet (the cost for users of either rebuilding or ignoring the package is greater than the benefit imho). As for putting binaries on the path - that's exacatly what those shell scripts are for. If you want the tools to always be on your path, source /opt/Xilinx/Vivado/2019.2/ in your shell's init script (e.g. .bashrc).

Edit: oh, and regarding the update: I'd rather not package those unless absolutely necessary, it would increase the build time even more with no benefit for most users. This also aligns with Xilinx's update recommendations.