LPDDR4 not available in NIOSV/g linker script - Agilex-5, Quartus 26.1 Pro
Hello, I have a simple design for Agilex 5, using NIOS V/g and EMIF IP with LPDDR4 memory. I have the NIOS V instruction and data manager ports connected to the EMIF IP. Design compiles Ok. But when I create a BSP, in the linker section, there is not a memory device for the LPDDR4. In this thread, a similar problem seems to be mentioned - issue-with-bsp-creation-for-nios-vm-using-lpddr4-on-agilex-5-quartus-24-1--24-3 Does it mean that Address Span Extender IP must be used in order to have the LPDDR4 show in the linker script section, as an available memory device?
SSLC Login Issue – "You need to enroll" loop after OTP verification
Hi, I am facing an issue with the Altera Self Service Licensing Center (SSLC). Problem: - I enrolled at licensing.altera.com successfully - I receive the OTP verification code on my email - After entering the OTP correctly, it shows: "Access to the SSLC portal requires registration Register here to get started." - This creates an infinite loop and I cannot access the portal at all I need to generate a free Questa Intel FPGA Starter Edition (SW-QUESTA) license for use with Quartus Prime Lite 24.1. Things I already tried: - Enrolled with two different email IDs - Tried Chrome, Edge, and Incognito mode - Cleared cookies and cache. Could you please either: 1. Fix my account access, OR 2. Manually generate and send the license.dat file to my email My registered email: [email protected] Thank you.
quartus pro 25.3 bug?
Now I am developing a project with agilex7 base on the quartus pro 25.3. the project contains R-TILE pcie hard ip and F-tile ethernet hard ip. During board bring-up debugging, we frequently encounter non-deterministic discrepancies between actual hardware behavior and simulation results. For instance, on a certain platform, the PCIe device fails to be enumerated by the host. Probing the Avalon-ST TX interface of the PCIe hard IP reveals continuous toggling on both the hvld and dvalid signals. However, we have verified that no traffic is being sourced to this interface, meaning these two signals should theoretically remain idle without constant toggling. And the timing of the project is cleaning. How should we proceed to troubleshoot this issue? Should we try upgrading the Quartus version as a potential solution?
Cascaded Avalon Stream Multiplexer in Platform Design does not forward valid data packets
Hello community, I have a DSP system with 32 independent 256-bit output channels using Avalon-ST (or AXI-Stream) on an AGX FPGA. To transfer packetized data to the HPS, I implemented a cascaded Avalon Streaming Multiplexer architecture. The 32 channels are divided into two groups of 16. Each group connects to a 16-to-1 Avalon-ST Multiplexer IP. The outputs of these two multiplexers are then connected to a final 2-to-1 Avalon-ST Multiplexer IP, forming an overall 32-to-1 mux structure. At the output of the final 2-to-1 mux, I also added another 2-to-1 Avalon-ST mux with a selectable input for a data packet emulator. Using the emulator path, I verified that the FPGA-to-HPS data path is functioning correctly. However, after switching from the emulator path to the DSP output path, I only receive packets from channel 0. No packets from the other DSP channels are observed by the HPS. For debugging, I intentionally generated valid packets on non-zero channels. In SignalTap, I observed that channel 28 was asserting valid packet data (valid = 1) while ready = 0. This capture was taken at the input of the second 16-to-1 mux, since channel 28 belongs to the upper 16-channel group. Next, I changed the SignalTap trigger condition to the rising edge of the output valid signal of the second 16-to-1 mux. However, the trigger condition was never met, even after repeated acquisitions. The ready signals throughout the mux stages remain asserted, which suggests there is no downstream backpressure from the FIFO path to HPS. The downstream FIFO status also indicates that it is empty. The confusing part is the following: After enabling channel 0 again, both channel 0 and channel 28 should have had valid packets simultaneously. In this case, packets from channel 0 were forwarded correctly to the HPS. I verified this by reading 8 words from the memory FIFO and reconstructing the original packet; all received packets contained the channel ID corresponding to channel 0. However, after disabling channel 0 again, no new packets were received from any channel, including channel 28. Based on these observations, it appears that the internal round-robin scheduler of the Avalon-ST mux may not be operating correctly. The two 16-to-1 muxes and the final 2-to-1 mux are all configured identically in Platform Designer. Does anyone have suggestions on what could cause this issue, or recommendations on how to further debug the Avalon-ST mux behavior? I noticed an interesting behavior on channel 28 related to the Avalon-ST handshake. The ready signal for channel 28 remains asserted during idle cycles, but it becomes deasserted exactly when valid is asserted. In other words: | Cycle | valid | ready | | ---------- | ----- | ----- | | Idle | 0 | 1 | | Data cycle | 1 | 0 | | Next cycle | 0 | 1 | This differs from channel 0, where both valid and ready are asserted simultaneously, forming a successful Avalon-ST handshake. My DSP source currently only pulses `valid` for one cycle when data is available. Could the Avalon-ST Multiplexer scheduling size setting (Scheduling Size = 2) contribute to this behavior? Specifically, can the mux arbitration latency caused by the scheduling configuration prevent non-zero channels from completing a handshake if valid is only asserted for one cycle? Thank you very much.
A5EG013BB18A OPN is visible in Quartus but not listed in Program File Generator
Hi everyone, I am currently working on programming an SCM FPGA board using Intel Quartus 25.1 . Our target FPGA OPN is A5EG013BB18A. I need to generate a .jic file from a .sof file by using the Program File Generator. However, when I try to select the FPGA Device in the Program File Generator, we cannot find A5EG013BB18A in the device list. The strange thing is that A5EG013BB18A can be seen in other places within Quartus, but it is not shown only in the Program File Generator device selection list. I have attached screenshots and related files showing: 1. The device can be seen in Quartus 2. The Program File Generator FPGA Device selection list 3. The content of .ini file and the .qsf file Could anyone help confirm the following? Is A5EG013BB18A supported in the Program File Generator? 2. Is there any specific .ini file setting or placement required for the Program File Generator to show this OPN? 3. Is a specific Quartus version or device package required? 4. Is there any known limitation where an OPN is visible in Quartus but not available in the Program File Generator? Any advice or reference would be appreciated. Thank you.
