Q&A - Recent Threads

Hold Slack (WHS) Timing Violation within AD9361 IP every impl run

FpgaSoCEngineer — Thu, 13 Aug 2026 03:37:57 GMT

I am using the AD9361 IP in a custom design for a Zynq-7000. The IP itself is copied from the "origin/hdl_2026_r1" off the "hdl" repo.; Unless I go through multiple impl runs with multiple different run strategies I am unable to get a timing clean build out. Here is an example:

WHS fault is on rx_clk within the AD9361 IP. rx_clk is constrained here:
create_clock -name rx_clk -period 4 [get_ports rx_clk_in_p];

AD9364 Reference Clock Requirements

CubecomAdriaan — Wed, 12 Aug 2026 14:15:01 GMT

Hi,

I am designing a transceiver with a RX band of 2.025 - 2.110 GHz and a TX band of 2.200 - 2.290 GHz. I was hoping to use a 125 MHz TCXO in this design, avoiding any harmonics in the RX band (with a single even harmonic in the TX band).
However, after doing some reading, I've found this forum discussion (AD9361- Asynchronous Behavior between DATA_CLK and the reference clock (XTAL_IN)? Could you help me to understand where is the problem and how to resolve it please?), indicating that the reference manual is not accurate and that the range is 10 - 80 MHz. However, the reference manual has not been updated and still states that the input range is 5 - 320 MHz, which can then be prescaled.

Could you please confirm which is true?

Balun recommendation (LTCC type) and design resources for AD936x (470–790 MHz)

kevin0506 — Tue, 11 Aug 2026 23:22:55 GMT

Hi,

I am designing a custom board using the AD936x and Zynq-7000, targeting the 470–790 MHz frequency band.

I need some recommendations for the RF front-end balun.

Transformer-type baluns are too expensive for my budget, so I am looking for LTCC-type baluns instead.

I previously checked the FMCOMMS2 documentation, but the baluns listed there do not cover my target frequency range properly.

https://developer.analog.com/docs/system-level/solutions/reference-designs/fmcomms2/hardware/configuration_options.html

Could you recommend any suitable LTCC baluns for the 470–790 MHz range that can support both transmission and reception?

Additionally, are there any helpful application notes, hardware design guides, or reference materials that I should review when designing a board for this specific frequency band?

Thank you in advance for your help!

Kevin

FMCOMMS5 - External LO Phase Coherence Consistency

UsernameUsurper — Tue, 11 Aug 2026 13:32:56 GMT

Hi there, I'd like to evaluate the FMCOMMS 5, specifically for phase coherent applications, but I'd like a bit more clarity about the phase calibration.

I understand the limitations on phase coherence and the required calibration, even under a shared external LO, but I found this statement in reference [1]:

"When an external LO is used, like with the ADF5355 on the FMComms5 development system, the transceiver still will have a random phase relation, but it is limited to an 0 or 180 degree offset. This offset is due to the input divider on the external LO input pins and cannot be bypassed. This phase relationship is randomized when the transceivers are power cycled or the power of the external LO is reduced to a certain point. This can happen even with an unmuted ADF5355 during large frequency changes."

My application will be switching between a few carriers spaced a ~100MHz from each other every few milliseconds, and I'd idealy only calibrate the phase at startup. My questions are:

Does the input divider phase error mentioned above stay consistent for a specific LO setting, such that if I change frequency and return to the same frequency, the error will be the same? (assuming the device stays on, and the phase errors have been calibrated)
If not, and calibration is required again, how fast does the calibration routine happen?

Thanks in advance!

[1] wiki.analog.com/.../phase-sync

AD9361BBCZ-REEL

qwertyman01 — Tue, 11 Aug 2026 07:12:40 GMT

Hi,

Good day,

May we seek ADi experts,

We have this part label for AD9361BBCZ-REEL, the country of origin indicated on the product body is marked as Korea, while the label shows Taiwan.

For COA, Korea is the packaging location; for COO, Taiwan, China is the wafer origin.

is there any supporting documents or evidence to verify the following information?

COA: Korea is the packaging location.
COO: Taiwan, China is the wafer origin.

thank you.

AD936x TDD control

kevin0506 — Tue, 11 Aug 2026 01:28:20 GMT

Hello, team.
I want to test and build a TDD product using the AD936x IC and Zynq-7000 FPGA.
Should I control the final T/RX switch through the AD936x IC or from the FPGA?

Are there any reference designs or application notes for this?

Thanks in advance.

Kevin

AD9361 Transmit Ch1 + Rx Ch1 and Ch2 Frequency Update rate

SStride — Thu, 06 Aug 2026 15:33:30 GMT

Greetings!

While using the AD9361, are there any issues with transmitting on CH1 (TX1A) and receiving on RX1A and RX2A?

Someone here ran into problems when setting the frequency of TX1A, RX1A and RX2A, and then quickly updating them all to another frequency.

The application requires that the TX frequency be updated/changed at a rate of 400 usec.

Many Thanks,

Scot

Expected receiver sensitivity with 315 MHz Tx and 314.8 MHz Rx LO

Danieljoseph — Mon, 03 Aug 2026 17:52:23 GMT

Hello,

I am implementing a demodulation setup using the AD9364. I am transmitting a signal at 315 MHz, and on the receiver side, the Local Oscillator (LO) is set to 314.8 MHz.

Given this 200 kHz offset, what is the expected receiver sensitivity at the Rx end?

Thank you,

Failure to tune sampling clock at cold temperatures and higher sample rates

ManThu — Fri, 31 Jul 2026 17:53:02 GMT

Hello,

We have been using the AD9364 for a number of years in a design based on the FMCOMMS board. Recently, we noticed that some units fail to lock at cold temperatures. I've boiled the problem down to a fairly simple set of steps:

1. Initial part with the ADI IIO driver.

2. Attempt to set the sampling frequency by using the command line interface:

echo 61440000 > /sys/devices/soc0/axi/e0006000.spi/spi_master/spi1/spi1.0/iio:device0/in_voltage_sampling_frequency

3. Check the error messages via dmesg, which reports the following:

ad9361 spi1.0: ad9361_dig_tune_delay: Tuning RX FAILED! 
SAMPL CLK: 61440000 tuning: RX 
 0:1:2:3:4:5:6:7:8:9:a:b:c:d:e:f: 
0:# # # # # # # # # # # # # # # # 
1:# # # # # # # # # # # # # # # #
When this error occurs we do not get samples that we request over the IIO interface.
I have tried setting the charge pump current according to the information provided here: https://ez.analog.com/rf/wide-band-rf-transceivers/design-support/f/q-a/596266/how-to-debug-timing-calibration-fail-reg-0x6-in-cold-temperature

This made no difference that I can see. We are able to tune lower frequencies (below 57 MHz), but anything above that causes the error.
What else can I look at to figure out why we are having this issue? Some units do not appear to have the problem at all, but some consistently fail to tune the sampling clock.
-Dave

communication between two boards

Marie2808 — Thu, 30 Jul 2026 20:15:09 GMT

Hi,

I saw your message that you successfully built and flashed HDL and no-OS for the FMCOMMS2 board with ZedBoard without changing anything. I'm trying to do the exact same setup and running into build errors, so I'd really appreciate a summary of your overall method.

Could you walk me through, at a high level:

HDL / XSA generation: Which HDL release branch did you use (e.g. 2023_R2, 2023_R2_p1)? Did you build it using make (and if so, on Windows — did you use Cygwin, WSL, or something else), or did you use the Tcl scripts directly in Vivado? Did you run into the util_i2c_mixer VLNV error, and if so how did you resolve it?
Vitis project setup: Once you had the .xsa, how did you create your Vitis project — a standard Platform + Application project through the GUI, or a different flow? Which Vitis version did you use, and did it match your Vivado version exactly?
no-OS software: Which no-OS branch/tag did you use? Did you use the main.c from projects/ad9361/src/ as-is, or did you modify it for FMCOMMS2 (since a lot of examples online are written for FMCOMMS3)?
Verification: Once you flashed and ran it, what exact output did you see on the serial console confirming the AD9361 initialized and communicated correctly?

Any details on your overall workflow — even just a rough step-by-step — would save me a lot of time. Thanks a lot for sharing that you got it working, it's very encouraging to know it's achievable on Windows.

Thanks!

Different sampling rate for baseband rx and tx

olegeorg — Thu, 30 Jul 2026 11:26:37 GMT

Hi,

Is it possible to configure the rx and tx baseband sampling rate differently, e.g. rx = 92.16 MSPS and tx = 102.4 MSPS?

Spurious signals (spurs) observed on the AD9361 output

111544 — Wed, 22 Jul 2026 06:41:12 GMT

"During AD9361 debugging, we encountered the following issue:

Center frequency: 2142 MHz
Output: +15 MHz single tone (i.e., RF output at 2157 MHz)
Observed spurious: At 2097 MHz, approximately -50 dBm, which is exactly at LO - 3×15 MHz = 2097 MHz.
This spur falls outside our filter passband.
We also observed that reducing the digital signal level (TX attenuation / digital scaling) significantly improves this spur.

Question: How can we further suppress this spur while maintaining the same output signal power level? Are there any register settings or hardware measures you would recommend?"

Max streaming capability over UDP

ortigoza — Tue, 21 Jul 2026 14:41:21 GMT

I am trying to build an IQ recording device that will stream samples continuously, with no gaps or dropouts over UDP using Python, the on-board linux environment, and/or iio_readdev calls.

My requirement is to stream 32Msps I/Q over Gigabit Ethernet. Instead of sending 16-bit I and 16-bit Q samples, I am reducing their size down to 8-bits each for a total required Ethernet throughput of 64MB/s

Hardware-wise, I should easily meet 64MB/s

I have tried vibe-coding with Claud the solution and have reached a roadblock of the code reaching 11.72Msps throughput.

Here is a snippet of the diagnostic of it running

The vibe-coding ran many different diagnostic attempts and tests trying to identify the bottleneck either with the Ethernet stackup, the DMA, the ADC, and the processor. Claud says we have reached the theoretical max (11.72Msps) with all of the debugging and diagnostics we have run.

Is there anyone more familiar with this hardware board and it's built up ADC->buffers/DMA->Linux who could chime in and give some real-world architecture advice on how to get the most *LIVE* throughput out of this device over Ethernet?

Or could someone potentially answer if this 11.72 Msps is the theoretical max full streaming through all of the DMA and buffering this design goes through?

I need to have zero gaps in the data and basically need an ADC direct to Ethernet UDP stream.

ADRV9361-Z7035: Intermittent Disappearance of TX/RX IIO Devices During Runtime & Sudden Shutdowns

abdulqadeer — Mon, 20 Jul 2026 09:36:27 GMT

Hello ADI Support Team and Community,

I am facing a critical intermittent issue with my ADRV9361-Z7035 board and would appreciate your expert insights.

The Symptoms:

IIO Devices Disappear Mid-Operation: While the board is running normally and processing data, the TX/RX IIO devices suddenly vanish. The devices cf-ad9361-dds-core-lpc and cf-ad9361-lpc completely drop out of the system during active operation.
Reboot Does NOT Resolve It: Unlike a typical driver crash, issuing a reboot or a quick power-cycle (off/on within a few seconds) does not bring the devices back. Linux boots successfully, but the tx and rx devices are still missing from /sys/bus/iio/devices.
Long "Rest" Recovers Them: The only way to recover the devices is to completely power off the board and leave it unpowered for 5–15 minutes. Upon powering back up after this "rest," the devices reappear and function normally until the next random failure.

Additional Issue:
I am also experiencing sudden complete shutdowns of the board during normal operation.

Receive Antenna Input Switching And Settling Time - 12 Single Ended Antennas

johnwest — Fri, 17 Jul 2026 18:14:11 GMT

Hello,

Datasheet claims 12 single ended antennas can be connected to the AD9361 - questions are:

How fast does the internal switch/mux switch between the inputs?

Can you really connect 12 single ended antennas?

What is the settling time of the input signal after switching to a new antenna?

Thanks In Advance,
John W.

Porting FMCOMMS2 (AD9361) HDL to Versal AI Edge VE2302 using Advanced IO Wizard - Shared PLL/XPHY integration question

saran1080 — Thu, 16 Jul 2026 06:48:34 GMT

Hi,

I'm porting the ADI FMCOMMS2 (AD9361) HDL reference design (2022_r2) to a Versal AI Edge VE2302.

The original receive interface (axi_ad9361_lvds_if.v) uses UltraScale+ primitives (IDELAYE3, IDDRE1, IDELAYCTRL, etc.), which are not available on Versal. To support Versal, I'm replacing the receive interface with a Versal Advanced IO Wizard (XPHY) configured for:

6 LVDS data lanes
1 LVDS frame/strobe
DDR receive
Async FIFO mode

The XPHY correctly produces the deserialized outputs (data_to_fabric_Data_pins_0 and data_to_fabric_Strobe_0), and my intention is to feed these into the existing AD9361 receive processing logic while leaving the rest of the ADI HDL unchanged.

I generated the Advanced IO Wizard with "Include PLL in Core" disabled, so the generated wrapper expects these external inputs:

shared_bank0_pll_clkoutphy_in
shared_bank0_pll_clkout2
shared_bank0_pll_locked_in

ctrl_clk
fifo_rd_clk

I have a few questions:

Shared PLL
- Should these shared PLL signals come from another Advanced IO Wizard/XPHY instance that owns the shared PLL?
- Or is it preferable to regenerate the receive interface with "Include PLL in Core" enabled for a single AD9361 interface?
Recommended architecture
- Has anyone successfully ported the AD9361 LVDS interface to Versal?
- If so, is the recommended approach to replace only the physical receive layer (IDDR/IDELAY) with XPHY while keeping the rest of axi_ad9361_lvds_if.v unchanged?
DDR output ordering
- Is there a documented mapping between the AD9361 LVDS DDR data and the Advanced IO Wizard outputs (data_to_fabric_Data_pins_0)? In other words, how should these bits be mapped to the original rx_data_0_s and rx_data_1_s signals?
Clocking
- For the AD9361 LVDS interface, what are the recommended sources for ctrl_clk and fifo_rd_clk? Is using a fabric 100 MHz clock for both appropriate?
Delay calibration
- The original ADI design exposes software-controlled delay adjustment through up_adc_dld, up_adc_dwdata, etc. With the Advanced IO Wizard/XPHY, is there an equivalent mechanism that should be implemented, or is static timing/calibration generally sufficient for AD9361?

Any guidance or examples of an AD9361-to-Versal implementation would be greatly appreciated.

Are there any internal ADI branches or upcoming releases that add Versal support for the AD9361/FMCOMMS2 HDL reference design, or is replacing the LVDS interface with the Versal Advanced IO Wizard currently the recommended migration path?

Thank you!

How to use the serial console commands to change the parameter setting of the board as per the desired mode

OrionakaOPtimus — Tue, 14 Jul 2026 11:10:20 GMT

So, I wanted to use the AD9361 in "dual port half duplex DDR mode in LVCMOS mode" but I am not able to . I have also uncommented "#define ADI_RF_SOM_CMOS" (if this is correct or not? I don't know that as well)

My question is whether the desired mode can be set through register values in serial console command by "register?" command because if i try "register?0x010" or "register? 0x010" the board becomes unresponsive or no command works after that so How should I do that. if not then how because

AuxADC Internal protection Circuit.

srinivas123 — Tue, 14 Jul 2026 05:30:12 GMT

According to AD9361 Datasheet. The input range to AuxADC pin is 0.05V to 1.25V. Is there any hardware protection inside the AD9361 provided for the AuxADC pin.

Why does the RSSI value stay fixed and wrong when the sampling rate is low?

pzz — Thu, 09 Jul 2026 07:42:35 GMT

I'm using the AD9361 to get the RSSI value, with a bandwidth of 200K and an LO of 1G, for slow attack AGC. When I set the sampling rate to 8.3MHz or higher, I get the correct RSSI value, but if I set the sampling rate to 8.2MHz or lower, the RSSI value stays fixed and is wrong. Do you know why this happens?The RSSI register is set as follows:
ad9361_spi_write(spi,0x150,0x0b);
ad9361_spi_write(spi,0x151,0);
ad9361_spi_write(spi,0x152,0xff);
ad9361_spi_write(spi,0x153,0);
ad9361_spi_write(spi,0x154,0);
ad9361_spi_write(spi,0x155,0);
ad9361_spi_write(spi,0x156,0);
ad9361_spi_write(spi,0x157,0);
ad9361_spi_write(spi,0x158,0x0d); // AGC gain change
ad9361_spi_write(spi,0x15c,0x69);

Seeking Advice on Learning RF for an AD9361-Based BBP Design

Black8 — Mon, 06 Jul 2026 07:32:54 GMT

Hi,

I'm an FPGA engineer working at a startup, and I've recently been asked to design a BBP. I have no experience with this area, but I accepted the challenge. The thing is, I have zero knowledge of EM or RF.

I'll soon be designing a BBP using the AD9361 as the RF frontend. What I wanted to ask is: is it possible to learn enough to become efficient with this chip and debug my BBP design (which will be an OFDM) without having prior RF experience?

I'm willing to learn everything that's needed, but if the learning curve is going to be very long, I need to communicate that to my management. The problem is that no one else in the company has RF experience either.

AD9361 github project can be compiled with Vivado 2024.2

HPBhat2149 — Thu, 02 Jul 2026 07:54:58 GMT

Hello,

I see that currently released AD9361 github project is compiled with Vivado 2023.2 targeted for AMD-Xilinx FPGAs.

I am planning a baselining with Vivado 2024.2 for the HDL implementation with ad9361.

Is there any problem if I directly use vivado 2024.2 for the compilation instead of Vivado 2023.2 ?

With Regards,

Hariprasad Bhat

FMCOMMS5 Tx Line Impedance

abang123 — Fri, 26 Jun 2026 17:50:36 GMT

Hello,

I am having trouble relating the recommendation for Tx line impedance for AD9361 with the layout of the FMCOMMS5 board.

Based on pg. 19 of this site (/cfs-file/__key/communityserver-discussions-components-files/441/8422.FAQRFMatching.pdf), the RF Line systems between the Tx ball pads and the balun reference plane should be designed for 50-ohms differential.

Inspecting this circled region of the FMCOMMS5 layout, the coupled microstrip traces at the Tx ball pads appear to have the following characteristics:

Trace widths: 8 mil

Gap: 6 mil

From this post (https://ez.analog.com/rf/wide-band-rf-transceivers/design-support/f/q-a/588307/stackup-information-ad-fmcomms5-ebz), the stackup for the FMCOMMS5 appears to have 1.6 mil copper thickness on the top/bottom layers and 8.3 mil thick FR4 dielectric between the top/bottom layers and their respective ground planes. Thus,

Height: 8.3 mil

Thickness: 1.6 mil

Dielectric Constant: 4.4 (see "Relative Permittivity" under "Properties" from https://en.wikipedia.org/wiki/FR-4)

Putting these parameters into a coupled microstrip calculator, I get the following:

There appears to be an odd mode impedance of 54 ohms, implying a differential impedance of 2*54 = 108 ohms. This does not seem to follow the recommendation of 50-ohm differential Tx impedance.

Are the trace characteristics and stackup I have used correct? Am I misinterpreting the recommendation? Any help would be appreciated. Thank you!

Request for Gerber Data for ADRV9361-Z7035 SOM Revision F Hardware

abdulqadeer — Wed, 24 Jun 2026 08:01:49 GMT

Hi,

I am working with the ADRV9361-Z7035 SOM, hardware revision F.

Could you please share the Gerber files / PCB fabrication data for this specific hardware revision, or let me know where I can download them from the official Analog Devices resources?

I would also appreciate it if you could confirm whether the available hardware design files correspond exactly to Revision F.

Thank you.

Best regards,
Abdul Qadeer

AXI DMAC -> util_upack2 -> axi_dac_fifo -> AD9361 TX: zero output despite fully verified register state, wiring, and timing (ZedBoard + FMCOMMS3)

Rumi11111 — Wed, 24 Jun 2026 06:07:50 GMT

DMA-fed TX playback through the standard FMCOMMS3 + ZedBoard reference design produces no measurable change in RF output on a spectrum analyzer, despite:

Every relevant software-side register confirmed correct via direct read-back (not just "the API call returned 0")
The full DMA -> upacker -> FIFO -> axi_ad9361 block design connection chain manually verified pin-by-pin against the known-good reference connect_bd_net script -- identical, no discrepancies
Clean implementation timing (WNS +0.276 ns, WHS +0.009 ns)
Reproducible identically on two separate physical boards
DDS-mode TX (same chip, same RF front end, bypassing the DMA path entirely) confirmed working correctly on both boards

This strongly suggests the fault is either inside util_upack2/util_rfifo/axi_ad9361 core logic itself (not the block-design wiring) or something about this core combination that isn't visible from the no-OS driver layer. Posting the full evidence trail in case anyone recognizes this signature or knows of a related erratum.

Hardware / software

Board: ZedBoard + AD-FMCOMMS3-EBZ (tested on two separate units, same result)
HDL: official analogdevicesinc/hdl FMCOMMS2/3 reference design, unmodified, built from GitHub
Software: no-OS, bare-metal Vitis (Cortex-A9), no Linux/IIO in this test path
Vivado 2023.1

What works (control group)

axi_dac_set_datasel(tx_dac, -1, AXI_DAC_DATA_SEL_DDS) + axi_dac_dds_set_frequency/scale produces a clean, correctly-tuned tone on the spectrum analyzer, at the expected RF frequency, on both boards. This confirms: AD9361 init, ENSM/FDD, LO tuning, TX attenuation, RF front end, antenna/cable, and the spectrum analyzer setup are all functioning correctly. DDS mode does not touch the DMA, util_upack2, or axi_ad9361_dac_fifo blocks at all.

What doesn't work

Switching to axi_dac_set_datasel(tx_dac, -1, AXI_DAC_DATA_SEL_DMA) and feeding a cyclic axi_dmac_transfer_start() transfer of either (a) a real NLFM chirp waveform or (b) a trivial alternating +/-16000 test pattern, in the documented 2-words-per-sample I/Q format, produces no detectable change in spectrum analyzer output at the carrier, the LO+/-offset bins, or anywhere across a 50 MHz span with max-hold enabled. The reading is statistically indistinguishable from the reading taken immediately before any DMA transfer was started.

What we verified, with method

ENSM: confirmed in FDD via direct SPI read of REG_STATE (0x017), low nibble == 0x0A, polled and sustained.
LO frequency: ad9361_set_tx_lo_freq() return checked, AND independently confirmed via ad9361_get_tx_lo_freq() read-back matching the commanded value exactly.
TX attenuation: set and read back via ad9361_get_tx_attenuation(), matches commanded value.
DAC datasel: read back directly via axi_dac_read(dac, AXI_DAC_REG_CHAN_CNTRL_7(c), &val) (i.e. 0x0418 + c*0x40) on all 4 channels, both immediately before and after starting the DMA transfer. Reads back 0x2 (DMA) on every channel, every time.
DMAC state: axi_dmac_transfer_start() returns 0. AXI_DMAC_REG_CTRL enable bit set. AXI_DMAC_REG_FLAGS shows both DMA_CYCLIC and DMA_LAST bits set (confirmed against the real bit definitions in axi_dmac.h, not guessed offsets). AXI_DMAC_REG_SRC_ADDRESS matches the buffer's real address exactly. tx_dmac->hw_cyclic == true and transfer size is well within tx_dmac->max_length (16777215), so HW cyclic mode is genuinely active per the driver's own internal logic in axi_dmac_transfer_start().
Buffer integrity: source table and DMA-target DDR buffer compared word-for-word after memcpy + cache flush -- 0 mismatches, buffer contents confirmed non-zero and correct both immediately before and immediately after axi_dmac_transfer_start() is called (i.e. nothing is corrupting the buffer in-flight).
DAC core status register (AXI_DAC_REG_STATUS, 0x005C): polled at 0ms/200ms/1000ms/3000ms after transfer start. bit0 (core OK) stays 1, bits 1-3 (over-range, PN out-of-sync, PN error) stay 0 throughout, on both the NLFM and the test-tone buffer.
Implementation timing: WNS +0.276 ns, WHS +0.009 ns -- no setup or hold violations anywhere in the implemented design.
Block design wiring, dumped pin-by-pin with get_bd_pins/get_bd_nets/get_property DIR and cross-checked against a known-working reference connect_bd_net script for this exact IP combination:
- axi_ad9361_dac_dma/m_axis_data,valid,ready <-> util_ad9361_dac_upack/s_axis_data,valid,ready: correctly cross-connected, matches reference.
- util_ad9361_dac_upack/fifo_rd_data_0..3 -> axi_ad9361_dac_fifo/din_data_0..3: correctly connected, matches reference.
- util_ad9361_dac_upack/fifo_rd_en <- axi_ad9361_dac_fifo/din_valid_0 (single shared strobe, channels 1-3 have no separate din_valid_1/2/3 net): confirmed this is the SAME pattern as the reference design, not a bug (verified against an independent working connect_bd_net script for this IP pairing).
- util_ad9361_dac_upack/enable_0..3 <-> axi_ad9361_dac_fifo/din_enable_0..3: correctly connected, matches reference.
- axi_ad9361_dac_fifo/dout_data_0..3,valid_0..3,enable_0..3 -> axi_ad9361/dac_data_i0/q0/i1/q1, dac_valid_*, dac_enable_*: correctly connected, matches reference.
- axi_ad9361_dac_fifo/dout_unf -> axi_ad9361/dac_dunf: connected (we cannot currently read this status bit from software -- see "what we can't check" below).
- Clocks: m_axis_aclk, upack/clk, fifo/din_clk all share util_ad9361_divclk_clk_out. fifo/dout_clk and axi_ad9361/clk both share axi_ad9361_l_clk. Resets correctly paired on each side. No clock-domain-crossing discrepancy found.

What we can't check (and would appreciate guidance on)

We do not have axi_ad9361.v / up_dac_common.v HDL source in this project (Vitis software project only contains the no-OS driver .c/.h files), so we cannot derive or verify the register address for the DAC-side underflow status bit (dac_dunf, registered somewhere in up_dac_common.v per an older EZ thread) to rule out FIFO underflow on the DAC-clock (dout) side as the cause. If anyone has:

The confirmed register address/offset for reading DAC underflow status via the axi_ad9361 core's AXI-Lite interface from bare-metal/no-OS, or
A known erratum or GitHub issue matching "DMA-sourced TX produces zero output despite fully correct register state" on util_upack2 + util_rfifo + axi_ad9361, or
Any suggestion for what else to check given the above is already verified

...we'd be very grateful. Happy to provide the full main.c, Tcl dump output, or any additional register reads on request.

ad9361 clock path settings

robsch94 — Tue, 23 Jun 2026 12:13:14 GMT

Hey everyone,

we are currently in the process of designing a custom transceiver using the ad9361 chip. For software development and testing, I am using the FMCOMMS3 board on a zedboard carrier and using the no-os drivers. We are using the ad9361 together with its axi_ad9361 FPGA core in LVDS mode.

Currently, I am stuck at setting the clock path frequencies correctly. I am using a FIR filter, in both TX and RX, with a interpolation/decimation of 4. As clock path, I am using [983040000, 491520000, 245760000, 122880000, 122880000, 30720000] for RX and [983040000, 245760000, 122880000, 122880000, 122880000, 30720000] for TX. The filter definition for TX looks like the following and similar for RX:

AD9361_TXFIRConfig tx_fir_config = {    // BPF PASSBAND 3/20 fs to 1/4 fs
    3, // tx
    -6, // tx_gain
    1, // tx_int
    {
        -4, -6, -37, 35, 186, 86, -284, -315,
            107, 219, -4, 271, 558, -307, -1182, -356,
            658, 157, 207, 1648, 790, -2525, -2553, 748,
            865, -476, 3737, 6560, -3583, -14731, -5278, 14819,
            14819, -5278, -14731, -3583, 6560, 3737, -476, 865,
            748, -2553, -2525, 790, 1648, 207, 157, 658,
            -356, -1182, -307, 558, 271, -4, 219, 107,
            -315, -284, 86, 186, 35, -37, -6, -4,
            0, 0, 0, 0, 0, 0, 0, 0,
            0, 0, 0, 0, 0, 0, 0, 0,
            0, 0, 0, 0, 0, 0, 0, 0,
            0, 0, 0, 0, 0, 0, 0, 0,
            0, 0, 0, 0, 0, 0, 0, 0,
            0, 0, 0, 0, 0, 0, 0, 0,
            0, 0, 0, 0, 0, 0, 0, 0,
            0, 0, 0, 0, 0, 0, 0, 0
        }, // tx_coef[128]
    64, // tx_coef_size
    {0, 0, 0, 0, 0, 0}, // tx_path_clks[6]
    0 // tx_bandwidth
};

I am setting the clock path during initialization of the chip, through the AD9361_InitParam and ad9361_init, then set both filters through ad9361_set_tx_fir_config and ad9361_set_rx_fir_config and then enable both filter with ad9361_set_trx_fir_en_dis.

When doing this, I get error messages "Calculating filter rates failed -22 using min frequency". It seems, the driver tries to set 122880000 Hz as data rate instead of the 30720000 Hz, which is more than the chip can supply. When setting lower rates, for example the path [1382400000, 86400000, 28800000, 14400000, 7200000, 1800000], again a rate of 4-times higher than the set 1800000 Hz at 7200000 Hz is commanded, which works.
I am at a complete loss at why this is happening inside the driver, can you give me any hinds on what I am doing wrong?

Thanks a lot for you help
Robin