Add MATLAB R2025b and HDL 2026-r1 support - #176
Conversation
Update the release contract to MATLAB R2025b, hdl_2026_r1, and Vivado 2025.1. Adapt AD9081 simulation and ZCU102 HDL Coder integration, preserve BSP generation context, add compatibility coverage, and integrate the ToolboxCommon R2025b access fix.
Use current checkout/setup-python actions and constrain Pygments below 2.20 to remain compatible with the documentation stack's pymdown-extensions release.
Install DSP System Toolbox and Fixed-Point Designer for the R2025b PFilter tests, and download the Google Vale style from its current vale-cli repository.
|
Final hosted verification for
The physical |
|
Additional classification of the earlier managed hardware run (
This run produced no valid JUnit pass result. The later cold-boot/IIO probes remain the authoritative physical diagnosis: the catalog |
|
Additional physical coverage on labgrid DAQ3/VCU118 for head
Infrastructure findings encountered and isolated before the passing run: Nemo's |
The AD9081 System objects assumed a fixed 4-coarse / 4-fine NCO datapath with a contiguous voltage-channel stride. The hdl_2026_r1 m8_l4 reference design instead presents 2 coarse (CDUC) converters shared across 4 fine (FDUC) channels, so the previous assumptions broke physical operation on ZCU102 AD9081-FMCA-EBZ hardware. Fixes, all verified against physical AD9081 on ZCU102 (labgrid mini2) with an HDL-2026-compatible kernel/DTB and MATLAB R2025b: * GetDataPathConfiguration: count unique coarse/fine converter indices instead of raw label occurrences. Several fine paths can share one coarse converter (FDUC1/2/3 -> CDUC0), which previously inflated the coarse count to 4 and produced an invalid attribute map. * CheckAndUpdateHW/HWFloat/HWBool: resolve the physical voltage channel IDs for main_* (coarse) attributes by probing attribute readability at write time, and only when connected to hardware. Coarse-capable channels are non-contiguous on this datapath, and the previous stride assumption wrote main_nco_* to channels that return EINVAL. Resolution now runs inside the connected guard so construction no longer probes a null device pointer. * Tx DDR offload: pl_ddr_fifo_enable was removed from the TX DMA device in the new HDL datapath. Probe for the debug attribute and skip the write when absent so DMA streaming works on both datapath variants. Adds pure mapper regression tests (no hardware required) to R2025bCompatibilityTests covering non-contiguous coarse selection, the too-few-readable error path, and the fully-populated fine case. Physical result: testAD9081Rx passes end-to-end; all construction and DMA-setup errors are eliminated. The remaining TX tone-accuracy checks depend on internal DAC->ADC loopback tone placement in the m8_l4 reference design (the pyadi-dt reference framework observes the same placement offset and only asserts SNR, not exact frequency); that gap is datapath behavior, not a toolbox regression.
AD9081 physical hardware verification — HDL 2026-r1 datapathRan the AD9081 System objects against physical AD9081-FMCA-EBZ on ZCU102 (labgrid Root causes (m8_l4 reference design)The
Results
Remaining TX tone-accuracy gap (characterized, not a toolbox regression)The four TX tests assert the looped-back tone frequency to ±1%. On this bench the internal DAC→ADC loopback tone does not land at the requested frequency:
This tone-placement offset is therefore a property of the m8_l4 reference datapath's DDS/NCO configuration affecting both frameworks, not a regression introduced by this PR. No hardware pass is claimed for the four TX tone tests; the RX data path is verified passing. Hardware: AD9081-FMCA-EBZ + ZCU102 @ labgrid |
The new AD9081 mapper regression tests called a static method on adi.AD9081.Base, which forces MATLAB to load the class and its matlabshared.libiio.base superclass. The hosted Build Toolbox runner has no libiio hardware support package, so the class fails to parse and the tests error with MATLAB:class:InvalidSuperClass. Extract the pure selection logic into a standalone package function adi.AD9081.selectReadableAttributeChannelIDs (no libiio dependency); Base retains a thin static forwarder for backward compatibility. The compatibility tests now call the package function directly, so they run on any MATLAB install without the libiio support package.
Correction + refined analysis: TX tone is coherent, but mis-placed in frequencyMy earlier comment described the MATLAB RX capture as "noise-dominated." That characterization was imprecise — it came from a raw So the MATLAB DDS path does deliver a coherent looped-back tone (SNR 25 dB), directly comparable to the reference run on the same board (1 MHz request → 106.8 kHz peak, SNR 22.5 dB). Precise root cause of the four TX failuresOn this m8_l4 datapath the looped-back tone is coherent but does not land at the commanded frequency — in either framework:
The DDS tone routing itself was verified correct offline: MATLAB's ConclusionThis is a datapath/DDS-configuration behavior of the m8_l4 reference design, not a HighSpeedConverterToolbox regression: both frameworks see the identical coherent-but-frequency-compressed tone. The MATLAB tests are simply stricter (exact frequency vs SNR-only) and correctly flag it. No hardware pass is claimed for the four TX tone tests. Closing the gap would require HDL/driver-side investigation of the DDS-to-DAC frequency mapping on m8_l4 (out of scope for this toolbox PR), not a toolbox code change — and I will not relax the frequency assertion to force green. The three toolbox bugs this PR fixes are independently verified: |
The R2025b/hdl_2026_r1 migration was verified on AD9081/ZCU102, but the other targeting platforms (daq2, ad9434, ad9265, ad9783, ad9208, plus fmcjesdadc1/ad9739a) failed BSP project generation on Vivado 2025.1. Six distinct issues, all in the toolbox's HDL Coder integration and BSP staging, were surfaced by running BSPTests (SynthesizeDesign=false) and fixed. AD9081 was immune because its reference design does not use the transceiver wizard or the classic CPU interconnect. Verified end-to-end: daq2/zcu102 rx now completes "Create Project" and the full IP Core Generation workflow on Vivado 2025.1. Fixes: 1. build_bsp.sh: stop overwriting the HDL branch's adi_project_xilinx.tcl with the stale toolbox fork. Since hdl_2026_r1 the reference designs call adi_xcvr_project, defined only in the branch copy; the fork broke "Create Project" with 'invalid command name "adi_xcvr_project"'. Keep the branch version (it already supports the MATLAB in-memory flow via ADI_MATLAB) and add a guard that fails fast if a future branch drops the proc. 2. system_project_rxtx.tcl: set ADI_MATLAB (the hdl_2026_r1 env contract) alongside the legacy MATLAB var so the top-level design reuses HDL Coder's in-memory project instead of calling create_project. 3. plugin_rd.m: add quiet.mk and Makefile to CustomFiles. The nested xcvr_wizard sub-build shells out to make, whose Makefile chain includes the HDL-root quiet.mk; HDL Coder only copies the folders listed in CustomFiles into the work area, so the root file was missing and the sub-make failed with "../../../quiet.mk: No such file or directory". 4. patch_xcvr_matlab_env.py (new, invoked by build_bsp.sh): patch the branch's adi_project_xilinx.tcl so adi_xcvr_project (a) runs its nested make with ADI_MATLAB/MATLAB unset -- otherwise the standalone xcvr_wizard Vivado inherits in-memory mode, skips create_project, and dies with "No projects are currently open" -- and (b) globs for the generated <xcvr>_cfng.txt when the reconstructed path is absent, since the Makefile's output-directory token order (RATE_REFCLK_PLLTYPE) does not match the Tcl reconstruction when ADI_PROJECT_DIR is unset. 5. matlab_processors.tcl: resolve the CPU/control AXI interconnect cell dynamically (adi_cpu_interconnect_cell) instead of hardcoding axi_cpu_interconnect. hdl_2026_r1 renamed it to a carrier-specific SmartConnect (axi_hpm0_lpd_interconnect on ZynqMP, axi_gp0_interconnect on Zynq-7000, axi_axi_interconnect on MicroBlaze), so the post-build preprocessing matched zero cells and failed "'set_property' expects at least one object". 6. get_memory_axi_interface_info.m: update the AXI4-Lite insertion point for every platform to the hdl_2026_r1 interconnect name (only the AD9081 entry had been migrated). HDL Coder's generated vivado_insert_ip.tcl otherwise connected the DUT to a non-existent axi_cpu_interconnect/M**_AXI and failed with empty connect_bd_intf_net arguments.
Multi-platform BSP build support on Vivado 2025.1 / hdl_2026_r1The migration was verified on AD9081/ZCU102, but the other targeting platforms failed BSP project generation on Vivado 2025.1. Running Commit
Verifieddaq2/zcu102 rx: PASS end-to-end on Vivado 2025.1 — "Task Create Project successful", full IP Core Generation workflow complete, build finished without exception. (No BOOT.BIN is expected: that requires The remaining platforms — ad9434/zc706, ad9265/zc706, ad9783/zcu102, ad9208/vcu118, and daq2 tx/rxtx — are building now with the same fixes to confirm they generalize; I'll post the completed per-platform matrix when the sequence finishes. No hardware/bitstream synthesis was run; this validates project generation and IP packaging only. |
Multi-platform BSP build matrix on Vivado 2025.1 / hdl_2026_r1 — completeRan project generation (
ad9208 / vcu118 — not a migration issueThis is the one MicroBlaze design, and its That is a Vivado IP-license limitation of the build host ( Summary
|
1 participant
Summary
hdl_2026_r1, Vivado 2025.1, and toolbox 25.2.1axi_hpm0_lpd_interconnect/M11_AXIand preserve target Tcl globals across HDL library buildsToolboxCommonmethod-access fix from Fix debug method access for MATLAB R2025b ToolboxCommon#24Verification
HDLBRANCH=hdl_2026_r1 bash build_bsp.sh: passedAnalogDevicesHighSpeedConverterToolbox_v25.2.1.mltbx: 26,642,280 bytes, 3,628 entries; archive inspection found no transient lab/test artifactsgit diff --check: passedPhysical AD9081 status
mini2was acquired and cold-booted repeatedly. The MATLAB hardware runner reached the board, but all five tests were blocked before data-path exercise because the catalog-default2023_R2_P1image does not initialize the converter:xilinx-amsandhmc7044ad9081 spi1.0: PLL not lockedad9081: probe of spi1.0 failed with error -21FindDeviceFailThe labgrid Kuiper downloader currently supports only 2018_R2, 2019_R1, and 2023_R2_P1, so no 2026-r1 boot image is selectable through
adi-lg --bootfile. This is recorded as an external hardware/image blocker; no physical pass is claimed.