Recent Content
Questa Sim on Windows - linking to external LIB
I have been trying to use Questa (from Quartus Lite 21.1) on Windows to link to the Winsock2 library, without success. I have a minimal test case attached. I can't get it to load into the simulator. I compile with the command: vlog -sv -dpiheader dpiheader.h test.v test.c That succeeds. Then, I try to start the simulator using the command: vsim -c DPI_test That fails with an error: # ** Fatal: (vsim-3828) Could not link 'vsim_auto_compile.dll': cmd = 'D:/intelFPGA_lite/21.1/questa_fse\gcc-7.4.0-mingw64vc15\bin\g++.exe -shared -o "C:/Users/barralem/AppData/Local/Temp\barralem@BHI4TNR6H2_dpi_32868\win64_gcc-7.4.0\vsim_auto_compile.dll" C:/work/embedded/test/work\_dpi\auto_compile@\win64_gcc-7.4.0\test.o -Wl,-Bsymbolic -L"D:/intelFPGA_lite/21.1/questa_fse/win64" -lmtipli' # (vsim-50) A call to system(D:/intelFPGA_lite/21.1/questa_fse\gcc-7.4.0-mingw64vc15\bin\g++.exe -shared -o "C:/Users/barralem/AppData/Local/Temp\barralem@BHI4TNR6H2_dpi_32868\win64_gcc-7.4.0\vsim_auto_compile.dll" C:/work/embedded/test/work\_dpi\auto_compile@\win64_gcc-7.4.0\test.o -Wl,-Bsymbolic -L"D:/intelFPGA_lite/21.1/questa_fse/win64" -lmtipli) returned error code '1'. # No such file or directory. (errno = ENOENT) # I have tried removing the "#pragma comment(lib, "ws2_32.lib")" line, with no change. I have also tried specifying the library on the command line with -sclib. I have tried copying the LIB to the project directory, with no help.Solved3.1KViews0likes4CommentsIs the Intel® Stratix® 10 timing model correct in the Intel® Quartus® Prime Pro Edition software versions 18.0 Update 1 and 18.1?
Description No, the Intel® Stratix® 10 timing model in the Intel® Quartus® Prime Pro Edition software version 18.0 Update 1 and 18.1 has a small miscorrelation. This is corrected in the Intel Quartus Prime Pro Edition software version 18.1 Update 1. These design scenarios may be affected: Designs that use source synchronous clocking Designs with transfers between the reference clock and the output clock for IOPLLs Designs with transfers between output clocks from different IOPLLs with different reference clocks Almost all designs will see timing delays change but most transfers will be unaffected because of either Common Clock Pessimism Removal (CCPR) or the transfer being asynchronous. Resolution All Intel Stratix 10 designs should be reanalyzed for timing in the Intel Quartus Prime Pro Edition software version 18.1 Update 1 or a patched version of 18.0 Update 1 or 18.1. Download and install Patch 1.45 for 18.0 Update 1 from the appropriate link below. Download the version 18.0 Update 1 patch 1.45 for Windows (.exe) Download the version 18.0 Update 1 patch 1.45 for Linux (.run) Download the Readme for the Intel Quartus Prime Pro edition software version 18.0 Update 1 patch 1.45 (.txt) Download and install Patch 0.31 for 18.1 from the appropriate link below. Download the version 18.1 patch 0.31 for Windows (.exe) Download the version 18.1 patch 0.31 for Linux (.run) Download the Readme for the Intel Quartus Prime Pro edition software version 18.1 patch 0.31 (.txt) For designs that are already in production: 1. Download and run the script lut8_iobuf_qsh_v3.tcl to check if the compiled design is affected by this problem. Command -> quartus_sh -t lut8_iobuf_qsh_v3.tcl -project <project name> -revision <revision name> -npaths 100 -debug 0 -verbose -check_lutmasks -vo_file simulation/modelsim/<revision name>.vo Output -> lut8check.rpt, iobuf.rpt, paths.csv iobuf.rpt and paths.csv report the paths that are affected by the timing model change 2. If there are no paths identified as impacted, no action is needed. 3. If there are paths identified as impacted and using the Intel Quartus Prime Pro Edition software version 18.1 or earlier, rerun timing analysis using the patched version of the Intel Quartus Prime Pro Edition software version 18.0 Update 1 or 18.1 a. If there is not sufficient margin then recompile the design. b. If there is sufficient margin, you may choose to perform no action Steps to rerun timing analysis: 1. Download and install patch 1.45 for 18.0.1 or patch 0.31 for 18.1 2. Open the design using the patched version of the Intel Quartus Prime Pro Edition software 3. Go to Tools -> Timing Analyzer and open Timing Analyzer. 4. Run the following commands: a. create_timing_netlist -model slow -force_dat b. read_sdc c. update_timing_netlist lut8check.rpt reports the LUTs impacted by the problem described in KDB Why do I have functional errors in my Intel® Stratix® 10 design? If this report contains "Found 0 LUTs with potentially incorrect bit settings" then the compiled design is safe. If the design is affected then the LUTs with this problem will be listed in the report.Cyclone V SoC 5CSXC6 Series GXB Utilization and Limitations
Dear Intel Altera, I would like to confirm that the 6 channels GXB device: Q1) Do it possible to use all 6 TX / RX GXB Transceivers when Hard PCIe is used. Based on: CV-53004 There are no specific diagram to explains the single PCIe hard core device with only 6 channel case. Q2) Based on the document: CMU PLL will use CH5 and do this simply means there will be one extra for PCIe Hard-Core? Q3) If not understood falsely, Either PCIe X2 GEN1 + 4 custom GXB usage nor PCIe X4 GEN1 + 2 custom GXB usage is possible? And most protocol uses 1,2,4 and the only possible case is PCIe X4 GEN1 + 1 custom GXB? A little more info from CV-53002 So in order for PCIe Hard Core to run x2 or x4 CH4 must be used. As a result for custom TRX there is no way to use CH1 when PCIe is > x1? Thanks, BrianWhy does the Intel® Quartus® Prime Standard Edition software fail to choose the 1.0V IO standard for Intel® MAX® 10 devices?
Description Due to a problem in the Intel® Quartus® Prime Standard Edition software version 20.1 and earlier, you may not be able to choose the 1.0V IO standard for 10M02/04/08/16 SAU324C8G Intel® MAX® 10 devices. Resolution To work around this problem, download and install the Intel® Quartus® Prime Standard Edition software version 20.1 patch 0.11 from the appropriate link below. After installing the patch, follow the steps provided in the readme files. Download patch quartus-20.1std-0.11std-windows.exe for Windows (.exe) Download patch quartus-20.1std-0.11std-linux.run for Linux (.run) Download the Readme for patch quartus-20.1std-0.11std-readme.txt (.txt)JESD204B Multi-Link Implementation with AD9695 ADCs Having Different Lane Counts (L=4 and L=2)
Hello Intel Community, I am currently working on a multi-chip ADC design using the AD9695 with the JESD204B interface on an Intel Stratix 10 FPGA. I am using the JESD204B Intel FPGA IP core and have been referring to the example design provided with the IP. I have also followed the guidelines mentioned in Intel Application Note AN 804: Implementing Analog-to-Digital Converter Multi-Link Designs with Intel Stratix 10 JESD204B RX IP Core. In my design, I have three ADC chips with the following configuration: ADC 1: 4 lanes (L=4) ADC 2: 4 lanes (L=4) ADC 3: 2 lanes (L=2) All other JESD204B parameters (such as F, M, S, N, N') are identical across all three ADCs. According to AN 804, it is mentioned that when adding multiple subsequent links within a single JESD204B IP core, all links must share the same set of JESD parameters, including the number of lanes (L). Since my third ADC has a different lane count, I am unsure about the correct implementation approach. I would appreciate your guidance on the following: Can I integrate all three ADCs into a single JESD204B IP core instance by configuring it as a multi-link design, even though the lane counts differ? If not, should I instantiate three separate JESD204B IP cores, each configured as a single link (L=4, L=4, L=2 respectively)? Alternatively, should I instantiate two IP cores — one for the first two ADCs (with L=4, using the multi-link feature) and a second core for the third ADC (with L=2)? Could you please suggest the correct and most efficient path forward? Also, if I use separate IP cores, what are the key considerations for ensuring proper synchronization (Subclass 1) and reliable operation across all three links? Any insights, reference designs, or best practices would be greatly appreciated. Thank you in advance for your support. Best regards, BALAMURuGAN V3Views0likes0CommentsImplementing many Nios® V cores on Agilex™ 7
Table of Contents Introduction Environment Configuration (HW) Configuration (SW) Mass Implementation Multicore Debugging Conclusion Note: This article is an English translation of this Japanese article by Macnica. Please refer to the original article for updates. Introduction The attention to RISC-V has been increasing year by year, and it seems that many manufacturers are developing based on RISC-V. The Nios® V I use this time is also one of the RISC-V based processors, and it is a softcore processor developed by Intel. This article is an experimental article about implementing Nios® V to the limit on Agilex™ 7, thinking about doing something interesting with RISC-V. Environment This time, since we are using Intel FPGA and Nios® V, we will use the following: Intel® Quartus® Prime Pro Edition Software Version 22.2 for Windows Ashling* RiscFree* IDE for Intel® FPGAs We will use the following for Agilex™ 7: Agilex™ 7 FPGA F-Series Development Kit (P-Tile and E-Tile) Configuration (HW) This time, to implement many Nios® V, we have created a submodule with Nios® V, and are instancing that module in the top level. The configuration of the submodule includes: Nios® V/m processor On Chip RAM JTAG-UART These three are the minimum requirements for operation confirmation. The top level includes: CLK Reset Submodule (Nios® V) ISSP Reset You may not be familiar with ISSP, but understand that we are using HW logic with ISSP to toggle the Reset because the development kit used this time does not have a reset button for FPGA. The block diagram of this configuration is as follows. (Orange is Bridge, and purple is IP, color-coded.) In this configuration, the On chip RAM for Nios® V execution memory is generated with 128kByte. For details, please refer to the capture of the Platform Designer in "Mass Implementation". This time, since we will not perform a standalone operation confirmation, we have constructed it to only run the elf file in RAM with a debugger without considering detailed settings such as Reset Vector or Boot methods for each Nios® V. Configuration (SW) The software is a simple program that outputs to the JTAG console. Since we implement multiple Nios® V, it is better to write the program so that the outputs from different cores can be distinguished. Please refer to the final outputs at the end of section Multicore Debugging. Mass Implementation This configuration is created in Platform Designer. Since we only need to instance the submodules in the top level, we are lucky that the top level remains clean, although it took time to generate. First, let's check with only one Nios® V. As explained earlier, it appears that only one Nios® V submodule is implemented in the Platform Designer system. Below is the top level system diagram (the red frame is the Sub module). This is the Sub Module (the red frame is Nios® V/m processor). The compilation result is below. Even though we used 128kB Onchip RAM, it is still only 1% utilized. Next, let's try with 10 units. To make it easier later, we have created a submodule that implements 10 submodules and instance it in the top level. Below is the compilation result. Roughly, the RAM block usage is 1% per Sub module. Let's go bold and implement 100 units. We barely managed to implement it! It's okay to implement 100 units!! Although we think we can implement a few more, as the RAM resources are over 90%, we will settle with 100 units for now. Multicore Debugging Finally, I would like to write about debugging when implementing multiple units. For the Nios® V development environment, we use Ashling* RiscFree* IDE for Intel® FPGAs introduced in Chapter 2. It can be downloaded together with Intel® Quartus® installer, so please install it together. Here, I will omit the steps for launching Ashling* RiscFree* IDE for Intel® FPGAs and importing the project. The build process was referenced from the article below: Development Procedure for Nios® V Projects using Ashling* RiscFree* IDE for Intel® FPGAs After you have built the projects, first create a Debug configuration for each CPU. You can select which CPU to create for from the Core selection in the Debugger tab, as shown below. After setting and creating the Debug configuration for each CPU, group them with Launch Group to execute them simultaneously. This completes the Debug configuration. Next, prepare the console output destination. This time, due to screen display limitations, we will display the output in each Nios® V command shell. Launch the Nios® V command shell for each CPU and execute the following command: #juart-terminal -c <change for each CPU> -d <device number> -i <instance number> juart-terminal -c 1 -d 0 -i 0 With this command, each Command shell will be linked to the JTAG console. (The last number in Core selection corresponds to the argument of -i.) Select the Group created earlier and press Debug. By default, it will break at the start of the main function, so you can add breakpoints, check register and variable values for each source to debug. The execution result this time is shown below. We captured the situation where the JTAG console is running simultaneously. Conclusion This time, I implemented many Nios® V just for fun, but it took a lot of time for tasks such as compilation time and Platform Designer hierarchy design. It was quite difficult for an article started with a light heart. However, since I think there are few people who actually perform this configuration, I hope you will find the multicore debugging part helpful. Notices & Disclaimers Intel technologies may require enabled hardware, software or service activation. No product or component can be absolutely secure. Your costs and results may vary. © Intel Corporation. Intel, the Intel logo, and other Intel marks are trademarks of Intel Corporation or its subsidiaries. Other names and brands may be claimed as the property of others. The products described may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade. Nios is a trademark of Intel Corporation or its subsidiaries.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/BuildingBootloaderStratix10FIR 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.303Views0likes11Comments
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,398 Topics
- fpga dev tools quartus® prime software pro4,292 Topics
- FPGA Dev Tools Quartus II Software3,160 Topics
- stratix® 10 fpgas and socs1,548 Topics
- agilex® 7 fpgas and socs1,481 Topics
- arria® 10 fpgas and socs1,377 Topics
- stratix® v fpgas1,319 Topics
- arria® v fpgas and socs1,232 Topics
- cyclone® v fpgas and socs1,059 Topics
- Configuration1,023 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.
16 hours 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.
8 days 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.
8 days 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
27 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.
28 days ago0likes