User Profile
FakhrulA_altera
Regular ContributorJoined 4 years ago
User Widgets
Contributions
Re: Marking codes of CY10CL040YF484
Hi Suvarna, Thank you for the detailed results. Because the same cable and programming file work on the good card, while the bad card does not return TDO or a device ID, the failure occurs at the JTAG communication stage before programming. Please check the following on a failing card: For a single-device configuration, nCE must remain low and should be connected directly to GND. Please verify the voltage at the FPGA nCE pin during JTAG detection. Reduce the JTAG frequency from 6 MHz to 1 MHz, then compare TCK, TMS, TDI, and TDO directly at the FPGA pins on the good and bad cards. Check continuity and solder connections for the JTAG and configuration pins, especially TDO, nCE, nSTATUS, and CONF_DONE. Confirm that VCCINT, VCCA, and Bank 1 VCCIO remain within specification during JTAG detection. For AS configuration, nSTATUS remaining low after programming indicates a configuration error. CONF_DONE remaining high throughout programming is also not the expected behavior. Please verify the pull-up and routing of nSTATUS and CONF_DONE, and compare DCLK, DATA0, and nCSO at the FPGA pins against the working card. If these signals, power rails, and connections are confirmed correct but TDO remains inactive only on the affected devices, the next step is to contact the distributor for RMA or failure analysis. Regards, Fakhrul1View0likes2CommentsRe: Unable to scan JTAG chain, TCK only 2V
Hello Carlhermann, Thank you for the detailed testing. Your standalone test confirms that the voltage drop is caused by the older USB-Blaster cable rather than the FPGA or development board. A 2.5 V target supply and the 1 kΩ TCK pull-down are supported connections. However, older USB-Blaster hardware revisions used a different MAX3378-based output circuit, while later revisions added buffering. The failing cable therefore appears to have insufficient output-drive margin or may be degraded; this does not indicate that the FPGA is damaged. Please continue using the known-good cable. No board modification should be required, and we can consider this issue resolved. Best regards, Fakhrul25Views1like0CommentsRe: Cyclone 10 LP Bitstream Compression Failing
Hi, Could you please share an update after trying the steps suggested by FvM? Please note that the .sof file is not compressed, and the .jic file size may remain unchanged because it reflects the selected flash capacity. To verify compression, please compare the generated .rpd file size or the flash programming and FPGA configuration times with compression enabled and disabled. If the issue remains, please share what is failing, along with a screenshot of the Programming File Generator settings and any error or warning messages. Regards, Fakhrul4Views0likes0CommentsRe: Marking codes of CY10CL040YF484
Hi Suvarna, Thank you for providing the device photographs. Both devices show the same ordering code, 10CL040YF484I7G, but have different corporate logos and trace/lot markings. These visual differences alone are not sufficient to determine whether a device is faulty or counterfeit. For devices purchased directly through Mouser’s authorized channel, please retain the invoice and packing-list traceability. For devices from the other vendor, please confirm that the supplier is an authorized distributor and request its certificate of conformance or traceability documents. The reported JTAG and Active Serial symptoms do not by themselves indicate a device defect. Please perform the following checks: Run JTAG Auto Detect/read the device ID and provide the complete Quartus Programmer log, Quartus version, download-cable model, and JTAG frequency. Verify the FPGA power rails, JTAG signal integrity, Bank 1 VCCIO/reference voltage, MSEL settings, nCE, nCONFIG, nSTATUS, and CONF_DONE. For AS operation, verify the programming file and flash-device selection, as well as the nCSO, DCLK, ASDO, and DATA0 connections. If possible, test both units on the same known-good board with the same programming file and cable. If the Mouser units consistently fail while a known-good lot passes under identical conditions, please contact Mouser for RMA support. Regards, Fakhrul14Views0likes4CommentsRe: Unable to scan JTAG chain, TCK only 2V
Hello Carlhermann, Thank you for the update. The 1 kΩ pull-down on TCK is the recommended Cyclone 10 LP connection, so its presence does not indicate a low-cost or unprotected design issue. Since Auto Detect works again when the oscilloscope is removed, the symptom is more consistent with limited cable-drive margin or TCK signal-integrity/loading than with a damaged FPGA pin. Please try a lower JTAG clock frequency or another known-good, preferably newer, download cable. Also check TCK at both the header and FPGA pin for reflections or a marginal high level, and verify that no other device is driving the JTAG signals. If needed, the board designer can evaluate TCK damping or a small capacitor based on signal-integrity analysis. If Auto Detect is stable after lowering TCK or changing the cable, the FPGA is likely not damaged and the case can be considered resolved as a board/cable signal-integrity issue. Regards, Fakhrul16Views0likes1CommentRe: Cyclone V GT Dev Kit - new units fail to boot from FPP
Hi Leonardo, Thank you for the detailed results and waveforms. Achieving 100 successful power cycles on all three boards is encouraging. The original overshoot/undershoot and the improvement with reduced drive strength support a marginal signal-integrity or timing-margin issue in the FPP path. However, since the modified image changes both the drive strength and DCLK frequency, we cannot yet confirm the root cause or treat this as an official production fix. If practical, could you perform one final comparison at 100 MHz, changing only the drive strength to 7 mA, and share the Quartus version used? The related internal case remains under engineering review; we do not yet have a confirmed internal reproduction or root cause. We will add your findings and request review of the DCLK routing and factory MAX V settings. Please treat the 7 mA setting as an experimental workaround. You may proceed with the distributor RMA process if you prefer, while we continue the engineering assessment. Thank you again for your valuable investigation. Regards, Fakhrul13Views0likes2CommentsRe: 10CL080YF780I7G BSDL FILE
Hello, Thank you for reporting this issue and sharing the details. We understand that Quartus allows pin F4 to be used as an output, but the BSDL file defines it as linkage. Because of this, the pin cannot be controlled through boundary scan. We will check with our internal team to confirm whether this is a device limitation or an issue with the BSDL file. We will also ask them to review pin E2 for 10CL040YF484I7G and 10CL016YF484I7G. For now, please do not change the BSDL file manually. Could you please share the BSDL filename or download date, and the Quartus Prime version you are using? Regards, Fakhrul25Views0likes0CommentsRe: USB Blaster
Hi Masif, Could you confirm whether the USB-Blaster is detected by the operating system and share the output of jtagconfig? Please also provide: Quartus Prime Pro version Operating system and version USB-Blaster model Any error message from Quartus Programmer If the cable is visible to the OS but not Quartus, please check or reinstall the USB-Blaster driver, restart the Quartus JTAG server (jtagd), and reopen Programmer. You can also try another USB port and ensure no other application is using the JTAG connection. The jtagconfig output will help us narrow down the issue.11Views0likes0Comments