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 FrankSolved16Views0likes3CommentsAgilex 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.69Views0likes9CommentsNOR Flash IC programming using 3rd party Programmer
We have observed that programming the NOR Flash using the Altera USB‑Blaster via JTAG behaves differently compared to programming the same Flash device using a third‑party gang programmer. We have created an RPD file as mentioned in the below intel document, tutorial-write-raw-programming-data-rpd-into-flash-devices.pdf Observations During NOR Flash Programming 1.When the fresh NOR Flash IC is programmed using a third‑party programming tool and subsequently mounted on the Base Card, the card fails to boot. 2.However, the RPD image functions correctly when the following programming sequence is followed: -> Program the fresh NOR Flash of the CFPG A using the Altera USB Blaster via JTAG. -> Erase the NOR Flash. -> Reprogram the same RPD image, generated as per the procedure defined in the referenced document. When the above sequence is followed, the card boots and operates as expected. We would appreciate your input on whether any additional steps are required when using third‑party programmers to ensure compatibility with the FPGA boot mechanism.13Views0likes2CommentsAgilex 9 Port Synchonization within A Tile
I am currently using Agilex 9 Evaluation Board AGRW014. I am trying to perform synchronization across 4 ports. I connected the sysref request from DRF IP to the respective pin connected to sync of LMK. Once powered ON, i issued the Start Latency Alignment command by writing the basic mode register 0x0400 bit[0] as 0x1. But i am facing the issue of SYSREF Response Error. Please share the proper sequence to be performed to achieve the Synchronization across port. As well as please provide the method or sequence of register writes to achieve proper phase synchronization (DDC NCO sync) over the bandwidth. Please list the things to be taken care while performing synchronization16Views0likes1CommentAgilex 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.49Views0likes5CommentsAgilex 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.50Views0likes6CommentsMAX10 FPGA pof-file programming fails
Hi all, I build a custom 10M02SCM153 board, when I attempt to download the .pof file, I got "Error (209012): Operation failed" at 4%. However, I can .sof can be loaded. Could anyone provide some hints to debug it? Thanks in advance. Linfeng2.2KViews0likes7CommentsArria 10: Remote Update Watchdog unpredicted behavior
Hello, I start a new thread here, since the previous thread is not answered anymore after the transformation from Intel to Altera Forum. All details and data is still valid from the original thread: Arria 10: Remote Update may brick FPGA and Factory Fallback won't work | Altera Community Main problem is: We have to scenarios (see also here) Misaligned Image: Enable Watchdog in Factory Image trigger reconfiguration (write 1 to RU_RECONFIGURATION_MODE & RU_RECONFIG) Reconfiguration fails due to misaligned image --> Watchdog triggers Fallback to factory mode ==> This case is working as expected. Good Case! Aligned valid Image Enable Watchdog in Factory Image trigger reconfiguration (write 1 to RU_RECONFIGURATION_MODE & RU_RECONFIG) Application Image starts. Application Image does not serve or actively disable the watchdog! Since the application image does not serve the watchdog, I would expect a factory fallback due to watchdog triggering. NOTE: We do not talk about further reconfiguration triggered from within application image. We only do reconfiguration from within the factory load. ==> This is not happening. And I don't understand why. Or is the watchdog automatically disabled once a valid application image is loaded? Critical Questions about the Watchdog timeout register: What is the unit of the watchdog timeout register? This is not specified in its datasheet/documentation. Farabi stated "Please make sure the watchdog timeout not too. eg. Dont set RU_WATCHDOG_TIMEOUT = 0xFFF (this is too long)". Why is this too long? I am missing any restrictions in the respective datasheet. Please advice. Thanks for any help best regards FabianSolved98Views0likes13CommentsCyclone 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!95Views0likes7Comments