RF & microwave forum - Recent Threads

AFE7950EVM: FE7950EVM + ZCU104: DAC JESD re-asserts SYNC with no alarms

Ngoc Hai Nguyen — Sat, 17 Oct 2026 10:17:43 GMT

Part Number: AFE7950EVM

Hi TI team,

I am bringing up the AFE7950EVM with a Xilinx ZCU104 instead of the TSW14J58. The ADC link works, but the DAC link (FPGA -> AFE) never reaches the data phase. I have followed the debug steps in the "AFE79xx JESD App Note" (sections 6 and 8). All of the listed checks pass, but the link still does not come up. Details are below.

1. Setup
- AFE7950EVM on the ZCU104 FMC connector (LPC). Only DP0 is available on LPC, so I use AFE STX7 (ADC) and SRX8 (DAC), i.e. channel C/CD.
- FPGA: TI204c IP v1.12 (8b/10b), GTH, 1 lane each direction. tx_sys_clock = rx_sys_clock = 122.88 MHz (lane rate / 80). FPGA refclk and core clock come from the LMK04828 on the EVM.
- Latte 2.9, configuration file attached (afe_zcu104_14810_v6.xlsx):
- LMFS 14810 for both RX and TX, 9.8304 Gbps, JESD204B subclass 1, K = 16, 122.88 MSPS
- syncLoopBack = 1 (hardware SYNC)
- jesdRxSyncMux = [2,2,2,2] -> DAC SYNC~ is driven out on FMC H7 (GPIO "DAC_SYNC0")
- ADC SYNC~ input on FMC H8 ("ADC_SYNC0")
- jesdRxLaneMux = [0,1,2,3,7,5,6,4] (SRX8 -> CD lane 0)
- jesdTxLaneMux = [0,1,2,3,6,5,4,7] (CD lane 0 -> STX7)
- skipFpga = True
- Note: DAC JESD-RX 0 (AB) has no lanes connected on the ZCU104 FMC LPC, so I think its LOS / Serdes-FIFO alarm in the log is normal for this setup. Only link CD is used.

2. What works
- ADC link (AFE STX7 -> FPGA) is up with hardware SYNC. The RX ramp test pattern is received with 0 errors over 1024 consecutive samples.
- Physical layer FPGA -> AFE SRX8 is clean: PRBS9 from the FPGA GTH, checked with enableSerdesRxPrbsCheck(0,7,0,1) / getSerdesRxPrbsError(0,7), gives 0 errors.
- Physical layer AFE STX7 -> FPGA: PRBS9 locked, 0 errors.

3. DAC link status (link CD) after AFE.adcDacSync(checkForLink=False)
Read with AFE.JESD.DACJESD[1].getJesdAlarms(0), i.e. without clearing alarms
- comma_align_lock_flag = 1
- JESD_CS_STATE (0xA2) = 0x02 -> lane 0 CS = 2
- JESD_FS_STATE (0xA4) = 0x00
- JESD_BUF_STATE (0xA6) = 0x00
- ALARMS 0x118-0x11F = all 0 (no LOS, no Serdes-FIFO, no lane errors)
- TX_DAC_SYSREF_FLAG (0xF0[7:4]) = 0xF after adcDacSync, cleared before the call
- lane_ena = 0x1, link0_init_state = 0, lane0_sync_err_cnt = 0

4. SYNC~ behavior
In captures A and B no SYSREF pulse reaches the FPGA, so only SYNC~ and the free-running FPGA LMFC (every 16 clocks, K = 16) are active.
- ila_A_sync_rise_sysref_gated.png: trigger on the SYNC~ rising edge, then AFE.adcDacSync() is run. The AFE releases SYNC~ (low -> high).
- ila_B_sync_fall_sysref_gated.png: trigger on the SYNC~ falling edge, then AFE.adcDacSync(checkForLink=False) is run. SYNC~ is high and then goes low again. After that it stays low: the AFE keeps requesting K28.5, CS stays 2 and FS stays 0.
- ila_A2_sync_rise_sysref_enabled.png: same as A, but with the FPGA SYSREF input enabled. A few irregular SYSREF pulses reach the FPGA (adcDacSync does not enable the LMK SYSREF in this mode) and the FPGA LMFC re-aligns to them.

SYNC~ behaves the same as in A and B: it is released, later re-asserted, and the final state is the same (CS = 2, FS = 0, no alarms). So SYSREF at the FPGA does not change the result.
- So the AFE does release SYNC~, then re-asserts it, but no error bit is latched to explain the re-sync request.

5. Questions
a) In which conditions does the DAC JESD RX re-assert SYNC~ without setting any alarm bit (link0_sync_request_ena reads 0xDF, i.e. every lane error except link configuration error can trigger a sync request)?
b) With syncLoopBack = 1 and a non-TSW FPGA, adcDacSync() only calls TOP.leakSysrefToDig() (the LMK SYSREF branch is only for the TSW). Does the DAC JESD RX need an external periodic SYSREF from the LMK (e.g. continuous mode) for ILAS / FS to complete? If yes, what is the recommended LMK setting and sequence for a custom FPGA?
c) Is anything extra needed when the only DAC lane is SRX8 routed through the lane mux to CD lane 0 (rxoctetpath4_sel = rxoctetpath4_clk_sel = 7)?
d) Is there a register that shows the reason for the last sync request, or the internal SYNC~ state of link0?

afe_zcu104_14810_v6.xlsx

AFE7903: AFE7903: JESD204B subclass 1 - internal LMFC offset from SYSREF differs by 0-7 frame-clock cycles across bring-ups

Xu Li — Sat, 19 Sep 2026 19:25:42 GMT

Part Number: AFE7903

Part/configuration

AFE7903 (chip version 0x12), external 6 GHz device clock (source from LMX2820, on-chip PLL bypassed).
TI LATTE originally generated the configuration.
RX: ADC 3 GSPS, DDC decimation 6x, 500 MSPS complex; TX: DAC 6 GSPS, DUC interpolation 12x; NCOs are set to 750 MHz.
JESD204B subclass 1 both directions: L=4, M=4, F=2, S=1, K=16, N=N'=16, scrambling on, 10 Gbps lanes, FPGA
- (Zynq UltraScale+ GTH) as the link partner. Multiframe = 8 frame-clock (250 MHz) cycles = 32 ns.
SYSREF: 3.472222 MHz single pulses from an LMK5B33216 (288 ns period = 9 multiframes), DC-coupled, captured on the
- device clock with the SYSREF timing monitor centered ("sufficient margin" reading, stable over 20 sweeps). The FPGA's
- LMFC takes the same SYSREF event on a separate LMK output.
Bring-up: the Latte-generated sequence, RESETZ toggled before each bring-up; one SYSREF pulse at `configurePll`
- and one at `sysrefJesdLinkup`; JESD SYSREF mode "use all".

What we see

After each full bring-up, the DAC JESD `lane0_f_counter_all_lanes_ready` (what `getAllLaneReady` returns) takes a different value, spread uniformly over 0-7 (FK/4 = 8) - e.g. 0, 7, 2, 2, 7, 4, 0, 6, 1, 0 over ten bring-ups. The FPGA's own LMFC holds a fixed phase to the SYSREF edge throughout (verified on every bring-up), and the ADC framer's multiframe arrives at the FPGA shifted by the same amount the other way, so the offset is the AFE's internal LMFC against the SYSREF edge, common to the ADC and DAC JESD blocks - a whole number of frame-clock cycles, drawn once per bring-up:

Within one bring-up, it holds: repeated `adcDacSync(pinSysref=1)` relinks return the same count.
It follows the SYSREF edge: delaying only the AFE's SYSREF by 4.0 ns (24 device clocks, the capture margin unchanged) and relinking moves the count by exactly one, and back.
The DAC-to-ADC loop latency stays constant as long as the arrival does not cross an RBD boundary, as subclass 1
predicts - but with the offset spread over the whole multiframe, no fixed RBD (on either side) has margin across

What we tried: no change to the spread

SYSREF mode "use all" and "skip one then use all", with one pulse and with a three-pulse burst at the link-up (the burst also shifts the loop latency by half a multiframe - the ADC and DAC directions appear to align to different pulses of the burst).
Taking the SYSREF at `configurePll` from the SPI strobe instead of the pin (the count stays spread; the ADC's divide-by-2 phase then flips half the time, as expected).
Clock-divider dither off, and the SYSREF selection alternatives available in the JESD configuration.
Register read-back of the JESD, JESD subchip, digital top, timing controller, top analog, and PLL pages after each of twenty bring-ups: no register other than the f-counters themselves correlates with the offset; the async FIFO pointer readings are stable within one.

Questions

Is the internal LMFC's phase relative to the latched SYSREF edge expected to be the same on every RESETZ bring-up in this configuration? If yes, which part of the sequence establishes it, and what does it need (pulse count, pulse timing relative to a particular step, the SYSREF leak counts, the SYSREF source)?
Is there a divider or counter on the SYSREF path to the JESD LMFC - with a period of a multiframe or more - that is started by an SPI write rather than by SYSREF, and how is it synchronized?
The SYSREF leak counts (digital 2, RX 2, FB 2, DAC 5 in our sequence): are they strobes per external SYSREF edge, or per arm of the SYSREF latch?
`setGoodRbd`'s note says deterministic latency across bring-ups needs `getAllLaneReady` once and the same RBD each time. Does that assume the internal LMFC is deterministic to SYSREF, and is there an application note on it?

We can share full register dumps, the bring-up sequence, and the measurement logs privately.

RE: AFE7903: AFE7903: JESD204B subclass 1 - internal LMFC offset from SYSREF differs by 0-7 frame-clock cycles across bring-ups

Xu Li — Fri, 16 Oct 2026 21:20:16 GMT

Below is the exact code I used to generate AFE bring up code, as well as the "sysref_delay_sweep()" for LMK5 clock chip (which is differs from the AFE79xx evaluation board)

##############################################################################
# AFE7903 - JESD204B subclass 1: LMFC-offset test, written for TI Latte
#
# Latte libraries 79xx-2.9.0 (19 Aug 2025), chip version 2.0. Runs in the Latte
# Scripts window (embedded Python 2.7), where AFE, sysParams and setupParams
# already exist.
#
# Our board runs this same sequence from its own firmware (no Latte, no TI EVM):
# it replays the register sequence Latte generated from section 1a's
# parameters, with section 1b's one change, and adds the steps in sections
# 3-6. This file states that procedure in Latte terms, so it can be read - or
# rerun on an EVM - without our tooling. Board-only actions (clock chips,
# SYSREF requests, the FPGA, our loop measurement) are stubs in section 2;
# each says what our hardware does at that point.
##############################################################################

import time

##############################################################################
# 1a. THE PROFILE - exactly what Latte used to generate our sequence
#
# Taken from the parameter dump Latte wrote at the top of the generated file.
# Anything not listed is Latte's default.
##############################################################################

sysParams = AFE.systemParams
sysParams.__init__()
sysParams.chipVersion = chipVersion
setupParams.skipFpga = 1 # our FPGA is not TI's capture card

# Clocking: external 6 GHz device clock into REFCLK, the AFE PLL bypassed.
sysParams.externalClockRx = True
sysParams.externalClockTx = True
sysParams.FRef = 6000.0 # device clock, MHz
sysParams.Fdac = 6000.0 # DAC at the device clock
sysParams.FadcRx = 3000.0 # ADC at device clock / 2
sysParams.FadcFb = 3000.0 # FB disabled; kept equal to RX

# Channels: AFE7903 2T2R - RX A and C, TX B and D. TDD, RRF mode 5.
sysParams.RRFMode = 5
sysParams.modeTdd = 2
sysParams.spiMode = 1
sysParams.rxEnable = [True, False, True, False]
sysParams.txEnable = [False, True, False, True]
sysParams.fbEnable = [False, False]
sysParams.ddcFactorRx = [6, 6, 6, 6] # 3000 / 6 = 500 MSPS
sysParams.ducFactorTx = [12, 12, 12, 12] # 6000 / 12 = 500 MSPS
sysParams.ddcFactorFb = [6, 6]
sysParams.rxNco0 = [[750.0, 750.0], [750.0, 750.0], [750.0, 750.0], [750.0, 750.0]]
sysParams.txNco0 = [[750.0, 750.0], [750.0, 750.0], [750.0, 750.0], [750.0, 750.0]]

# JESD204B, both directions: L=4 M=4 F=2 S=1 HD=0, K=16, scrambled, 10 Gbps.
# LMFC = 10 Gbps / (10 x F x K) = 31.25 MHz (a 32 ns multiframe)
# LMFC counter range: F x K / 4 = 8 counts (0..7), one count = 4 ns
sysParams.jesdSystemMode = [3, 3]
sysParams.jesdTxProtocol = [0, 0] # 0 = JESD204B
sysParams.jesdRxProtocol = [0, 0]
sysParams.LMFSHdRx = ["44210"] * 4 # ADC side, AFE -> FPGA
sysParams.LMFSHdTx = ["44210"] * 4 # DAC side, FPGA -> AFE (the link under test)
sysParams.LMFSHdFb = ["22210"] * 2 # inert, FB disabled
sysParams.rxJesdTxK = [16, 16, 16, 16]
sysParams.jesdRxK = [16, 16, 16, 16]
sysParams.rxJesdTxScr = [True, True, True, True]
sysParams.jesdRxScr = [True, True, True, True]
sysParams.jesdRxRbd = [4, 4, 4, 4] # Latte's default; replaced per bring-up in section 6
sysParams.jesdRxInitLmfcCounter = [0, 0, 0, 0] # no LMFC counter shift
sysParams.jesdTxIlaM = [4, 4, 2, 4, 4, 2]
sysParams.jesdTxIlaL = [4, 4, 2, 4, 4, 2]
sysParams.jesdTxIlaLid = [0, 1, 2, 3, 4, 5, 6, 7]
sysParams.jesdRxLaneMux = [0, 1, 2, 3, 4, 5, 6, 7]
sysParams.jesdTxLaneMux = [0, 1, 2, 3, 4, 5, 6, 7]
sysParams.rxDataMux = [0, 1, 4, 5, 2, 3, 6, 7]
sysParams.txDataMux = [0, 1, 4, 5, 2, 3, 6, 7]

# SYNC~ on the hardware pins (SBAA417 3.4). The FPGA drives lanes 4-7
# (SRX5-8) into the CD deframer, and the DAC-side SYNC~ leaves on H9.
sysParams.syncLoopBack = True
sysParams.jesdRxSyncMux = [2, 2, 2, 2]
sysParams.jesdABLvdsSync = 1
sysParams.jesdCDLvdsSync = 0

# SerDes: firmware adaptation on; TX main cursor 3 on lanes 0 and 7.
sysParams.serdesFirmware = True
sysParams.serdesTxMainCursor = [3, 0, 0, 0, 0, 0, 0, 3]

# SYSREF: pin SYSREF, pulsed (never continuous), 100 ohm termination.
# Frequency 3.472222 MHz = 250 MHz / 72, period 288 ns = 9 LMFC periods.
# One positive pulse per request, 144 ns wide, from an idle-low line;
# the AFE takes the leading (rising) edge. Two requests per bring-up, at
# Latte's two "External-Action: Give Sysref Here" markers (pllConfig step 1
# and sysrefJesdLinkup step 3). Source: LMK5B33216, output pair 0/1 in
# pulser mode, pulse count 1.
sysParams.useSpiSysref = False
sysParams.continuousSysref = False
sysParams.sysrefTermination = 0

# Our part reports MCU firmware 15005, so Latte loads topPatch2P0_15000.hex.

##############################################################################
# 1b. OUR ONE CHANGE TO THE GENERATED SEQUENCE
#
# Step 31 (miscConfig/step1) sets every RX and TX DSA to 5 dB instead of 0, for
# our bench's RF loop pad. Latte applies these two parameters at that step;
# setRxDsa takes dB (5.0 -> index 10), setTxDsa takes 1 dB steps.
##############################################################################

sysParams.defaultRxDsa = [5.0, 5.0, 5.0, 5.0]
sysParams.defaultTxDsa = [5, 5, 5, 5]
sysParams.defaultFbDsa = [0, 0]

##############################################################################
# 2. BOARD HOOKS - what our firmware does outside Latte
#
# On TI's EVM these are the EVM's own controls (its LMK04828 SYSREF, its reset).
##############################################################################

AFE_INST = 0
CD_LINK = 2 # CAFE link number: 2 = DAC JESD CD instance, link 0 (our link)

def board_reset_afe():
"""SLEEP low, then RESETZ pulsed low. The device clock and the FPGA keep running."""
pass

def board_set_sysref_delay(code):
"""LMK5B33216 SYSREF analog delay (ADLY) on the AFE's SYSREF output,
32 codes of about 12.5 ps. On TI's EVM: the LMK04828 SYSREF delay."""
pass

def board_fire_sysref():
"""One SYSREF request: one 144 ns pulse at the AFE pin (and at the FPGA's)."""
pass

def board_fpga_before_bringup():
"""FPGA, TI's order (SBAA417 Fig 23), before the AFE is touched:
- GT transmitters running, sending K28.5, so the AFE's SRX adapts on live data;
- TX link layer enabled: K28.5 until the AFE releases the DAC-side SYNC~ (H9),
then the ILAS from the FPGA's first LMFC edge, then data (zeros);
- RX link layer, LMFC and sample gearboxes disarmed; GT receivers in reset.
During deviceBringup, at step 35, the FPGA arms its LMFC for the same pin
SYSREF pulse the AFE takes at step 36. (Latte cannot pause there; with
SYSREF = 9 LMFC periods any pulse gives the FPGA's LMFC the same phase.)"""
pass

def board_fpga_after_bringup():
"""FPGA, after the AFE is up and its TDD override is set: GT receivers
released against the AFE framers' K28.5; its RX link layer releases the
ADC-side SYNC~ (H8) and, after the ILAS, releases its lane buffers at FPGA
LMFC count 0 (its reset value - no compensation in this test); the sample
gearboxes armed."""
pass

def board_fpga_set_release(rbd):
"""FPGA's own RX elastic-buffer release point, in LMFC counts (0..7)."""
pass

def board_fpga_disarm():
"""FPGA's RX link layer, LMFC and sample gearboxes disarmed, its GT
receivers held, before a relink re-runs the link-up."""
pass

def board_measure_loop():
"""Our RF loop, which gives the latency and phase this test reports. The
FPGA sends a 10.0098 MHz tone at -30 dBFS on channel A, started on its LMFC
tick; DAC TX B (TX2) -> cable and pad -> ADC RX A (RX1). An FPGA logic
analyser counts 500 MSPS samples from the tone's first sample entering the
FPGA's TX path to its first sample out of the FPGA's RX path, and reads its
phase there. Three bursts per bring-up. Returns (latency_samples, phase_degrees)."""
return (None, None)

def board_dump_registers():
"""Every register of the JESD, subchip, DIGTOP, timing-controller,
top-analog and PLL pages, read after the measurement (sent to TI privately)."""
pass

##############################################################################
# 3. ONCE PER POWER-UP: put SYSREF on one fixed 6 GHz edge
#
# TI's SYSREF alignment detector (readSysrefMonitor, new in 79xx-2.9.0):
# "Readout value 6: SYSREF alignment has sufficient margin. Other readout
# values: SYSREF is in window of timing uncertainty, Advance/delay SYSREF in
# steps of 10-15ps to enter valid window."
#
# We sweep the delay over all 32 codes and park it at the centre of the
# longest run of readout 6. On our board every sweep finds the same two
# windows, one 6 GHz period (167 ps, 13 codes) apart: the latch is deterministic.
#
# Our firmware sweeps on a part brought up through pllConfig only, then starts
# the measured bring-ups from reset. Latte cannot stop deviceBringup part-way,
# so here the sweep follows a full bring-up; that is equivalent, because the
# armed detector takes its pulse for itself and every bring-up below starts
# again from reset.
##############################################################################

def sysref_delay_sweep():
# The detector needs the MCU awake and the clock tree up (steps 0-7).
board_reset_afe()
AFE.deviceBringup()

passes = []
for code in range(32):
board_set_sysref_delay(code)
# readSysrefMonitor waits for one pin pulse while it is armed.
status, readout = setupParams.CAFE.readSysrefMonitor(AFE_INST)
print("SYSREF delay %2d: monitor readout %d%s"
% (code, readout, " <- sufficient margin" if readout == 6 else ""))
if readout == 6:
passes.append(code)

# Longest run of passes (a one-code hole bridged); park at its centre.
best = (-1, -1)
i = 0
while i < len(passes):
j = i
while j + 1 < len(passes) and passes[j + 1] - passes[j] <= 2:
j += 1
if passes[j] - passes[i] > best[1] - best[0]:
best = (passes[i], passes[j])
i = j + 1
if best[0] < 0:
raise Exception("no readout-6 window: SYSREF cannot be placed")
centre = (best[0] + best[1]) // 2
board_set_sysref_delay(centre)
print("SYSREF delay parked at %d (window %d-%d)" % (centre, best[0], best[1]))
return centre

##############################################################################
# 4. ONE BRING-UP
##############################################################################

def bring_up():
board_fpga_before_bringup()
board_reset_afe() # Latte's "External-Action: Toggle HW Reset"
AFE.deviceBringup() # TI's sequence; SYSREF is requested at its two
# "Give Sysref Here" markers (steps 7 and 36).
# Our firmware stops after step 41: step 42
# (dlJesdLinkupCheck) only reads the deframer's
# status, which section 5 reads instead.

# Every receive lane must have adapted (we added this 2026-09-23; the
# LMFC spread below was measured both before and after it). Our firmware
# checks this before the link is armed; after deviceBringup in Latte, the
# equivalent is a re-adapt followed by a relink.
status, lanes = setupParams.CAFE.pollSerdesLinkStatusAllLanes(AFE_INST)
if lanes != 0xFF:
print("SerDes lanes not adapted: 0x%02X - re-adapting and relinking" % lanes)
setupParams.CAFE.reAdaptSerDesAllLanes(AFE_INST)
setupParams.CAFE.adcDacSync(AFE_INST, 1)

# TI's GUI forces the TDD chains on after bring-up; we force only the
# populated ones: RX A+C, FB off, TX B+D.
AFE.TOP.overrideTdd(0x5, 0x0, 0xA, 1)

board_fpga_after_bringup()

##############################################################################
# 5. THE MEASUREMENT - what we read after every bring-up
##############################################################################

def read_arrival():
"""f_counter_all_lane_ready of the CD deframer (SBAA543 Table 4-1)."""
status, count = setupParams.CAFE.getAllLaneReady(AFE_INST, CD_LINK)
return count

def read_link_record():
status, opp = setupParams.CAFE.getSysrefCntOnReleaseOpp(AFE_INST, CD_LINK)
for i in range(2): # as Latte's dlJesdLinkupCheck does
AFE.JESD.DACJESD[i].getJesdAlarms(0)
return opp

##############################################################################
# 6. THE TEST - the arrival count over N bring-ups
#
# Expected for subclass 1 with a deterministic SYSREF: the same count every
# time (SBAA543 3.1, 4.2). Measured on our board: 0..7 - the whole LMFC
# period - drawn once per bring-up and held until the next reset.
# adcDacSync usually keeps it, but redrew it in 2 of 37 link-ups.
#
# This is the test as run on 2026-10-16, twice: bench fans off (AFE die
# 74-92 C) and on (62-66 C). Both gave the same result - see the end.
##############################################################################

N_BRINGUPS = 20

sysref_delay_sweep()

histogram = [0] * 8
late_counts = []
for n in range(N_BRINGUPS):
bring_up()
count = read_arrival()
opp = read_link_record()
latency, phase = board_measure_loop()
board_dump_registers()
histogram[count % 8] += 1
if latency is not None and latency > 510:
late_counts.append(count)
print("bring-up %2d: f_counter_all_lane_ready = %d, sysref_cnt_on_release_opportunity = %d, loop %s samples"
% (n + 1, count, opp, latency))

print("arrival count over %d bring-ups: %s" % (N_BRINGUPS, histogram))
print("counts of the late (517-sample) bring-ups: %s" % sorted(late_counts))
# A frozen RBD (SBAA543 4.2) needs all_lane_ready < RBD on every bring-up
# (p.10). With the count spread over all 8 values no single RBD satisfies it.
# Measured 2026-10-16 with Latte's default RBD (rbd_m1 = 3) and the FPGA's
# release at 0, two series of 20 bring-ups:
# fans off, AFE die 74-92 C: counts on all 8 values; loop 501 samples x15, 517 x5
# fans on, AFE die 62-66 C: counts on all 8 values; loop 501 samples x15, 517 x5
# In both, the late (517-sample, one multiframe later) bring-ups are exactly
# those whose count read 4 or 5.

##############################################################################
# 7. OUR WORKAROUND - placement on every bring-up (enable to run)
#
# SBAA543 3.2's formula, applied at every boot instead of once:
# AFE RBD (rbd_m1) = (count + 4) mod 8
# and the FPGA's release moved by the opposite amount, so the two release
# points keep a fixed sum (6). With it our TX->RX loop holds one latency
# (507 samples) and one phase (within 0.1 degree) on every bring-up.
# This compensates the offset; it does not remove it.
##############################################################################

RUN_WORKAROUND = False

def place_release_points():
after = read_arrival() % 8
for attempt in range(3): # adcDacSync may redraw the count
count = after
afe_rbd = (count + 4) % 8
board_fpga_disarm()
setupParams.CAFE.setManualRbd(AFE_INST, CD_LINK, afe_rbd)
board_fpga_set_release((6 - afe_rbd) % 8)
setupParams.CAFE.adcDacSync(AFE_INST, 1) # relink on the pin SYSREF
board_fpga_after_bringup() # receivers released, re-armed
time.sleep(0.5)
after = read_arrival() % 8
if after == count:
break
print("placed: arrival %d, AFE rbd_m1 %d, FPGA release %d"
% (after, (count + 4) % 8, (6 - (count + 4) % 8) % 8))

if RUN_WORKAROUND:
for n in range(N_BRINGUPS):
bring_up()
place_release_points()

RE: AFE7903: AFE7903: JESD204B subclass 1 - internal LMFC offset from SYSREF differs by 0-7 frame-clock cycles across bring-ups

Dajon McGill — Fri, 16 Oct 2026 19:22:44 GMT

Team would like to check the sysref frequency for your config.

Could you please hare the bring-up script and the Latte version used so Rohan can check them.

RE: AFE7952: Number of frequency bands

Shunsuke Yamamoto — Fri, 16 Oct 2026 07:56:56 GMT

Hi Kang-san,

Thank you for the detailed answers. I will refer to the application sections 10.1 as well.

I see that 2400MHz IBW is limited by the JESD204 interface.

Best regards,

Shunsuke Yamamoto

AFE7952: Number of frequency bands

Shunsuke Yamamoto — Wed, 14 Oct 2026 08:00:04 GMT

Part Number: AFE7952

Hi team,

How many frequency bands can AFE7952 support? There are two NCOs per 1TX or 1RX channel, so 2 frequency bands are supported. Is my understanding correct?
Regarding IBW of TX side, 2400MHz IBW is supported when using 2TX. This means TX DAC can be interleaved. Correct?

Best regards,

Shunsuke Yamamoto

AFE8108: DDC/DUC Count

Daniel Barbalato — Wed, 14 Oct 2026 17:48:33 GMT

Part Number: AFE8108

Hi all,

Looking at the TI page for the AFE8108, it says there are two DDCs/DUCs per channel, but the datasheet appears to say otherwise. Which one is accurate?

Thanks!

-Dan

RE: AFE8108: DDC/DUC Count

Vijayendra Varma Siddamsetty — Wed, 14 Oct 2026 19:05:19 GMT

Hi Dan,

Datasheet is correct. We will update the webpage to reflect this.

Regards,

Vijay

RE: AFE7952: Number of frequency bands

Kang Hsia — Wed, 14 Oct 2026 14:38:01 GMT

Hello Yamamoto-san,

I need some help from you on how you define the number of bands. There are general terminologies such as 3GPP bands (i.e. B1, B3, and B7) that consume specific set of bandwidth over the air, or there can be carriers (i.e. 2 of the 20MHz LTE carriers) within the 3GPP bands.

[quote userid="519373" url="~/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1689451/afe7952-number-of-frequency-bands"]How many frequency bands can AFE7952 support? There are two NCOs per 1TX or 1RX channel, so 2 frequency bands are supported. Is my understanding correct?[/quote]

There are two DDCs (two down conversion stage and two NCOs) per RX ADC chain, and there are two DUCs (two upconversion stage and two NCOs) per TXDAC chain. You are correct.

Since the bandwdith for each DDC and DUC can be programmed for sufficiently large, you can in theory to fit multiple carriers into a single DDC or DUC. Therefore, if you define the number of carriers as number of bands, you can technically fit a few carriers for each DDC/DUC. You may see application sections 10.1 for examples

[quote userid="519373" url="~/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1689451/afe7952-number-of-frequency-bands"]Regarding IBW of TX side, 2400MHz IBW is supported when using 2TX. This means TX DAC can be interleaved. Correct?[/quote]

No, each TX remains independent. The two TX DAC outputs are not phyiscally or duty cycle shared. The 2400MHz IBW band is ultimately limited by the JESD204 interface (i.e. number of lanes and also the maximum SerDes rate within the JESD204 bus.

RE: AFE7903: AFE7903: JESD204B subclass 1 - internal LMFC offset from SYSREF differs by 0-7 frame-clock cycles across bring-ups

Dajon McGill — Tue, 13 Oct 2026 22:28:41 GMT

Team - Any suggestions for Xu?

AFE7950: Problem achieving deterministic latency and clock definition using AFE7950EVM

Rafael Morais — Wed, 09 Sep 2026 15:41:53 GMT

Part Number: AFE7950

Hello,

I am having trouble achieving deterministic latency using AFE7950EVM with ZCU102. I based my design on the reference designs. This was the 8b10b ref design that I updated to use a line rate of 3686.4 MSPS.

I have seen in this post: AFE7950: 4T4R2F 8b10b 2.4576 Gbps SERDES JESD link not always initializing properly where it mentions the need to use an external clock directly to the IP with length matching the sysref signal and without passing through a PLL. The IP datasheet also mentions that for both rx_sys_clock and tx_sys_clock should be sourced independantly.

My problem comes from the fact that tx_sys_clock is limited to "linerate/80" in the case of 64bits data width which is 46.08 MHz. rx_sys_clock says that it can be greater to or equal than linerate/80, and I dont seem to be able to get 46.08 MHz from the lmk on the AFE7950EVM. Is this possible to get or what would be the best way to achieve deterministic latency without changing linerate?

I am only using one TX and one RX channel.

Please guide me through this problem.

RE: AFE7950: Problem achieving deterministic latency and clock definition using AFE7950EVM

Roshan N T — Mon, 12 Oct 2026 19:10:59 GMT

Hi,

Please refer the below AFE79xxEVM LMK Clocking Parameters.

In order to setup the clocking for the AFE79xxEVM LMK the following parameters need to be set:
• lmkParams.pllEn
– False: LMK is in distribution/divider mode (Won’t use PLL); True : PLL1 of the LMK will be used with the onboard
122.88MHz crystal to generate a 2949.12MHz clock from LMK VCO and a 10MHz input through J14 to the LMK can
be used to frequency lock to equipment.
• lmkParams.lmkFrefClk
– False: AFE will not get Fref from LMK; True: AFE will receive the Fref from the LMK.
• lmkParams.fpgaRefClk
– Value of the FPGA ref clock from the LMK. This number can be obtained from your lane rate depending on the
JESD encoding.
– For the default firmware: JESD204B: (Lane Rate)/40. JESD204C: (Lane Rate)/66.

• lmkParams.inputClk
– This parameter is only valid only when lmkParams.pllEn = False.
– This is the input through J14 to the LMK. This should be an integer multiple of both your Fref, if the
AFE will get the Fref from the LMK, and your FPGA ref clock when lmkParams.pllEn = False to use
the LMK in distribution/divider mode.

Regards,
Roshan

RE: AFE7950: Problem achieving deterministic latency and clock definition using AFE7950EVM

Roshan N T — Mon, 12 Oct 2026 18:54:46 GMT

Hi,

You would have to set the LMK params section of the bringup script as below.

############## LMK Params ##############

lmkParams.pllEn = False # To configure LMK in divider or distribution mode

lmkParams.inputClk = 1474.56 # Valid only when lmkParams.pllEn = False

lmkParams.lmkFrefClk = False # True when AFE Fref is from LMK.

setupParams.fpgaRefClk = 46.08

Regards,
Roshan

RE: AFE7071: DACCLK input swing and common-mode requirements with LMK1D1204P

River Dowdy — Fri, 09 Oct 2026 21:41:07 GMT

Hello? Is anyone out there?

AFE7071: DACCLK input swing and common-mode requirements with LMK1D1204P

River Dowdy — Fri, 02 Oct 2026 22:58:05 GMT

Part Number: AFE7071

Hi,

We’re considering an LMK1D1204P to drive the AFE7071 DACCLKP/N inputs at 16, 32 or 64 MHz in dual-input-clock mode. The LMK would run from the same 1.8 V rail as AFE7071 CLKVDD18. The interface circuit is still being designed.

I have a few questions about the DAC clock input specifications:

The AFE7071 datasheet (SLOS789C, page 5) specifies 0.4–1 V differential input. Is that peak-to-peak voltage or peak magnitude? For example, does a differential waveform alternating between +350 mV and −350 mV meet this requirement?
The LMK1D1204P specifies 250–450 mV differential magnitude and 1.0–1.2 V output common mode into 100 Ohm at a 1.8 V supply. Is DC coupling to the AFE supported? What is the permitted DACCLK common-mode range? If AC coupling is needed, are the AFE inputs internally biased, or is an external bias network required?
Is there a recommended input circuit or complete AFE707xEVM clock schematic available? The EVM guide identifies the 100 Ohm R55 termination, but I couldn’t find the full bias details.

We also intend to disable the LMK outputs during startup. Are there any DACCLK requirements during power sequencing or clock stop/restart that we should account for?

Thanks,
River

TRF37B32: IF frequency Coverage

Akshay Rathod — Thu, 08 Oct 2026 05:14:04 GMT

Part Number: TRF37B32

For an Application with strict requirements of IM3 of 60dBc and best spurious response, although this part's datasheet says IF up to 600 MHz, will it support 720 MHz IF since that is the frequency of interest?

RE: TRF37B32: IF frequency Coverage

Dhruv Kalra — Fri, 09 Oct 2026 15:13:08 GMT

Thanks for reaching out about using the TRF37B32 with a 720 MHz IF for your application requiring 60 dBc IM3 and strong spurious performance. Here's where things stand and how we'd like to proceed:

Preliminary Assessment:

The TRF37B32 datasheet specifies the IF output range as 30–600 MHz, defined at the amplifier's 1-dB gain corner. All of TI's published linearity (OIP3) and spurious performance data are characterized at FIF = 200 MHz. Running the IF at 720 MHz would push operation past the specified corner frequency, into a region TI does not characterize or guarantee. We'd expect some combination of gain roll-off and degraded linearity/spurious performance beyond 600 MHz, but we don't have data to say definitively whether it would still meet your 60 dBc target at 720 MHz.

What this means practically: We can't give you a confident yes/no from the datasheet alone. However, we have TRF37B32 EVMs on hand and can run empirical bench tests (two-tone IM3 and spurious scans at 720 MHz IF, benchmarked against the datasheet's 200 MHz reference condition) to get you a real answer rather than an extrapolation.

One important dependency — we need from you:

IM3 (dBc) is not a fixed number; it scales with output power (roughly 2 dB of IM3 degradation per 1 dB increase in output power, per standard third-order behavior). To make sure our bench testing is directly relevant to your application, we need:

What output power per tone (or total output power) will the IF port be delivering in your actual system? (dBm per tone at the IF output)
What is your RF frequency of interest and LO configuration - this helps us replicate your exact use case on the bench.
Is 60 dBc IM3 required at a worst-case power level, or at a typical/nominal operating point? This affects how we structure the power sweep.
Any constraints on tone spacing for the two-tone IM3 test, if you have a preference based on your actual signal bandwidth?

AFE7900EVM: Finding latest code and guides for AFE7900EVM with AMD ZCU102

Tim Acland — Thu, 08 Oct 2026 08:41:33 GMT

Part Number: AFE7900EVM

Hi! Please direct me to the latest code and guidance docs to get AFE7900EVM up and running with AMD ZCU102. Thanks! We will use the Simulink model in the secure folder to get more familiar with this part family - looks useful. We may have some newbie questions around that, to follow.

RE: AFE7900EVM: Finding latest code and guides for AFE7900EVM with AMD ZCU102

Tim Acland — Thu, 08 Oct 2026 13:27:35 GMT

I think I found the material in the JESD204 IP Reference Designs folder.

AFE7950: Designing with GTYP Transceivers

Brian Canty — Fri, 02 Oct 2026 19:28:03 GMT

Part Number: AFE7950

Reposting this as my previous post was locked without answer.

We're working on a design that integrates the AFE7950 with an AMD Versal SoC. We have a functioning prototype based off of the provided AFE7950/ZCU102 example and are hoping to use that as a starting point for a Versal-based design. The ZCU102 uses AMD GTH transceivers and we are hoping to use the GTYP transceivers on a Versal. Is there a version of the TI FPGA IP that is compatible with GTYP transceivers, or at least one in development?

If we are unable to get an answer you will force us to switch to a component manufacturer that provides current-gen support for their parts.

RE: AFE7950: Designing with GTYP Transceivers

Brian Canty — Mon, 05 Oct 2026 19:26:10 GMT

Thank you Mr. Nagarajan, I appreciate the response! It might be worthwhile to update the product description to reflect that. Thank you, this solves my issue.

RE: AFE7950: Designing with GTYP Transceivers

Gokul Nagarajan — Mon, 05 Oct 2026 18:40:17 GMT

Hi Mr.Brian,
The latest TI JESD 204C IP also supports GTYP transceivers on Versal. For an example reference design, please raise a request at the following site TI-JESD204-IP Firmware | TI.com once you have finalized the AFE7950 configuration.

AFE7950EVM: AFE7950 external 10Mhz not lock

Luca Meloni — Mon, 05 Oct 2026 13:44:48 GMT

Part Number: AFE7950EVM

Dear TI

I am using the AFE7950-TRF1208 EVM Evaluation module. I have a 10MHz source on the LMK_CLK_IN connector (J14)

As per the document SBAU392, both LEDs D3 and D4 should be lit. In this case only the PLL 2 LED (D3) is lit, not D4.

Can you please help me?

Regards

RE: AFE7950: Problem achieving deterministic latency and clock definition using AFE7950EVM

Rafael Morais — Wed, 30 Sep 2026 07:30:40 GMT

Hi Roshan,

Can you provide the command via script to configure the LMK in divider mode?

Regards,
Rafael Morais

RE: AFE7903: AFE7903: JESD204B subclass 1 - internal LMFC offset from SYSREF differs by 0-7 frame-clock cycles across bring-ups

Xu Li — Tue, 29 Sep 2026 18:31:05 GMT

In short: SYSREF appears to do every job except one: it latches on one fixed 6 GHz edge, reaches every JESD block, phases the NCOs and aligns the JESD LMFC counter to its edge, yet the counter's offset from that edge is drawn anew from 0 to 7 at every bring-up, as if we had missed just one register bit that leaks SYSREF into the reset of whatever sets that offset -- a single register bit is missed.