Incremental Design Management - 2025.1 English - UG1701

Embedded Design Development Using Vitis User Guide (UG1701)
Document ID
UG1701
Release Date
2025-07-16
Version
2025.1 English

Constructing the project in a single, monolithic build process as described in this chapter so far does not account for the iterative nature of practical design scenarios. As a project grows in complexity, managing changes and updates to individual components becomes essential. By adopting an incremental build strategy, you can significantly reduce the project build time by focusing only on the components that are directly affected by a change. This section explains the methods of managing design changes, allowing you to identify the specific steps that require rebuilding, streamlining the development process and optimizing project workflows.

Understanding the Build Order

To effectively manage the build process, it is crucial to understand the order in which various tools and steps are executed. The Vitis Integrated Flow and Vitis Export to Vivado Flow, provide a high-level overview of the build sequence. Next, it is important to consider the file-level handoffs between Vivado and Vitis flows. The following diagram serves as a starting point for the discussion, illustrating the key components involved in this process.

Figure 1. System Level Dependencies and Build Handoffs

The diagram uses boxes to represent activities and arrows to depict the flow of inputs and outputs between them. The activities are governed by a range of settings which can be specified through the IDE GUI, command line options, or a configuration file. Typically these are defined using tcl, python scripts, Makefiles, and configuration text files. In addition to the settings, the build process also relies on source files representing the design objects.

While it can seem intuitive that any step following an activity would necessitate a rebuild, there are nuanced distinctions to consider. The following table highlights some scenarios to shed light on what triggers a rebuild.

Rebuild Strategies

This section lists common scenarios encountered during incremental design evolution. The scenarios are categorized from both hardware and software perspectives. For hardware changes, the software may need to be rebuilt, as software is often used to control and monitor hardware devices. Conversely, pure software changes allow for significant shortcuts as it only involves simple recompile and repackaging, leading to shorter iteration cycles.

Table 1. Use Case Scenarios for Hardware Rebuild Strategy
Scenario Action Comments
Initial build Build/Compile all steps according to Vitis Integrated Flow or Vitis Export to Vivado Flow. When using the "part" selection method for the device, all activities that generate inputs for the Vitis linker can be compiled in any order. This flexibility allows for parallel processing and potentially faster build times.
Note: For Vitis Integrated Flow projects with XRT host applications, the extensible XSA can be used to setup Linux OS. This allows concurrent development of software applications alongside the AIE and PL kernels.
Important: While incremental builds offer significant benefits, it's crucial to perform regular full builds as part of regression testing. This ensures the design's integrity and readiness for reuse or branching into other projects.
Modify Vivado RTL or IP integrator blocks not related to the Vitis region.
  1. Open the Vivado project containing the imported VMA.
  2. Edit the block design, validate and save
  3. Reset synthesis and implementation runs, and then rerun them as performed in initial design iteration.
  4. Rebuild/recompile all steps following the Vivado synthesis and implementation step.
 This scenario involves modifying Vivado RTL or IP integrator blocks that are not directly related to the Vitis region, assuming these changes do not impact the AI Engine or Vitis region itself. Typical use cases include modifying synthesis and implementation strategies, addressing engineering change orders (ECOs), or adding additional debug ILAs.
Modify Vivado RTL or IP integrator blocks connected to Vitis region
  1. Open the Vivado project containing the imported VMA.
  2. Disconnect and remove the Vitis region with vitis::remove_archive_hierarchy
  3. Update the block design, validate and write a new extensible xsa.
  4. Update and recompile affected PL kernels or AIE graph.
  5. Update the link instructions and run Vitis linker.
  6. Rebuild/recompile all steps subsequent to Vitis linker.
 This scenario involves modifications to Vivado RTL or IP integrator blocks that have connections to the Vitis region. Typical use cases include implementing incremental design strategies or merging ECOs into the base design.
Modify RTL or HLS PL kernels
  1. Open the Vivado project containing the imported VMA.
  2. Disconnect and remove the Vitis region with vitis::remove_archive_hierarchy
  3. Update and recompile affected PL kernels.
  4. Update the link instructions and run Vitis linker.
  5. Rebuild/recompile all steps subsequent to Vitis linker.
 This scenario addresses changes to RTL or HLS IP kernels within the Vitis region, assuming these modifications do not impact the physical interfaces to/from the AI Engine.
Note: If you adjust the number of instances of an existing kernel XO, step 3 can be skipped.
Modify AI Engine graph
  1. Open the Vivado project containing the imported VMA.
  2. Disconnect and remove the Vitis region with vitis::remove_archive_hierarchy
  3. Update and recompile AI Engine graph as required.
  4. Update and recompile any affected PL kernels.
  5. Update the linking instructions and run Vitis linking.
  6. Rebuild/recompile all steps subsequent to Vitis linker.
Tip: If the interface protocols between AI Engine and PL or GMIO remain unchanged, recompiling the graph can be treated as a software update. This allows for skipping all steps except recompiling SW host application and rerunning Vitis package and Flash package steps.
Modify VSS components
  1. Follow the methods presented in previous scenarios to update and recompile PL kernels and AI Engine graph.
  2. Update and recompile the affected VSS components.
  3. Follow the methods presented in previous scenarios to rebuild/recompile with Vitis linker.
 Changes to VSS follow the same principle as listed in the previous scenarios with the addition of recompiling the VSS components and repeating the steps mentioned in the respective scenarios.
Table 2. Use Case Scenarios for Software Rebuild Strategy
Scenario Action Comments
Modify host software applications
  1. Modify the software source code and recompile to executable.
  2. Rerun Vitis flash package.
 This assumes no new hardware changes are made to the design.
Note: The new executable can alternatively be downloaded directly to the boards Linux file system using FTP or secure copy. To ensure the new file is properly saved, use the poweroff or reboot command to synchronize the file system.
Modify device drivers
  1. Modify the device tree system include.
  2. Rebuild Vitis platform component to update system device tree and board support packages.
  3. Update and recompile affected SW host applications
  4. Rerun Vitis package steps.
  

Key takeaways:

  • By analyzing these scenarios and the dependencies between the flow steps, you can leverage concurrent development strategies to streamline the design process.
  • When multiple designers collaborate in developing a design, it is crucial to ensure the ability to rebuild the design from scratch to a known state.
  • A clear understanding of the merge points and opportunities for splitting activities across a team is essential for efficient collaboration.