Recent Content
USB Blaster II Problem
Hello, I’m having a persistent issue with my USB-Blaster II programmer. No matter what I try, the programmer is detected only as a USB-Blaster variant, without the TCK speed option, and it does not work ... Occasionally, I can get it working by removing the installed driver and reinstalling it. However, after unplugging the programmer or restarting the computer, it reverts back to being detected as the USB-Blaster variant. Then I have to repeat the process: remove the driver, reinstall it, restart the JTAG server, or sometimes restart the whole computer. Even when it works, it only lasts for a single session. I have tried several Quartus Programmer versions, but the issue remains the same. The strange part is that I do not have this problem on my personal laptop or on my colleagues’ computers, so it seems specific to this machine. IT Helpdesk was also was not able to solve this problem Has anyone encountered this issue before or found the root cause? This is especially frustrating because I need to program a Cyclone GX device, and other programmers do not work for this use case. Any suggestions would be appreciated. Thank you!24Views0likes3Commentswriting a word to cfm1 using on chip flash ip on max10
hii i have the neek board development kit , and i am writing my own logic to perform a writing of an image to cfm1 flash sector for remote update i am transferring the image through uart from rpd file just like in nios rsu example lab . i configured the on chip flash ip in this parameters data interface :parallel read burst mode :incrementing read burst count:8 configuration mode :dual compressed images i set the burstcount to 1 I managed to erase the CFM1 sector, and I read the status register to confirm that the erase of sectors 3 and 4 was successful. Sector 3 + 4 corresponds to CFM1. Before performing the write operation, I verify that the on-chip flash is in the idle state by reading the CSR status register. I place the word on the data_writedata signal of the Avalon bus with the correct address, assert the data_write signal, and then wait until waitrequest goes low before proceeding to the next word. I confirm that the write was successful by reading the ‘write successful’ bit in the CSR status register. but sometimes in the middle of the file transfer , i get a write failure and i am not sure why , my clock on board is 50 mhz and i am using pll to generate 75mhz. so i i am feeding the 75mhz clock to the on chip flash ip and my own writing fsm logic Using SignalTap, I can see that the word before the one where the write failed was written successfully. I send each word over the UART interface with a delay of 2.5 ms, which I believe is sufficient for the write to complete. I also check the waitrequest signal before proceeding to the next word and verify that the on-chip flash is in the idle state.” I would be thankful to know why I am getting a write failure and what I should check to resolve this issue? thanks190Views0likes15CommentsFIR IP configured for Interpolation
Why does my Altera FIR IP, configured for interpolation by 80, produce the expected outputs when I provide 3 input samples, but fail to produce the expected behavior when I provide 10 input samples? In this case, the FIR IP keeps tready asserted high, but only generates 4 valid outputs. What could be causing this behavior? I am simulating this in Quartus Prime Lite Edition.190Views0likes6CommentsCascaded 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.15Views0likes3CommentsM9K utilization is different for the same RAM IP for two different projects.
I have a single-port Altera Avalon on-chip memory of 18,432 bytes with a data width of 32-bit instantiated in the two different QSYS subsystem used in different projects. The first project consumes 18 M9K blocks for this memory IP as shown below. This seems correct since, each M9K has about 1 kB of memory, so 18kB of memory should consume about 18 M9K blocks. For, the same-IP the second project consumes 32 M9K blocks instead of 18 as shown in the image below: The settings for the RAM-IP are as shown in the image below: Quartus Tool Version : Quartus 18.1 Standard FPGA Device : MAX-10 10M50DAF256I7G Please help us understand why the same RAM IPs have different utilization for different projects. Also, what settings can be made to the second project so that it consumes only 18 M9K blocks. Thank you, Akhilesh.AI Suite - Custom model in the FPGA building process
Hello Altera Community. My question is: Where in the FPGA building process do I incorporate my costum neural network into the design? This is my current understanding of the FPGA building process: The IP block is generated with the dla create ip script, which takes arch file as input. The IP block is placed in platform designer, and then is connected to memory and signals. After compiling, the data is send to the design using runtime, (JTAG being the slowest) Where does the NN Model I made with PyTorch gets incorporated into all this?11Views0likes1CommentASx4 Interface debug in MSEL=111 (JTAG mode)
Hi, could you, please, help me understand what is happening here: I am working with an Agilex3 FPGA (fuses are on factory default, no keys programmed, etc.) MSEL=111, so we are in JTAG mode I am trying to debug the NOR flash interface through Configuration Debugger / QSPI Controller and SFDP page. I have connected an oscilloscope. When I press Read button without QSPI Debug Session Activate button pressed, I see some NOR flash transactions on the oscilloscope and get back an Error 0x515 Unknown error and nothing is read in the SFDP window. So I try the QSPI debug session active way, and when I press it I get a lot of content but anything below the SFDP line in the tree structure is random at each read button press AND I do not see any NOR flash transaction at all on the ASx4 interface. (Did it several time, so yes, I did not forgot press the trigger active button.) So questions: is this an expected behavior? Copilot suggest that ASx4 interface is not initialized when MSEL=111 and I am reading some internal "garbage" If this is expected, should not the Quartus Programmer tool (which reads MSEL=111 correctly) warn me that I should not expect any meaningful output in this debug window? Is there any way to use the JTAG interface here as supposed: test the interfaces for problems? if yes, how?! (I stuck for a few more days/weeks with MSEL=111, so if that is the solution just let me know.) Thanks, Peter81Views0likes5CommentsNeed Step-by-Step Guide: Configuring Arria 10 HPS for UART0 Access (Tools & Workflow)
Hello Altera Community, I am starting a new project using the Intel/Altera Arria 10 SoC FPGA. My immediate goal is to successfully configure the Hard Processor System (HPS) side of the chip and enable HPS UART0 access so I can view the boot messages and interact via a serial console terminal. Since I am new to the Arria 10 HPS ecosystem, could someone provide a detailed, step-by-step workflow of the procedure? Specifically, I would appreciate guidance on: 1. Required Tools: Which exact software versions (Quartus Prime Pro, SoC EDS, Arm DS, etc.) are recommended for a stable Arria 10 HPS development pipeline? 2. Platform Designer (Qsys) Setup: What are the specific steps to route and configure UART0 pins, clocks, and DDR parameters inside Platform Designer? 3. Bootloader Generation: How do I correctly handle the hardware handoff files to generate the U-Boot/SPL bootloader using the SoC EDS utilities? 4. Target OS: I intend to use Bare-Metal . What are the final steps to write these images to a boot medium (like an SD card / QSPI flash) to verify that UART0 is transmitting successfully? If there are any updated Golden System Reference Designs (GSRD), specific user guides, or community tutorials that outline this exact UART0 baseline setup, please share the links. Thank you in advance for your time and guidance! Best regards, Team D&D ESSEN23Views0likes2Comments
Featured Places
Community Resources
Check out the support articles on personalizing your community account, contributing to the community, and providing community feedback directly to the admin team!Tags
- troubleshooting10,403 Topics
- fpga dev tools quartus® prime software pro4,293 Topics
- FPGA Dev Tools Quartus II Software3,160 Topics
- stratix® 10 fpgas and socs1,549 Topics
- agilex™ 7 fpgas and socs1,468 Topics
- arria® 10 fpgas and socs1,371 Topics
- stratix® v fpgas1,316 Topics
- arria® v fpgas and socs1,229 Topics
- cyclone® v fpgas and socs1,056 Topics
- Configuration1,004 Topics
Recent Blogs
4 MIN READ
Runtime flexibility is only valuable when it is reliable High-speed systems are being asked to do more with the same hardware. A data-center platform may need to operate as a single 400G Ethernet link in one deployment, then support multiple 100G links in another. A front-haul or edge system may need to adapt to different rates, protocol roles, or customer configurations over the life of the product. The promise is simple: deploy one platform, then adapt it as requirements change. But in high-speed design, changing a configuration is not the hardest part. Changing it correctly is. A live transition is not just a speed change. It can require coordinated updates across the the various networking layers, along with clocking, lane mapping, reset behavior, and link recovery. If those layers do not move together and in the right order, the result can be an unstable link, silent data corruption, or a system that hangs indefinitely waiting for CDR lock. That is the real value of Altera Dynamic Reconfiguration: it gives designers confidence that runtime transitions are clean, verified, and repeatable. The Altera difference: clean, verified transitions Altera Dynamic Reconfiguration is built around a profile-driven, silicon-aware flow. Designers define the target operating modes in Quartus Prime, and the system generates validated profiles for each supported state. At runtime, the Dynamic Reconfiguration Controller applies the selected profile through a managed, hardware-driven sequence. It orchestrates the transition across the full protocol stack, ensuring MAC, FEC, PCS, and PMA layers are updated in a coordinated and deterministic order, rather than leaving the designer to manually manage each step. The result: clean, verified transitions - no partial configurations, no unsequenced resets, and no user-managed state machines to debug at 2 a.m. This matters because the transition itself is often where risk appears. A system may appear to support multiple modes on paper, but if each layer must be independently controlled, reset, and validated by user logic, the design team carries the burden of proving that every edge case works under real operating conditions. Altera reduces that risk by turning reconfiguration into a controlled system operation. The selected profile is known, and the transition is repeatable. Silicon-driven confidence The assurance comes from the architecture. Agilex devices use hardened transceiver and protocol IP designed for high-speed operation. Rather than treating reconfiguration as a collection of ad hoc register writes, Altera Dynamic Reconfiguration works with hardened IP and validated profiles to help ensure that runtime switching happens in a controlled, silicon-driven way. That silicon foundation is especially important at 100G and 400G data rates, where small sequencing mistakes can lead to difficult debug cycles. When designers hand-craft transceiver reset state machines, getting the order right, the timing right, and the edge cases right can take weeks. With Altera, those critical sequencing responsibilities are built into the reconfiguration flow. The benefit is not just ease of use. Ease of use is a result. The primary benefit is trust: designers can enable live switching with greater confidence that the system will move from one valid state to another without glitches. A practical advantage for real systems In real deployments, flexibility has business value only if it does not create operational risk. Altera Dynamic Reconfiguration helps a single hardware platform support multiple configurations while avoiding the disruption of a full FPGA reprogramming cycle or duplicate hardware paths for every possible mode. For networking platforms, this can mean supporting different Ethernet configurations on the same physical transceiver resources. For multi-protocol systems, it can mean adapting a port role as requirements evolve. For platform owners, it means more deployment options from the same hardware design. This is where Altera has a practical positioning advantage: customers get runtime flexibility with more of the critical transition behavior handled by the platform. Instead of asking designers to manually manage every reconfiguration step, Altera provides a structured flow designed to produce predictable, verified results. What the demo proves The Agilex 7 400G Dynamic Reconfiguration demo turns this story into proof. In the demo, two Agilex 7 FPGA boards are connected over QSFP-DD, and the system dynamically switches between a 400G Ethernet configuration and multiple 100G Ethernet links using the same setup. The demonstration shows more than a mode change. It shows live traffic validation, link status, packet counters, error status, and FEC behavior during the transition. That is the point: the feature is not theoretical. It is running on silicon, switching in real time, and validating the kind of clean transition designers need before they trust the feature in production systems. Why this matters now As data-center, telecom, edge, and industrial systems become more configurable, customers increasingly need hardware platforms that can support multiple roles over time. The question is no longer whether a system can support more than one mode. The question is whether it can switch modes cleanly, predictably, and with confidence. Altera Dynamic Reconfiguration is designed for that moment. It combines hardened IP performance, profile-driven control, and coordinated sequencing to deliver runtime flexibility without compromising reliability. Dynamic reconfiguration is valuable because it enables flexibility. Altera makes it compelling because it makes that flexibility trustworthy. Watch the Runtime Reconfiguration You Can Trust demo video
8 days ago1like
Agilex® 9 Direct RF-Series FPGAs help system designers address two critical RF system priorities: lower latency and improved SWaP (size, weight, and power). By integrating high-performance RF data converters directly with FPGA fabric, Agilex 9 Direct RF-Series FPGAs can reduce RF-to-baseband latency, simplify the signal chain, lower system power, and free up valuable board space for future capabilities addition. In a draft comparison of discrete JESD-based architectures versus an Agilex 9 integrated Direct RF approach, the integrated solution showed up to 78% lower latency versus a JESD204C discrete solution and up to 86% lower latency versus a JESD204B discrete solution. The comparison also showed approximately 40% lower power consumption and up to 48% board-area reduction. These gains support both primary value propositions: faster system response through lower latency, and better SWaP through fewer external components, lower power, and a smaller, more efficient RF design. Digital radio frequency memory (DRFM), electronic attack, and electronic protection are good examples of applications where latency improvements can make a meaningful difference. In these types of RF systems, lower RF-to-baseband latency helps systems act on complex signals faster, improving responsiveness, timing precision, and mission effectiveness in contested electromagnetic environments. The SWaP benefit is also critical in long-lifecycle aerospace and defense platforms which may remain operational for decades, yet have limited space, weight, power, and cooling capacity for new hardware. As signal environments evolve, these platforms need room to add or upgrade capabilities without major system redesigns. By integrating RF data conversion with FPGA processing, Agilex 9 Direct RF-Series FPGAs can help system designers improve responsiveness, reduce board area, simplify the RF signal chain, and create more headroom for future upgrades. Learn more about Agilex 9 Direct RF-Series FPGAs and the benefits of integrated data converters. Discover how Agilex 9 Direct RF-Series FPGAs enable lower-latency and more power-efficient RF system designs Download the Altera® Direct RF-Series FPGA Wideband Product Brief Source for draft proof points: Agilex 9 Direct RF-Series integrated data converter app note draft, version 0.1, last updated March 31, 2026.
9 days ago0likes
2 MIN READ
New DDR5-6400 support delivers a 14% increase in maximum DDR5 data rate, strengthening Agilex® 7 M-Series device’s memory leadership on a production device family. This effort reflects Altera’s continued investment to improve features on platforms already in volume production. For customers building high-performance FPGA-based systems, memory capability is a core platform requirement, and the level of memory performance increasingly shapes overall system differentiation. That is why this latest Agilex 7 M-Series enhancement matters. With DDR5 support increasing from 5600 MT/s to 6400 MT/s, Agilex 7 M-Series devices support a 14% increase in maximum DDR5 performance on a device family already shipping in production. The significance of this update goes beyond speed alone. It reinforces a broader story about platform value: more usable bandwidth, better system efficiency, and continued innovation on a platform customers can design around today. More bandwidth, better system efficiency DDR5-6400 is not just a higher interface number. It enables more memory bandwidth from the same platform, helping customers move more data through bandwidth-intensive designs. That added bandwidth can also improve bandwidth density at the system level. In practical terms, it can help designers reach target throughput with a more optimized memory subsystem, potentially reducing DIMM or channel requirements in some designs and improving overall platform efficiency. Those advantages become increasingly important in the kinds of applications Agilex 7 M-Series devices are built to address. Across AI, networking, video processing, and data center infrastructure, system performance depends not only on compute capability, but also on how efficiently data can be moved and sustained through the platform. A broader production-ready platform advantage This update also says something important about the platform itself. Agilex 7 M-Series devices already offer production-ready support for advanced external memory technologies, and DDR5-6400 extends that advantage further. As next-generation infrastructure platforms evolve for AI, scale-out networking, and data-intensive acceleration, advanced memory capability is becoming an increasingly important platform differentiator. DDR5 support is now emerging across a broader range of FPGA segments, including mid-range devices such as Agilex 5 and even power- and cost-optimized devices such as Agilex 3 (with LPDDR5 support). Agilex 7 M-Series devicesbrings DDR5-6400 to a high-end FPGA platform tier built for larger, more data-intensive AI, networking, and infrastructure applications. By combining advanced memory performance with substantially greater logic capacity, it delivers differentiation at the platform level. This enhancement is enabled through an upcoming release of Quartus® Prime Pro Edition and is designed to be backward compatible with previously shipped silicon and boards. Customers interested in enabling DDR5-6400 should contact Altera for additional guidance on supported configurations, applicable speed grades, and implementation details. Conclusion The move to DDR5-6400 on Agilex 7 FPGAs and SoCs M-Series delivers a 14% improvement in maximum DDR5 data rate, improving bandwidth density and system-level efficiency while extending the value of a production-ready platform for evolving customer requirements. Watch the DDR5-6400 Demo Performance Video
9 days ago0likes
2 MIN READ
Altera introduced three new Agilex® 7 M-Series FPGA package options, R31G, R47C, and R47D, to give customers more flexibility in balancing bandwidth, connectivity, and performance for AI, networking, video, embedded, and acceleration applications. The new options support DDR5-6400, up to 204.8 GB/s memory bandwidth, and expanded transceiver configurations, enabling designers to optimize systems for PCIe connectivity, maximum data throughput, or efficient right-sized scaling.
14 days ago0likes
This post demonstrates a 200G-4 Ethernet link running on Agilex 7 FPGAs using F-Tile transceivers. It walks through the full link bring-up process, including Auto-Negotiation and Link Training, followed by stable high-speed data transmission using 53.125G PAM4 lanes over QSFP-DD. The demo provides real-time visibility into link status, signal integrity, and error metrics, and evaluates performance across loopback configurations and varying cable lengths. The result highlights reliable link initialization, consistent throughput, and robust operation under practical system conditions.
27 days ago0likes