12-20-2019 05:18 PM
I've made a Vivado zynq project that builds successfully and exports hardware. I've generated a platform, system, and project with that hardware in Vitis. The project compiles and runs correctly on hardware. Great... moving on I go back to the same hardware in Vivado and make updates. Specifically I change an existing AXI gpio block to have two channels and enable interrupts. Once again it all builds and exports nicely. The problems with Vitis start here:
At this point in Vitis with the same platform I do: Clean Project, Update Hardware Specification, Build Project. But after these steps the xparameters.h file in the platform doesn't reflect the changes in the hardware. However, if I click platform.spr and look at the Hardware Specification tab I can see the hardware updates in the "IP blocks present in this design table" by looking at the registers in the AXI GPIO row that clearly show a dual channel GPIO with interrupts enabled.
I've tried closing and reopening vitis, recleaning, rebuilding, reupdating hardware specification... no combination of these attempts will generate a new xparameters.h that properly reflects the hardware. Creating a new platform from the same xsa file creates a correct xparameters.h file.
So -- how does one force an existing vitis platform to regenerate xparameters.h so that one can properly develop hardware incrementally...?
12-24-2019 09:48 PM
I've found one workaround: After doing an "Update Hardware Specification" on the project the entire ps7_cortexa9_0 can be deleted. Then load platform.spr, "standalone on ps7_cotexa9_0", "Board Support Package." The "Reset BSP Sources" button on that screen of course will regenerate everything that goes into the ps7_cortexa9_0 folder and allow a rebuild with an updated xparameters.h.
I'm not sure why the BSP doesn't get updated when "Updated Hardware Specification" is run ... seems like those should go together to me.
02-05-2020 04:05 PM
Vitis tool : UPDATE HARDWARE (thus upgrading after modifying the PL on a existing platform)
Sometimes it works, most of the time it does not (reset bsb, restart Vitis, .... whatever you do).
You are never sure for 100% that the hardware is updated.
Dura lex sed lex : you have to completely rebuild the project platform. That works.
That's not funny anymore ....
(after hardly surviving the random crashes on SDK @ Win10)
02-13-2020 10:25 AM
I am also having this problem and have been geenratling a new project with every handoff file update (HDL PS update)
Was wondering if this issue has been resolved or if that is the way to go until updating hardware specification works more reliably.
Its annoying having to regenerate a project every single time to avod this problem, especially as the projects and programs/applications get more complex.
re-cleaning, rebuilding, closing application, cleaning BSP its all very unreliabled. I have yet to find an easier way to update the hardware specification correctly without restarting the project from scratch.
02-13-2020 02:59 PM
The update hardware functionality in Vitis seems unreliable. At least on a Win10 computer. After rebuilding the hardware project Vitis does not update the hardware! A working solution : re-create the hardware platform. My ZynqMP design is using 3 (out of 4) cortexa53 cores. The cores are using FreeRTOS, LWiP and some other stuff making it pretty painful to create each time the hardware platform after a hardware upgrade (via Vivado). A dirty trick : I added the cortexa53_3 as a "dummy processor" domain. Steps to upgrade the hardware in a decent way :
1. update the hardware in Vitis. (thus only update , without building the project)
2. quit Vitis and at Windows level : delete the whole cortexa53_3 folder (inside workspace ----> hardware platform)
3. restart Vitis and now also delete the cortexa53_3 hardware domain (because Vitis does not detect that the files have already been deleted by Win10)
4. re-create the cortexa53_3 hardware domain
5. build the whole hardware platform. It works !
6. rebuild the software platform ( advice : first clean the software project). The first rebuild generates a crazy error. No panic.
7. rebuild the software platform again : this time no errors/warnings anymore.
Thus no need to completely delete the hardware platform. Only deleting the dummy cortexa53_3 and re-create the dummy is triggering Vitis to do what it should do.
It's all very tricky. For instance the rebuild of the software always has to be executed twice. I presume the Vitis software is behaving properly under Linux and has been tested carefully by the Xilinx engineers. I'm afraid that somewhere - deep inside - Win10 is responsible for all the troubles.
04-07-2020 07:17 AM - edited 04-07-2020 07:21 AM
I had the same problem on a Win10 installation.
My workaround is as follows:
For me this works very reliably now. The only down side is that the scripts takes a few minutes to run, but not interaction needed.
I will try to put together a more general version of the script and upload it later.
04-07-2020 08:23 AM - edited 04-07-2020 08:25 AM
Attached is my tcl script. The following steps are necessary to execute it:
it should execute the steps i listed in the previous post.
04-24-2020 01:48 AM
Thank you very much for your solution!!, it works for me. I've been struggling with this problem for several days and was making me crazy. This is my first time with Vitis, I worked with sdk and everything was fine.
I hope Xilinx resolve this problem, but until then thanks to you I can work with a elegant solution.
11-08-2020 06:00 AM
11-08-2020 01:16 PM
Dear mr. Eyke,
Thanks a lot for your script.
But meanwhile I am using this process :
1. update the hardware specification (new .xsa file) under the hardware project .
2. do NOT rebuild the hardware project. Do NOT. The hardware project will show the "not ready" sign. Ignore it.
3. do rebuild the software project. During the processing the hardware project "not ready" sign will change into "everything ok" and at the end the software project is also updated into "everything ok".
To be honest, most of the time this procedure works. Sometimes it does not update properly. Then go back to whatever plan-B ....