Requirements Gathering - Requirements Gathering - 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

The following is a functional model of the algorithm implemented in MATLAB® .

Figure 1. MATLAB Code Example

The following table summarizes the algorithm and system requirements of the example Hough transform to be implemented on AIE1.

Table 1. Hough Transform Parameters
Parameter Value Units Notes
Image # Rows Pixels "R" 216 Pixels  
Image # Column Pixels "C" 240 Pixels  
Histogram Data Type Size 2 B Assume <int16>
Theta Resolution (# steps) 128   Over 180°
Target throughput 220 Mpixel/sec

It is important to reflect on these parameters and understand how they drive your implementation cost. Image size understandably drives storage cost because it needs to be stored in-part or in-full for processing. Storing the image in the AI Engine local tile memory is costly. It is better to store the image in PL and stream the pixels into the tiles for computation as needed.

The histogram H(ρ, θ) collecting statistics also need to be stored and its size is dependent on:

  • Largest possible value of “ρ,” calculated as ceiling(sqrt(R2+C2))
    • Directly dependent on image size. A tall image is more costly than a square image.
  • θ resolution
  • Data type, chosen as int16 requiring 2 Bytes

Total histogram storage requirement can be calculated as (1 + 2 x largest possible value of “ρ”) x θ resolution x 2 Bytes.

cos_theta and sin_theta used in line 37 of the code above can be pre-computed and stored in a look-up table (LUT) as int16 values. The size of the LUT is directly dependent on the theta_resolution and assumed data type.

Throughput requirement, image dimensions, and theta resolution drive compute cost. The data types of multiplication operands in line 37 of the MATLAB code above also drive it.

For example, computation of rho_i requires 128 x 2 (int16 x int16) MACs/pixel and you need to run at 220 Mpixel/sec. Assuming AI Engine clock rate of 1.25 GHz, this requires 46 real MACs/cycle. A single tile in AIE1 supports 32 real MACs/cycle. This is an important conclusion, as it means the solution requires multiple tiles. The functional overview in the following documents underpins this information:

  • Versal Adaptive SoC AI Engine Architecture Manual (AM009)
  • Versal Adaptive SoC AIE-ML v2 Architecture Manual (AM027)

Similarly, throughput and image dimensions drive bandwidth cost.

From an image processing perspective, there are a couple of options to partition this problem.

Option 1
Each tile computes a full transform for a portion of the image. This has a linear reduction in compute. It reduces the amount of bandwidth required to each tile. However, it has the storage requirements of the full histogram. It also requires an additional compute block to combine the histogram outputs from each tile.
Option 2
Each tile computes a partial transform for the whole input image. This also reduces compute linearly. It requires higher bandwidth compared to option 1 because each tile must receive the full image. However, it reduces the storage requirements of the histogram. The histogram outputs from each tile need to be collected.
Option 3
A combination of options 1 and 2. You build a low-throughput solution using option 2, then instantiate that multiple times to achieve your desired throughput.

The next step is to proceed with analyzing hardware requirements.