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/1686881/afe7071-dacclk-input-swing-and-common-mode-requirements-with-lmk1d1204pFri, 02 Oct 2026 22:58:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7ca73555-d6b3-4028-a3e7-cd58bc317059River DowdyPart Number: AFE7071 Other Parts Discussed in Thread: LMK1D1204P 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, RiverAFE7071LMK1D1204Phttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1686846/afe7950-designing-with-gtyp-transceiversFri, 02 Oct 2026 19:28:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3f5964fb-0a1a-4af8-b693-17effbe6cfebBrian CantyPart 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.AFE7950https://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1680871/afe7950-problem-achieving-deterministic-latency-and-clock-definition-using-afe7950evm/6498117Wed, 30 Sep 2026 07:30:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3c67f423-679a-48e8-9379-2f5761ec161fRafael MoraisHi Roshan, Can you provide the command via script to configure the LMK in divider mode? Regards, Rafael Moraishttps://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/6497471Tue, 29 Sep 2026 18:31:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:155127d8-a7c4-488e-a4a0-8c3fd3983771Xu LiIn 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.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/6497450Tue, 29 Sep 2026 18:15:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1f62f320-e965-48ca-9b19-09580839d237Xu LiHi Roshan, Thank you. We have already followed SBAA543 §3.2 and §4 throughout, and its RBD formula is what we use. Our difficulty is the premise of §4.2: that f_counter_all_lane_ready repeats from one bring-up to the next, so that one measured RBD can be frozen into the configuration. On our board it doesn't, although SYSREF is latched deterministically. Setup. AFE7903 DAC-side link, JESD204B subclass 1, L=4 M=4 F=2 S=1 K=16 at 10 Gbps, so F×K/4 = 8. External 6 GHz device clock with the AFE PLL bypassed. SYSREF comes from an LMK5B33216, one pin pulse per request on a 288 ns grid (9 multiframes). The FPGA is the transmitter. SYSREF is latched deterministically on the same 6 GHz edge every bring-up. On each power-up, we sweep the LMK5B33216's SYSREF analog delay through its full range against the AFE's own SYSREF timing detector, and set the delay to the center of the widest window where the detector reports sufficient margin. Every sweep finds the same two windows, exactly one device-clock period (167 ps) apart. SYSREF is therefore captured on one fixed 6 GHz device-clock edge, with setup and hold margin, at every bring-up. As a cross-check, moving the pin SYSREF 4 ns later shifts the arrival count by exactly one, as it should. Yet the arrival count is not repeatable. On the CD deframer, f_counter_all_lane_ready takes values from 0 to 7 across bring-ups, the whole LMFC period, with lane skew 0–2. It is set during the bring-up, before the link-up steps, and normally holds until the next reset. adcDacSync keeps it in most cases but redrew it in 2 of 37 link-ups. The spread can't come from the latch. One count is 4 ns, i.e. 24 device-clock periods, while a latch landing one edge off would move timing by only 167 ps. The latch is fixed, so the variation must arise after it: in how the LMFC counter is phased relative to the captured edge. The FPGA side is deterministic. Its LMFC takes SYSREF on the same phase every bring-up, its ILA starts on its LMFC edge, and the AFE reports sysref_cnt_on_release_opportunity = 0. None of the following removes the spread: a single SYSREF pulse versus a three-pulse burst at link-up, SYSREF by SPI versus pin at the PLL step, the digital clock-divider dither disabled, or the SerDes FIFO seating. In each case the count still varies over most of 0–7 . Why §4.2 doesn't work here. p.10's condition all_lane_ready < RBD has to hold on every bring-up. With the arrival covering all 8 counts, no single frozen RBD satisfies it. With a fixed RBD, our TX→RX loop latency came out at 501 or 517 samples: one multiframe apart, with about one bring-up in three late. Our current workaround, the one applied at every boot, is to connect TX to RX directly and measure. On every bring-up we read f_counter_all_lane_ready , set RBD = (c + 4) mod 8 as in §3.2, apply it with adcDacSync , and move the FPGA receiver's release point by the opposite amount. That holds the loop at one latency: Always 507 samples with the phase within 0.1° on 20 of 20 bring-ups today, and 41 of 41 earlier across re-inits, FPGA reloads and power cycles. It is a compensation, not a fix, and we'd rather use TI's deterministic method: the CAFE setGoodRbd description itself says per-bring-up placement may not give deterministic latency and recommends measuring once, which on this board we can't do. This method solves ADC + DAC combo determinism, but not ADC or DAC alone. Questions §5.1 item 2 attributes a non-repeating arrival to SYSREF not being latched deterministically, or to a non-deterministic transmitter. Both are ruled out here: the timing detector confirms a margined, repeatable latch, every single boot time, and the transmitter is deterministic. What else sets the phase of the DAC JESD LMFC counter relative to the captured SYSREF edge? Has LMFC-to-SYSREF determinism been characterized with the PLL bypassed and an external device clock? The validated-mode list we have from Latte uses the internal PLL throughout. This differs from the EVK: we used the LMX2820 as the low-phase-noise DEVCLK source here. We also mastered using the " SYSREF timing detector " to center the SYSREF edge. Is there a supported configuration that resets the LMFC counter deterministically on the SYSREF edge? If not, is per-bring-up placement with a matching FPGA-side release TI's recommended approach for this case? We can share register-level details privately if that helps. Regards, Xu Lihttps://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/6497407Tue, 29 Sep 2026 17:43:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:96fdff21-e361-4bae-887b-b0246c04ade2Roshan N THi, Please refer "Determining Optimal Receive Buffer Delay in JESD204B and JESD204C Receivers" guide. Link: https://www.ti.com/lit/an/sbaa543/sbaa543.pdf?ts=1790703404730 In this guide sysref, LMFC etc.. are explained in detail to achieve deterministic latency. Regards, Roshanhttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1680871/afe7950-problem-achieving-deterministic-latency-and-clock-definition-using-afe7950evm/6497395Tue, 29 Sep 2026 17:23:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d830ccb7-751d-4997-bbda-2400a578b683Roshan N THi, Configuring the LMK in PLL mode to achieve 46.08 MHz is not possible because the VCO is running at 2949.12 MHz, and the maximum divider for the LMK clock output is 32. Instead, the LMK can be configured in divider mode, so the LMK takes an input clock and provides both the FRef and the FPGA reference clock using a divider factor <= 32 Example: LMK Input Clock: 1474.56 MHz FRef: 491.52 MHz FPGA RefClk: 46.08 MHz Regards, Roshanhttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1685185/afe7906-syncronization-of-adcFri, 25 Sep 2026 07:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:61cc7e8a-775c-49d3-af2a-1e3a78c46594BHAVANISH PPart Number: AFE7906 How to syncronization NCO and AFE seriesAFE7906Aerospace & Defensehttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1683729/afe7951-afe7950evm-tx-power-variation-rx-noise-floor-density-inconsistency-across-channels-at-9-6ghzSun, 20 Sep 2026 06:50:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c39d2fb5-2d28-45e2-8b57-1ebc947cc231Luke ChiangPart Number: AFE7951 Other Parts Discussed in Thread: AFE7950 Hi TI Team, We are currently evaluating the AFE7950 EVM for an C/X-band application and have encountered a few questions regarding the RF performance across different channels and frequency bands. We would greatly appreciate your guidance on the following points: Question 1: TX/RX Channel Power Discrepancies & RF Matching at 9.4–10 GHz When testing the AFE7950 EVM at 9.6 GHz , we observed noticeable variations in output power between the transmit channels (specifically between TX13 and TX24 ). Is this channel-to-channel power difference primarily driven by RF impedance mismatches, or is it mainly due to PCB trace losses and layout routing differences on the EVM? We noticed that the $S_{11}$ parameters differ among the transmit channels. Could you kindly clarify if the onboard matching network on the standard EVM is optimized for a specific default center frequency? If our system operates within the 9.4 GHz to 10.0 GHz range, what recommended design methodologies or guidelines should we follow to optimize the RF matching network? Additionally, we observed similar power/gain inconsistencies across the RX channels . Are these RX variations also attributed to the same matching/trace loss factors? Question 2: RX Noise Spectral Density Variance Across Channels We also noticed a systematic difference in the receiver noise spectral density across the four RX paths: Channels RX1 and RX3 show a lower noise floor density compared to Channels RX2 and RX4 . Could you help us understand the potential root cause of this noise density difference between odd and even channels? Some literature suggests this phenomenon might be related to JESD204B/C high-speed lane assignments, clock distribution, or digital crosstalk. Could you confirm if this applies to the AFE7950 EVM, or if there are specific RF/analog power supply domain factors we should investigate? What is the root cause of this noise density offset between the odd and even channels? I read in another TI document/application note that this phenomenon might be related to the JESD204B/C lane assignment and clocking/digital crosstalk on specific high-speed lanes. Is this true for the AFE7950, or are there other RF/analog layout and power domain factors contributing to this behavior? Thank you very much for your time and help. Looking forward to your insights! Best regards,AFE7951AFE7950EVMAFE7950https://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-upsSat, 19 Sep 2026 19:25:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:640b078c-f370-40e2-b5a6-66440f8dcc36Xu LiPart Number: AFE7903 Other Parts Discussed in Thread: LMX2820 , , LMK5B33216 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.AFE7903LMX2820LMK5B33216Aerospace & Defensehttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1677889/am6442-am6442-use-the-profinet_device_demo-of-ind_comms_sdk/6485541Wed, 16 Sep 2026 15:26:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:efb74d2f-dcf6-4aa1-bf49-a07dcde32e66Kamil AlkhouriHello ZX T, since you are using your own custom board, the support we can offer here is limited. You may reach out to your regional sales representatives for custom support and deliveries. In general, I would advise you to verify the network interface behavior: 1. Do you see any packets on Wireshark? 2. Our PROFINET example runs on PRU-ICSSG. Are you doing the same? 3. Do you have the same PHYs used by our AM64x EVM? if not, you need to modify PHY configuration. Kind regards, Kamilhttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1682065/afe7950-package-material-propertiesMon, 14 Sep 2026 15:55:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:750c0cb3-1f38-48ba-8726-9bbb00152897Jocelyn WilkinsPart Number: AFE7950 Hello, Please provide the Young's Modulus, Poisson's Ratio, and CTE of the package and/or the constituent materials for the subject line partsAFE7950https://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1678449/am3352-am3352-rgmii-radiated-emi-25-mhz-125-mhz-harmonic-emissions/6482401Mon, 14 Sep 2026 15:24:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c852ad2c-758a-48c5-9974-fa06ec85d6fcKallikuppa SreenivasaHello Erfan Omidvar, Thank you for the detailed explanation, sincerely appreciated. Regards, Sreenivasahttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1678449/am3352-am3352-rgmii-radiated-emi-25-mhz-125-mhz-harmonic-emissions/6482384Mon, 14 Sep 2026 15:11:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f11fc5f0-3eab-4484-a31d-2f464f27172eErfan OmidvarHi Sreenivasa, Yes, I meant the actual far-field measurement performed at the CE test laboratory. During our own troubleshooting, I used the HZ552 H-field probe for near-field measurements to identify and localize the main radiation sources on the PCB, particularly around the PHY and Ethernet/RGMII traces. After making the PCB changes, we sent the device back to the CE laboratory, where they performed the standard radiated-emissions test using the full test setup and measurement antenna in the chamber. This was used to evaluate the far-field radiation and confirm the actual emissions against the applicable limits. So, when I mentioned “far-field,” I was referring to the laboratory measurement with the actual test setup, rather than the close-probe measurements I performed during debugging in our lab. Regards,https://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1678449/am3352-am3352-rgmii-radiated-emi-25-mhz-125-mhz-harmonic-emissions/6482318Mon, 14 Sep 2026 14:25:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:07fdc815-f52e-4292-989e-47fd5f50cfc2Kallikuppa SreenivasaHello Erfan Omidvar, Thank you for the inputs and glad you were able to resolve the issue. [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/6482226"]UPDATE in Far-field test: [/quote] Can you please elaborate what you meant by far-field - is it testing with actual setup? Regards, Sreenivasahttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1678449/am3352-am3352-rgmii-radiated-emi-25-mhz-125-mhz-harmonic-emissions/6482226Mon, 14 Sep 2026 12:58:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:71705a54-4fa8-4fe2-baae-127bfda647c7Erfan OmidvarUPDATE in Far-field test: Root cause identified: the electrically floating metal thermal/mechanical layer above the PCB was strongly coupling to RF energy generated by the Ethernet/PHY circuitry and acted as an unintended resonant/radiating structure. Removing the metal layer eliminated the excessive emissions. Electrically bonding the metal layer to PCB ground also eliminated the failure, confirming that its floating RF potential/coupling was a major contributor to the EMC issue.https://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1680967/lm706a0-lm706a0-ibb-drop-with-different-loading/6480324Fri, 11 Sep 2026 02:07:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:36246f78-fb7f-4301-8397-772ffc44d2e9Pramanik PatelHi, There seems some unstability. I will try calculating poles and zeros to see there is a issue. Thankshttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1681314/afe7950evm-latest-trm-register-map-still-only-sbau337-deprecated-may-2020-in-afe79xx-hsc-designFri, 11 Sep 2026 01:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:af3c858c-6015-4915-a5f2-d02efd143b7bLi LeonPart Number: AFE7950EVM We requested ande downloaded AFE79XX-HSC-DESIGN. The only full register document we can find is still Deprecated_Register_Set_SBAU337_13th_May_2020. Our SPI log ( Afe79xxPg1 ) contains many field names and addresses that are not in SBAU337. So we are not sure if this deprecated document is right. Questions: Where is the current TRM/ register map for the AFE7950EVM?AFE7950EVMhttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1677181/lmzm23601-locating-stock/6479461Thu, 10 Sep 2026 13:13:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d4deddfd-524d-454c-b884-397393e233faRaz ZeevyHi Paul, Depends which version is in the radio. The 3.3V part you can get, TI.com shows 1805 of V3SILR today besides the two 5V reels above. The adjustable SILR/T is at zero everywhere I can see, restocks out in 2027. Pin-to-pin fallback per the datasheet is the LMZM23600, 258 on TI.com today, but it's 0.5A so check your load. We mapped module crosses for the SILR at Parter too parter.ai/.../lmzm23601silrhttps://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1680967/lm706a0-lm706a0-ibb-drop-with-different-loading/6479160Thu, 10 Sep 2026 08:50:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:28b2db03-6196-491e-88f7-14747d74c272Alvin TsaiHi Patel, We try your suggestion and add output caps(10uF*2 and 22uF*2). It seems to improve voltage drops. But the power good is abormal behavior. So we change to EXT COMP. the power good is normal. then we want to know the SW waveform is different betwewn 1A and 2A. SW pin have ring and triple on/off in 2A but SW always on/off in 1A. Internal COMP: Loading 0A 0.5A 1A 2A 3A Vout -8.24V -7.97V -8.08V -8.28V -7.53V Wavform EXT COMP: Loading 0A 0.5A 1A 2A 3A Vout -8.24V -7.94V -7.88V -7.77V -7.44V Waveform