https://e2e.ti.com/support/rf-microwave-group/rf-microwave/Products covered in this section are Digital Radio (Gray Chip) Products. en-USTelligent Community 13https://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1683701/afe7903-afe7903-jesd204b-subclass-1---internal-lmfc-offset-from-sysref-differs-by-0-7-frame-clock-cycles-across-bring-ups/6521478Mon, 26 Oct 2026 18:48:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f0d5d661-6c94-4b28-82c0-a4cba034888fXu LiHello Roshan, Points 1, 2, and 3 are met. The LMK5B and the LMX2820 are configured once and locked before AFE RESETZ is released, and nothing reconfigures them during an AFE bring-up. After that, the only LMK5B action is the SYSREF request itself. My board's SYSREF connection refers to AFE7900: Using LMK5C33126A and LMX2820 to drive AFE7900 REFCLK and dealing with SYSREF (except I changed to LMK5B33126, and 250MHz reference to LMX2820 to generate thr 6 GHz DEVCLK) My board's SYSREF is a DC-coupled pair from LMK5B OUT1 directly to the AFE, with no termination or bias components. The pair runs on inner layers under both BGAs, so I can't probe it or switch it to AC coupling. OUT1 is HSDS with 400 mV VOD (800 mVpp differential) and a 0.7 V common mode, inside the AFE's 0.6-0.8 V common-mode range and its swing limits. The AFE's own SYSREF timing detector (readSysrefMonitor) reads "sufficient margin" at the same LMK delay code in twenty sweeps of twenty. SYSREF, SYNC~, the NCOs, and both JESD links all work, which is how I measured the problem at all. (Otherwise I won't get the waveform and count samples to find LMFC mod of 8 lottery in the first place) Point 2. The FPGA's JESD core is my own, with no vendor IP. Its LMFC aligns to the first SYSREF edge after it is armed. Across AFE re-initializations, its counter reads the same value at every later SYSREF edge, checked with an ILA. The test method and symptom. TX2 is cabled to RX1. I play a tone on TX2, capture it on RX1 with a timestamp (also driven by the LMK5B clock), and measure the TX-to-RX latency in samples. With a fixed RBD, the latency is one of two values, one multiframe apart: 506 or 522 samples, depending on bring-up. Underneath, getAllLaneReady is drawn uniformly over 0-7 (F*K/4 = 8). Delaying OUT1's SYSREF by 4 ns moves the count by exactly one, so the AFE's JESD LMFC does follow the SYSREF edge, but with an offset of 0-7 words. The offset is drawn once per RESETZ, is held through later SYSREF pulses, and is only occasionally redrawn by adcDacSync. Point 4. AFE only: ten re-inits from RESETZ with the FPGA image, the LMK5B and the LMX2820 left running gave getAllLaneReady = 1, 7, 3, 1, 7, 4, 3, 1, 0, 1. FPGA only: twenty FPGA link resets (GT receivers reset, link re-armed) with the AFE left running held getAllLaneReady at 6 on all twenty. A full FPGA reload with the AFE untouched isn't possible on this board because the board controller stops the AFE clocks while the FPGA reconfigures. The non-determinism is the AFE's. Point 5. Continuous SYSREF, DC-coupled (the only option on this board), ran from before RESETZ through link-up and was turned off afterward. Twenty bring-ups gave 3, 4, 1, 0, 2, 7, 6, 7, 5, 3, 0, 0, 4, 7, 2, 0, 7, 7, 1, 6, all eight values, the same as pulsed SYSREF. What I found. The link-up SYSREF reaches the JESD blocks only through the digital domain's leak (AFE register map Property_50h[23:16]), and that leak also re-syncs the digital dividers that clock the JESD LMFC counters. If the counter's reset is synchronous to that clock, it is taken while the clock restarts and never lands, so the counter keeps whatever phase its clock's start left it. I tried to separate the two with the documented registers, twenty bring-ups each: - With the LCM divider's SYSREF reset disabled (Property_34h[23] = 0) for the link-up pulse, no SYSREF reached the JESD blocks (ADC JESD 0x0130 stayed clear). - With the pin SYSREF taken to the domains directly (Property_34h[25] = 0) and the LCM divider left running, the link came up and the count was still drawn. - With that, plus the digital domain's leak at 0 and the other leaks kept, no SYSREF reached the JESD blocks. - With every domain's leak at 0, no SYSREF reached the JESD blocks. - With four pulses (the first for the LCM divider, the converter clock dividers, and REFDIV; a second for the ADC, FB, and DAC domains; a third for the digital domain; sysrefJesdLinkup unchanged on the fourth), the link came up, and the count was still drawn. No documented register delivers SYSREF to the JESD LMFC counters without re-syncing the digital domain on the way. What works. I apply SBAA543's method at every bring-up instead of once. I read getAllLaneReady, set RBD to count + 4 mod 8 with setManualRbd, set the FPGA's release point to keep the sum of the two release points constant, and relink with adcDacSync. This takes about 0.1 s, needs no loopback, and has given a single latency on every corrected bring-up: 41 of 41 in September and every one since. So SYSREF alone does not give this AFE deterministic latency, which defeats the JESD204B subclass 1 promise. SBAA543's frozen RBD fails here, because the count it freezes is redrawn at every RESETZ. Without the correction, the TX and RX paths move by the offset in opposite directions. The loopback ( TX2 is cabled to RX1 ) measures only their sum, and neither path has been measured on its own. Questions: 1. Any possible register or mode that delivers SYSREF to the JESD LMFC counters without re-syncing the digital domain divider? (the crux) 2. If there is none, how is the counter's reset meant to land on a clock that the same SYSREF restarts? 3. Does the JESD block have an LMFC-to-SYSREF alignment status we can read after link-up? Additional Claim: If these questions have no answer, that does not disqualify the AFE7903; it remains a good device for this design. You may close this issue because applying the RBD correction at every bring-up is ok for us, and I will continue to use it. Best regards, Xu Lihttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1691950/tps25763-q1-tps25763-configuration-and-programming/6519915Fri, 23 Oct 2026 15:45:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:fce36a40-293d-4e59-8aab-110b878dff65Seong KimHello Rafal, You can submit a request for the FW package from here -> https://www.ti.com/drr/opn/TPS25772-Q1-DESIGN BR, Seonghttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1692272/afe7950evm-needed-clarifications-regarding-tx-nco-hoppingFri, 23 Oct 2026 12:53:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9ec89a3d-8395-470c-993f-81dd0a80c1b2ABDCEFPart Number: AFE7950EVM Dear Team, In a project we are trying to do NCO-hopping. As per our idea, we only have 16 possible states to hop. But i have to do hopping of 3 different frequencies over 4 tx channels , which is in result causing for more possible states. So i am configuring them as per the below way in the AFEConfig.py . So after bringup i am programming all TX-NCO's to 10GHZ and then i am sending that [3:0]TX_NCO_SEL value as '0' , which in turn only configuring channel-A to 9.2GHZ .So i was expecting that all the remainig channels NCO are at 10 GHZ. But all the other channels are going back to 9.5GHZ, which i have given as in sysParams.txNco0. So what i want is now, after configuring i dont want the other channels to go to it's defult NCO state, other than that i want to disable the GPIO programming for the other 3 channels and i want to manually program them from LATTE/ from PS. Basically i want to make the other 3 channels listen to LATTE normal programming, other than going back to it's defult NCO value. Please let me know if you need any other clairfiacations. AFEConfig.txt LMKConfig.txtAFE7950EVMAerospace & Defensehttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1687109/afe7950evm-afe7950-external-10mhz-not-lock/6519649Fri, 23 Oct 2026 11:09:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f1435186-cc9c-4d85-aa9f-ac778668fb0dLuca MeloniSolved with: AFE7950EVM: LMK04828 PLL1 doesn't lock to external clock - RF & microwave forum - RF & microwave - TI E2E support forumshttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1687109/afe7950evm-afe7950-external-10mhz-not-lock/6519637Fri, 23 Oct 2026 10:58:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:79abbf02-c081-478e-816e-528f1bac9d40Roshan N THi, What's the 10Mhz clock power? When capturing the Rx channels, you can determine if the EVM is unlocked from the 10MHz reference by checking the signal coherence. Even if a coherent signal is fed into the Rx channel, the captured FFT will show non-coherent results if the reference is not locked. When the D4 LED is unlit, do you observe the signal remaining coherent or becoming non-coherent? Regards, Roshanhttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1683701/afe7903-afe7903-jesd204b-subclass-1---internal-lmfc-offset-from-sysref-differs-by-0-7-frame-clock-cycles-across-bring-ups/6519626Fri, 23 Oct 2026 10:47:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:47b7431c-eb95-4b76-90fb-6a667e7a5d57Roshan N THi Xu, The SysRef frequency looks good. The clock dividers, N-dividers, NCO, and the JESD block (including the LMFC) all realign when executing adcDacSync(pinSysRef = 1) (sysref leak aligned with the external sysref), which confirms that the SysRef is leaking and relinking in alignment with the external sysref. As you mentioned the RBD remains stable after every adcDacSync(1) with bringup, it indicates that the entire device realigns with the external SysRef properly also the AFE and FPGA are aligned within a bringup To debug further, please check the following: SysRef Common Mode Voltage and swing: What is the common mode voltage for the SysRef? The AFE requires a common mode voltage of 0.6V. Have you probed and verified that both the common mode voltage and the swing are within limits? Please share the SysRef path circuit between the AFE and the LMK here or via email. FPGA Clocking: Have you probed the FPGA clocks (Reference clock and SysRef) to ensure they are within spec? Does the FPGA align with the SysRef after programming only once, or you're aligning it whenever required? Check the RBD without disturbing the Clock: Are you reconfiguring the LMX and LMK during every bring-up? If so, please try configuring them only once, then bringup the AFE and FPGA. Reconfigure only one device at a time: If points 1, 2 and 3 are verified. Bring up only the AFE multiple times while keeping the FPGA and clocking untouched, then check the RBD. Conversely, bring up the FPGA multiple times while keeping the AFE and clocking untouched, then check the RBD. This will help identify which device is not deterministic. Continuous sysref: Can you check with continuous sysref with AC coupled; leak the sysref always from the LMK during bringup and linkup. This will confirm that the issue is when using pulsed sysref not any other clocks. Regards, Roshanhttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1691950/tps25763-q1-tps25763-configuration-and-programmingThu, 22 Oct 2026 13:49:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:303604c8-6347-4bd9-8f25-adaa8de62611Rafal PlichtaPart Number: TPS25763-Q1 Dear Technical Support Team, Would be able to help with configuration of TPS25763 by providing a base firmware files, please? Regards, RafalTPS25763-Q1Wireless Infrastructurehttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1691375/sn74avc4t245-clarifications-on-junction-temperature-limit-for-sn74avc4t245dgvr-package/6517556Wed, 21 Oct 2026 18:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8fb525ae-68e2-4779-8e24-e6d07712df52Joshua SalinasHello, The max junction temperature is equal to the max storage temperature. See FAQ below: [FAQ] What is the maximum junction temperature (TJMAX) for a device? Based on this, the junction temperature does not exceed the absolute max junction temperature. For supporting documentation, see this Application Note: Semiconductor and IC Package Thermal Metrics Regards, Joshhttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1691375/sn74avc4t245-clarifications-on-junction-temperature-limit-for-sn74avc4t245dgvr-packageWed, 21 Oct 2026 06:12:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:142ffed7-1117-413a-adbb-5d40c678d5d6Suryaprakash APart Number: SN74AVC4T245 Hi, We are currently using the SN74AVC4T245DGVR component in one of our boards. Based on the datasheet specifications, we performed a thermal simulation using the following parameters: Ambient temperature: 5 5°C Power dissipation: 0.544 W Thermal characteristics: Rja: 126 °C/W Rjc: 50 °C/W For the simulation, we considered an ambient temperature of 55°C. The results showed: Component temperature : 65.33°C Junction temperature : 92.97°C However, we could not find the maximum allowable junction temperature for the SN74AVC4T245DGVR in the datasheet. Could you please confirm whether the above thermal results are within the safe operating limits specified by the manufacturer? Based on these results, should the component be considered Pass or Fail from a thermal reliability perspective? Additionally, if available, please provide the following information: Maximum junction temperature (TJ(max)) Recommended junction temperature limit for reliable operation Any thermal derating guidelines Supporting documentation or application notes related to thermal limits and power dissipation Your support in providing this information would be greatly appreciated.SN74AVC4T245https://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1690781/afe7950-request-firmware-for-96lc46a-connected-ft4232h-on-afe7950evm-boardMon, 19 Oct 2026 13:45:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:49e579b2-812f-4d4f-bffe-6f44adcc0ccaAli KelemPart Number: AFE7950 Hi, We've designing a board with AFE7950 and Kintex FPGA We need firmware code for EEPROM 96LC46A connected FT4232H on AFE7950 EVM board. Otherwise, I think we will not able to access AFE7950 registers by using Latte Tool. Right? We can use Latte Tool on EVM without any problem. Could you please help us? Thanks. AliAFE7950EVMAFE7950Aerospace & Defensehttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1690460/afe7950evm-fe7950evm-zcu104-dac-jesd-re-asserts-sync-with-no-alarms/6514427Mon, 19 Oct 2026 10:48:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c0da11e7-56dc-481f-b611-9f3be1197982Ngoc Hai NguyenHi TI team, Quick update. I switched the FPGA (TI204c IP) and Latte to JESD204C 64b/66b, and the DAC link is up now. The ADC ramp test pattern is also received correctly. I still want to understand the 8b/10b case. I changed jesdRxSyncMux from [2,2,2,2] to [0,0,2,2]. After that one change, jesd_buf_state reads 0x1 instead of 0x0. The rest is the same as before: CS = 10, FS = 00, no alarms, SYNC~ stays low, and the 8b/10b DAC link still does not come up. What does jesd_buf_state = 0x1 mean? SBAU337 and the JESD App Note only describe 0x0 and 0x3. Any idea where the problem could be? Thanks!https://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1690460/afe7950evm-fe7950evm-zcu104-dac-jesd-re-asserts-sync-with-no-alarmsSat, 17 Oct 2026 10:17:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1222c32c-fd5c-4ff0-b094-468b0cf95580Ngoc Hai NguyenPart Number: AFE7950EVM Other Parts Discussed in Thread: LMK04828 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.xlsxLMK04828AFE7950EVMWireless Infrastructurehttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1683701/afe7903-afe7903-jesd204b-subclass-1---internal-lmfc-offset-from-sysref-differs-by-0-7-frame-clock-cycles-across-bring-ups/6513739Fri, 16 Oct 2026 21:20:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1f26303d-0401-48cc-b880-2198aadaeb11Xu LiBelow 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, " best[1] - best[0]: best = (passes[i], passes[j]) i = j + 1 if best[0] 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 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()https://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1683701/afe7903-afe7903-jesd204b-subclass-1---internal-lmfc-offset-from-sysref-differs-by-0-7-frame-clock-cycles-across-bring-ups/6513662Fri, 16 Oct 2026 19:22:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5689354d-167b-47b8-b4a7-4a4c1ba56f31Dajon McGillTeam 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.https://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1689451/afe7952-number-of-frequency-bands/6512925Fri, 16 Oct 2026 07:56:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d4242fe8-6ac2-4804-bd38-00491ecab3a7Shunsuke YamamotoHi 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 Yamamotohttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1689698/afe8108-ddc-duc-count/6511019Wed, 14 Oct 2026 19:05:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:31ee27d8-d8b2-4bf3-9263-ac9e4dcb02b1Vijayendra Varma SiddamsettyHi Dan, Datasheet is correct. We will update the webpage to reflect this. Regards, Vijayhttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1689698/afe8108-ddc-duc-countWed, 14 Oct 2026 17:48:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:979e3a1b-1be8-436f-a22a-eeb3d42d96e7Daniel BarbalatoPart 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! -DanAFE8108https://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1689451/afe7952-number-of-frequency-bands/6510636Wed, 14 Oct 2026 14:38:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:55261744-6c8f-4cb1-b93c-82c0f14c4926Kang HsiaHello 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.https://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1689451/afe7952-number-of-frequency-bandsWed, 14 Oct 2026 08:00:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0ebc61ee-3f0a-4fbd-bfbd-364646108197Shunsuke YamamotoPart 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 YamamotoAFE7952Wireless Infrastructurehttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1683701/afe7903-afe7903-jesd204b-subclass-1---internal-lmfc-offset-from-sysref-differs-by-0-7-frame-clock-cycles-across-bring-ups/6509759Tue, 13 Oct 2026 22:28:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e3180c7d-4ce4-48bc-bf8b-1dbcd1de6a0fDajon McGillTeam - Any suggestions for Xu?