Vivado->SDK sometimes updates sometimes creates a new hw platform, why?

[archangel-lightworks]

I have found that, apparently at random(*), When exporting the hardware to SDK with an already existing hw platform, sometimes (I would say when SDK is open) it updates it (with the pop up warning about it). Nice. but sometimes I noticed it just creates an additional hw platform, typically named like  mytopfile_hw_platform_1, which makes me wonder which one will SDK use...

How can I control that?

(*) "random" is an interesting term, it has a clear meaning in mathematics, yet it is widely used to refer to what is actually unknown

[abouassi]

Hi @archangel-lightworks,

By saying random, have you modified your project path or something like that?
Which SDK version are you using?

[archangel-lightworks]

No, I don't change paths. My work flow is typically making hardware, create bitstream, exporting hardware, creating software, trying it, pulling my hairs out, deciding I have to change the hardware, going back to vivado, doing the changes, bitstream again, export and that's when I find it.

[abouassi]

Hi @archangel-lightworks,

Strange!
Which version are you using?
Are you using the same version for both SDK and Vivado?
In the case where a new Hradware Platform Project was created, could you please share the "properties.index" file of each project to check the used HDF file path on each case. You can find these file on the following path:  <your_work_space>\.metadata\.plugins\org.eclipse.core.resources\.projects\<your_harware_platform_project>\.indexes\properties.index). Otherwise, just try to open these two files with an HEX editor and check if the same path was used.

[archangel-lightworks]

Both Vivado and SDK are 2018.3. Xilinx has taught me to never mess up with versions.

Now that you mention the metadata folder... just yesterday I saved a Vivado project with another name, so it went to another folder, opened it with Vivado, launched SDK from there and crashed (shut off with no message). Repeated, same result. Opened SDK from the start menu, same thing. Opened SDK and choose another repository folder then changed to that one, same crash... I found somewhere else that is fixed by deleting that metadata folder. and yes, that worked, but man, that's not an 'aesthetic' bug.

[abouassi]

Hi @archangel-lightworks,

I can't reproduce this crash on my machine (Windows10) using the same version.

[archangel-lightworks]

It happens now and then, as the best bugs do. If it happened every time by 2019, I'd be using Intel.

[mfryba]

I have this happen frequently also; was on 2018.3 and now 2019.1. It creates a {base_name}_hw_platform_1 directory and puts the system.hdf and a .project file in there. Also, I notice that SDK seems really paranoid about thinking the hardware platform has changed and keeps prompting you to export again (making this issue happen more often). Since I'm often re-building (just the) bitstream only when the .elf file changes, it's doubly annoying.

Given that I'm trying to manage stuff in GIT, this willy-nilly creation of new directories (block design does this too...the secret is you want to save the .XCI and the .XML files for each IP subdirectory) throughout Vivado is very annoying.

[ibaie]

Hi @archangel-lightworks and @mfryba 

The mechanism that generates hardware platform projects in SDK works in the following way:

1. Vivado exports hardware definition files (HDF, DSA or now XSA) to a given location selected in the GUI menu when export option is selected. By default <Local to Project> location is used, which basically is just a new folder within the Vivado project ot be used as SDK workspace <project-name>.sdk. The export operation does not generate any SDK project al all.

2. Launch SDK from Vivado. There is a big difference between launching SDK from Vivado or launching manually from Windows, launching from Vivado means that a Hardware Platform Project will be GENERATED based on the HDF file previously exported.

3. The hardware platform project gets "linked" to the HDF file that has been used for project generation and SDK provides a background feature that monitors the timestamp of the HDF file to detect any update. The PATH of the baseline can be checked easily anytime in the "Change Hardware Platform Specification" option.

4. If Vivado exports a new HDF file overwriting the previous HDF file, SDK will pop-up a notice message stating that the hardware has been updated and requesting to update the project. This feature just works on Timestamp basis and does NOT INSPECT the design.

5. Launching SDK from Vivado with previously exisiting workspace and hardware platform project will create a new Hardware Platform Project, only in the cases where the exisiting projects baseline HDF file PATH does not correspond to the one used for the new export operation.

The key point for the reported issue on this thread is the 5th point. Check the paths used for hwspec when SDK was launched (either in Vivado TCL or SDK Log file) and check if the spec file of the existing project matches.

Regards

[archangel-lightworks]

It doesn't help at all. I'm basically doing the same things all the time:

vivado -> hdf -> export (1st time) -> launch SDK from Vivado -> create sw app -> try bitstream + sw -> back to Vivado -> new hdf -> export (SDK open) -> etc.

Most of the times the hw platform gets updated. Sometimes a new hw_platform_1 appears. I wouldn't bother if I could just delete it, what happens is I don't know which one is the rest of the sw project using.

[ibaie · Accepted solution]

Hi @archangel-lightworks 

My explanation was just a guideline on how the tool works in order to have a better pickture of the under the hood flow. I'm not sure what's going wrong on your side so I would suggest to debug it in the following way.

1. Modify the SDK log level in the Preferences window to increase up to Trace or Debug level
2. When a new hardware platform is generated by the tool (undersired behaviour)
   1. Check the SDK log file and post it here
   2. Check the Hardware Specification File on both Hardware Plaftorm Project and post the image or the path of the file here. (Just right click on the project and select Change Hardware Specification File and click on OK

I know the issue is frustrating but the only way the community can help you is providing as much as details possible.

Regards

[mfryba]

Worse, the OS support makefile doesn't notice the new HW spec and doesn't rebuild the BSP. When you make just minor tweaks this could be considered a beneficial feature. But, I've looked at the BSP settings (standalone 6.8 on a MicroBlaze) and it's pointing to _0 whereas the SDK just created a new _1 hardware profile.