RF & microwave forum - Recent Threads

AFE7769: AFE7769: Independent per-channel NCO control (Macro 0x29 groups channels in pairs) + runtime re-calibration after bring-up

Petro Khlyshchyborshch — Wed, 02 Sep 2026 13:40:34 GMT

Part Number: AFE7769

Hi,

I'm working with the AFE7769.

I need to set the IF mixer NCO frequency for each TX/RX channel independently, but Macro 0x29 only exposes NCO control grouped by channel pairs / all channels:

Operand 1 (offset 0x00): NCO for TX IF Mixer, channels [12]/[1234]
Operand 2 (offset 0x04): NCO for TX IF Mixer, channels [34]
Operand 3 (offset 0x08): NCO for RX IF Mixer, channels [12]/[1234]
Operand 4 (offset 0x0C): NCO for RX IF Mixer, channels [34]
Operand 5/6 (offset 0x13/0x14): NCO for FB-1 / FB-2 IF Mixer

There is no operand that lets me set channels 1, 2, 3 and 4 to four independent NCO values in one macro call — only pairs ([12] or [1234] together, [34] together).

Questions:

Is there a supported way (another macro, or direct register access) to program a unique NCO frequency/phase for each individual TX and RX channel — all 4 channels independently, not as [12]/[34] pairs? If direct register writes are required instead of Macro 0x29, which registers (mixer NCO frequency/phase control) should I target per channel?
After changing NCO on a subset of channels at runtime — i.e. after the initial bring-up sequence and steady-state calibration have already completed — what is the correct procedure to re-calibrate successfully? Do I need to re-run the full Tune + Enable Chains macro plus power-up calibration, or is there a lighter-weight recalibration path just for the NCO update, without redoing the entire bring-up sequence?
Is per-channel independent NCO retuning at runtime (post bring-up) an officially supported use case for the AFE7769, or is NCO configuration expected to be static once bring-up/calibration is finished?

Any guidance, register-level pointers, or an example sequence would be very helpful.

Thanks!

AFE7950: AFE7950 Not Completing Configuration

Doug Zielinski — Thu, 20 Aug 2026 20:20:11 GMT

Part Number: AFE7950

I am working on this issue with Sam Compton at Tomorrow.io.

We are bringing up a custom design that uses the AFE7950 interfaced to a Xilinx Virtex UltraScale+ FPGA. The AFE is programmed via SPI using the HEX file generated by Latte. For SYSREF generation, we are currently using SPI-generated SYSREF. The FPGA design uses the TI204C IP core instantiated directly in RTL (not through an IPI design). We have also modified the example design to use the appropriate GTY transceivers.

Our JESD204C configuration uses:

Lane rate: 11.6 Gbps
Number of lanes: 4

We are experiencing an issue where the AFE configuration sequence does not complete successfully. The register programming sequence from the Latte-generated HEX file fails during the verification stage.

We have tested two configurations:

1. sysParams.continuousSysref = False

Configuration fails while reading register 0x133 in the ADC JESD page. The expected value is 0x08, but the readback value is 0x00.

Our assumption is that the SPI-generated SYSREF event may not be occurring, or the device is not detecting it as expected.

2. sysParams.continuousSysref = True

Configuration progresses further but eventually fails while reading register 0xEE in the DAC JESD page. The expected value is 0x03, but the readback value is 0x00.

Based on the documentation, this appears to indicate a comma-align lock issue. In this mode, I observe rx_all_lanes_locked asserting successfully.

I also observe QPLL0_LOCK for all test cases.

We are using the TI204C example design to generate TX data and monitor RX data.

As a reference, we have been following the guidance in the following forum thread:

https://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1365862/afe7950-i-want-to-understand-how-the-sysref-input-signal-is-configured-for-operation-in-either-pulsed-mode-or-continuous-mode-in-both-the-afe-device-and-ti-s-xilinx-jesd-fpga-ip-core

One notable difference is that our design does not use an LMK04828 clock device.

I have reviewed the schematics for polarity issues and lane swapping. There are lane swaps in the design, but these have been accounted for through the cfg_lane_map inputs to the TI204C IP.

We would appreciate any guidance on what might be preventing the AFE configuration sequence from completing successfully.

I have attached the output log files for both test cases
I have cut and pasted the Latte python script.

The same Python script is used in both cases, with the only difference being the value of sysParams.continuousSysref (True vs. False).

Thank you for any suggestions or debug recommendations.

Doug Zielinski

Latte file:

############## Read me ##############
#In HSDC Pro DAC tab, Select AFE79xx_2x2TX_44210; Data Rate = 491.52M
#In HSDC Pro ADC tab, Select AFE79xx_2x2RX_44210; Data Rate = 491.52M ---> To capture 4 RX channels

sysParams=AFE.systemParams
sysParams.__init__();sysParams.chipVersion=chipVersion

setupParams.skipFpga = True # setup FPGA (TSW14J56) using HSDC Pro
############## Top Level ##############
sysParams.FRef = 9280
sysParams.FadcRx = 2320
sysParams.FadcFb = 2320
sysParams.Fdac = 9280

sysParams.externalClockRx=True
sysParams.externalClockTx=True

############## Digital Chain ##############

##### RX ADC #####
sysParams.ddcFactorRx = [8,8,8,8] #DDC decimation factor for RX A, B, C and D
#sysParams.numBandsRx = [1,1,1,1]
#sysParams.numRxNCO = 2

#sysParams.rxNco0 = [[9500,9500], #Band0, Band1 for RXA
# [9500,9500], #Band0, Band1 for RXB
# [9500,9500], #Band0, Band1 for RXC
# [9500,9500]] #Band0, Band1 for RXD
sysParams.rxNco0 = [[2625, 2875], #Band0, Band1 for RXA
[2625, 2875], #Band0, Band1 for RXB
[2625, 2875], #Band0, Band1 for RXC
[2625, 2875]] #Band0, Band1 for RXD

##### FB #####
sysParams.fbEnable = [False,False]
sysParams.ddcFactorFb = [8,8] #DDC decimation factor for FB 1 and 2
sysParams.fbNco0 = [2625,2625] #Band0 for FB1 and FB2

##### TX #####
sysParams.ducFactorTx = [32,32,32,32] #DUC interpolation factor for TX A, B, C and D
#sysParams.txNco0 = [[9500,9500], #Band0, Band1 for TXA
# [9500,9500], #Band0, Band1 for TXB
# [9500,9500], #Band0, Band1 for TXC
# [9500,9500]] #Band0, Band1 for TXD
sysParams.txNco0 = [[2580,2580], #Band0, Band1 for TXA
[2580,2580], #Band0, Band1 for TXB
[2580,2580], #Band0, Band1 for TXC
[2580,2580]] #Band0, Band1 for TXD

############## JESD ##############

##### ADC-JESD #####
sysParams.jesdSystemMode= [3,3]
#SystemMode 0: 2R1F-FDD ; rx1-rx2-fb -fb
#SystemMode 1: 1R1F-FDD ; rx -rx -fb -fb
#SystemMode 2: 2R-FDD ; rx1-rx1-rx2-rx2
#SystemMode 3: 1R ; rx -rx -rx -rx
#SystemMode 4: 1F ; fb -fb- fb -fb
#SystemMode 5: 1R1F-TDD ; rx/fb-rx/fb-rx/fb-rx/fb

sysParams.jesdTxProtocol= [0,0] # 0 - 8b/10b encoding; 2 - 64b/66b encoding
sysParams.LMFSHdRx = ["24410","24410","24410","24410"]
# The 2nd and 4th are valid only for jesdSystemMode values in (0,2).
# For other modes, select 4 converter modes for 1st and 3rd.
sysParams.LMFSHdFb = ["44210","44210"]

sysParams.rxJesdTxScr = [True,True,True,True]
sysParams.fbJesdTxScr = [True,True]

sysParams.rxJesdTxK = [16,16,16,16]
sysParams.fbJesdTxK = [16,16]

sysParams.serdesTxLanePolarity =[0,0,0,0,0,0,0,0]
sysParams.jesdTxLaneMux = [0,1,4,5,2,3,6,7] # Enter which lanes you want in each location.

##### DAC-JESD #####
sysParams.jesdRxProtocol= [0,0]
sysParams.LMFSHdTx = ["24410","24410","24410","24410"]
sysParams.serdesRxLanePolarity = [0,0,0,0,0,0,0,0]
sysParams.jesdRxLaneMux = [0,1,4,5,2,3,6,7] # Enter which lanes you want in each location.
#sysParams.jesdRxLaneMux = [0,1,2,3,4,6,7,5] # Enter which lanes you want in each location.

sysParams.jesdRxRbd = [4, 4]
sysParams.jesdRxScr = [True,True,True,True]
sysParams.jesdRxK = [16,16,16,16]

##### JESD Common #####

sysParams.jesdABLvdsSync= True
sysParams.jesdCDLvdsSync= True
sysParams.syncLoopBack = True #JESD Sync signal is connected to FPGA

############## GPIO ##############
sysParams.gpioMapping = {
'H8': 'ADC_SYNC0',
'H7': 'ADC_SYNC1',
'N8': 'ADC_SYNC2',
'N7': 'ADC_SYNC3',
'H9': 'DAC_SYNC0',
'G9': 'DAC_SYNC1',
'N9': 'DAC_SYNC2',
'P9': 'DAC_SYNC3',
'P14': 'GLOBAL_PDN',
'K14': 'FBABTDD',
'R6': 'FBCDTDD',
'H15': ['TXATDD','TXBTDD'],
'V5': ['TXCTDD','TXDTDD'],
'E7': ['RXATDD','RXBTDD'],
'R15': ['RXCTDD','RXDTDD']}

sysParams.continuousSysref = False
sysParams.useSpiSysref = True

############## LMK Params ##############
lmkParams.xtalFreq = 122.88
lmkParams.sysrefFreq = 2275/1024

lmkParams.pllEn = False
lmkParams.inputClk = 500 # Valid only when lmkParams.pllEn = False
lmkParams.lmkFrefClk = False
setupParams.fpgaRefClk = 290 # Should be equal to LaneRate/40 for TSW14J56

pathdz = "C:/DesignLinx_Projects/Tomorrow_io/stadium/542/Latte_NoSysRef/Latte_Output"

############## Logging ##############
#logDumpInst.setFileName(ASTERIX_DIR+DEVICES_DIR+r"\Afe79xxPg1.txt")
logDumpInst.setFileName(pathdz+r"\Afe79xxPg1.txt")
#logDumpInst.logFormat=0x21 #Modify to 0x1 to save register scequence to log file. Script takes more time to execute.
#logDumpInst.logFormat=0x2000 #Modify to 0x1 to save register scequence to log file. Script takes more time to execute.
logDumpInst.logFormat=0x40 #Phil wants this one. Modify to 0x1 to save register scequence to log file. Script takes more time to execute.
logDumpInst.rewriteFile=1
logDumpInst.rewriteFileFormat4=1
device.optimizeWrites=0
device.rawWriteLogEn=1

device.delay_time = 0
#-------------------------------------------------------------------------------------------------#

#added by dz
#PhaseOffset=int(90/(360/2^16))
#PhaseOffset=int(32768)
#device.writeReg(0x12,0x2)
#device.writeReg(0xE1,(PhaseOffset>>8)&0xFF)
#device.writeReg(0xE0,PhaseOffset&0xFF)
#device.writeReg(0x12,0x0)

lmklogDumpInst=mLogDump.logDump(pathdz+r"\Afe79xxPg1_LMK.txt")
lmklogDumpInst.logFormat=0x21
lmk.logClassInst = lmklogDumpInst
lmk.rawWriteLogEn=1

setupParams.skipLmk = False
AFE.initializeConfig()
lmkParams.sysrefFreq = AFE.systemStatus.sysrefFreq
lmkParams.lmkPulseSysrefMode = True
AFE.LMK.lmkConfig()

log_noncont_sysref.txt

log_cont_sysref.txt

RE: AFE7950: AFE7950 Not Completing Configuration

Roshan N T — Wed, 02 Sep 2026 12:03:28 GMT

Hi Doug Zielinski,

Which latte version are you using and can you please share the full log for both the case.
Can we move this thread to email?

RE: AM3352: AM3352 RGMII Radiated EMI – 25 MHz / 125 MHz Harmonic Emissions

Kallikuppa Sreenivasa — Tue, 01 Sep 2026 17:48:13 GMT

Hello Erfan Omidvar,

Please refer inputs i received from our device expert regarding the series termination:

Increasing the series termination resistor from 22 ohms to 50 ohms is going to introduce additional reflections on the PCB trace due to source impedance mismatch encountered when energy from the initial far-end reflection returns back to the source. I suspect they are trying to do this to reduce the signal slew rate, but the higher source impedance doesn’t have much effect on the initial signal slew rate launched onto the PCB trace. It will reduce the slew rate at the far end of the PCB trace, but that may not help if the EMI issue is caused by radiation from the PCB traces.

Regards,

Sreenivasa

AM3352: AM3352 RGMII Radiated EMI – 25 MHz / 125 MHz Harmonic Emissions

Erfan Omidvar — Tue, 01 Sep 2026 15:17:29 GMT

Part Number: AM3352

We are experiencing radiated EMI issues related to the RGMII Ethernet interface between an AM3352 processor and a KSZ9031RNX Gigabit Ethernet PHY.

The RGMII signals are routed over a continuous reference ground plane. During EMI testing, we observe strong harmonic peaks that are clearly correlated with Ethernet activity:

At 100 Mbps, the emissions are dominated by 25 MHz harmonics.
At 1 Gbps, strong peaks related to the 125 MHz RGMII clock and its harmonics are observed.

Changing the RGMII series termination resistors from 22 ohm to 51 ohm reduced the emissions by a few dB, but the levels are still above the required limit.

The emissions decrease significantly when the Ethernet interface/PHY is disabled, which strongly suggests that the source is related to the RGMII/PHY activity.

Could you please advise whether there are any recommended AM3352 RGMII drive-strength, slew-rate, termination, pin configuration, or PCB design settings that could help reduce these emissions? Are there any known recommendations for reducing RGMII-related EMI on the AM3352?

RE: AM3352: AM3352 RGMII Radiated EMI – 25 MHz / 125 MHz Harmonic Emissions

Kallikuppa Sreenivasa — Tue, 01 Sep 2026 17:43:38 GMT

Hello Erfan Omidvar,

Thank you for the input.

Are you able to share the implementation details including the clock source for processor and EPHY, IO voltage level used. In case you are using 3.3C, do you have an option to change to 1.8V.

[quote userid="639158" url="~/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1678449/am3352-am3352-rgmii-radiated-emi-25-mhz-125-mhz-harmonic-emissions"]The emissions decrease significantly when the Ethernet interface/PHY is disabled, which strongly suggests that the source is related to the RGMII/PHY activity.[/quote]

Have you tried enabling loopback tests on the EPHY that does not include the RGMII interface signals or using near field probe to determine the origin of the noise.

Regards,

Sreenivasa

RE: AM3352: AM3352 RGMII Radiated EMI – 25 MHz / 125 MHz Harmonic Emissions

Erfan Omidvar — Tue, 01 Sep 2026 15:35:33 GMT

Test Specification EN 55032 Electric Field Strength Class B

Frequencies			Receiver Settings
Start	Stop	Step	Res BW	M-Time	Atten	Preamp
30 MHz	1 GHz	90 kHz	120 kHz (6dB)	5 ms	Auto	Auto

Final Measurement

Detector: QP Meas Time: 10 s

Peaks: 15 Acc. Margin: 10 dB

RE: AM3352: AM3352 RGMII Radiated EMI – 25 MHz / 125 MHz Harmonic Emissions

Kallikuppa Sreenivasa — Tue, 01 Sep 2026 15:26:38 GMT

Hello Erfan Omidvar,

Thank you for the query.

Are you able to share the implementation details and the emission test results.

Regards,

Sreenivasa

AM6442: AM6442:use the profinet_device_demo of ind_comms_SDK

ZX T — Mon, 31 Aug 2026 08:44:28 GMT

Part Number: AM6442

MEMORY

{

R5F_VECS : ORIGIN = 0x0 , LENGTH = 0x40

R5F_TCMA : ORIGIN = 0x40 , LENGTH = 0x7FC0

R5F_TCMB0 : ORIGIN = 0x41010000 , LENGTH = 0x8000

ICSS_PKT_BUF_MEM : ORIGIN = 0x70000000 , LENGTH = 0x10000

HEAP_MEM : ORIGIN = 0x70010000 , LENGTH = 0x80000

MSRAM : ORIGIN = 0x70090000 , LENGTH = 0x144000

USER_SHM_MEM : ORIGIN = 0xA5000000 , LENGTH = 0x80

LOG_SHM_MEM : ORIGIN = 0xA5000080 , LENGTH = 0x3F80

RTOS_NORTOS_IPC_SHM_MEM : ORIGIN = 0xA5004000 , LENGTH = 0xC000

CODE_MEM : ORIGIN = 0xA0101000 , LENGTH = 0x1D0000

BOOT_PKT_MEM : ORIGIN = 0xA02D1000 , LENGTH = 0x200000

DATA_MEM : ORIGIN = 0xA04D1000 , LENGTH = 0x200000

DDR0 : ORIGIN = 0xA0100000 , LENGTH = 0x1000

/* For memory Regions not defined in this core but shared by other cores with the current core */

}

this is my linker.cmd.

Successfully started this R5F0-0 project on Linux via remoteproc, but didn't see the Profinet device through FRONETA. Do I still need to modify the device tree? I'm using a Chuanglong development board.

AFE7950: Designing with GTYP transceivers

Brian Canty — Thu, 27 Aug 2026 21:34:38 GMT

Part Number: AFE7950

We're working on a design that integrates the AFE7950 with an AMD Versal SoC. We have a functioning prototype based off of the 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?

LMZM23601: Locating Stock

Paul Carey — Thu, 27 Aug 2026 10:47:31 GMT

Part Number: LMZM23601

Good morning

We ordered some of these components from Mouser back in March 2026 with a delivery date of 5 days - this was then delayed and today we have now been told its going to be Feb 2027- We have urgent military radios that we need to repair that need to go back to theatre and without these we cannot fix them. We need 100 pieces are you able to advise how we might be able to locate some.

Thanks

Paul

RE: LMZM23601: Locating Stock

Oscar Ambriz — Thu, 27 Aug 2026 21:01:12 GMT

Hello Paul,

Unfortunately from my side most units appear to be out of stock. It appears that we only have the following two in stock, my understanding from the marketing team is these units need to be purchased in a full real quantity from TI.com or we recommend ordering from an external vendor.

LMZM23601V5SILR 3000unit real

LMZM23601V5SILT 250 unit real

AFE7950: AFE7950 5 second startup delay

JT Miller — Wed, 26 Aug 2026 17:54:35 GMT

Part Number: AFE7950

The AFE7950 takes multiple seconds to startup with the reference design script we were provided.

There's a five second delay in the bringupafe() script we were given as part of a reference design, line 21054:

dev_spi_write(0x702d,0x0);
	dev_spi_write(0x702c,0x5);
	dev_spi_write(0x7025,0x0);
	dev_spi_write(0x7024,0x8);
	dev_spi_write(0x702b,0xe0);
	dev_spi_write(0x702a,0x20);
	dev_spi_write(0x702d,0x0);
	dev_spi_write(0x702c,0x2);
	dev_spi_write(0x7025,0x0);
	dev_spi_write(0x7024,0x50);
	dev_spi_write(0x702b,0xe0);
	dev_spi_write(0x702a,0x20);
	dev_spi_write(0x701b,0x7);
	dev_spi_write(0x701a,0x77);
	dev_spi_write(0x701b,0x0);
	dev_spi_write(0x701a,0x0);
	delaySec(5.000000);
	dev_spi_write(0x16,0x0);
	dev_spi_write(0x15,0x80);
	dev_spi_write(0x81,0x0);
	dev_spi_write(0x80,0x1);
	dev_spi_write(0x8c,0x1);
	dev_spi_write(0x8d,0x1);
	dev_spi_write(0xa0,0x1);
	dev_spi_write(0xa1,0x1);
	dev_spi_write(0x15,0x0);
	dev_spi_write(0x15,0x2);
	dev_spi_write(0x129,0x0);
	dev_spi_write(0x12a,0x0);
	dev_spi_write(0x12b,0x0);

Is this five second delay necessary? We'd like to minimize the AFE7950 startup time. Is it possible to get the time <100ms? How should we pursue minimizing the time?

AFE7950: TX spur at 9.6 GHz tone

Dietmar Veerkamp — Wed, 26 Aug 2026 12:30:26 GMT

Part Number: AFE7950

Hi,

in the datasheet of the AFE7950 figure 7-267 (see attachment afe7950_spur.pdf ) the spectrum is presented with a spur close to the carrier.

Reading the test conditions for this plot:

Upconversion with 8 x interpolation
No use of the NCO
Use of the PLL

Is it possible, to reduce the spur level under the following conditions:

For our application (weather radar X-Band) we use a narrow baseband frequency modulated signal (~10 MHz bandwidth).

Use of the NCO
External clock signal (low phase noise) instead of PLL

Thank you in advance for your feedback!

Dietmar

AFE7769D: AFE7769: TXA and TXB on a shared LO at different frequencies via NCO — how to keep TX LO-leakage (DC offset) and IQ-mismatch calibration valid?

Petro Khlyshchyborshch — Fri, 14 Aug 2026 14:48:11 GMT

Part Number: AFE7769D

Setup

TXA and TXB share one analog LO (same PLL, one pair). I need them to transmit at two different RF frequencies, a small offset (a few MHz) apart, using the per-channel digital NCO/mixer rather than separate LOs.

Question

What is the recommended, supported procedure to:

Place TXA and TXB at two different frequencies around their shared LO using the digital NCO/mixer, and
Have the TX LO-leakage (DC offset) and TX IQ-mismatch calibration pass correctly for both chains afterward?

Specifically:

Does the calibration flow need to know about the per-chain frequency offset beforehand (i.e. is there a supported way to communicate it before or during calibration), or is it safe to calibrate first at the shared/nominal frequency and apply the NCO offset afterward?
Is there a recommended order of operations (calibrate then shift vs. shift then calibrate), and does it differ between LO-leakage/DC-offset calibration and IQ-mismatch calibration?
Are these calibrations expected to remain valid after a post-calibration NCO shift of a few MHz, or do they need to be re-run/re-triggered per chain once the offset is applied?
Is per-chain NCO placement (independent frequency per chain, shared LO) a supported use case on AFE7769 at all, or is it only intended for symmetric/pair-level offsets (e.g. via low-IF mode, which applies the same offset to both chains of a pair)?

Any guidance on the correct sequence, or a pointer to documentation/reference code that covers this, would be appreciated.

RE: AFE7769D: AFE7769: TXA and TXB on a shared LO at different frequencies via NCO — how to keep TX LO-leakage (DC offset) and IQ-mismatch calibration valid?

Serkan Tokgoz — Thu, 20 Aug 2026 17:10:17 GMT

Hi Petro,

Per-chain NCO is supported. TXA and TXB each have an independent digital mixer (Low-IF NCO), so you can place them at different offsets from their shared LO. This is not limited to symmetric/pair-level offsets.

You should program the NCO before bringup in your configuration file — not after.

1. Configure TX Low-IF NCO for each chain in your configuration file.
2. Configure the feedback (FB) NCO for TX calibration — the FB NCO should be set to the TX LO frequency so that LO leakage lands at DC in the
feedback path, which is what the calibration algorithm expects.
3. Follow the procedure for delay calibration using CAPIs

4. Run IQMC calibration using CAPIs.

I do not recommend shifting the NCO after calibrating. An NCO change after calibration invalidates the IQMC result in particular, since the mismatch correction is frequency-dependent. Can you please share your use-case for updating the lowIF NCOs after booting the device?

Thanks,

Serkan

AFE7950-SP: REVIEW dESIGN

mkarim bali — Thu, 20 Aug 2026 10:25:49 GMT

Part Number: AFE7950-SP

Hello,

I am currently working on a hardware design based on a TI AFE device, and I would like to ask if it is possible to publish my schematic/design on the TI E2E forum for review.

The design includes the AFE and its surrounding circuitry, and I would appreciate feedback from TI experts regarding the schematic, component selection, connections, layout recommendations, and any potential issues before finalizing the PCB.

Could you please let me know if sharing the schematic and design files on the forum is acceptable, and what information or format you would recommend providing to facilitate the review?

Thank you for your support.

Best regards,

AFE7903: Solderability issue

Mike Neuman — Sat, 08 Aug 2026 16:04:20 GMT

Part Number: AFE7903

We've been succesfully using the AFE7903IABJ in a socket since we started the project. We just spun and assembled our first two boards that solder the part on. Both boards have failed in a very pecuiliar way. 1.2V and 1.8V are shorted on the part itself.

The balls underneath all look just fine--there are no bridges here.

We removed one of the AFE7903's and probed its 1.2V and GND pins and found a 50mOhm resistance between them. 1.8V and GND also have similarly low impedance.

But most surprising, there is what looks like a solderball that appeared underneath the heat spreader. There's nothing in our process (entirely SMT) that would account for solder appearing on both boards (assembled on different days) in the same location. See attached images for chip1 (removed from board) and chip2 (still on board). They both have the same blob(?) of solder(?) in the same location. I did not photograph these parts before placing them, but none of the rest in our lot have this defect before soldering.

We followed the Loctite GC10 reflow curve #2:

The following are "chip1" (taken off PCB):

The following are taken from "chip 2" still on the PCB:

Please advise on next steps. Burning these rather expensive chips is getting painful.

RE: AFE7903: Solderability issue

Mike Neuman — Mon, 17 Aug 2026 20:10:23 GMT

Hello? It's awfully quiet out there. Is there a better place to ask this question?

AFE7950EVM: Request for Updated TI JESD204C IP Release Supporting Newer Vivado Versions (AFE7950EVM)

Krithik Krishna — Mon, 17 Aug 2026 11:02:41 GMT

Part Number: AFE7950EVM

HI Texas Instruments Support Team,

I am currently working with the AFE7950EVM evaluation module and implementing the JESD204C interface logic. Previously, I received a version of the TI JESD204C IP core package (containing the encrypted netlist/source files such as TI_204c_IP.svp) which is constrained and structured for older toolsets (specifically targeting Vivado 2019.2). As we are upgrading our FPGA design toolchain to a higher/latest version of AMD Vivado, trying to use the existing IP results in decryption errors and key mismatch warnings (such as IEEE-1735 encryption key incompatibility with newer Vivado releases). Could you please provide access to the latest updated version of the TI JESD204C IP core release package (compatible with Vivado 2024.x, or later) for the AFE7950EVM?

Hardware / Software Details:

Device: AFE7950EVM / AFE7950
Current IP Version in Use: Supporting Vivado 2019.2
Target Tool: AMD Vivado (Latest/Higher Version)
Core Files: TI_204c_IP.svp / TI-204c-CoreIP

Looking forward to your assistance in providing the updated secure download link or resource access. Best regards,

Krithik Krishna

Sanlayan Technologies

krithik.krishna@sanlayan.com

AFE7950: AFE7950 Reference Design

JT Miller — Tue, 11 Aug 2026 19:57:19 GMT

Part Number: AFE7950

I've inherited the attached TI-provided reference design and Vivado crashes when I try to build the design.

There seem to be a few oddities. First is a simple mistake in the create_top_level_wrapper.tcl source (although I don't know how this built for you with the mistake):

-make_wrapper -files [get_files ../${project}.srcs/sources_1/bd/${bd_name}/${bd_name}.bd] -top
-add_files -norecurse ../${project}.gen/sources_1/bd/${bd_name}/hdl/${bd_name}_wrapper.v
+make_wrapper -files [get_files ./${project}/${project}.srcs/sources_1/bd/${bd_name}/${bd_name}.bd] -top^M
+add_files -norecurse ./${project}/${project}.gen/sources_1/bd/${bd_name}/hdl/${bd_name}_wrapper.v^M

Second, the afe7950_lmfs12410_64b66b_bd.tcl seems to have been generated in 2023.1, but the XCI for the gth is from 2023.2. I updated the script to 2023.2 and that seems to solve the issue, but later trying to build the design it fails.

For reference, I am trying to build in 2023.2 on Linux. I don't get any messages, Vivado just quits, then memory usage spikes to the maximum on my machine and I have to pkill -f "vivado" to get the machine back.

The AFE_ZCU102_1T1R.pptx accurately describes how the reference design should work.

Can you please check the reference design and advise?

AFE_ZCU102_1T1R.zip

RE: AFE7950: AFE7950 Reference Design

JT Miller — Fri, 14 Aug 2026 15:02:54 GMT

I was able to get the reference design working. I recreated the gth xci using the powerpoint as a guide.

Vivado was crashing because apparently it was launching too many parallel jobs. I had to restrict the number of parallel jobs to keep Vivado from launching too many processes and crashing the machine:

launch_runs synth_1 -jobs 2
wait_on_run synth_1

launch_runs impl_1 -to_step route_design -jobs 2
wait_on_run impl_1

launch_runs impl_1 -to_step write_bitstream -jobs 2
wait_on_run impl_1

RE: DAC39RF20EVM: Broadband Chirp Generation with DDS SPI Mode

Matthew Kramer — Thu, 13 Aug 2026 00:18:14 GMT

Hello,

If you installed the latest GUI (V0.4.0) you should see some Python scripts in the installation directory (By default the Texas Instruments directory in my documents).

<Documents>\Texas Instruments\DAC39RF20\v0.4.0\dac39rf20api_examples\!top_level_scripts\dds_vector

This script will generate a chirp using the DDS vector engine. I am working on additional scripts for more advanced waveforms (including chirps with 2nd order ramps). These will be included with the next GUI update.

Regards,

Matt

DAC39RF20EVM: Broadband Chirp Generation with DDS SPI Mode

firat g — Wed, 05 Aug 2026 10:46:42 GMT

Part Number: DAC39RF20EVM

Hi,

I purchased the DAC39RF20EVM. How do I generate wideband chirp signals using DDS mode via USB connection? Can I generate complex waveforms with this mode? Can PW and PRI be produced using DDS Mode? Is there a guide on this?

AFE7950: Clock Synchronization & Calibration for 60× AFE7950 Multi-Channel Direct-RF Data Acquisition System (8.5–10.5 GHz)

Jiongyi Du — Wed, 12 Aug 2026 07:09:15 GMT

Part Number: AFE7950

Hello TI team,

We are designing a multi-channel direct-RF sampling data acquisition and test system operating from 8.5 GHz to 10.5 GHz, and would like your recommendation on clock synchronization and phase calibration using a full TI chipset.

System overview:

12 circuit boards, each with 5× AFE7950 (20 TX + 20 RX channels per board); 60× AFE7950 total (240 TX / 240 RX / 120 FB)
AFE7950 internal PLL generates the ~12 GSPS DAC sampling clock from a single common 100 MHz TCXO (no external 12 GHz clock distribution)
Two-level clock tree: 1× root clock device (LMK04828-EP or LMK04832) → 12× board-level clock devices, each distributing matched REFCLK + SYSREF pairs to 5× AFE7950 + local FPGA
All links use JESD204B/C Subclass 1; the 12 board FPGAs are coordinated by a central timing controller
All channels must be phase-coherent and phase-repeatable across power cycles

Questions:

Clock topology: Is a two-level tree (1 root + 12 board-level clock devices, e.g., LMK04828-EP) recommended for deterministic phase repeatability across 60 AFE7950 devices over power cycles? Any preferred alternative?
SYSREF: What SYSREF frequency and generation scheme do you recommend (evaluating 12.5 MHz or 6.25 MHz; continuous vs. N-pulse)? Should SYSREF be generated at the root and distributed, or generated per board?
Deterministic phase: With each AFE7950’s internal PLL generating ~12 GHz from the common 100 MHz reference, is Subclass 1 SYSREF alignment sufficient for repeatable device-to-device phase across power cycles, or are additional steps required?
Calibration: For a phase-coherent multi-channel acquisition system in this frequency range, what is TI’s recommended RX common-pilot and TX feedback-path calibration methodology (NCO phase / delay table compensation), and how to maintain it over temperature?
Reference noise budget: With 100 MHz multiplied to ~12 GHz (~41.6 dB theoretical PN degradation within PLL bandwidth), what reference phase noise / jitter performance do you recommend? Should the root be a jitter cleaner (LMK04828 PLL mode) rather than a pure distributor?

Reference designs, EVM guidance, or app notes for multi-AFE7950 synchronous systems would be greatly appreciated.

Best regards