User Profile
Farabi_Altera
Regular ContributorJoined 4 years ago
User Widgets
Contributions
Re: LTPI IP - any plan to support OCP LTPI Revision 1.2? (MAX 10)
Hello, On the current compliance baseline: the LTPI IP is compliant with OCP DC-SCM 2.1 LTPI revision 1.1, version 1.1 specifications, and for MAX 10 devices specifically, it supports up to 400 Mbps data rate for all speed grade configurations. LVDS Tunneling Protocol and Interface (LTPI) IP User Guide On the Quartus Prime Standard Edition version that introduced MAX 10 support: LTPI IP v25.1 (Quartus Prime Standard Edition 25.1, dated 2025.11.03) added support for MAX 10 FPGAs. LVDS Tunneling Protocol and Interface (LTPI) IP v25.1 On the resource utilization reference: the LTPI IP resource utilization values for MAX 10 are obtained from Quartus Prime Standard Edition software version 25.1. LVDS Tunneling Protocol and Interface (LTPI) IP User Guide Regarding the specific Revision 1.2 changes you mention — extended CRC/error handling, the new Frame Lost error, the LTPI Version → LTPI Revision rename, and the Link Speed timeout/Link Lost condition changes — none of those are documented in the available LTPI IP materials I have access to. I cannot confirm or deny a planned update.0Views0likes0CommentsRe: Subject: Hitless Update Implementation Guidelines (AN904)
I'll address each of your three questions in turn. 1. Section 1.5 of AN904 — Quartus Prime Programmer for Hitless Update Your interpretation is correct. AN 904 describes implementing the hitless update through the Quartus Prime Programmer or the Jam STAPL Byte-Code Player. AN 904: MAX 10 Hitless Update Implementation Guidelines The Quartus Prime Programmer path in that section is primarily a file generation and orchestration path, not a guarantee of glitch-free I/O during the update itself when used directly from the GUI. To implement the hitless update through the Quartus Prime Programmer, you must create and execute a pin state information (.ips) file. AN 904: MAX 10 Hitless Update Implementation Guidelines The key point is that the MAX 10 hitless update in AN904 must be performed through external JTAG pins, AN 904: MAX 10 Hitless Update Implementation Guidelines and the MAX 10 device must be in user mode before performing the hitless update. AN 904: MAX 10 Hitless Update Implementation Guidelines If the device is not already in user mode (e.g., it is blank or freshly erased), the real-time ISP / hitless clamp mechanism will not engage correctly — which is a common source of confusion between "programming via Programmer GUI" and "true hitless update." So yes — Section 1.5 is best understood as describing how to use the Programmer to generate the .pof + .ips → .jbc/.jam files that carry the hitless algorithm, not as a claim that clicking "Program" in the GUI alone achieves a hardware-glitch-free update. 2. JBC Hitless Update Failure — Generation and Execution Checklist Here are the critical checkpoints based on the documented flow: File generation: Always use the .pof with pin state information to create the .jam or .jbc files. AN 630: Real-Time ISP and ISP Clamp for Intel MAX Series Devices The pin state must be embedded in the .pof before conversion. The .jam or .jbc file contains all information required to program the ISP-capable device(s), including the programming algorithm and the hitless update mechanism — if you include the .ips file during file conversion. AN 904: MAX 10 Hitless Update Implementation Guidelines If the .ips was not included at conversion time, the clamp data will be absent from the .jbc. You must select "Enable real-time ISP to allow background programming" prior to creating a JAM file to enable ISP clamp for the JAM STAPL flow. AN 904: MAX 10 Hitless Update Implementation Guidelines Known software version issue: Due to a problem in Quartus Prime Software version 17.0, JAM/JBC files generated for MAX 10 devices do not contain the DO_REAL_TIME_ISP option. To perform real-time ISP programming on MAX 10 devices, use JAM/JBC files generated in version 16.1 to execute the DO_REAL_TIME_ISP option. This issue is fixed in version 17.1. Why is my Intel® MAX® 10 device being erased and programmed in normal ISP mode even though I invoke the DO_REAL_TIME_ISP option using JAM/JBC files generated in Intel® Quartus® Prime Software version 17.0? Please confirm which Quartus version you used to generate the .jbc. There is also a separate known issue: programming MAX 10 with a JBC or JAM file may fail when other FPGA devices are in a JTAG chain with MAX 10, due to incorrect formatting in Quartus Prime Software when converting the programming file. The workaround is to check "Enable real-time ISP to allow background programming when available" before generating the JAM/JBC file. Why does Intel® MAX® 10 fail programming with JAM file? Execution — ISP clamp and TAP sequencing: You can set the I/O pins to tri-state (default), high, or low states; or sample and sustain the existing pin state in the ISP clamp operation. AN 630: Real-Time ISP and ISP Clamp for Intel MAX Series Devices If your .ips specifies "sample and hold" but the signals are toggling at the moment of SAMPLE execution, the captured value will be incorrect. You need a steady-state signal because you cannot control the sample set-up time — it depends on the TCK frequency as well as the download cable and software. AN 630: Real-Time ISP and ISP Clamp for Intel MAX Series Devices The EXTEST instruction is then executed to clamp the I/O pins to the values loaded into the boundary-scan registers during SAMPLE/PRELOAD. AN 630: Real-Time ISP and ISP Clamp for Intel MAX Series Devices If the TAP is reset prematurely before EXTEST completes, the clamp is released early — this is the most common cause of I/O dropping mid-update. When the ISP clamp feature is used, the weak I/O pull-up resistors are disabled during programming even if the I/O is clamped to a tri-state value. AN 630: Real-Time ISP and ISP Clamp for Intel MAX Series Devices If your downstream logic depends on pull-ups during programming, this can cause apparent "drops." Blank device edge case: When a MAX 10 FPGA is blank (new device, or UFM and CFM erased), the JAM player cannot program it successfully because the real-time ISP feature is turned on when the device is not in user mode. To fix this, use the JAM player command to disable the real-time ISP feature and program it again. Why Intel® MAX® 10 FPGA cannot be programmed with Jam player if it is blank? Since you mention the new image runs after a power cycle, this suggests the flash write itself succeeds but the clamp/reconfiguration handoff is failing — pointing to the TAP sequence or clamp release timing rather than the file content. Jam Player execution command: For real-time ISP with the .jbc and Jam STAPL Byte-Code Player, use: jbi_22 -aprogram -ddo_real_time_isp=1 file_name.jbc AN 630: Real-Time ISP and ISP Clamp for Intel MAX Series Devices Confirm this flag is being passed; omitting it will cause the player to fall back to normal ISP (tri-state, no clamp). 3. CFM0-Only (Partial) Hitless Update All CFM in MAX 10 devices consist of three sectors — CFM0, CFM1, and CFM2 — except for the 10M02. MAX® 10 FPGA Configuration User Guide Your 10M08 and 10M25 both have all three CFM sectors. The ISP clamp and boundary-scan mechanism itself is independent of which CFM sectors are being written — the clamp operates at the JTAG TAP level and holds I/Os stable regardless of the flash write scope. MAX 10 devices offer the hitless update feature, which provides the capability and flexibility to control the state of the I/O pins during the internal flash image update and reconfiguration. AN 904: MAX 10 Hitless Update Implementation Guidelines All I/O pins can remain stable without any disruption throughout the hitless update process. AN 904: MAX 10 Hitless Update Implementation Guidelines However, the critical constraint is the reconfiguration trigger: after the flash write completes, the device must reconfigure from the updated image. In a typical Hitless Update setup, you must first perform a Remote System Update (RSU), which involves updating the agent device's Configuration Flash Memory (CFM) with either the factory image or an application image. This step must be completed before initiating the JTAG instructions required for the Hitless Update procedure. AN 963: MAX 10 Hitless Update Implementation Guidelines Using Internal JTAG Interface If you are writing only CFM0 and the device is configured to boot from CFM0, the reconfiguration after the write should pick up the new CFM0 image — but you need to ensure the boot source selection in your POF matches your intent. For the internal JTAG approach (which avoids the external JTAG pin dependency), when the host controls the agent to perform a Hitless Update, a challenge arises after the CLAMP instruction is executed: the agent's I/O pins are clamped, preventing the host from driving further reconfiguration since access to the I/O pins is restricted. To overcome this, the agent MAX 10 device should include an RTL design module within its core that initiates the reconfiguration internally once the CLAMP instruction has been executed. AN 963: MAX 10 Hitless Update Implementation Guidelines Using Internal JTAG Interface In summary: CFM0-only programming is supported within the hitless update framework, but verify your boot image selection and ensure the reconfiguration source is correctly set to CFM0 in your design.0Views1like0CommentsRe: Quartus Programmer 21.1: JTAG Server Error Code 82 – Port 1309 Cannot Be Bound
Hello, You've already narrowed this down very precisely. The `jtagserver.exe --foreground` output tells us exactly what's wrong: **something else is already bound to TCP port 1309**, which prevents the Altera JTAG Server from starting. Everything else (error code 82, "Server error" from jtagconfig, the service failing to start) is a downstream consequence of that single root cause. By default, the JTAG Server listens to TCP/IP port 1309, and JTAG client applications connect to the same port. AN 939: JTAG Connections Over SSH If that port is already occupied, the server cannot bind and immediately exits — exactly what you're seeing. Here's how I'd work through this systematically: 1. Identify what is actually holding port 1309 Your `taskkill` attempt failed because the PID may have already exited between the `netstat` scan and the kill command, or the process is a system-protected service. Try this instead: Run Task Manager → Details tab, sort by PID, and look up PID 12888 (or whatever current PID `netstat` shows). Note the process name. Alternatively, use Resource Monitor → Network tab → Listening Ports — it shows the owning process name directly alongside the port. You can also run: netstat -ano | findstr 1309 again after a fresh reboot (before starting anything) to see if the port is still occupied at boot time. If it is, a service is claiming it at startup. Common culprits on Windows 11 that can grab port 1309: a stale/orphaned `jtagserver.exe` instance still registered as a service but in a broken state, another Quartus installation (e.g., a full Quartus Prime install alongside the standalone Programmer), or a third-party application. 2. Clean up any stale JTAG Server registration To remove or delete the Altera JTAG Server service from your Windows computer, you can uninstall the service using the Windows Command Prompt by entering `jtagserver --uninstall` and then rebooting, or delete the service using `sc delete Altera JTAG Server` followed by a reboot. How do I remove the Altera JTAG Server service from my Windows computer? Run both of these from an **elevated (Administrator) command prompt**, then reboot. After the reboot, check `netstat -ano | findstr 1309` again before reinstalling. If port 1309 is now free, proceed to reinstall. 3. Reinstall the JTAG Server correctly (as Administrator) To correct issues with the JTAG server, place the required files into the appropriate folder, then open a DOS command prompt and type `jtagserver --install`. To confirm that the jtagserver was installed correctly, run the `jtagserver --status` command. Attempted to access JTAG -- internal error code 82 occurred Make sure you run the install command from an **elevated prompt** — to enable a remote JTAG server on your Windows computer, you will need administrator privileges or rights since a modification to the registry will be performed. Do I need administrator privileges to enable a remote JTAG server on a Windows computer? The same applies to the install step itself. After installing, start it with: jtagserver --start Then verify with: jtagserver --status After installation, you can either use the Task Manager → Services tab or the command-line option `--status` to verify if the jtagserver service is running. You can control the jtagserver service using the `--start` and `--stop` command-line options or using the Task Manager. Altera FPGA Software Installation and Licensing 4. Check for firewall blocking port 1309 You may receive the "Can't Enable Remote Connections to JTAG Server" error if your computer's firewall program or your IT department has blocked port 1309. Another sign that port 1309 may be blocked is that when you try to enable remote connections the settings will not be saved and revert back to default settings. Enable port 1309 on your computer or firewall program, or speak to your IT department to make sure they are not blocking port 1309. Can't Enable Remote Connections to JTAG Server Also, you may receive the "Attempted to access JTAG server -- internal error code 82 occurred" error if you have a firewall or anti-virus program running when you installed Quartus and the Altera JTAG Server. To resolve this, disable or uninstall your firewall or anti-virus program, then start the JTAG server. Once you have started the Altera JTAG Server, you may then re-enable or reinstall the firewall or anti-virus program. Attempted to access JTAG server --internal error code 82 occurred 5. If the JTAG Server service is conflicting with itself (broken service state) The USB Download Cable may not be detected because the version of JTAGServer running as a host is not working properly as a user mode application. To resolve this: run Windows in Safe Mode, run "msconfig" in the command prompt to bring up the System Configuration window, and in the Services tab, disable "Altera JTAG Server" and then reboot the PC. Why is the Intel® FPGA USB Download Cable not detected by Intel Quartus® Prime Programmer when it is recognized correctly in Device Manager? This clears the broken service state so you can do a clean reinstall. Regarding your specific questions: Q5 (Can the JTAG server use a different port?): The JTAG Server's port is fixed at 1309 — there is no way to specify the port used to connect to the EthernetBlaster cables; the default port will be 1309. Can I specify the port used to connect to the EthernetBlaster II Communications Cable? The same applies to the local JTAG Server. You cannot redirect it to an alternate port. Q3/Q4 (Known issue with Quartus Programmer 21.1 on Windows 11): I don't have a documented specific known issue or patch for Quartus Programmer 21.1 on Windows 11 in the available documentation. The port-conflict root cause you've identified is the primary issue to resolve first — it's not version-specific behavior. Q6 (Complete removal and reinstall): The clean sequence is: (1) `jtagserver --stop`, (2) `jtagserver --uninstall` or `sc delete Altera JTAG Server`, (3) reboot, (4) confirm port 1309 is free, (5) `jtagserver --install` from an elevated prompt, (6) `jtagserver --start`. Q7 (Anything else to check): Also verify there is no second Quartus installation on the machine whose `jtagserver.exe` is running and holding the port. Check Services (services.msc) for any duplicate "Altera JTAG Server" entries. The bottom line: free port 1309 first (identify and terminate or remove whatever is holding it), do a clean uninstall/reinstall of the JTAG Server as Administrator, and temporarily disable antivirus during the reinstall. That should get `jtagconfig` detecting your USB-Blaster and Cyclone IV board.0Views0likes0CommentsRe: Agilex5 NSATUS signal behavior at power up.
Hi Asaf, This is actually documented behavior, and what you're seeing is expected. The brief ~20 µs falling/rising pulse on nSTATUS after you release nCONFIG high is the device's normal error-status signaling mechanism during configuration. If an error occurs during configuration, nSTATUS is asserted (driven low) for a pulse duration ranging from 0.5 ms to 10 ms. Device Configuration User Guide Agilex™ 5 FPGAs and SoCs However, a sub-millisecond (~20 µs) transient is more likely a normal part of the SDM startup and synchronization handshake rather than a configuration error pulse. Here's the key thing to understand about nSTATUS behavior on Agilex 5: Previous device families implement nSTATUS as an open-drain output with a weak internal pull-up resistor. In contrast, Agilex 5 devices use a push-pull (actively driven) output for nSTATUS. Device Configuration User Guide Agilex™ 5 FPGAs and SoCs This is a significant difference from earlier families — the push-pull driver means you can see sharper, more defined transitions. Typically, the Agilex 5 device updates nSTATUS to match the state of nCONFIG, except in error conditions. For example, following a power-on reset (POR), nSTATUS asserts after nCONFIG asserts. Device Configuration User Guide Agilex™ 5 FPGAs and SoCs The nSTATUS pin indicates device readiness to initiate FPGA configuration. The configuration source can only change the state of the nCONFIG pin when it has the same value as nSTATUS. When the Agilex 5 device is ready, it drives nSTATUS to follow nCONFIG. Device Configuration User Guide Agilex™ 5 FPGAs and SoCs Regarding the timing specs that bound this behavior: nCONFIG low to nSTATUS low: max 400 ms (tCF02ST0). Agilex™ 5 FPGAs and SoCs Device Data Sheet nCONFIG high to nSTATUS high: max 20 ms (tCF12ST1). Agilex™ 5 FPGAs and SoCs Device Data Sheet So the SDM has up to 20 ms to bring nSTATUS high after nCONFIG goes high. A brief transient dip during that window — while the SDM is initializing and synchronizing — is consistent with the push-pull driver actively managing the signal state during the SDM startup sequence. One important note: all dedicated configuration/JTAG, SDM, and SDM optional signal pins are in the undetermined state during device power up and power down. Pin Connection Guidelines This means some transient behavior on nSTATUS during and immediately after power ramp-up is expected before the SDM takes full control. Also worth confirming on your board: nSTATUS has an internal 20-kΩ pull-up resistor with 8 mA drive strength. Ensure that during power up, no external component drives the nSTATUS signal low. Pin Connection Guidelines And per the design guidelines, pull the nSTATUS pin high to VCCIO_SDM and ensure no external component drives nSTATUS low during power up. Device Design Guidelines: Agilex™ 5 FPGAs and SoCs Bottom line: The ~20 µs transient you're seeing on nSTATUS after nCONFIG releases high is consistent with normal SDM startup behavior on Agilex 5. As long as nSTATUS settles high within 20 ms of nCONFIG going high and configuration completes successfully (CONF_DONE and INIT_DONE assert), this is not a concern. Altera recommends measuring the configuration time starting from when nSTATUS goes high to when CONF_DONE goes high Device Configuration User Guide Agilex™ 5 FPGAs and SoCs — use that as your primary health indicator. If you are seeing repeated configuration failures alongside this pulse, then it would be worth checking whether any external component is inadvertently pulling nSTATUS low during that window.0Views0likes0CommentsRe: 10CL040YF484 Programming fails
This is a useful dataset — you have two distinct failure modes across two vendor batches, which actually helps narrow down the root causes. Let me break them down. Failure Mode A — ISP programs successfully but JTAG errors / device fails to execute (Cards 2 & 7) The most likely culprit here is a board-level JTAG signal integrity or pin connection issue, not a bad FPGA. A few things to check: JTAG pin noise or floating state: Noise on the JTAG pins during configuration, user mode, or power-up can cause the device to go into an undefined state or mode. Altera Cyclone 10 LP Device Design Guidelines Verify TCK, TMS, TDI, and TDO are clean on these specific boards with a scope. JTAG takes priority: Because JTAG configuration takes precedence over all other configuration methods, the JTAG pins should not be left floating or toggling during configuration if you do not use the JTAG interface. Altera Cyclone 10 LP Device Design Guidelines If TCK is picking up noise on those two boards, it can interfere with the non-JTAG configuration flow. TDO connection: TDO is a dedicated JTAG test data output pin. If the TDO pin is not used, leave this pin unconnected. Cyclone 10 LP Device Family Pin Connection Guidelines Check that TDO is not inadvertently shorted or loaded on Cards 2 and 7. nCE pin: You may receive a CONF_DONE failure if the nCE pin of the device is not connected to GND. For successful JTAG programming of a device chain, all nCE pins must be connected to GND. Why do I receive the error 'CONF_DONE pin failed to go high in device X' when I try to JTAG configure my Intel® FPGA using the Intel® Quartus® Prime Software and a download cable? Confirm nCE is properly grounded on those boards. MSEL pins: JTAG configuration is always available, regardless of the MSEL settings. Altera Cyclone 10 LP Device Design Guidelines However, the MSEL pins must be connected to select the configuration scheme — do not leave them floating. Altera Cyclone 10 LP Device Design Guidelines If MSEL is floating on those boards, behavior will be unpredictable. In Cyclone 10 LP devices, you must hardwire MSEL pins to VCCA (for logic high) or GND (for logic low). Which voltage should I use for MSEL pins to drive a logic high in Intel® Cyclone® 10 LP devices? AS mode + JTAG interaction: If your MSEL pins are set to AS mode, note that the ACTIVE_DISENGAGE instruction is required before JTAG programming regardless of the current state of the Cyclone 10 LP device if the MSEL pins are set to an AS configuration scheme. Cyclone 10 LP Core Fabric and General Purpose I/Os Handbook Also, if the MSEL pins are set to AS mode, the Cyclone 10 LP device does not transmit a DCLK signal when JTAG configuration takes place. Cyclone 10 LP Core Fabric and General Purpose I/Os Handbook The fact that swapping the FPGA on Card 2 reproduced the same failure strongly points to a board-level issue on that specific card, not a device defect. Failure Mode B — ISP and JTAG program successfully but most pins not functioning (Cards 5 & 6) This pattern — programming succeeds but I/O behavior is wrong — typically points to power supply or I/O bank voltage issues rather than a programming problem. VCCIO levels: Cyclone 10 LP devices support a wide range of industry I/O standards. The device output pins do not meet the I/O standard specifications if the VCCIO level is out of the recommended operating range for the I/O standard. Altera Cyclone 10 LP Device Design Guidelines Measure VCCIO on each I/O bank on Cards 5 and 6 — a marginal or incorrect VCCIO rail is a very common cause of "pins not working" after successful configuration. GPIO tri-stated until configured: All Cyclone 10 LP GPIO pins are tri-stated until the device is configured and the configuration pins drive out. Altera Cyclone 10 LP Device Design Guidelines If CONF_DONE is not asserting properly, the device may appear configured but GPIOs remain tri-stated. VCCINT supply: VCCINT pins are the internal logic array voltage supply pins. All VCCINT pins must be connected to either a 1.0 V supply or a 1.2 V supply. Cyclone 10 LP devices with VCCINT 1.0 V and Cyclone 10 LP devices with VCCINT 1.2 V have different ordering codes. Cyclone 10 LP Device Family Pin Connection Guidelines Confirm you are supplying the correct VCCINT for your specific ordering code variant. CRC error detection note: CRC error detection is only supported in Cyclone 10 LP devices with VCCINT 1.2 V, and not in Cyclone 10 LP devices with VCCINT 1.0 V. Cyclone 10 LP Device Family Pin Connection Guidelines If you are relying on CRC error detection and running a 1.0 V core variant, that could mask configuration integrity issues. Cross-batch observation Both failure modes appear across both vendor batches (2525 and 2619), which argues against a batch/lot quality issue and strongly suggests board-level variation — likely marginal power rails, JTAG signal integrity differences, or MSEL/nCE wiring inconsistencies between individual cards. I'd recommend: Scope VCCIO, VCCINT, and VCCA on the failing cards and compare against passing cards. Scope TCK on the failing cards for noise or ringing. Verify MSEL, nCE, and nCONFIG connections match exactly between passing and failing boards. Check CONF_DONE assertion timing after programming completes on the failing cards. If you can share the schematic or scope captures from a failing vs. passing card, that would help narrow it down further.0Views0likes1Comment