Cyclone 10 LP Bitstream Compression Failing
I am using the Altera Cyclone 10 LP Development Kit with the 10CL025YU256I7G Device. Do do the design, I am using Quartus Prime Version 24.1 Standard. I am trying to compress my bitstream in order to have a faster configuration. I am using Active Serial with the on-board flash device. Altera documentation suggests two ways of performing the compression: Cyclone 10 LP bitstream compression I can get the compression to work using the 2nd way, where the .sof file is compressed during "Convert Programming Files" by accessing the file properties. The 1st suggested way of compression is not working: "To enable compression before design compilation: Click Assignment Menu > Device. Select the appropriate Intel ® Cyclone ® 10 LP device and then click Device and Pin Options. In the Device and Pin Options window, select Configuration under the Category list and turn on Generate compressed bitstreams. Click OK." The checkbox for "Generate compressed bitstreams" is checked, but after compilation, the .sof file is not compressed and configuration takes the same amount of time as when the checkbox is not checked. Why is this occurring?
Updated .brd file for Stratix 10 GX dev kit
Referencing this post: EK-10M08E144 PCB .brd file corrupted | Altera Community - 302242 The .brd file that comes in the documentation at: https://www.altera.com/products/devkit/po-3028/stratix-10-gx-signal-integrity-development-kit-h-tile ...was done in Allegro, prior to version 16.6. The only available Allegro viewer gives an error because it was done prior to version 16.6, and you need the DB Doctor utility to update the file. The only way to get the DB Doctor utility is to install Allegro. If I had Allegro...I would not be installing the Allegro viewer. Altera: As mentioned in the post above (well over a year ago), it would make sense for you to update your files so customers can view the board of their $10K+ development board. How do we make that happen? Thanks!Agilex 5 D-Series HVIO IOPLL runtime reconfiguration: C0 write succeeds, but output remains 100 MHz
I am trying to change an Agilex 5 D-Series HVIO IOPLL output from 100 MHz to 50 MHz at runtime through the core_avl reconfiguration interface. The register transactions appear to work correctly: C0 at 0x05C can be written and read back successfully, and Signal Tap confirms that the reset (0x080), recalibration enable (0x048), and recalibration request (0x088) commands all reach the IOPLL interface with the expected data. However, the physical output clock still remains at 100 MHz, and locked stays high throughout the procedure. My main problem is that I cannot determine whether the new C0 divider is actually being applied to the active PLL, or whether the recalibration cycle is not really starting/completing. Problem: Runtime writes to the Agilex 5 HVIO IOPLL reconfiguration registers succeed, including C0 write/readback and the documented reset/recalibration sequence, but the output frequency does not change from 100 MHz to 50 MHz. locked remains high, so I cannot tell whether recalibration actually starts or whether the new C0 value is applied to the active divider. Environment: Device: Agilex 5 A5ED013BB32AE4S Board: Terasic DE25-Standard Rev. Quartus Prime Pro: 26.1 Reference clock: 50 MHz Initial IOPLL output: 100 MHz Target runtime output: 50 MHz What I have verified HVIO dynamic reconfiguration is enabled. core_avl_clk is running at 50 MHz Register access at 0x010[0] is enabled. Calibration status bits 0x058[7] and [21] are cleared according to the Agilex 5 D-Series 25.1.1 guide. C0 register address is 0x05C. C0 can be written and read back correctly. For the 50 MHz test, I use: high_count = 32 low_count = 32 bypass = 0 odd = 0 which gives: C0 = 0x10000C20 The hardware readback after writing C0 is also 0x10000C20. Signal Tap confirms that the following writes reach the actual IOPLL core_avl interface: 0x080 = 0x00000004 // PLL reset 0x048 = 0x00004000 // recalibration enable 0x088 = 0x00000800 // recalibration request. The 0x080[2] reset pulse is longer than 10 ns, and there are no bridge errors, rejected transactions, or timeouts. I also compared known-good static 100 MHz and 50 MHz Quartus-generated configurations. The main implemented difference is: Static 100 MHz: C0 divide = 32 high/low = 16/16 Static 50 MHz: C0 divide = 64 high/low = 32/32 M, N, VCO, compensation mode, phase, and the other relevant PLL parameters remain unchanged. Observed result: After the complete runtime sequence: C0 final readback = 0x10000C20 locked = 1 output clock = still 100 MHz. So the register value is retained, but the active output divider does not appear to change. Questions: If locked is already high before asserting 0x088[11], how can I confirm that a new recalibration cycle actually starts and completes?Does successful C0 readback at 0x05C mean the new divider value is ready to be applied to the active PLL, or is another condition required?Is there any additional documented step after 0x080[2], 0x048[14], and 0x088[11] before the new C0 divider becomes active?Is the Agilex 5 HVIO IOPLL runtime reconfiguration example #16029156620 available? I can provide Signal Tap captures for the 0x080, 0x048, and 0x088 transactions, as well as the complete UART register log if needed. Thanks.Agilex5 NSATUS signal behavior at power up.
Hello Again, We used the AGILEX5 device, After powers ramp up, we pulled nCONFIG low for ~500 ms and pull it up for configuration. The NSTATUS signal is follow the nCONFIG as expected but we observe falling and rising scenario for ~20us that we do not know to explain Please advise it it normal and can cause it. Thanks Asaf nSTATUS and nCONFIG after ramp up nSTATUS and nCONFIG after ramp up - falling and rising of nSTATUS nSTATUS and nCONFIG after ramp up - falling and rising of nSTATUS - zoom out
Cyclon 5 tampering protection bit
I have a cyclone V with an AS scheme. I have generated an key-file (ekp) with tampering protection bit set according to AN556 Then I open it in the programmer programmer and generate a jam-file now in the jam-file the procedure DO_KEY_SECURE is optional which means I have to enable that procedure manualy with "-e DO_KEY_SECURE" in the command, for example: quartus_jli -c <n> keys.jam -e DO_KEY_SECURE -a <action> is it possible to make this procedure non-optional so it will program the tampering bit by default when programming the key?
10CL040YF484 Programming fails
1st Vendor Batch (Date Code: 2525): - First Test (3 FPGAs): - Card 1: ISP and JTAG programming successful; functioning correctly. - Card 2: Programmed in ISP mode, but fails to execute and returns a JTAG error. Replacing the FPGA on this board with another one resulted in the same issue. - Second Test (3 FPGAs): - Cards 3 & 4: ISP and JTAG programming successful; functioning correctly. - Card 5: ISP and JTAG programming successful, but the device is not functioning correctly, and most pins are not working as required. - Mouser Batch (Date Code: 2619): - Third Test (2 FPGAs): - Card 6: ISP and JTAG programming successful, but the device fails to function properly, with most pins not meeting requirements. - Card 7: ISP programming successful, but returns a JTAG error and fails to execute. Based on these outcomes, could you please help us identify where the problem lies?Quartus Programmer 21.1: JTAG Server Error Code 82 – Port 1309 Cannot Be Bound
Hello Altera Community, I am working on an FPGA project using a Cyclone IV FPGA development board and an Altera USB-Blaster. I am currently unable to program the FPGA because Quartus Programmer cannot access the JTAG server. System details: - OS: Windows 11 64-bit - Software: Quartus Programmer 21.1 - Installation path: C:\intelFPGA\21.1\qprogrammer - Programmer: Altera USB-Blaster - FPGA: Cyclone IV development board The USB-Blaster is detected by Windows Device Manager and the driver is installed. The USB-Blaster also powers on normally. However, Quartus Programmer gives: "Attempted to access JTAG server -- internal error code 82 occurred" When I run: jtagconfig I get: Error when scanning hardware - Server error Sometimes it also hangs at: Connecting to server(s) [...] I checked the JTAG server using: jtagserver --status It reports: Installed JTAG server is 'C:\intelFPGA\21.1\qprogrammer\bin64\jtagserver.exe' Server is stopped Remote clients are disabled I tried reinstalling the JTAG server: jtagserver --install jtagserver --start But the server immediately stops. I also tried: net start "Altera JTAG Server" The result was: The Altera JTAG Server service could not be started. The service did not report an error. NET HELPMSG 3534. I then ran: jtagserver.exe --foreground and received: Unable to bind changedetect socket: 10048 Can't bind to TCP port 1309 - exiting I checked the port using: netstat -ano | findstr 1309 and found that TCP port 1309 was being used/listened to by another process, for example PID 12888. I tried terminating the process using: taskkill /F /PID 12888 but Windows reported: ERROR: The process with PID 12888 could not be terminated. Reason: There is no running instance of the task. I also tried stopping the JTAG server, reinstalling it, and restarting it. In addition, I already tried the following: 1. Disabled PCI Express → Link State Power Management. 2. Disabled USB Root Hub power saving ("Allow the computer to turn off this device to save power"). 3. Stopped the Print Spooler service. 4. Closed Quartus/Programmer-related applications. 5. Reinstalled the JTAG Server. 6. Restarted the computer. 7. Tried starting the JTAG server manually. 8. Checked TCP port 1309 using netstat. The problem still remains. My main questions are: 1. Why is Quartus Programmer 21.1 unable to start the JTAG Server? 2. What is causing TCP port 1309 to remain occupied? 3. Is there a known issue with Quartus Programmer 21.1 and Windows 11? 4. Is there a recommended patch, driver, or newer Quartus Programmer version for this problem? 5. Is it possible to configure the JTAG server to use another TCP port? 6. What is the correct way to completely remove and reinstall the JTAG Server on Windows 11? 7. Is there anything else I should check before reinstalling Quartus Programmer? I would appreciate any guidance on how to get the JTAG Server running so that jtagconfig can detect my USB-Blaster and FPGA. Thank you.Subject: Hitless Update Implementation Guidelines (AN904)
Target Devices: 10M08SAU324I7G / 10M25SAU324I7G Reference Document: AN904: MAX 10 Hitless Update Implementation Guidelines KDB 000080468 https://community.altera.com/discussions/fpga-device/subject-issues-implementing-hitless-update-on-max-10-via-quartus-prime-programme/355534/replies/355841?emcs_t=S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufE1TNzJGWlhLRUhRVlowfC0xfFNVQlNDUklQVElPTlN8aEs Problem Description: Hi Altera Team, Thank you for the detailed explanation. I apologize for the delayed response, as I took some time to run experiments based on your feedback. After completing my implementation testing, I would like to clarify a few points: 1. Clarification on Section 1.5 in AN904 Section 1.5 of AN904 is titled "1.5. Hitless Update using Intel Quartus Prime Programmer". However, since your response indicates that the Quartus Prime Programmer GUI itself cannot achieve a true hitless update during reconfiguration without logic/IO interruption, the section title seems misleading. Could you confirm if Section 1.5 is actually intended to describe using the Quartus Prime Programmer to generate .jbc, .jam files for external hitless execution, rather than executing the update directly via the Programmer GUI? 2. JBC Hitless Update Issue Following KDB 000080468 I generated a .jbc file by strictly following the workflow outlined in KDB 000080468: During execution, hitless update still fails (I/O states drop/reset during reconfiguration). However, after rebooting/power-cycling the CPLD, the new FW/image runs successfully. Could you help verify: • Is there any step missing in my .jbc generation flow based on KDB 000080468? • If the generation sequence is correct, which part of the execution flow (e.g., Jam Player ACTION parameter, TAP Reset timing, or clamp release sequence) could cause the I/O clamping to fail prematurely? 3. Support for Partial / CFM0-Only Hitless Update Is it supported to perform a Hitless Update when programming only CFM0 (ROM0) instead of the full flash image? Does the ISP Clamp and Boundary-Scan mechanism function the same way during a partial image update? Thanks and best regards,
