10-28-2020 11:11 PM
I have been trying to write a custom IP to implement a simple counter with the IP having AXI and AXIS ports. The Synthesis and Implementation tests on the IP alone are successfully passed.
But, when merging changes in Customization Parameters/Ports and Interfaces, the IP Packager and Vivado crash altogether. The next time the IP is opened in IP packager again, the verilog code files are missing and and unable to add them again although they are in the correct location inside the IP directory. I'm nable to understand what's happening.
Why does the IP packager crash during the Merge step? Is it a bug or does it have to do with faulty values in my ports/parameters? What happens to the files as they aren't getting included in the project while they are also not being instantiated the second time?
10-28-2020 11:38 PM
Crashes are generally bugs.
Which Vivado version are you using ?
Is it possible to upload a design or tcl file that helps in reproducing what you have reported?
10-29-2020 12:00 AM
I am using Vivado version 2018.3.
I am attaching below the tcl files that are present in the IP directory. Also attached is a screen grab of the IP directory just before it crashed. Let me know if you need anything else.
What causes the bug? And how can it be fixed? I have created numerous IPs in the past few months but have never faced this issue.
10-29-2020 12:16 AM - edited 10-29-2020 12:18 AM
Over the years multiple crashes were found and fixed and root cause varies. First suggestion would be, if possible, upgrade and use latest Vivado version (2020.1)
To reproduce pls upload all the files shown in your "Design Sources" hierarchy and mention the FPGA part that your are targeting
10-29-2020 07:46 AM - edited 10-29-2020 07:48 AM
After the crashes are resolved (using 2019.2) I wouldn't rely on the S_AXI interface (which is probably axi-lite for configuration).
This hangs on writes. See a few forum posts but also this https://zipcpu.com/formal/2019/04/16/axi-mistakes.html
"Perhaps the reason why this bug is so common is because it’s prevalent in Xilinx’s example code."
See Dan Gizzlequists (@) posts https://forums.xilinx.com/t5/user/viewprofilepage/user-id/75728 - he's extensively written about this.
My workaround was to use the ADI axi4 lite slave interface, works well.