Recent Content
Stratix 10 Linux SD card booting
Hi Altera Community, I tried multiple attempts to boot the SD card from Rocketboard.org. https://releases.rocketboards.org/ I downloaded and booted the SD card with the .wic image file. It only has the .itb file by default in the boot partition. Whenever I try to boot, it asks for the U-Boot.img file. And also it says "failed to load "socfpga_stratix10_socdk.dtb" even if the file is there. And then I compiled my simple HPS design and can easily program the FPGA from the Quartus Programmer (rbf and sof file), but whenever I try to overlay it, like say: echo overlay.dtb > /sys/kernel?config?device-tree/overlays/0/path It says "FPGA manager error, timeout," and so on. Does any community member have notes or steps that you made to boot the SD card of the Stratix 10 FPGA? I am following this link: https://www.rocketboards.org/foswiki/Documentation/BuildingBootloaderStratix1082Views0likes9CommentsCyclone V nRST assertion upon nPOR
Hello, I am looking for a confirmation on whether the nRST pin is driven low upon a nPOR input assertion. I have found no definite answer in the HPS TRM (cv_5v4 dated 2024.12.03). But HPS TRM version 1.3 (Nov 2012), Table 3-3 page 3-7 says with I ran an experiment today on our prototype, asserting nPOR once the system has boot-up (linux) and see no assertion of nRST pin. Also, in the Reset Manager register description, I see no configuration bit that would enable/disable nRST assertion upon nPOR. Can someone confirm the unconditional assertion of nRST upon a nPOR as I understand from HPS TRM from Nov 2012. Thanks, Best regard Pascal21Views0likes1CommentQPP 26.1.0 Tools->Generate Simulator Setup Script produces no output
Hello, I have a relatively simple Agilex 3 QPP 26.1.0 project with four IPs on Win 11. Today after adding the latest IP block, running Tools->Generate Simulator Setup Script produces no output when executing the command. I can see from the Quartus log that "--spd" is not passed, and I believe this is the problem. If I run ip-sim-script in the Quartus command line and include the "--spd" option, the correct sim folders and files are produced. I do not see this same problem when working with the same project on Ubuntu Linux. What would cause "--spd" not to be passed? Note that the *.spd files do exist. Thank you.86Views0likes7CommentsModelSim-Intel FPGA Starter Edition 18.1 exits with code 211 when pressing Restart button
Hello, I am using ModelSim-Intel FPGA Starter Edition included with Quartus Prime Lite Edition 18.1. When I press the Restart button in the ModelSim GUI after running RTL simulation, ModelSim exits with the following message: "ModelSim is exiting with code 211. Check the transcript file for more information on the fatal error." Environment: - Quartus Prime Lite Edition 18.1 - ModelSim-Intel FPGA Starter Edition 18.1 - Windows PC - ModelSim path: C:\intelFPGA_lite\18.1\modelsim_ase\win32aloem 確認したこと: - Quartus / ModelSim は再インストールされました。 - 環境変数とPATH設定を確認しました。 - 同じプロジェクトが別のPCで正しく再起動できる場合。 - このPCではGUIの再起動ボタンを押すと問題が発生します。 - PCにはTrend Micro Apex Oneがインストールされています。 - リアルタイムスキャンからIntel FPGA / ModelSimフォルダを除外した後、ModelSimは正しく動作しました。 質問: GUIの再起動ボタンを使う場合、ModelSim-Intel FPGA Starter Edition 18.1で既知の問題として、終了コード211はありますか? また、この問題はウイルス対策ソフトやエンドポイントセキュリティソフトに関係している可能性はありますか? この問題に対するおすすめの設定や回避策はありますか? ありがとうございます。Stratix III FPGA Development Kit
"Hello! I am currently facing an unusual issue when trying to use the Stratix III FPGA Development Kit. After installing Quartus II 13.1 Subscription Edition (the last version supporting the Stratix III family) along with the respective device files (.qdz) for Cyclone, Arria, and Stratix III, and properly configuring the license on Windows 11, the Stratix III family does not appear in the device selection wizard. Interestingly, the Quartus Device Installer states that the family is already installed, but it remains hidden inside the software. To isolate the issue, I have tested multiple operating systems and Quartus versions, but the problem persists: 1) Windows 11 & Windows 7 (Quartus II 13.1, 13.0, and 12.1 Subscription): Arria and Cyclone families work perfectly. Stratix III shows as installed in the device manager but is unavailable inside Quartus. 2) Windows 7 (Quartus II 9.0 Web Edition): The Stratix III family appears in the family selection menu in Quartus, but our specific device (EP3SL150F1152) is listed as unsupported. 3) Ubuntu 12.04 (Quartus II 13.1 Subscription): Same behavior as Windows; the installer claims it is there, but Quartus does not show it. Given these cross-platform results, I suspect the root cause might be: 1) A corrupted or flawed Stratix III device installer file (.qdz). 2) A licensing restriction, where our current license might need a specific feature enabled for the Stratix III family, even though the software allows the installation. Could you please guide me on how to get this Stratix III Development Kit operational (which features the EP3SL150F1152 device)?" Thank you for your time and assistance. I look forward to your guidance. Best regards!99Views0likes9CommentsCyclone IV GX PCIe Hard IP behaves differently on Intel Core I7 vs Xeon root complexes
Hello, I am working with a Cyclone IV GX (EP4CGX22) using the Altera PCIe Hard IP configured as PCIe Gen1 x1 with an Avalon-MM interface. The same FPGA image shows different behavior depending on the host platform. Platforms Tested Working Platform Intel Core i7-13700 Windows 11 Platforms Where the Issue Is Observed Supermicro X10SRA + Xeon E5-1620 v3 Supermicro X12SPL-F + Xeon Silver 4309Y PCIe Configuration The FPGA endpoint is configured as PCIe Gen1 x1 The Xeon platforms provide newer PCIe root complexes: Xeon E5-1620 v3 -> PCIe Gen3/4 capable slot Xeon Silver 4309Y -> PCIe Gen3/4 capable slots However, the link correctly negotiates down to: Link Width : x1 Link Speed : Gen1 (2.5 GT/s) which matches the FPGA endpoint capability. Common Observations On all platforms: PCIe enumeration succeeds Vendor ID and Device ID are detected correctly BAR resources are assigned correctly The device driver loads successfully The PCIe link is established successfully TLP as data input getting unexpected value Observed Difference Although the PCIe link is established correctly on all systems, the FPGA observes different transaction behavior on the Xeon platforms compared to the Intel Core i7 platform. The same FPGA image and software stack operate as expected on the Intel Core i7-13700 system, while different behavior is observed on both Xeon-based systems. Questions Are repeated accesses to BAR-space offsets after boot expected from BIOS/UEFI, Windows PCI bus enumeration, or other background PCIe activity? Has anyone observed different behavior between Intel Core desktop root complexes and Xeon/server root complexes when using the Cyclone IV GX PCIe Hard IP? Are there known interoperability issues between older Cyclone IV GX PCIe endpoints and modern Gen3/Gen4 server root complexes, even when the link successfully negotiates to Gen1 x1? Is there a recommended way to distinguish firmware/OS-generated PCIe accesses from accesses generated by the application or function driver? Any feedback or similar experience would be greatly appreciated. Thank you.10Views0likes0CommentsUnable to receive OUT packet on USB in device mode
Hello, I am trying to use USB on Cyclone V soc with tinyUSB. I am able to receive SETUP transaction and send device descriptor, but then I cannot receive and acknowledge the next OUT transaction. I see that DOEPINT0.nakintrpt goes to 1, confirming that the device responds NAK to the OUT transaction, but I don't understand why. Here are the settings that are relevant to me : GAHBCFG.dmaen = 0 DCTL.sgoutnak = 1 GRXFSIZ.rxfdep = 0x50 DOEPMSK.xfercomplmsk = 1 GINTMSK.rxflvlmsk = 1 Written before waiting for OUT packet: DOEPCTL0.epena = 1 DOEPCTL0.cnak = 1 DOEPTSIZ0.xfersize = 0 DOEPTSIZ0.pktcnt = 1 I am lacking ideas of where to search or what could cause this behaviour. Is there anything to take care ? Best regards, Romain45Views0likes2CommentsNew Quartus/Questa license Questa Issue
I received a fulfillment message to generate a new license and the dates are all correct, however Questa FPGA 25.1 does not work. In looking at the new license, I see the Questa version is 2024.8, could this be the issue? Note, the SALT path is set to the correct license file. Support said since I am non-commercial (ASAP partner), I have to post here. This is holding up a project. Below are the license entries. # Questa*-FPGA Edition (License: SW-QUESTA-PLUS), 1 Seat(s) # - Maintenance Expiration of 2024.08 - License Expires 30-Jun-2027 # FEATURE START # The following is the license file for Questa*-FPGA Edition - Questa Plus # Number of seat licenses is 1 # License Expires 30-Jun-2027 DAEMON mgcld path_to_mgcld INCREMENT intelqsim mgcld 2027.01 30-jun-2027 uncounted \ 6FACEB5E7A42A2D9DA1C VENDOR_STRING=D20DAB7F HOSTID=080027cbc9ae \ ISSUER=Altera SN=2109769017 SIGN2="1392 510D 3792 D6DE 281C 2CF3 88E7 \ 20EC A2EE 106B D91A 534D C105 ECD1 CA52 08D5 170B FF42 6DED 5B95 F933 \ 8F24 2872 08A5 FEB3 7ECC 2E3E 81ED 00F5 260B" # FEATURE END177Views0likes8CommentsArria 10 Native PHY 66:64 RX wrong word with valid asserted
I am using Arria 10 Native PHY in Basic Enhanced PCS mode at 12.5 Gbps for a custom protocol. The protocol layer is implemented in FPGA fabric. The Native PHY is intended to provide the serial transceiver path and the Enhanced PCS 66b gearbox only. The fabric provides one 66b block per clk_sys: 2-bit sync/control header + 64-bit payload The goal is a non-backpressure full-rate interface: one 66b TX block accepted every clk_sys, and one 66b RX block produced every clk_sys after RX lock. I've attached the .tcl to generate the core, but some of the key config parameters are: protocol_mode = basic_enh data_rate = 12500 enh_pld_pcs_width = 66 enh_pcs_pma_width = 64 TX 64b/66b encoder = disabled RX 64b/66b decoder = disabled TX scrambler = disabled RX descrambler = disabled RX block synchronizer = enabled TX FIFO mode = Phase Compensation RX FIFO mode = Phase Compensation double width = disabled 10GBASE-R insert/delete = disabled Interlaken deletion features = disabled Clocking: clk_sys <= tx_clkout(0); tx_coreclkin <= (others => clk_sys); rx_coreclkin <= (others => clk_sys); Controls: tx_enh_data_valid <= (others => '1'); rx_enh_fifo_rd_en <= (others => '1'); tx_pma_elecidle <= (others => '0'); 66b mapping: (inside a loop that iterates for every channel 'c') tx_parallel_data((c+1)*64-1 downto c*64) <= tx_data(c)(63 downto 0); tx_control((c+1)*2-1 downto c*2) <= tx_header(c)(1 downto 0); rx_data(c)(63 downto 0) <= rx_parallel_data((c+1)*64-1 downto c*64); rx_header(c)(1 downto 0) <= rx_control((c+1)*2-1 downto c*2); Observed in serial loopback simulation: With RX FIFO in RX Register mode, rx_enh_data_valid has periodic bubbles, apparently matching the 66:64 gearbox cadence. With RX FIFO in RX Phase Compensation mode, rx_enh_data_valid stays asserted, but rx_parallel_data periodically has a whole-word discontinuity. It looks like a 66b word is skipped/repeated, or the latency changes by one word. The event periodicity is about 160 ns, close to the expected 66:64 gearbox cadence. These two captures are from a sequence where I receive wrong data with rx valid asserted (the first is the tx'ed sequence and the second the received: To make the issue clear I mapped the word to a letter to make it easier to see the issue: In the capture above there is the tx and rx sequence, and can be seen where the pattern breaks compared to tx. My question is: For Arria 10 Native PHY Basic Enhanced PCS with enh_pld_pcs_width=66, enh_pcs_pma_width=64, and RX FIFO in Phase Compensation mode, is a continuous non-backpressure 66b RX stream supported? If yes, what configuration or clocking condition could cause a periodic one-word wrong while rx_enh_blk_lock, rx_enh_data_valid, and rx_control remain stable? Thanks in advance.38Views0likes4Comments
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,333 Topics
- fpga dev tools quartus® prime software pro4,276 Topics
- FPGA Dev Tools Quartus II Software3,131 Topics
- stratix® 10 fpgas and socs1,539 Topics
- agilex® 7 fpgas and socs1,495 Topics
- arria® 10 fpgas and socs1,368 Topics
- stratix® v fpgas1,311 Topics
- arria® v fpgas and socs1,224 Topics
- cyclone® v fpgas and socs1,054 Topics
- Configuration1,027 Topics
Recent Blogs
Agilex® 5 and Agilex® 3 FPGAs now provide native MIPI D-PHY support for CSI-2 camera and DSI display interfaces, making it easier to bring sensor and display data directly into FPGA fabric for real-time processing, aggregation, adaptation, and transport. The blog highlights how scalable MIPI bandwidth, multi-interface connectivity, and integration with the Altera Video Solutions Stack enable high-performance vision, robotics, medical imaging, edge AI, and display systems while simplifying the path from image capture to processing and AI workflows.
22 days ago0likes
The Nios® V/c compact microcontroller is the third and the latest addition to the Nios V soft processor family and is supported in Intel® Agilex®, Intel® Stratix® 10, Intel® Arria® 10, and Intel® Cyclone® 10 GX FPGAs and SoCs. With the Nios V processor, you can easily create a processor and peripheral system using the traditional hardware tool flows like Intel® Quartus® Prime Software and Platform Designer as needed for your production solution.
23 days ago0likes
2 MIN READ
Altera is extending the availability of its Agilex®, MAX® 10, and Cyclone® V FPGA families through 2045 to support long-lifecycle applications like industrial, aerospace, and medical systems. This helps customers avoid costly redesigns and ensures reliable, long-term supply, reinforcing Altera as a trusted partner for decades-long deployments.
1 month ago2likes
To help address these challenges, Altera® is expanding the Agilex® 9 Direct RF-Series FPGA portfolio with the addition of the AGRW039, a new maximum-compute wideband device designed for demanding aerospace and defense RF applications.
1 month ago0likes
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
1 month ago1like