Solution Synthesis - Solution Synthesis - 2026.1 English - UG1504

Versal Adaptive SoC System and Solution Planning Methodology Guide (UG1504)

Document ID
UG1504
Release Date
2026-07-22
Version
2026.1 English

Based on the Requirements Gathering section above, here is a list of key takeaways.

  • PL stores the image pixels and streams them into the design as they are consumed.
  • The AI Engine stores and computes the histogram. The histogram storage requirement is larger than the tile memory available for a single AI Engine tile. Therefore, the solution is a multi-tile design.
  • The rho_i computation is vectorized and runs on the AI Engine vector processor. You need to prototype this computation to confirm what vectorization and throughput is achievable.
  • The design expects the histogram update to be the throughput bottleneck. The RMW access pattern cannot be vectorized or pipelined, so the AI Engine scalar processor runs it. Assume a single RMW requires eight cycles, but you need to validate this as this is the key assumption.
Figure 1. Multi-Tile Solution

To validate the assumptions above, you need to prototype a multi-tile solution with histogram updates. The exact number of tiles to use is not critical at this point, because the objective is to characterize the cycles consumed by the RMW. Additionally, you can receive an accurate estimate for how many tiles you will need to reach the target throughput. Once you define the assumptions accurately, you can scale the solution accordingly. Next, proceed by prototyping a 32-tile design.

For a 32-tile design, each tile computes four of the 128 theta values. Propose using mac16 intrinsics operating on four pixels per cycle. Local tile memory stores the cos(θ), sin(θ) arrays, and the partial 2D histogram H.

To meet the desired throughput of 220 Mpps, you have a budget of 294545 cycles to process 216 x 240 pixels. This translates to 5.7 cycles per pixel. Assume you can vectorize the algorithm to run eight pixels in parallel. Under that assumption, the budget to process the eight pixels is 5.7 x 8 = 45.5 cycles.

The expected throughput is ~39 Mpps. The RMW bottlenecks it. This assumes eight cycles per histogram update (or 32 cycles per pixel assuming a 32-tile design).

To support the final desired throughput of 220 Mpps, you need to scale the 32-tile design. Base the scaling on either option 2 or 3 previously mentioned.

The risky areas that need to be developed and quantified are the rho and address compute as well as the histogram update. The next section focuses on de-risking these.