Debugging Flows & Tools - The industry utilizes a four-step debug process: probing, implementing, analyzing, and fixing [1][2][3] - AMD provides ChipScope debug solution to reduce verification and debugging time, maximizing visibility into programmable logic during system operation [3] - Vivado Logic Analyzer (VLA) interacts with debug cores for triggering and data collection via JTAG pins, supporting various triggering scenarios and flexible probing [4] - Captured data can be reused as test vectors, enhancing design verification, and a single JTAG connection simplifies programming and debugging [5] - Debug cores like Integrated Logic Analyzer (ILA), System ILA, Virtual Input/Output (VIO), and JTAG to AXI Master enable design visibility without obstructing functionality [6] Debug Cores & Features - Integrated Logic Analyzer (ILA) IP core monitors internal signals with advanced features like Boolean trigger equations and edge transition triggers, configurable with up to 1024 probe ports [7] - Virtual Input/Output (VIO) core monitors and drives internal signals in real time, presenting data as virtual LEDs, pushbuttons, or toggle switches [9][10] - JTAG to AXI Master debug feature generates AXI transactions to interact with AXI-Full and AXI-Lite slave cores [11][12] - BSCAN to JTAG Converter core bridges BSCAN and JTAG interfaces for designs supporting JTAG but not BSCAN [13][14] Data Cables & Debug Ports - Platform Cable USB II is a general-purpose cable for programming and debugging, supporting devices with target clock speeds from 750 kHz to 24 MHz via USB 20 [15] - SmartLynq Data cable provides JTAG rates up to 40 Mb/s via Ethernet and USB, supporting JTAG debugging and indirect flash programming [16][17] - SmartLynq+ is designed for high-speed debugging and tracing in Versal Adaptive SoCs, offering trace capture speeds up to 10 Gb/s and up to 14 GB of trace memory [19][20] Probing Flows & Methodologies - HDL instantiation flow involves manual customization and connection of debug cores directly in the HDL design source, requiring re-running synthesis and implementation [22][23] - Netlist insertion flow inserts ILA cores directly into the netlist, eliminating design resynthesis and allowing probing at various design levels [23][24] - Incremental Compile Flow allows modifying debug cores while reusing 95% of prior placement and routing results [36] - ECO Flow focuses on replacing existing debug nets with minimal changes, preserving previous implementation results [37][38] ChipScoPy - ChipScoPy provides a Python interface to program and debug Versal devices, with a 100% Python code base available on githubcom [39] - ChipScoPy enables high-level control of Versal debug IPs, allowing developers to control and communicate with cores like ILA and VIO [39][40]

Overview of PDI and Configuration - PDI file contains device programming data for AMD Versal devices, similar to bitstreams [1] - AMD Versal devices require configuration of multiple blocks (NOC, AI Engine, PL, CIPS) at boot using Configuration Data Objects (CDOs) packaged into a single boot image file [2] - PDI may contain bootloaders, firmware, and user applications [3] - Platform Loader and Manager (PLM) processes the Versal PDI boot image during boot or partial configuration [4] Introduction of PDI Debug Utility - PDI debug utility introduced in Vivado 20242 release assists with debugging programming errors in PLM and BootROM [5] - Utility generates error reports, analyzes errors, provides debugging suggestions, and can be used for programming the PDI and analyzing errors upon failure [6] - Use cases include decoding PLM/ROM errors, analyzing errors from log files or connected hardware, and programming PDI with error analysis [6] PDI Debug Utility Commands and Usage - Basic feature is decoding PDI errors obtained via JTAG or UART output [8] - Analyze-log subcommand analyzes PDI configuration error logs, useful for remote debugging [10][11][12] - List-target subcommand lists targets detected on a JTAG chain to determine the target index [12][13] - Analyze-hw subcommand analyzes configuration errors remotely via JTAG, automatically detecting device details [13][14][15] - Program subcommand configures and analyzes errors remotely via JTAG, showing programming progress and error analysis [17][18]

Demonstration: Running through the IBERT Example in Jupyter notebook. ...

Demonstration: Running through the Memory Access Example in Jupyter notebook. ...

Demonstration: Running through the Fabric Debugging example in Jupyter notebook. ...

This video takes a quick introductory look at the new ChipScoPy API. ...

Software Installation - The video guides the installation of the ChipScoPy API [1] - The installation process includes the official Python install [1] - It covers obtaining the latest version of the ChipScoPy API [1] - The video demonstrates installation on a Windows PC [1]

Overview - This video demonstrates how to obtain the Hardware Server and ChipScope Server from the Unified Installer [1] - This video demonstrates how to connect ChipScoPy to the VCK190 evaluation platform [1]

Challenges with Current NoC Solution - Current NoC IP requires all instances to be placed on a block design canvas, making the block design a bottleneck for teams modifying NoC connectivity or attributes [4][6] - Routing AXI busses through the RTL hierarchy is a tedious process [5][6] - Additional complications arise when considering DFX use cases [6] Modular NoC Solution Overview - The modular NoC solution allows the NoC to be distributed among various design sources and hierarchies, resolving issues with the current solution [7] - The solution comprises three main steps: connecting AXI busses to Xilinx Parameterizable Macros (XPMs), adding constraint files (XDCs) to define connectivity and QoS parameters, and executing the `validate_noc` command [7][9][10] - The `validate_noc` command ensures full connectivity between XPM instances, runs DRCs, and executes the NoC compiler to generate the NoC solution [10][21] Key Features and Benefits - Teams can develop solutions independently, and the tool ensures the NoC is not overcommitted [8][10] - The solution maintains compatibility with the current solution, and simulation, debug flows, Vitis Unified IDE, and system software support are unchanged [11] - The solution is designed with enough flexibility to accommodate future enhancements such as security and isolation features [12] Supported Use Cases - AXI Master in the RTL accessing a port of the DDR memory controller on the block design [25] - A master on the BD accessing a peripheral in the RTL [26] - An RTL master accessing peripherals of the processing subsystem [26] - RTL to RTL NoC transfers [27] Tutorials and Further Learning - A series of tutorials are available for download, covering foundational concepts, DFX basics, advanced NoC properties, advanced DFX topics, and HBM [30]

Welcome to part two of the Modular NoCs series. In this video, you are going to learn about how to add XPMs into your design to utilize the modular NoC. To refresh your memory, the modular NoC solution is comprised of three main steps.Step one is to connect all AXI busses that want to utilize the NoC to Xilinx parameterizable macros or XPMs. . The second step of the process is to add constraint files (or XDCs) to the design that define connectivity and quality of service parameters for each individual NoC c ...