Using ChipScope to Debug AMD Versal Designs

Introduction

The Versal AI Edge series offers a powerful range of System-on-Chip (SoC) devices specifically optimized for edge applications—particularly those involving AI and machine learning.

These devices combine multiple processing elements, including Arm Cortex-A72 application processors, real-time Cortex-R5F processors, programmable logic, and dedicated AI Engines. All of these components are interconnected through a high-bandwidth, low-latency Network on Chip (NoC), enabling efficient data movement and tight integration across the heterogeneous compute fabric.

One of the many edge applications that leverages AI and machine learning is video stream detection and classification. These systems typically use convolutional neural networks (CNNs) to perform inference locally at the edge. This type of application is ideally suited for implementation on Versal AI Edge devices, which combine AI Engines, a high-bandwidth Network on Chip (NoC), programmable logic, and application processors to enable high-performance, low-latency solutions.

Before higher-level applications and ML models can be developed and deployed, a robust image processing pipeline must be established. This pipeline typically interfaces with a MIPI camera and performs operations such as demosaicing, color space conversion, and basic image enhancement or preprocessing functions. These steps ensure that the captured image data is suitable for further processing and inference.

A crucial early milestone in many development workflows is demonstrating reliable hardware and camera interfacing. This includes verifying that the image processing pipeline functions as expected, that the MIPI camera can be correctly configured, and that a valid image stream is received. Confirming these elements early reduces development risk by ensuring the I/O allocation, clocking strategy, and image processing flow are correctly implemented before integrating higher-level AI or application logic.

This solid foundation enables faster iteration and more confident progression through the rest of the project.

In this project, we’ll explore the creation of a Versal AI Edge image processing platform, targeting the Alinx VD100 development board, which features two four-lane MIPI inputs and an LVDS LCD display output. Versal AI Edge devices can be developed using the license-free Vivado Standard Edition, making this platform accessible for prototyping and development.

Versal Debug

While debugging applications on Versal is largely similar to debugging on 7 Series, UltraScale, and UltraScale+ devices, and we can use Chipscope there are a few important differences to be aware of.

The most significant change lies in how the debug hub is connected. In 7 Series, UltraScale, and UltraScale+ devices, the debug hub connects through the JTAG boundary scan interface to the debug cores inserted in the design. This debug hub is inserted automatically during the optimization phase of the implementation flow.

In contrast, for Versal, the debug hub connects via the AXI4 master interface of the CIPS (Configuration, Initialization and Power Management System) block to the debug cores. Additionally, unlike previous generations where debug cores used proprietary interfaces, Versal debug cores use standard AXI4-Stream interfaces, aligning with the platform’s modernized interconnect architecture.

As a result, a CIPS block must be present in the design to facilitate the AXI4 master connection to the debug hub. Debug hub insertion in Versal designs can be either automatic or manual, depending on the design context. For designs that include DFX (Dynamic Function eXchange), the debug hub must be inserted manually.

Another key difference is the use of the AXI-Stream ILA. In Versal, this IP core integrates both standard ILA and System ILA functionality into a single block. Additionally, users can now select the type of memory used for storing captured data—either BRAM or URAM—providing greater flexibility in terms of capture depth and resource usage.

Methodology of Debugging

When it comes to debugging applications, we need to take a logical approach. As such, when using the System ILA or ILA, we should understand that FPGA design is an iterative process, which is most successful if we solve problems logically.

The best approach to this is to:

• Break a problem into smaller parts
• Simplify by reducing variables and variation
• Make a prediction, then verify the results
• Plan how and where to debug early in the design cycle

Instrumenting Approaches

When using the Integrated Logic Analyzer (ILA) in real-world designs, it’s important to be strategic about what you instrument to balance debug visibility with FPGA resource usage.

ILAs consume logic and block RAM, which becomes a critical concern in devices already near capacity.

Capture depth and the width of monitored signals directly impact BRAM usage—wider probes and longer capture windows can quickly exhaust available memory.

In early revisions, follow the methodology outlined above, focusing on key control signals, reset lines, and status or error indicators, as these often provide immediate insight into system behaviour and help identify issues early in the debug cycle.

Critical AXI buses within the system—particularly those interfacing with the Versal’s Network on Chip (NoC) and the processing system, should also be considered for instrumentation. These interfaces are key data paths between the PL, NoC, and PS, and can expose subtle issues in system integration and data movement

While these wide buses are resource-intensive, they carry essential traffic between the programmable logic and processing system, and can reveal subtle issues in data handling and system integration.

Starting with a well-chosen mix of control, reset, status/error, and these key AXI interfaces at moderate capture depths provides valuable visibility into system-level behaviour while preserving headroom for iterative debug refinement.

Vivado Design

To create an image processing pipeline capable of receiving, processing, and displaying images from a sensor, we must design a complex system that operates under the control of the Control, Interfaces, and Processing System (CIPS).

Image frames are captured and processed through a series of IP blocks, while application software, DDR memory access, and communication between the CIPS and the programmable logic all occur via the Network on Chip (NoC).

This high-performance interconnect ensures efficient data movement across the system. The overall architecture of the design is illustrated in the diagram below.

Pixels will be received from the sensor as 10-bit raw data, processed four pixels per clock cycle. As the data moves through the pipeline, it is converted into RGB format, resulting in an AXI4-Stream interface that is 120 bits wide (4 pixels × 3 channels × 10 bits). This wide data path ensures high throughput and low latency across the image pipeline.

While the exact IP blocks used in the design are dependent on the specific requirements of the application, the core pipeline typically includes modules for sensor interface, demosaicing, color space conversion, image enhancement, and video timing control, along with AXI stream interconnect and control logic.

To help me ensure the design is operating correctly I am going to insert several ILAs in the image processing pipeline.

• ILA_LCD_LVDS - This will help me monitor the LCD / LVDS Interface, ensuring its error and status signals can be easily observed.
• Video ILA – Uses four channels to monitor the AXIS video in the processing pipeline. It observes the MIPI output, Demosaic, Subset Converter, and VDMA output. This allows us to monitor the video at any stage of the pipeline both going into and coming out of the VDMA.
• Memory ILA – Monitors AXI4 traffic to/from DDR via NoC this allows me to check the data writes to and from the DDR are occurring correctly.
• Output ILA – This monitors AXI Stream to Video Out status to ensure we can see its status and error conditions.

• The Control, Interfaces, and Processing System (CIPS) configures the Processing System (PS), manages platform initialization, and provides access to essential peripherals.

• The Network on Chip (NoC) facilitates high-bandwidth data movement by providing entry and egress points to the interconnect fabric, and also integrates the DDR memory controller for access to external memory.

• SmartConnect – Provides connectivity to AXI-Lite register interfaces on IP blocks, enabling control and configuration from the Processing System.

• MIPI CSI-2 RX Subsystem – Implements a 4-lane MIPI CSI-2 interface running at 1000 Mbps per lane, enabling high-speed image data capture from compatible camera sensors.

• Demosaic – Converts raw Bayer-pattern pixel data into full RGB pixels, reconstructing color information for each pixel from the sensor input.

• AXI Subset Converter – Converts 40-bit pixel data (typically 10 bits per RGB channel) to 24-bit pixel format (8 bits per channel), maintaining a throughput of 4 pixels per clock cycle.

• VDMA (Video Direct Memory Access) – Bridges AXI4-Stream and AXI4 memory-mapped interfaces, enabling the storage and retrieval of video frames in DDR memory via the NoC, and supporting efficient buffering between processing stages.

• AXI4-Stream to Video Out – Converts an AXI4-Stream video stream into a standard video output format, generating the necessary synchronization signals such as HSync, VSync, and video timing to drive display interfaces.

• Video Timing Controller (VTC) – Generates the required video timing signals such as HSync, VSync, and active video indicators, and synchronizes with the AXI4-Stream to Video Out block to ensure proper display timing.

• LCD LVDS Interface – Converts the standard parallel video output into a serialized VESA LVDS stream format, suitable for driving LVDS-based LCD panels with the required timing and signaling characteristics.
• Advanced IO Wizard – Configures the XPIO in Versal devices to serialize the LCD LVDS output data, enabling high-speed transmission of video signals to the display in compliance with LVDS VESA standards.

To ensure we can validate and debug the operation of the image processing pipeline, several Integrated Logic Analyzers (ILAs) have been added to the design. These ILAs provide real-time visibility into key internal signals and enable monitoring of the following elements:

• ILA_LCD_LVDS – Monitors the status outputs of the LCD_LVDS block to verify correct serialization and data transmission to the LCD panel.

• Video_ILA – Monitors key points along the video processing pipeline, including the RAW video output, the RGB output from the Demosaic block, the 24-bit output from the AXI Subset Converter, and the video stream output from the VDMA. This enables validation of pixel data transformation at each stage.

• Memory_ILA – Monitors AXI4 transactions to and from DDR memory over the NoC, providing visibility into memory access patterns, bandwidth utilization, and potential bottlenecks in data movement.

• Output_ILA – Monitors the status signals of the AXI4-Stream to Video Out IP, including sync validity, data enable, and video timing alignment, ensuring proper handoff to the display interface.

This provides us with the ability to observe both static go/no-go status signals and high-bandwidth data transfers throughout the image processing pipeline.

The completed design is shown below and can be recreated using the provided TCL script included with this project.

To generate the bitstream, we of course need to define the XDC I/O constraints, which specify the physical pin locations and electrical standards for all external interfaces. These I/O locations are defined as follows:

set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design]
set_property DIFF_TERM_ADV TERM_100 [get_ports sys_clk_p]
set_property PACKAGE_PIN A23 [get_ports {clkout1_p[0]}]
set_property IOSTANDARD LVDS15 [get_ports {clkout1_p[0]}]
set_property PACKAGE_PIN F22 [get_ports {dataout1_p_0[0]}]
set_property PACKAGE_PIN A20 [get_ports {dataout1_p_1[0]}]
set_property PACKAGE_PIN C22 [get_ports {dataout1_p_2[0]}]
set_property PACKAGE_PIN A25 [get_ports {dataout1_p_3[0]}]
set_property IOSTANDARD LVDS15 [get_ports {dataout1_p_*[0]}]
set_property PACKAGE_PIN E24 [get_ports {lcd_en}]
set_property IOSTANDARD LVCMOS15 [get_ports {lcd_en}]
set_property PACKAGE_PIN D24 [get_ports {lcd_sync}]
set_property IOSTANDARD LVCMOS15 [get_ports {lcd_sync}]
set_property PACKAGE_PIN AC11 [get_ports {DDR4_act_n[0]}]
set_property PACKAGE_PIN AB12 [get_ports {DDR4_adr[0]}]
set_property PACKAGE_PIN AB17 [get_ports {DDR4_adr[10]}]
set_property PACKAGE_PIN AE13 [get_ports {DDR4_adr[11]}]
set_property PACKAGE_PIN AH12 [get_ports {DDR4_adr[12]}]
set_property PACKAGE_PIN AD15 [get_ports {DDR4_adr[13]}]
set_property PACKAGE_PIN AD21 [get_ports {DDR4_adr[14]}]
set_property PACKAGE_PIN AD17 [get_ports {DDR4_adr[15]}]
set_property PACKAGE_PIN AC13 [get_ports {DDR4_adr[16]}]
set_property PACKAGE_PIN AE22 [get_ports {DDR4_adr[1]}]
set_property PACKAGE_PIN AD22 [get_ports {DDR4_adr[2]}]
set_property PACKAGE_PIN AB15 [get_ports {DDR4_adr[3]}]
set_property PACKAGE_PIN AD12 [get_ports {DDR4_adr[4]}]
set_property PACKAGE_PIN AE17 [get_ports {DDR4_adr[5]}]
set_property PACKAGE_PIN AD16 [get_ports {DDR4_adr[6]}]
set_property PACKAGE_PIN AG11 [get_ports {DDR4_adr[7]}]
set_property PACKAGE_PIN AE14 [get_ports {DDR4_adr[8]}]
set_property PACKAGE_PIN AB14 [get_ports {DDR4_adr[9]}]
set_property PACKAGE_PIN AC16 [get_ports {DDR4_ba[0]}]
set_property PACKAGE_PIN AD11 [get_ports {DDR4_ba[1]}]
set_property PACKAGE_PIN AB18 [get_ports {DDR4_bg[0]}]
set_property PACKAGE_PIN AC19 [get_ports {DDR4_ck_t[0]}]
set_property PACKAGE_PIN AD19 [get_ports {DDR4_ck_c[0]}]
set_property PACKAGE_PIN AB21 [get_ports {DDR4_cke[0]}]
set_property PACKAGE_PIN AC17 [get_ports {DDR4_cs_n[0]}]
set_property PACKAGE_PIN AG12 [get_ports {DDR4_dm_n[0]}]
set_property PACKAGE_PIN AH13 [get_ports {DDR4_dm_n[1]}]
set_property PACKAGE_PIN AE28 [get_ports {DDR4_dm_n[2]}]
set_property PACKAGE_PIN AD24 [get_ports {DDR4_dm_n[3]}]
set_property PACKAGE_PIN V22 [get_ports {DDR4_dm_n[4]}]
set_property PACKAGE_PIN V28 [get_ports {DDR4_dm_n[5]}]
set_property PACKAGE_PIN N28 [get_ports {DDR4_dm_n[6]}]
set_property PACKAGE_PIN U25 [get_ports {DDR4_dm_n[7]}]
set_property PACKAGE_PIN AF14 [get_ports {DDR4_dq[0]}]
set_property PACKAGE_PIN AH18 [get_ports {DDR4_dq[10]}]
set_property PACKAGE_PIN AH20 [get_ports {DDR4_dq[11]}]
set_property PACKAGE_PIN AH14 [get_ports {DDR4_dq[12]}]
set_property PACKAGE_PIN AH22 [get_ports {DDR4_dq[13]}]
set_property PACKAGE_PIN AH15 [get_ports {DDR4_dq[14]}]
set_property PACKAGE_PIN AG22 [get_ports {DDR4_dq[15]}]
set_property PACKAGE_PIN AF26 [get_ports {DDR4_dq[16]}]
set_property PACKAGE_PIN AE26 [get_ports {DDR4_dq[17]}]
set_property PACKAGE_PIN AH27 [get_ports {DDR4_dq[18]}]
set_property PACKAGE_PIN AE27 [get_ports {DDR4_dq[19]}]
set_property PACKAGE_PIN AG18 [get_ports {DDR4_dq[1]}]
set_property PACKAGE_PIN AG27 [get_ports {DDR4_dq[20]}]
set_property PACKAGE_PIN AD26 [get_ports {DDR4_dq[21]}]
set_property PACKAGE_PIN AG26 [get_ports {DDR4_dq[22]}]
set_property PACKAGE_PIN AG28 [get_ports {DDR4_dq[23]}]
set_property PACKAGE_PIN AE24 [get_ports {DDR4_dq[24]}]
set_property PACKAGE_PIN AD25 [get_ports {DDR4_dq[25]}]
set_property PACKAGE_PIN AH24 [get_ports {DDR4_dq[26]}]
set_property PACKAGE_PIN AF25 [get_ports {DDR4_dq[27]}]
set_property PACKAGE_PIN AG23 [get_ports {DDR4_dq[28]}]
set_property PACKAGE_PIN AG25 [get_ports {DDR4_dq[29]}]
set_property PACKAGE_PIN AG15 [get_ports {DDR4_dq[2]}]
set_property PACKAGE_PIN AH23 [get_ports {DDR4_dq[30]}]
set_property PACKAGE_PIN AH25 [get_ports {DDR4_dq[31]}]
set_property PACKAGE_PIN Y22 [get_ports {DDR4_dq[32]}]
set_property PACKAGE_PIN V23 [get_ports {DDR4_dq[33]}]
set_property PACKAGE_PIN Y23 [get_ports {DDR4_dq[34]}]
set_property PACKAGE_PIN W24 [get_ports {DDR4_dq[35]}]
set_property PACKAGE_PIN AA22 [get_ports {DDR4_dq[36]}]
set_property PACKAGE_PIN V24 [get_ports {DDR4_dq[37]}]
set_property PACKAGE_PIN AA21 [get_ports {DDR4_dq[38]}]
set_property PACKAGE_PIN W25 [get_ports {DDR4_dq[39]}]
set_property PACKAGE_PIN AF18 [get_ports {DDR4_dq[3]}]
set_property PACKAGE_PIN V25 [get_ports {DDR4_dq[40]}]
set_property PACKAGE_PIN W27 [get_ports {DDR4_dq[41]}]
set_property PACKAGE_PIN AA28 [get_ports {DDR4_dq[42]}]
set_property PACKAGE_PIN W26 [get_ports {DDR4_dq[43]}]
set_property PACKAGE_PIN Y26 [get_ports {DDR4_dq[44]}]
set_property PACKAGE_PIN AA26 [get_ports {DDR4_dq[45]}]
set_property PACKAGE_PIN AB28 [get_ports {DDR4_dq[46]}]
set_property PACKAGE_PIN AB26 [get_ports {DDR4_dq[47]}]
set_property PACKAGE_PIN P27 [get_ports {DDR4_dq[48]}]
set_property PACKAGE_PIN K27 [get_ports {DDR4_dq[49]}]
set_property PACKAGE_PIN AF13 [get_ports {DDR4_dq[4]}]
set_property PACKAGE_PIN R28 [get_ports {DDR4_dq[50]}]
set_property PACKAGE_PIN L28 [get_ports {DDR4_dq[51]}]
set_property PACKAGE_PIN R27 [get_ports {DDR4_dq[52]}]
set_property PACKAGE_PIN K28 [get_ports {DDR4_dq[53]}]
set_property PACKAGE_PIN T28 [get_ports {DDR4_dq[54]}]
set_property PACKAGE_PIN M27 [get_ports {DDR4_dq[55]}]
set_property PACKAGE_PIN P25 [get_ports {DDR4_dq[56]}]
set_property PACKAGE_PIN L26 [get_ports {DDR4_dq[57]}]
set_property PACKAGE_PIN R26 [get_ports {DDR4_dq[58]}]
set_property PACKAGE_PIN M26 [get_ports {DDR4_dq[59]}]
set_property PACKAGE_PIN AF19 [get_ports {DDR4_dq[5]}]
set_property PACKAGE_PIN T25 [get_ports {DDR4_dq[60]}]
set_property PACKAGE_PIN K26 [get_ports {DDR4_dq[61]}]
set_property PACKAGE_PIN T26 [get_ports {DDR4_dq[62]}]
set_property PACKAGE_PIN J25 [get_ports {DDR4_dq[63]}]
set_property PACKAGE_PIN AG13 [get_ports {DDR4_dq[6]}]
set_property PACKAGE_PIN AE19 [get_ports {DDR4_dq[7]}]
set_property PACKAGE_PIN AH17 [get_ports {DDR4_dq[8]}]
set_property PACKAGE_PIN AG21 [get_ports {DDR4_dq[9]}]
set_property PACKAGE_PIN AG17 [get_ports {DDR4_dqs_t[0]}]
set_property PACKAGE_PIN AG16 [get_ports {DDR4_dqs_c[0]}]
set_property PACKAGE_PIN AG20 [get_ports {DDR4_dqs_t[1]}]
set_property PACKAGE_PIN AH19 [get_ports {DDR4_dqs_c[1]}]
set_property PACKAGE_PIN AC28 [get_ports {DDR4_dqs_t[2]}]
set_property PACKAGE_PIN AD27 [get_ports {DDR4_dqs_c[2]}]
set_property PACKAGE_PIN AF24 [get_ports {DDR4_dqs_t[3]}]
set_property PACKAGE_PIN AF23 [get_ports {DDR4_dqs_c[3]}]
set_property PACKAGE_PIN Y24 [get_ports {DDR4_dqs_t[4]}]
set_property PACKAGE_PIN AA23 [get_ports {DDR4_dqs_c[4]}]
set_property PACKAGE_PIN Y28 [get_ports {DDR4_dqs_t[5]}]
set_property PACKAGE_PIN Y27 [get_ports {DDR4_dqs_c[5]}]
set_property PACKAGE_PIN U27 [get_ports {DDR4_dqs_t[6]}]
set_property PACKAGE_PIN U28 [get_ports {DDR4_dqs_c[6]}]
set_property PACKAGE_PIN P26 [get_ports {DDR4_dqs_t[7]}]
set_property PACKAGE_PIN N27 [get_ports {DDR4_dqs_c[7]}]
set_property PACKAGE_PIN AC22 [get_ports {DDR4_odt[0]}]
set_property PACKAGE_PIN AC24 [get_ports {DDR4_reset_n[0]}]
set_property PACKAGE_PIN AB23 [get_ports {sys_clk_clk_p[0]}]
set_property PACKAGE_PIN AC23 [get_ports {sys_clk_clk_n[0]}]
set_property IOSTANDARD LVDS15 [get_ports {sys_clk_clk_n[0]}]
set_property IOSTANDARD LVDS15 [get_ports {sys_clk_clk_p[0]}]
create_clock -period 5.000 -name sys_clk -waveform {0.000 2.500} [get_ports {sys_clk_clk_p[0]}]
set_property PACKAGE_PIN G26 [get_ports {cam1_gpio[0]}]
set_property IOSTANDARD LVCMOS15 [get_ports {cam1_gpio[0]}]
set_property PULLUP true [get_ports {cam1_gpio[0]}]
set_property PACKAGE_PIN G27  [get_ports cam1_i2c_scl_io]
set_property PACKAGE_PIN F28 [get_ports cam1_i2c_sda_io]
set_property IOSTANDARD LVCMOS15 [get_ports cam1_i2c_scl_io]
set_property IOSTANDARD LVCMOS15 [get_ports cam1_i2c_sda_io]
set_property PULLUP true [get_ports cam1_i2c_scl_io]
set_property PULLUP true [get_ports cam1_i2c_sda_io]
set_property PACKAGE_PIN U23 [get_ports mipi_phy_if_0_clk_p]
set_property PACKAGE_PIN T23 [get_ports mipi_phy_if_0_data_p[0]]
set_property PACKAGE_PIN R23 [get_ports mipi_phy_if_0_data_p[1]]
set_property PACKAGE_PIN L23 [get_ports mipi_phy_if_0_data_p[2]]
set_property PACKAGE_PIN M22 [get_ports mipi_phy_if_0_data_p[3]]
set_property IOSTANDARD MIPI_DPHY [get_ports mipi_phy_if_0_clk_p]
set_property IOSTANDARD MIPI_DPHY [get_ports mipi_phy_if_0_clk_n]
set_property IOSTANDARD MIPI_DPHY [get_ports mipi_phy_if_0_data_p[0]]
set_property IOSTANDARD MIPI_DPHY [get_ports mipi_phy_if_0_data_n[0]]
set_property IOSTANDARD MIPI_DPHY [get_ports mipi_phy_if_0_data_p[1]]
set_property IOSTANDARD MIPI_DPHY [get_ports mipi_phy_if_0_data_n[1]]
set_property IOSTANDARD MIPI_DPHY [get_ports mipi_phy_if_0_data_p[2]]
set_property IOSTANDARD MIPI_DPHY [get_ports mipi_phy_if_0_data_n[2]]
set_property IOSTANDARD MIPI_DPHY [get_ports mipi_phy_if_0_data_p[3]]
set_property IOSTANDARD MIPI_DPHY [get_ports mipi_phy_if_0_data_n[3]]
set_property CLOCK_REGION X3Y0 [get_cells -hier -filter {name =~ *mipi_csi2_rx_subsyst_1/inst/phy/inst/inst/rxbyteclkhs_buf}]
set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets -hier -filter {name =~ *mipi_csi2_rx_subsyst_0/inst/phy/inst/inst/*/inst/BANK_WRAPPER_INST0/fifo_wr_clk[0]}]

Application Software

The application software will be developed using the Vitis Unified Software Platform. The application is responsible for performing the following key tasks:

• Configure the camera, using the initialization files provided by Alinx [link here if needed].
• Set up the Video Timing Controller (VTC) to generate the appropriate timing signals for 720p resolution.
• Configure the Demosaic IP for correct color reconstruction.
• Enable the camera via a GPIO control signal.
• Configure the VDMA to read and write image frames between the DDR memory and the video pipeline, leveraging the NoC for high-speed data access.

The complete software application is available on my GitHub for reference and reuse.

#include <stdio.h>
#include "math.h"
#include <ctype.h>
#include <stdlib.h>
#include "xil_types.h"
#include "xil_cache.h"
#include "xparameters.h"
#include "xiicps.h"
#include "i2c/PS_i2c.h"
#include "demosaic/demosaic.h"
#include "cam_config.h"
#include "config.h"
#include "sleep.h"

#include "xil_cache.h"

#include "xgpiops.h"
#include "xscugic.h"
#include "vtc.h"
#include "xaxivdma.h"
#include "xaxivdma_i.h"

//#include "ff.h"
/* ------------------------------------------------------------ */
/*				Global Variables								*/
/* ------------------------------------------------------------ */

#define LED_MIO	25
#define CAM1_EMIO	26
#define CAM2_EMIO	27

XAxiVdma vdma;
XAxiVdma_DmaSetup vdmaDMA;
XAxiVdma_Config *vdmaConfig;

XVtc Vtc_inst;

//static int WriteError;

int wr_index=0;
int rd_index=0;


XIicPs ps_i2c0;
XIicPs ps_i2c1;
XGpioPs GPIO_PTR ;


int PsGpioSetup() ;

/*
 * Framebuffers for video data
 */

u8 frameBuf0[1][DEMO_MAX_FRAME] __attribute__ ((aligned(4096)));
u8 *pFrames0; 


void InitVideoFmt(XIicPs *IicInstance,int w, int h)
{

	i2c_reg16_write(IicInstance, 0x36, 0x3808, (w>>8)&0xff);
	i2c_reg16_write(IicInstance, 0x36, 0x3809, (w>>0)&0xff);
	i2c_reg16_write(IicInstance, 0x36, 0x380a, (h>>8)&0xff);
	i2c_reg16_write(IicInstance, 0x36, 0x380b, (h>>0)&0xff);

}

void InitDisplay()
{
    Vtc_init(&Vtc_inst,VMODE_1280x720);
    
}

int main(void)
{

	int i;
    int Status;

	PsGpioSetup() ;

    for (i = 0; i < 1; i++) 
	{
		pFrames0 = frameBuf0[i];
	}
	
	demosaic_init(XPAR_V_DEMOSAIC_0_BASEADDR,VIDEO_COLUMNS,VIDEO_ROWS);

	i2c_init(&ps_i2c0,100000);

    XGpioPs_WritePin(&GPIO_PTR, CAM1_EMIO, 1) ;
	usleep(500000);
	XGpioPs_WritePin(&GPIO_PTR, CAM1_EMIO, 0) ;
	usleep(500000);
	XGpioPs_WritePin(&GPIO_PTR, CAM1_EMIO, 1) ;
	usleep(500000);

	sensor_init(&ps_i2c0);
    InitVideoFmt(&ps_i2c0,VIDEO_COLUMNS,VIDEO_ROWS);



	InitDisplay();

	xil_printf("config done!\r\n");

    vdmaConfig = XAxiVdma_LookupConfig(XPAR_AXI_VDMA_0_BASEADDR);
	XAxiVdma_CfgInitialize(&vdma, vdmaConfig, vdmaConfig->BaseAddress);
	//video = VMODE_1280x720;
	vdmaDMA.FrameDelay = 0;
	vdmaDMA.EnableCircularBuf = 1;
	vdmaDMA.EnableSync = 0;
	vdmaDMA.PointNum = 0;
	vdmaDMA.EnableFrameCounter = 0;

	vdmaDMA.VertSizeInput = 720;
	vdmaDMA.HoriSizeInput = (1280)*3;
	vdmaDMA.FixedFrameStoreAddr = 0;
	vdmaDMA.FrameStoreStartAddr[0] = (u32)  pFrames0[0];
	vdmaDMA.Stride = (1280)*3;

	XAxiVdma_DmaConfig(&vdma, XAXIVDMA_WRITE, &(vdmaDMA));
    XAxiVdma_DmaSetBufferAddr(&vdma, XAXIVDMA_WRITE,vdmaDMA.FrameStoreStartAddr);

	XAxiVdma_DmaConfig(&vdma, XAXIVDMA_READ, &(vdmaDMA));
	XAxiVdma_DmaSetBufferAddr(&vdma, XAXIVDMA_READ,vdmaDMA.FrameStoreStartAddr);


	XAxiVdma_DmaStart(&vdma, XAXIVDMA_WRITE);
	//Status = XAxiVdma_StartParking(&vdma, 0, XAXIVDMA_WRITE);
	XAxiVdma_DmaStart(&vdma, XAXIVDMA_READ);
	//XAxiVdma_StartParking(&vdma, 0, XAXIVDMA_READ);

	while(1){
		XGpioPs_WritePin(&GPIO_PTR, LED_MIO, 0) ;
		usleep(500000);
		XGpioPs_WritePin(&GPIO_PTR, LED_MIO, 1) ;
		usleep(500000);
	}


	return 0;
}


int PsGpioSetup()
{
	XGpioPs_Config *GPIO_CONFIG ;
	int Status ;


	GPIO_CONFIG = XGpioPs_LookupConfig(XPAR_XGPIOPS_0_DEVICE_ID) ;

	Status = XGpioPs_CfgInitialize(&GPIO_PTR, GPIO_CONFIG, GPIO_CONFIG->BaseAddr) ;
	if (Status != XST_SUCCESS)
	{
		return XST_FAILURE ;
	}

	XGpioPs_SetDirectionPin(&GPIO_PTR, LED_MIO, 1) ;
	XGpioPs_SetOutputEnablePin(&GPIO_PTR, LED_MIO, 1) ;

	return XST_SUCCESS ;
}

ILA validation

When the software is running, we can use the ILAs to verify that the image processing pipeline is functioning as expected. These ILAs also play a critical role in system optimization and debugging.

Within the Vivado Hardware Manager the ILA will be remapped to a numerical value. The mapping is shown below:

• ILA1 - Memory ILA.
• ILA2 - Output ILA.
• ILA3 - LCD LCDS ILA.
• ILA4 - Video ILA.

The first step in validation is to monitor the status signals of the AXI4-Stream to Video Out block. This IP provides indicators that show whether the AXI stream and the video timing signals are properly synchronized. If the incoming video timing is mismatched or unstable, the block will fail to lock, preventing video output.

Additionally, because the block includes an internal FIFO, we can observe its overflow and underflow status signals via the ILA. These signals are especially valuable when diagnosing performance issues, such as data starvation or backpressure in the pipeline, and help guide improvements in memory bandwidth or buffering strategies.

Observing the signals on the ILA1 which is the output ILA, we can see the AXI Stream which contains the video is being locked with the timing signals generated by the Video Timing Controller. If the AXI Stream was not synchronised e.g. it was a different format the AXI Stream to Video Out block would not be able to lock.

The next step in the validation process is to check the LCD LVDS output. This stage provides key status indicators that confirm whether the internal clock is locked and whether the interface is enabling downstream data transmission to the display. Monitoring these signals helps ensure that the serialized video stream is being correctly generated and transmitted to the LCD panel, and can quickly highlight issues related to clocking or link enablement.

When it comes to validating the image processing path itself, the first point to check is the video output of the MIPI CSI-2 RX Subsystem. At this stage, we should observe a 10-bit raw output at 4 pixels per clock. If there are issues with the camera configuration or the MIPI interface, this is where they typically become visible—either as no video output or video in an unexpected format. Verifying this output helps confirm that the camera is correctly initialized and that the MIPI link is properly established.

The output of the MIPI CSI-2 RX Subsystem feeds into the Demosaic block, which converts the 10-bit raw Bayer pixel data into a 30-bit RGB format, with 10 bits per color channel (Red, Green, and Blue). Since the pipeline continues to operate at four pixels per clock, the resulting AXI4-Stream output from the Demosaic block is 120 bits wide (4 pixels × 30 bits), maintaining high throughput while delivering fully reconstructed color data.

The LCD display requires 24-bit RGB pixels, with 8 bits per color channel. To meet this requirement, the AXI Subset Converter reduces the pixel depth from 30 bits to 24 bits per pixel. As the system continues to operate at four pixels per clock, the output of the converter becomes 96 bits wide (4 pixels × 24 bits), aligning with the format expected by the downstream video output path.

Finally, on the write path, we can observe the AXI4 transactions writing processed video frames to DDR memory. These transfers are initiated by the VDMA, which bridges the AXI4-Stream video pipeline to the AXI4 memory-mapped interface, enabling efficient storage of frame data via the NoC. Monitoring this activity ensures that frame buffers are being correctly written to memory for subsequent reading and display.

The read path begins with the VDMA issuing AXI4 read transactions over the NoC to retrieve video frames from DDR memory. These transactions move the stored frame data back into the AXI4-Stream domain, where it can flow through the rest of the pipeline toward the display. Observing these AXI4 reads confirms that memory access is functioning correctly and that frames are being fetched in sync with the video output timing.

The final element of the image processing pipeline is the AXI4-Stream output from the VDMA, which delivers one pixel per clock. This stream is fed into the AXI4-Stream to Video Out IP block, where it is synchronized with video timing signals and prepared for display. This handoff marks the transition from memory-based buffering to real-time video output, completing the image pipeline.

By observing all of these ILAs, we gain valuable insight into the internal operation of the image processing pipeline, allowing us to investigate and pinpoint any issues that may arise. Typically, such issues can be traced back to software configuration errors or misconfigured settings on individual IP blocks—as would be expected in early bring-up and integration phases.

Of course, the most immediate and visual confirmation of correct system operation is seeing a live image displayed on the screen—but the ILAs provide the deeper visibility needed when things don’t go as planned.

Wrap Up

In this project, we have explored how to build a simple image processing pipeline on a Versal AI Edge device and validate its functionality. Establishing this foundational pipeline significantly reduces technical risk when moving on to develop the higher-level aspects of the application and its algorithms.

By leveraging Integrated Logic Analyzers (ILAs), we are able to observe and validate critical points within the design, ensuring that each stage behaves as expected. This real-time visibility allows us to quickly and efficiently identify the root cause of any issues that may arise during integration or bring-up, leading to a smoother and more reliable development process.

ChipScope, and its Integrated Logic Analyser are great elements that developers can use to quickly and easily debug an application.