Agilex 7 R-Tile RBES FPGA – CXL Device Enumeration Failure with CXL IP Design Example
1. What is the failure symptom? Please elaborate on the failure symptoms in detail. The CXL device fails to enumerate when using the CXL Type-3 IP design example. • lspci -vvv | grep 0ddb does not detect the CXL device • numactl -H does not report a CXL NUMA node The issue persists across multiple system reboots and bitstream rebuilds. A factory reset was attempted but did not resolve the issue. 2. When did the failure happen? When did you buy the part, and when did you receive it? The device failed at some point around October 2025. 3. How did you discover the failure? Please describe it in detail. We found OS failed to find the CXL device and confirmed the issue after factory recovery. 4. In which part of your process did you find the issue (Lab, production, quality, etc.)? Lab environment.4.1 Was the device already in the field? How many times has it been used? No. The device has only been used in a controlled lab environment for bring-up and testing. 5. How many units failed and how many units were used/tested by you? Which is the production code? • Failed units: 1 • Units tested: Multiple Agilex FPGA boards • Production code: Not available Only this unit exhibits the failure. 6. How did you determine the failure? Please elaborate on the procedures. Multiple bring-up attempts were conducted using known-good hardware, software, and bitstreams. • 6.1 Internal Debug: No internal physical failure analysis was performed. • 6.2 Device Swap: Yes. Replacing the board with a known-good FPGA resolves the issue. 7. Was the failing unit ever working before the failure? Yes. The device was functioning correctly before the failure. 8. How did you rule out electrical overstress (EOS) or electrostatic discharge (ESD)? There is no visible physical damage on the FPGA or PCB. The board has been handled according to standard ESD-safe lab procedures. 9. What are your expectations from this failure analysis? Identify the root cause of the failure and restore proper CXL IP functionality, or provide a replacement device. 10. Have you re-balled your device? If yes, was it lead-free reballing? No. The device has not been re-balled, and no third-party rework was performed. 11. Please add pictures of the device from the top and the bottom. See attached. 12. Is there any other relevant information that could assist in the failure analysis? No additional information at this time. 13. Are there any known changes to the process, materials, or design that could have contributed to the failure? No.Agilex 7 R-Tile RES FPGA – CXL Device Enumeration Failure with CXL IP Design Example
OPN:DK-DEV-AGI027RES (Power Solution 1) SN: AGIPCIE8000296 1.Failure Symptom The CXL device fails to enumerate when using the CXL Type-3 IP design example. • lspci -vvv | grep 0ddb does not detect the CXL device • numactl -H does not report a CXL NUMA node The issue persists across multiple system reboots and bitstream rebuilds. A factory reset was attempted but did not resolve the issue. 2. When did the failure happen? When did you buy the part, and when did you receive it? The device was received approximately two years ago. The failure was observed during initial bring-up and has been present since first use 3. How did you discover the failure? Please describe it in detail. We programmed the FPGA with the CXL Type-3 design example; however, the host server failed to enumerate the device. The same bitstream works correctly on other Agilex FPGA boards, indicating the issue is specific to this unit 4. In which part of your process did you find the issue (Lab, production, quality, etc.)? Lab environment. 4.1 Was the device already in the field? How many times has it been used? No. The device has only been used in a controlled lab environment for bring-up and testing 5. How many units failed and how many units were used/tested by you? Which is the production code? • Failed units: 1 • Units tested: Multiple Agilex FPGA boards • Production code: Not available Only this unit exhibits the failure. 6. How did you determine the failure? Please elaborate on the procedures. Multiple bring-up attempts were performed using known-good hardware, software, and bitstreams. • 6.1 Internal Debug: No internal physical failure analysis (e.g., X-ray or short-circuit testing) was performed. • 6.2 Device Swap: Yes. Replacing the board with a known-good FPGA resolves the issue. 7. Was the failing unit ever working before the failure? No. The unit has never functioned correctly since initial use. 8. How did you rule out electrical overstress (EOS) or electrostatic discharge (ESD)? There is no visible physical damage on the FPGA or PCB. The board has been handled according to standard ESD-safe lab procedures. 9. What are your expectations from this failure analysis? Identify the root cause of the failure and either restore proper CXL IP functionality or provide a replacement device 10. Have you re-balled your device? If yes, was it lead-free reballing? No. The device has not been re-balled, and no third-party rework has been performed. 11. Please add pictures of the device from the top and the bottom.See attached. 12. Is there any other relevant information that could assist in the failure analysis? No additional information at this time.Agilex 7 R-Tile RBES FPGA – Board Fails to Power On and JTAG Not Detected
1. What is the failure symptom? Please elaborate on the failure symptoms in detail. The FPGA power LED does not turn on, and Quartus fails to detect the JTAG interface. Debugging steps performed: • Board Test System (BTS) attempted • JTAG detection fails in BTS as well A factory reset was attempted but did not resolve the issue. 2. When did the failure happen? When did you buy the part, and when did you receive it? The failure occurred around early August 2025. The device was received approximately one year ago. 3. How did you discover the failure? Please describe it in detail. Quartus failed to detect the JTAG device, and the FPGA power LED was observed to remain off. 4. In which part of your process did you find the issue (Lab, production, quality, etc.)? Lab environment. 4.1 Was the device already in the field? How many times has it been used? No. The device has only been used in a controlled lab environment for bring-up and testing. 5. How many units failed and how many units were used/tested by you? Which is the production code? • Failed units: 1 • Units tested: Multiple Agilex FPGA boards • Production code: Not available Only this unit exhibits the failure. 6. How did you determine the failure? Please elaborate on the procedures. Multiple bring-up attempts were conducted using known-good hardware, software, and bitstreams. • 6.1 Internal Debug: The device was sent to a university repair shop; however, the issue could not be resolved. • 6.2 Device Swap: Yes. Replacing the board with a known-good FPGA resolves the issue. 7. Was the failing unit ever working before the failure? Yes. The device was functioning correctly before the failure. 8. How did you rule out electrical overstress (EOS) or electrostatic discharge (ESD)? There is no visible physical damage on the FPGA or PCB. The board has been handled according to standard ESD-safe lab procedures. 9. What are your expectations from this failure analysis? Identify the root cause of the failure and restore proper CXL IP functionality, or provide a replacement device. 10. Have you re-balled your device? If yes, was it lead-free reballing? Yes. The device was re-balled by a university repair facility. 11. Please add pictures of the device from the top and the bottom. See attached. 12. Is there any other relevant information that could assist in the failure analysis? No additional information at this time. 13. Are there any known changes to the process, materials, or design that could have contributed to the failure? No.
To INTEL - Request for Compliance Data from Analog Devices, Inc
Dear Sir/Madam, GreenSoft Technology, a leading provider of environmental compliance data management services and software for the global electronics industry (http://www.greensofttech.com), has been contracted by Analog Devices, Inc to collect compliance data on parts purchased from your company or request the latest update on the data you previously submitted due to recent regulatory changes. Attached to this e-mail are (1) a letter of authorization from Analog Devices, Inc and (2) a Combined Certificate-of-Compliance template. Please note that Analog Devices, Inc might not purchase directly from your company but via a reseller or distributor. In addition, you may need to collect material or compliance documents from your suppliers to fulfill this request. Your support to Analog Devices, Inc is highly appreciated. If you think we reach out to you by mistake, please let us know right away so we will stop contacting you. If you are the correct supplier, please follow the below instructions: 1. Please review the attached Combined CoC Template (Excel) and complete all the “Data requirements” below by following the instructions in the file. This template will serve as a valid compliance statement and is pre-populated with the corresponding part numbers. 2. Please note – (1) The requirements showing “Received” in the Excel file have already been collected and no additional action is required. (2) If the compliance data is available on your website, please mark “Web” for those parts in the Excel file. (3) If the Part Number is incorrect, please indicate it in the “Note” column of the “PN List” sheet in the Excel file. (4) If GreenSoft does not receive full material disclosure for the components you sold to Analog Devices, Inc, GreenSoft may reach out to you again upon regulation changes. 3. Once completed, please sign, and return to us by January 08, 2026 or provide an expected date of completion and we will follow up. We may contact you if any clarification is needed. Data requirements: • EU RoHS Directive 2011/65/EU as amended by (EU) 2015/863 • REACH SVHC per Article 33 of EU Regulation 1907/2006 • Part Weight and Unit of Measurement. • TSCA PBT substances under restriction per US CFR title 40, part 751 • Halogen Free Certificate of Compliance (CoC) • All Per- and Polyfluoroalkyl Substances (PFAS) are defined as a class of organic chemicals containing at least one fully fluorinated carbon atom. If you have any questions, please visit our suppliers' page at https://www.greensofttech.com/suppliers/. You may contact us by phone at +1 323-254-5961 x 2, and our Support Engineers will help you with your questions. If no one is available, please leave a voice mail with your name, company's name, questions about the request, and the best number to reach you. If you need to contact me directly, please email me at the email address listed below. Best Regards, Grayson Wang Project Engineer grayson@greensoft-usa.com GreenSoft Technology, Inc. 155 S. El Molino Ave, Suite 100, Pasadena, CA 91101, USA Ph: 323.254.5961 www.greensofttech.com DISCLAIMER: The information transmitted by this email is intended only for the person or entity to which it is addressed. This email may contain proprietary, business-confidential and/or privileged material. If you are not the intended recipient of this message, then any use, review, retransmission, distribution, reproduction or any action taken in reliance upon this message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete or destroy any copy of this message. Emails directly from GreenSoft Technology Inc. are limited to the @greensofttech.com and @greensoft-usa.com email domains. Do not reply to emails identifying as GreenSoft Technology Inc. without reviewing the sender's email address for the beforementioned email domains.
Agilex 3 ESD Protection
What is the ESD rating for A3CZ100BM16AE7S I/O pins (and HSIO true differential pins if they are different)? Do they require external ESD protection, and if so, are there any guidelines on selection of an appropriate device? I intend to use some of the true differential receiver/transmitters for LVDS comms on a 1.3V bank, and found the information shown below about maximum ratings and maximum overshoots implying the maximum voltage on those pins can't exceed ~1.75V, but finding an ESD diode which doesn't breakdown at 1.3V, and clamps before 1.75V is an impossible task, so what is an acceptable clamping voltage?
10AX115H3F34E2SG, Laser marking
Dear INTEL/ALTERA Support Team, Good day. We previously purchased a batch of INTEL/ALTERA components from the authorized distributor ARROW and sold them to my client. Our client has raised concerns about the components having been re-marked. Model: 10AX115H3F34E2SG D/C: 2113, Lot Number: S848AK02TW, COO: Taiwan, Arrow Delivery ID: 011717919 We have received a statement regarding the product markings, which says: "De-mark/Re-mark is a qualified and controlled process within the manufacturing site. There is no impact on quality, reliability, and compliance with specifications on a de-marked/re-marked product." Attached please check our document. Could you please help verify the authenticity of this statement? Is it from Altera? We would greatly appreciate it if you could provide clarification to help address our client’s concerns. Hope to receive your feedback soon. Best regards, Carol ChoiShift Register triggers occassionally on both clock edges
Good morning community, in my project a MAX10 M08 FPGA serves as an interface between a microcontroller and an ADC board with 32 channels. In order to parallelize the serial data from the board I developed a shift register. This register shall only read the first 512 bits of a data stream. Therefore a counter is included. -- serial-parallel converter synchronous to falling edge of DCLK p_ser_par_dclk : process (DCLK,nRES) is begin if (nRES = '0') then dout0_shr_dclk <= (others => '0'); dout1_shr_dclk <= (others => '0'); mod1023_count_i <= 0; elsif (falling_edge(DCLK)) then -- resets counter when nDRDY active if (nDRDY = '1') then mod1023_count_i <= 0; elsif (mod1023_count_i < 512) then mod1023_count_i <= mod1023_count_i + 1; end if; -- counter masks the 512 DCLK clock edges without data if (mod1023_count_i < 512) then -- shift-registers, alert bit, address bits, CRC bits shifted, maybe later omitted dout0_shr_dclk(0) <= DOUT0; dout1_shr_dclk(0) <= DOUT1; dout0_shr_dclk((snr_length - 1) downto 1) <= dout0_shr_dclk((snr_length - 2) downto 0); dout1_shr_dclk((snr_length - 1) downto 1) <= dout1_shr_dclk((snr_length - 2) downto 0); -- no shifting else dout1_shr_dclk <= dout1_shr_dclk; dout0_shr_dclk <= dout0_shr_dclk; end if; end if; end process p_ser_par_dclk; The data from the AD converters contains the channel number. Therefore there must be regular data patterns in the 512 bit wide vector when a complete set of 16*32bit have been written into the FIFO. I could never see this pattern when I visualized the internal data with the signal tap analyzer. What I can occassionally see is that the shift registers and the counter triggers at the wrong edge. This is a severe error. What could be the reason? Best regards Christof Abt
Documentation issue with 10M40SAE144C8G
I'm working on adding the part 10M40SAE144C8G into a board that will have a small quantity built using a pick and place machine, and need to find information on how it's packaged in tray form. so far any documentation included on the website that I can find hasn't included any info on tray or part orientation in either drawing or even basic text form. is there anything I'm missing or somewhere I can be directed to to find this information?
