Recent Content
MAX 10: Can an ASx1 RBF be written directly to internal CFM via on-chip flash Avalon-MM?
Hi, I am implementing an in-system self-update mechanism for an Intel MAX 10 FPGA (10M16SAU169I7G) and I would like to confirm the correct configuration image format for programming the internal CFM through logic running inside the FPGA. My setup Device: MAX 10 10M16SAU169I7G Current design already boots normally from internal flash Inside the running design, I receive a new FPGA image over UART I split the image into blocks, verify CRC, and then write the data into the internal CFM using the on-chip flash IP Avalon-MM data interface After the transfer is complete, I plan to power-cycle the board so the FPGA boots from the newly written image What I am currently doing I generate the update file using quartus_cpf from the .sof: ~.bat ''' quartus_cpf ^ --option=bitstream_compression=off ^ --configuration_mode=ASx1 ^ -c ^ input.sof ^ output_file_active_serial.rbf ''' Then I send this .rbf file to the FPGA and write it word-by-word into the internal CFM. My question Can a Raw Binary File (.rbf) generated from a MAX 10 .sof with --configuration_mode=ASx1 be written directly into the MAX 10 internal CFM through the on-chip flash Avalon-MM interface, and then be used successfully as a bootable configuration image after power cycle? Or, stated differently: Is the ASx1 RBF byte layout identical to the internal CFM configuration image layout expected by MAX 10? If not, what is the correct file format / conversion flow for self-updating the internal CFM from user logic? Should I be using RBF, POF, or another file/image format for this purpose? Is there any official Intel example or application note showing the correct way to write a new configuration image into MAX 10 CFM from inside the running FPGA design? Additional context I already reviewed: MAX 10 FPGA Configuration User Guide Remote System Upgrade in Intel MAX 10 Devices Using the MAX 10 User Flash Memory From the documentation, I understand that MAX 10 supports configuration from JTAG and internal flash, and that remote/dual configuration is supported. However, I could not find a clear statement confirming whether an ASx1-generated RBF is the correct binary image to write directly into CFM via Avalon-MM. My main concern is avoiding a situation where: the UART transfer is correct, the CFM write completes, but the FPGA does not boot afterwards because the file format/layout written into CFM is not the expected one. If anyone from Intel or anyone who has implemented MAX 10 self-update / remote update can clarify the correct image format and recommended flow, I would appreciate it. Thank you.2Views0likes0CommentsCyclone 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, BrianJESD204B RX Link Never Achieves CGS at 12.8 Gbps on S10 ES (1SG280LU3F50E3VGS1, Quartus Pro 17.1)
Hi Team, I am using the Intel JESD204B RX Example Design on a Stratix 10 GX Engineering Sample FPGA (1SG280LU3F50E3VGS1, L-Tile) with Quartus Prime Pro 17.1.I have two JESD204B configurations using the same board, RTL, and hardware. Case 1 (Working):ADC Clock = 1228.8 MHz, Decimation = 6 Lane Rate = 8.192 Gbps REFCLK (Core/XCVR) = 409.6 MHz Link/Frame Clock = 204.8 MHz SYSREF = 6.4 MHz This configuration works correctly and the JESD link comes up successfully. Case 2 (Not Working): ADC Clock = 1280 MHz Decimation = 4 Lane Rate = 12.8 Gbps REFCLK (Core/XCVR) = 640 MHz Link/Frame Clock = 320 MHz SYSREF = 5 MHz The JESD204B parameters are identical in both cases: L = 4 M = 8 F = 4 S = 1 N = 16 NP = 16 K = 32 Subclass 1 In the failing case, the following status is observed: Core PLL Locked = Yes ADC PLL Locked (Register 0x056F = 0x80) rx_is_lockedtodata = 0xF rx_ready = 0x0F rx_cal_busy = 0 rx_analogreset = 0 rx_digitalreset = 0 jesd204_rx_link_ready = 1 jesd204_rx_link_valid = 0 The Debug Link Buffer outputs are always zero: jesd204_rx_dlb_kchar_data = 0 jesd204_rx_dlb_data_valid = 0 jesd204_rx_dlb_data = 0 jesd204_rx_dlb_disperr = 0 jesd204_rx_dlb_errdetect = 0 Therefore, no CGS (/K28.5/) characters are detected and the link never progresses beyond this point. I have verified the following: ADC SPI configuration is correct.SYSREF is present on both ADC and FPGA.Register 0x0120 is written with 0x1C and correctly reads back 0x18 after SYSREF capture.Register 0x056E is configured correctly for the 12.8 Gbps lane rate.Register 0x0201 is set correctly for decimation by 4.REFCLK, Link Clock, and Frame Clock frequencies are correct.Native PHY calibration completes successfully.No Quartus warnings are reported.The Intel example design is used without RTL modifications.I also tried lane swapping and RX polarity inversion, but the result was unchanged.This 12.8 Gbps configuration has never worked even once since the beginning, whereas the 8.192 Gbps configuration works reliably on the same hardware. Could you please advise: Is there any known limitation or errata for Stratix 10 ES (1SG280LU3F50E3VGS1 L-Tile) at 12.8 Gbps?Is any additional Native PHY or transceiver configuration required for 640 MHz reference clock and 12.8 Gbps lane rate?Are there any known issues in Quartus Prime Pro 17.1 related to JESD204B RX at this operating point?Any suggestions on additional debug steps would be greatly appreciated.Why 390.625MHz clock to F-Tile Reference fequency
Hi, This question is regarding the Agilex 7 M-Series FPGA Development Kit. In the evaluation board schematics, the Si5518 provides a 390.625 MHz clock that is connected to two F-Tile reference clock inputs. From the F-Tile Ethernet Hard IP User Guide, I understand that standard Ethernet designs typically use 156.25 MHz as the PMA reference clock, while the 390.625 MHz clock appears internally as the clk_txmac/clk_rxmac clock. My questions are: 1. Which F-Tile configuration or interface is intended to use the external 390.625 MHz reference clock on the development board? 2. Is this reference intended for the Ethernet Hard IP, PMA Direct mode, SyncE, or some other transceiver application? 3. Are there any official reference designs that use this 390.625 MHz reference clock? I would appreciate it if you could clarify the intended use of this clock on the Agilex M Development Kit. Regards,16Views0likes2CommentsHPS First Boot Configuration for Agilex 7
Dear Community, I'm developing a design using Agilex 7 on Quartus Pro 24.2. I'm a bit confused on the parameter settings I need for the HPS (and its EMIF) and my Quartus project settings in order to have HPS-First boot (Called HPS Early Release in former Quartus versions). For that, I'd like to generate .core.rbf and .periph.rbf files. I tried generating the .rbf files in two different ways given below, none succeeded. #1) Having the below pfg command in a text file and sourcing it in my .qsf --convert --hps -o bitstream_compression=on output_files/ProjectName.sof output_files/ProjectName.rbf #2) Using the Programming File Generator tool of Quartus I can generate .sof programming file, but converting that to .rbf fails with the following error when I did either given above. "sof is incomplete. Hps is present but bootloader information is missing". When doing case #2, I even add a bootloader .hex file that I could find on Rocketboards' webpage. Could anyone support me to have an HPS-first boot on Agilex 7 ? Thanks in advance!7Views0likes1CommentVVP Protocol Converter Not work
Hello, I am looking for how to use the VVP protocol converter, by converting Altera Stream Video Lite to Avalon Streaming Video. I generate a simple pipeline with Protocol Converter to Frame Buffer on Cyclone 10 GX... Here's the settings of the converter, And the Register settings for this IP, For unknown reason, I am unable able to see the protocol converter ready to work by setting rx ready signal goes "high" on STP. Even when the tx side ready signal is OK. Readback the register, the mode is fine and the CTRL is bit 0 is set already.. What would be wrong on my settings? Please help. Thank you.28Views0likes8CommentsAgilex 7 R-Tile PIPE Direct endpoint receives Set_Slot_Power_Limit, but no Config TLPs
Hello, I am developing a custom PCIe endpoint using the Agilex 7 R-Tile PIPE Direct interface. The PHY is provided by the R-Tile IP, while the LTSSM, Data Link Layer, and TLP/DLLP handling are implemented in soft RTL. Environment FPGA: Agilex 7 AGIB027R29A Quartus Prime Pro 24.3.0 Build 212 R-Tile PIPE Direct mode PCIe Gen3 x8 Custom soft LTSSM and Data Link Layer Linux host with a commercial PC/root complex The FPGA is configured before a host cold boot The endpoint is not currently visible in lspci In a successful Signal Tap capture: The LTSSM reaches Gen3 L0. The Data Link Layer reaches DL_ACTIVE. InitFC1 and InitFC2 for Posted, Non-Posted, and Completion traffic are exchanged. We observe valid incoming TLP traffic with a correct LCRC. The host sends a Message TLP that appears to decode as Set_Slot_Power_Limit. No subsequent Configuration Type 0 Read TLP or other expected enumeration TLP is observed. The link later returns from L0 to Recovery.RcvrLock. Our understanding is that Set_Slot_Power_Limit is a posted Message TLP and should not require a Completion TLP from the endpoint. The endpoint should only acknowledge successful reception at the Data Link Layer. Please correct us if this interpretation is wrong. Questions Is receiving Set_Slot_Power_Limit before the first Configuration Read a normal root-port enumeration sequence? Does the endpoint need to respond to this Message TLP in any way other than sending a Data Link Layer ACK? If the ACK DLLP has an incorrect sequence number, CRC, or timing, could the root port stop sending further TLPs and eventually force the link into Recovery? Are there any R-Tile PIPE Direct-specific status or control signals that must be handled before the host starts Configuration transactions? Are there recommended R-Tile debug signals for determining why the root port stops after this message? Could an incorrect Flow Control advertisement—especially Completion Header/Data credits—cause this behavior even if InitFC2 completes? Are there known PERST#, cold-boot, or FPGA-configuration timing requirements for enumeration when using PIPE Direct mode? We are currently capturing the following signals: LTSSM state Data Link Layer state InitFC1/InitFC2 and UpdateFC status Received TLP Fmt/Type and complete header Received TLP sequence number LCRC result ACK/NAK request and transmitted ACK/NAK sequence number Replay timer/replay status RX block lock, CDR lock, and lane numbers Raw 1024-bit PIPE RX block data Any guidance on the expected transaction sequence after Set_Slot_Power_Limit, or additional signals that should be captured, would be greatly appreciated. Thank you.2Views0likes0CommentsUnable to Generate Valid PAM4 Eye Diagram and BER Measurements on Stratix 10 SI E-Tile Native PHY
Hardware Intel Stratix 10 Development Kit E-Tile Native PHY IP Single SMA TX and RX channel SMA-to-SMA cable (50 Ω) Software Quartus Prime Pro 18.1 Intel Transceiver Toolkit Configuration PAM4 operation Line rate: 51 Gbps One TX channel connected directly to one RX channel through an SMA cable Design compiles successfully and programming is successful. Problems Encountered 1. PAM4 Eye Detection Failure Transceiver Toolkit reports: "PAM4 eye could not be detected, check lock status and run RX adaptation." 2. RX Adaptation Questions One-time adaptation completes successfully, but: Eye detection still fails. BER measurements do not produce a usable eye diagram. Questions: Should continuous adaptation be used instead? Is there a recommended adaptation sequence before running Eye Viewer? 3. Eye Diagram Parameters Undefined After running Eye Viewer: Eye Width = Undefined Eye Height = Undefined i.e. ratio = (0/0) The heatmap returns with full RED and no eye diagram. The eye diagram is not generated even though the receiver reports lock. 4. BER Test Issues I am unsure: How many bits are required before Eye Viewer can successfully generate a PAM4 heat map. Whether there is a minimum BER sample count required for a valid eye diagram at 51 Gbps. Whether insufficient captured bits can cause "Undefined" eye width/height. 5. TX Pattern Currently transmitting a repeating user-defined pattern, for example: .tx_parallel_data({20{40'b0, 40'h0F0F0F0F0F, 40'b0, 40'h0F0F0F0F0F}}) Questions: Is this pattern suitable for PAM4 eye measurements? Would PRBS13 or PRBS31 be required instead? 6. Signal Integrity Questions: Can a 50 cm SMA cable (Pasterneck PE3CA1035) reliably carry a 51 Gbps PAM4 signal? Is additional equalization or TX pre-emphasis typically required even for short SMA connections? 7. Transceiver Toolkit Configuration I would appreciate guidance on: Recommended Eye Viewer settings. Auto Sweep configuration. Vertical and horizontal ranges. TX FIR tap values. RX CTLE/DFE settings. Required number of bits before starting the eye scan. What are the common reasons for "PAM4 eye could not be detected" despite PLL/CDR lock? What checks should be performed before running Eye Viewer? PRBS as well as USER sequence, both generate complete RED heatmap, why? How many bits should be accumulated before generating an eye diagram at 51 Gbps? Are there recommended TX FIR, CTLE, and DFE settings for a direct SMA-to-SMA connection? Has anyone successfully generated a PAM4 eye using the Stratix 10 E-Tile Native PHY over SMA? If so, could you share the required configuration or debugging steps?Issue with MIPI CSI2 Encrypted IP File During Project Integration
Hi, I am working on a project where I have integrated two separate projects into a single top-level design. Project A includes the MIPI CSI2 IP and other related components. Project B contains the logic to process the output data generated by the MIPI CSI2 IP. When I compile both projects individually, they complete successfully without any errors. However, after instantiating both projects together in a single top-level wrapper, I encounter a compilation error originating from the generated encrypted file of the MIPI CSI2 IP. I have attached the error snapshot for your reference. Could you please help identify the possible cause of this issue? Is there any known limitation or configuration requirement when integrating the MIPI CSI2 IP with additional logic in the same top-level design? Thanks.26Views0likes4Comments
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,335 Topics
- fpga dev tools quartus® prime software pro4,280 Topics
- FPGA Dev Tools Quartus II Software3,131 Topics
- stratix® 10 fpgas and socs1,539 Topics
- agilex® 7 fpgas and socs1,499 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,039 Topics
Recent Blogs
As industries race to unlock real-time insights from massive volumes of sensor data, the need for high-performance, low-latency computing at the edge has never been greater. From medical imaging to industrial automation and autonomous robots, success depends on the seamless integration of data capture, processing, and AI-driven decision-making. That’s why Altera is proud to be an ecosystem partner of NVIDIA Holoscan, working together to enable a new class of accelerated computing platforms designed for sensor-rich, AI-powered applications. Leading the Way in High-Speed Connectivity Innovation at the edge starts with moving data fast and reliably. Altera is proud to offer the FPGA industry’s only 25G and 100G Holoscan Sensor Bridge designs, providing the high-bandwidth infrastructure needed to handle today’s most demanding Edge AI workloads. These high-speed interfaces are critical for: Streaming multiple high-resolution video or other high-bandwidth data streams Processing large radar, robotics, drone, or medical imaging datasets Enabling low-latency, deterministic decision-making in mission-critical environments “With Altera FPGAs driving these capabilities, developers can scale their applications confidently, knowing their systems won’t be bottlenecked by sensors and data movement pipelined via Holoscan Sensor Bridge into NVIDIA GPUs,” says Farhad Shafai, Altera, Head of Business Solutions and Vertical Marketing. Why Altera FPGAs + GPUs Are Better Together Modern intelligent systems require both flexibility and performance, which is why combining Altera FPGAs and GPUs is becoming the architecture of choice. Here’s how this powerful pairing works: FPGA Capability How It Enhances GPU-Based AI Sensor Connectivity and Data Ingestion FPGAs excel at interfacing directly with diverse sensors, handling custom protocols, and aggregating data streams efficiently. Ultra-Fast Processing With deterministic, low-latency performance, FPGAs can preprocess and filter data before it reaches the GPU, ensuring only the most relevant information is passed along. AI Acceleration FPGAs can be designed into your solution to pre-process and prepare your data for the most efficient AI processing by the GPU. Flexibility and Futureproofing FPGAs offer reconfigurability, allowing systems to adapt to evolving standards and algorithms without redesigning hardware. Enhanced Security With built-in hardware-level security features, FPGAs can encrypt sensor data directly at the source, helping ensure that sensitive information is protected from the edge to the compute/GPU, critical in industries like defense, and industrial automation. Together, Altera FPGAs and NVIDIA accelerated computing create an architecture that delivers both performance and adaptability, enabling developers to build smarter, faster, and more efficient systems. See It in Action: Altera’s 25G Demo on Agilex® 5 SoC FPGAs Want to see how high-speed connectivity and intelligent processing come together in real-world applications? Watch the demo: https://www.youtube.com/watch?v=ikmNKdOHbUU This demonstration highlights Altera’s latest 25G Holoscan Sensor Bridge design, enabling multi-camera sensor data flow and accelerated processing at the edge. Ready to Get Started? Developers can jump in quickly and start building with our 10G, 25G, and 100G reference designs at: Get started on GitHub https://github.com/altera-fpga/holoscan-sensor-bridge/tree/altera-release-2.6.0/fpga/altera Whether you’re building next-generation medical devices, robotics platforms, or AI-powered industrial systems, Altera and NVIDIA Holoscan provide the foundation you need to succeed. Learn More Explore Altera’s 10G – 100G Holoscan Sensor Bridge offerings at: http://www.altera.com/holoscan-sb
1 day ago1like
Smart cameras and embedded vision systems are being asked to do more at the edge. They need to capture higher-resolution video, process images in real time, support evolving sensors and interfaces, and prepare clean data for analytics or AI. At the same time, many of these systems are constrained by board area, system cost, power budgets, and long product lifecycles. That combination creates a familiar engineering challenge: how much of a real vision pipeline can be built in a device class optimized for lower logic density and cost? The Agilex® 3 4Kp30 Camera Lite reference design gives a compelling answer. It demonstrates a practical sensor-to-display camera pipeline built on Agilex 3, showing how a power- and cost-optimized FPGA can ingest a 4K image stream over MIPI CSI-2, process raw sensor data through an image signal processing pipeline, and output 4Kp30 video through DisplayPort 1.4. The reference design is a complete working vision pipeline that you can use to build your own based on your unique requirements. From sensor input to display output The reference design starts with a Raspberry Pi High Quality Camera module using the Sony IMX477 image sensor. The sensor outputs 12-bit raw Bayer data and connects to the FPGA through a MIPI CSI-2 interface. From there, the MIPI CSI-2 IP converts the incoming pixel stream into AXI4-Streaming data, making it available to the rest of the Altera® Video and Vision Processing (VVP) Suite pipeline. Inside the FPGA fabric, the design implements the major stages needed to turn raw sensor data into display-ready video. The ISP pipeline includes Black Level Correction, White Balance Correction, Demosaic, Color Correction Matrix, and a 1D LUT. The pipeline supports 12-bit raw data up to the Demosaic IP and 10-bit RGB for downstream video processing. The result is a fixed 3840 x 2160, 30 Hz video path from camera input to display output. That matters because many real products need more than a way to receive camera data. They need image correction, color processing, buffering, video formatting, display output, and software control. Agilex 3 brings those pieces together in a reference design that engineers can study, run, and adapt. A practical foundation for smart camera products For security cameras, industrial vision, smart infrastructure, robotics, retail analytics, and access control, the camera pipeline is often the first major design decision. The system must bring pixels in from the sensor, correct and format them, keep timing deterministic, and deliver data to the next stage of the product. In many cases, that next stage may be a display path, a host processor, a networking subsystem, a storage path, or an AI analytics engine. The Agilex 3 reference design is valuable because it gives developers a working foundation for that pipeline. It demonstrates the sensor input, image-processing path, video frame buffer, output mixer, and DisplayPort output using Altera IP. Developers can use it as a starting point, then adapt the pipeline for their own sensor choice, image-processing requirements, overlay needs, output path, or product-specific differentiation. In the current reference design, the video frame buffer is used for video synchronization. This is a practical detail worth highlighting because real video designs often need buffering for timing alignment, rate matching, format conversion, or system-level processing. The design uses external LPDDR SDRAM through an external memory interface for that frame buffer. More broadly, Agilex 3 SoC devices also supports LPDDR5 memory interfaces, giving production designs a path to compact memory subsystems around video and embedded processing workloads. Embedded control today, hard processor path for production systems The current Agilex 3 Camera Lite reference design uses a Nios® V soft processor running a bare-metal software application. That software discovers the hardware IP blocks, configures them, monitors feedback loops, and provides a terminal-based interface over JTAG-UART. This is a good fit for the reference design because it keeps the example compact and focused on the FPGA-resident video pipeline. For production smart camera or industrial vision systems, Agilex 3 SoC devices add another important platform option: an integrated hard processor system with dual-core Arm® Cortex®-A55 processors. That HPS is not used in this reference design, but it can be a major advantage in a product architecture. Designers can use the FPGA fabric for deterministic video ingest and image processing while using the HPS for system control, application software, communication stacks, user interfaces, sensor orchestration, security services, or higher-level product logic. This combination is especially important for embedded vision. Hardware pipelines are excellent at moving and processing pixels predictably. Software is excellent at managing the product around that pipeline. Agilex 3 gives designers both paths in the same device family: a fabric-based video processing foundation and, when needed, an integrated Arm-based processing subsystem for production software. A path toward AI-enhanced edge vision The Agilex 3 4Kp30 Camera Lite reference design is not an AI inference design. Its focus is 4K camera ingest, ISP processing, video buffering, output mixing, and DisplayPort output. That distinction is important. At the same time, the architecture points naturally toward smarter edge vision systems. Agilex 3 includes AI-capable Tensor Block architecture in the fabric, and Agilex 3 and Agilex 5 share an architecturally aligned FPGA fabric foundation. The related Agilex 5 camera reference design shows the fuller concept by combining multi-sensor 4K camera input, ISP processing, FPGA AI Suite inference, Linux software on the HPS, and display output with AI results. That gives customers a scalable design story. Agilex 3 can be the cost-optimized starting point for 4K smart camera pipelines and edge vision preprocessing. Agilex 5 can scale the concept to larger, more compute-intensive designs that integrate AI inference directly into the reference architecture. Customers can begin with the 4K vision pipeline they need today and scale toward more intelligent camera systems as product requirements evolve. Why it matters The real message of the Agilex 3 4Kp30 Camera Lite reference design is: a lower-density, cost-optimized FPGA can still implement a substantial portion of a modern vision system using available Altera IP. That includes native camera ingest, AXI4-Streaming video movement, ISP processing, frame buffering, output mixing, embedded software control, and DisplayPort output. For customers building smart cameras, industrial vision systems, surveillance endpoints, or edge AI preprocessing pipelines, this is a practical starting point rather than a blank page. With Agilex 3, designers can build compact, customizable 4K vision systems while keeping a clear path to hard processor integration, modern memory support, and future AI-enhanced processing. It is a strong example of how much capability can fit into the power- and cost-optimized segment of the Agilex portfolio. Explore the Agilex 3 4Kp30 Camera Lite reference design and use it as a starting point for your next smart camera, industrial vision, surveillance, or edge AI preprocessing system. Source links for reviewers Agilex 3 4Kp30 Camera Lite developer documentation Agilex 3 camera GitHub repository Agilex 3 FPGAs and SoCs device overview Agilex 3 HPS documentation Agilex 5 4Kp30 Multi-Sensor Camera with AI Inference documentation
3 days ago0likes
Engineers starting a new FPGA design make several important choices before they write the first line of RTL. The device they select influences the tool flow, IP base, debug method, training path, and production roadmap that follow. For teams working on cost-sensitive embedded, vision, control, DSP, and edge AI-enabled systems, the ideal starting point needs to be affordable, accessible, and serious enough to support real implementation work. Agilex® 3 brings that starting point into the modern Agilex portfolio. Built with Intel 7 technology and second-generation HyperFlex™ architecture, Agilex 3 FPGAs and SoCs extend Agilex-class fabric, efficient performance, modern I/O, embedded memory, DSP resources, and security features into power- and cost-optimized applications. The result is a practical entry point for developers who want a current-generation FPGA platform with a path that can grow beyond the first evaluation board. Start with a real Agilex device for less than $130 The Arrow AXC3000 starter kit gives developers a low-cost way to begin designing with Agilex 3. Currently listed through Arrow at $129, the kit is based on the Agilex 3 C-Series 100 device A3CY100BM16AE7S. That means developers can start with a real Agilex 3 FPGA that provides roughly 100K logic elements, 138 DSP blocks, 276 18x19 multipliers, MIPI D-PHY support, LVDS, a Secure Device Manager, internal memory, external HyperRAM, QSPI configuration flash, CRUVI HS expansion, Arduino MKR standard pads, USB-C power, and an on-board programmer and debugger. This gives first-time Agilex 3 users a compact board for labs, proofs of concept, and early design exploration while preserving a connection to production-capable architecture and tools. It also gives experienced teams a low-cost evaluation path for assessing Agilex 3 in edge, industrial, vision, and control applications. The hardware ecosystem gives developers several ways to start. In addition to AXC3000, Terasic lists Agilex 3 kits under $180, including the DE23-Lite Development Kit, Atum A3 Nano, and Atum Nios® V Starter Kit. These options support different entry paths: education and prototyping, compact FPGA development, and Nios V-focused embedded exploration. A complete set of professional tools for no cost The low-cost Agilex® 3 makes FPGA development more accessible, while a no-cost professional tool flow helps developers realize the device’s full performance and design potential. Quartus® Prime Pro Edition software is the professional design environment and is available from the Altera Download Center. For Agilex 3 devices, developers can use Quartus Prime Pro with a no-cost license, providing a fast path from installation to first compile without a separate manual licensing workflow. Quartus Prime Pro gives Agilex 3 developers a professional FPGA implementation environment from day one. The integrated flow includes synthesis, place-and-route, timing analysis, system debug, power analysis, IP integration, and example designs. Altera knows that FPGA designs can become complex quickly, even during early evaluation. Developers need strong visibility into design behavior so they can find issues, validate functionality, and keep projects moving. For that reason, Altera does not charge for system debug tool. We provide a full license for no cost for any Agilex 3 design. Developers can also use advanced Altera tools and capabilities such as DSP Builder, Power & Thermal Analyzer, FPGA AI Suite, and Nios V processor IP where they fit the design objective. That matters because the first evaluation project often becomes the foundation for production work. Design teams want to learn a flow that can carry forward. They want timing closure methods, IP, debug tools, and software habits that remain useful as the design grows. Agilex 3 gives them that continuity in a professional Quartus Prime Pro environment. Application-ready examples make the story concrete The most compelling way to evaluate a starter platform is to see it run a meaningful application. Agilex 3 is well suited for that kind of demonstration because it combines modern FPGA fabric, useful I/O, embedded memory, DSP resources, and application-oriented IP in a cost-optimized device family. A strong example is the Agilex 3 4Kp30 camera reference design. The design shows how a compact FPGA platform can support a complete video pipeline, including image sensor input, MIPI-based connectivity, image signal processing, and display output. For vision developers, that is a much more useful starting point than a generic board bring-up exercise. It connects directly to applications such as industrial vision, smart cameras, robotics, surveillance, retail analytics, and edge preprocessing. For the AXC3000 mentioned above, a GitHub repo is provided that includes several designs for the AXC3000 board: https://github.com/ArrowElectronics/Agilex-3/wiki/Agilex-3-AXC3000-Development-Platform#reference-designs The same principle applies to embedded and software-oriented development. Nios V provides a RISC-V processor path for control-plane and embedded workflows, and the Atum Nios V Starter Kit gives developers a focused way to explore that environment. As additional Agilex 3 software examples become ready for public promotion, they can extend the story into platform management, real-time control, and HPS-based use cases. A starter path that scales Agilex 3 is the accessible on-ramp to the broader Agilex portfolio and Especially Agilex 5 E-series. Developers can begin with low-cost starter hardware, use professional Quartus Prime Pro tools, and build confidence on real application examples. As designs become more demanding, the path does not stop at the entry board. More capable Agilex 3 boards and device options give teams room to expand into richer I/O, larger designs, more embedded memory, and more complete application prototypes. For software-rich embedded systems, Agilex 3 SoC devices extend the story further with a dual-core Arm Cortex-A55 hard processor system integrated alongside the FPGA fabric. That gives developers a path from simple FPGA evaluation into more powerful applications that combine programmable logic, embedded software, real-time control, and system-level processing in one platform. Need more gates? Even more powerful devices? A pin to pin migration path to Agilex 5 E-series will get you there. The same design environment can support early prototyping, design optimization, IP integration, and eventual deployment across Agilex 3 devices and the broader Agilex family.
3 days ago0likes
3 MIN READ
How a published OpenCores study connects workload behavior, fabric architecture, and software optimization. Mid-range FPGA designers rarely optimize for only one thing. A design has to fit. It has to close timing. It has to stay within the power budget. As more functions move into the same device, those requirements become harder to satisfy at the same time. That is why the combination of fabric architecture and software matters. A new Altera white paper, ”Altera Delivers Superior Performance, Power, and Logic Packing with Quartus® and Agilex® 5 FPGAs Versus AMD Kintex™ UltraScale+”, examines this challenge using twelve publicly available OpenCores benchmark designs. The study compares Agilex® 5 E-Series devices with AMD Kintex™ UltraScale+ devices using each vendor’s recommended software flow and a stamping methodology that increases utilization by replicating each design across the FPGA. FPGA performance is application-dependent, and the paper’s value is in showing how different workload types stress different parts of the FPGA architecture and implementation software, highlighting where Agilex 5 E-Series demonstrates meaningful advantages. Why Agilex 5 E-Series is well suited for these workloads Agilex 5 E-Series is designed for mid-range applications that need a balance of performance, power efficiency, and integration density. Its fabric combines HyperFlex™ architecture, adaptive logic modules, embedded M20K memory, and Quartus® Prime optimization technology. Just as important, its regular fabric structure and scalable interconnect help routing remain more predictable as utilization rises. That matters because timing closure is often limited by placement and routing pressure, not only by raw logic count. Because Agilex 5D shares the same underlying Agilex 5 fabric architecture, these fabric-level advantages extend to the D-Series as well, with higher device density, greater on-chip resource capacity, and approximately 20% higher fabric performance. Where the advantages show up For designs where routing and timing closure dominate, such as deeply pipelined processor and error-correction workloads, Agilex 5 E-Series benefits from HyperFlex retiming and register duplication. These capabilities help break up long interconnect paths, reduce critical path depth, and sustain fMAX as replicated design instances push utilization higher. For arithmetic-heavy workloads, such as trigonometric, DSP, and iterative compute kernels, Agilex 5 adaptive logic modules help pack arithmetic more locally and efficiently. Better local packing can reduce routing overhead, which becomes increasingly important as dense compute designs scale across the device. For memory-sensitive and resource-constrained workloads, including video, security, and embedded compute designs, embedded memory and logic packing become key limiters. Agilex 5 E-SeriesM20K resources and efficient ALM utilization help preserve usable logic capacity and timing margin when competing implementations may need more LUT-based memory or additional routing resources. For designs where implementation efficiency depends heavily on the tool flow, Quartus Prime advanced synthesis and physical synthesis add another part of the formula. The software can co-optimize logic, placement, and routing, helping improve utilization and power efficiency without requiring RTL changes. The proof, and what it means The published white paper provides the detailed benchmark data, but several results stand out because they connect directly to real design challenges: 22% higher geometric mean performance at high-utilization operating points. This matters because FPGA designs often become harder to close as utilization rises. Higher performance under those conditions points to better timing behavior when routing pressure, placement density, and resource contention increase. More stable achievable fMAX as utilization increases. The paper shows less frequency degradation for Agilex 5 E-Series as benchmark instances are stamped across the device. For designers, that means more predictable timing closure as the design approaches fuller device usage. 47% lower total power at iso-frequency and iso-workload conditions. This result isolates power at equivalent workload and clock frequency, showing that Agilex 5 E-Series can do the same work with significantly lower total device power in the evaluated designs. Up to 2.83x greater energy efficiency in individual workloads. This shows that the advantage is not only about reducing watts. It also reflects better work-per-watt behavior, which can help improve thermal margin, power budgets, and system-level efficiency. 17% higher effective device capacity. In this context, effective capacity reflects the amount of design logic that can be implemented while still meeting timing constraints Read the full white paper This blog highlights the key findings, but the full whitepaper provides detailed benchmark data, workload-by-workload analysis, methodology transparency, and architectural insights across all twelve OpenCores designs. Read the whitepaper to understand how Agilex 5 E devices and Quartus Prime software delivered higher performance, lower power, and greater effective design capacity across a diverse set of real FPGA workloads. Altera Delivers Superior Performance, Power, and Logic Packing with Quartus® and Agilex® 5 FPGAs Versus AMD Kintex™ Ultrascale+
3 days ago0likes
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.
1 month ago0likes