You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should look at all platforms and check for Vivado version specific build script/files.
Motivating Example
Currently, for the U250, we need to create a new dir for each Vivado version and we end up sym linking bd_lib files anyways. This seems redundant and adds unnecessary steps for new Vivado versions.
A useful end state might be a version-independent U250 platform directory plus thin Vivado-version overlays containing only the files or Tcl branches that genuinely differ. The cleanup should probably include a build-time compatibility check that rejects an unsupported Vivado version with a clear message, since removing duplicated directories also removes the current implicit list of supported versions. A CI check comparing the generated block-design inputs for two supported versions could catch accidental coupling back into the shared bd_lib files.
Activity
hiSandog commentedon Jul 10, 2026
A useful end state might be a version-independent U250 platform directory plus thin Vivado-version overlays containing only the files or Tcl branches that genuinely differ. The cleanup should probably include a build-time compatibility check that rejects an unsupported Vivado version with a clear message, since removing duplicated directories also removes the current implicit list of supported versions. A CI check comparing the generated block-design inputs for two supported versions could catch accidental coupling back into the shared
bd_libfiles.