Recent Discussions
MAX10 nCONFIG pin slew rate requirement
Hello, is there any requirement for nCONFIG pin of MAX10 family with regards to signal transition time (signal slew rate)? Unfortunately MAX10 data sheet does not include any parameter for the same. It also does not specify, if the nCONFIG includes a Schnitt-Trigger feature which makes any slew rate demand redudant. Best regards Frank
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.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.
Cyclone IV E(EP4CE30) FPGA JTAG and USB-Blaster
Hi Team, I am working with a Cyclone IV E FPGA(EP4CE30), where all my banks (Bank 1–8) have VCCIO = 3.3V. The FPGA core voltage is 1.2V, and the PLL supply is 2.5V. I am configuring the FPGA in Passive Serial (PS) mode. My current doubt is regarding the pull-up voltage for JTAG and USB Blaster: Should the pull-up resistors be tied to 2.5V or 3.3V? What should be the pullup voltage for MSEL Pin..? As per the Hardware Design Guidelines, my understanding is that the pull-up supply should match the VCCIO of the respective bank. Please confirm if this is correct. For your review, I have attached a snippet of the Configuration Pin Schematic. Kindly check and let me know if anything looks incorrect. Additionally, for the 10-pin male header, what should be the voltage level for Pin 4 and Pin 6? Please respond at the earliest. If you need any clarification, feel free to ask. Thank you!
Timing Behavior of Remote Update IP After Reset on Cyclone 10 GX (10CX150YF672E5G)
I am using the Remote Update IP with the Cyclone 10 GX FPGA, part number 10CX150YF672E5G. I observed that the Remote Update IP does not respond properly after reset until approximately 300 µs. I experimented with delays of 1 µs and 2 µs after reset, but did not observe the expected behavior. However, after waiting for 300 µs, the IP responded as expected. Previously, I used the same Remote Update IP with a different part number, 10CX150YF672I5G, and in that case, it worked as expected with just a 10 clock cycle delay after reset. Could you please confirm if there is a specific timing requirement after reset for initializing the Remote Update IP with the 10CX150YF672E5G device? I am using Quartus Prime Pro 24.2 tool for Both version of Cyclone 10GX FPGA(10CX150YF672E5G & 10CX105YF672I5G) Thank you.
IO speed limit while implementing high resolution PWM on Cyclone 10
I would like to implement high resolution PWM on a Cyclone 10 LP. One simple approach I have is running the IO at double data rate for a high possible switching frequency. However as the single ended IOs (3.3V LVTTL for example) cannot switch that fast, when I compiled the design I got a [limit due to minimum port rate restriction (tmin)] with original Fmax=425MHz restricted to 223MHz. But for my application I know I can control the minimum pulse width in software. So my question is where does the IO speed limit actually apply? Does it apply in the IO buffer or does it apply in the double data rate register? In the former case that should not create a problem because I am not switching every cycle, I only want to tune the pulse width with fine steps. In the later case it would. I want to ask this for both input and output, as I might want to measure the realized switching pattern as well. I am aware that another possible way is to add a delay to the IO. However correct me if I am wrong, I don't see how I can dynamically choose the IO delay in any of the IP / primitives. You can dynamically change the phase of the PLL I guess, but I am not sure how fast does it stabilize at the new phase. Also If I use multiple output in my design then I would need a dedicated clock output for each output.
