Recent Content
Perpetual license Quartus II doesn't allow to build Cyclone V devices anymore.
We have been using Quartus II for certain smaller designs on Cyclone V for nearly 15 years now, but now, after re-generating the license again I can now still run Quartus II, but it gives me the error : Error (119013): Current license file does not support the 5CGTFD9E5F31C7 device. I can also still build all my Arria10 designs using Quartus Prime (for which we have separate licenses), so it's not an issue with the license server or license daemon. Can someone help me with this ?141Views0likes22CommentsIntegrating Cocotb to Quartus using Native link
To integrate cocotb to Quartus Prime Native link and Questa, among a few environment variables needed, one has to set the following `vsim` option: `-foreign "cocotb_init $(cocotb-config --lib-name-path fli questa)"` see here: https://docs.cocotb.org/en/stable/custom_flows.html This needs to be actually slightly adapted to questa, and the following option should be used instead: `-foreign \"cocotb_init [exec cocotb-config --lib-name-path fli questa]\"` With all this information in hand, I try to add `questa=-foreign \"cocotb_init [exec cocotb-config --lib-name-path fli questa]\"` in Assignments >> Settings >> EDA Tools Settings >> Simulation Flow Settings >> Simulation Options, and I get the following error in Quartus: Info(125063): set_global_assignment -name EDA_EXTRA_SIM_OPTION "questa=-foreign \\\"cocotb_init [exec cocotb-config --lib-name-path fli questa]\\\"" -section_id eda_simulation Error(125048): Error reading Quartus Prime Settings file /home/msilvaol/LATOME_HLS/firmware/src/latome_fw/s2p_bram/s2p_bram.qsf, line 49 And then when I try to start the simulation, I get the following error: Error(23031): Evaluation of Tcl script /home/sw/intel/25.3/quartus/common/tcl/internal/nativelink/qnativesim.tcl unsuccessful The workaround I have at the moment is to do the following: I set Assignments >> Settings >> EDA Tools Settings >> Simulation Flow Settings >> Simulation Options to `questa=COCOTB_CFG` Then, I start the simulation that fails because COCOTB_CFG is not a valid vsim option. I open the file `./simulation/questa/rtlsim/s2p_bram_run_msim_rtl_vhdl.do`, and I replace the line 42 from: ` eval "vsim -t 1ps $pd_libs -L work -L rtl_work -voptargs=\"+acc\" COCOTB_CFG $ELAB_OPTIONS $DPI_LIBRARIES_ELAB s2p_bram_showahead" ` to the actual option that I tried to set in Quartus Prime, as follows: eval "vsim -t 1ps $pd_libs -L work -L rtl_work -voptargs=\"+acc\" -foreign \"cocotb_init [exec cocotb-config --lib-name-path fli questa]\" $ELAB_OPTIONS $DPI_LIBRARIES_ELAB s2p_bram_showahead" Then, I run the .do script again in questa and the simulation with cocotb works using Quartus Prime as the build flow. However, every time the simulation is started again from Quartus Prime, the generated scripts are overwritten, and I have to edit the automatically generated file again. It seems Quartus is parsing the simulation option and adding escape characters in a way that the automatically generated TCL code no longer works. Can you please point out a way that I can set the simulation option correctly?12Views0likes0CommentsBackplane Ethernet 10GBASE-KR PHY FPGA IP
I would like to know more information about the Intel\Altera Backplane Ethernet 10GBASE-KR PHY FPGA IP . Can it be implemented in the Agilex 5 FPGA ? If not are there any plans to incorporate it there and what would be the time frame ? Also what type of license is offered. I tried the site contact :- https://www.altera.com/products/ip/po-3078/backplane-ethernet-10gbase-kr-phy-fpga-ip twice but I got no response ???4Views0likes0CommentsQSPI DDR Interface with Cyclone10LP: Maximum frequency
Hello, We are planning to implement a QSPI interface between Altera Cyclone10LP (10CL025YU256A7G) and a microcontroller iMXRT1180. The microcontroller is capable of a maximum frequency of 166 MHz (which would mean 332MHz DDR) on the QSPI interface. We want to know which would be the maximum frequency we are able to achieve on the FPGA for this interface. We have this information extracted from the datasheet: "I/Os using general-purpose I/O standards such as 3.3-, 3.0-, 2.5-, 1.8-, or 1.5-LVTTL/LVCMOS are capable of a typical 200 MHz interfacing frequency with a 10 pF load." Does this mean the pins will not be able to accept data changing at a rate faster than 200 MHz or will it be possible to have something like a fHSCLK of 200 MHz (which would mean double device operation in Mbps) as we can see in Table 24 (example for RSDS Transmitter) on the datasheet? Are there any special pins on the FPGA which we can use to achieve maximum potential on this interface? Or any strategies like using IDDR/ODDR modules that could help? Any suggestions are welcome. Thank you!58Views0likes6CommentsCan not program Agilex-5 device
Quartus programmer stops at 44% with error: Error(18950): Device has stopped receiving configuration data Error(18948): Error message received from device: Bitstream error. (Subcode 0x0093, Info 0x00000003, Location 0x00000800) Error(18948): Error message received from device: Device specification (SKU ID) of the target device used in bitstream generation does not match physical device. Error(23925): Debug suggestion: Verify that the device OPN selected in Quartus Prime matches exactly with the OPN of your hardware device. Error(209012): Operation failed What can be the cause, the device is selected correctly.Solved41Views0likes3CommentsConnecting Intel Agilex FPGA to DE1-SoC via Hub
Hello, I have an Intel Agilex FPGA with QSFP-DD 10 GbE PHY, a DE1-SoC board with 1 GbE PHY, and an Ethernet Hub 1 GbE. I want to connect the Agilex to the DE1-SoC through this hub. I understand the DE1-SoC only supports 1 GbE while the Agilex PHY is capable of 10 GbE. I would like to know the best way to communicate between these boards. Is it possible to configure the Agilex Ethernet IP and PHY to 1 GbE so it can communicate directly through the hub without a physical adapter? If not, would a media converter or adapter be needed to downspeed from 10 GbE to 1 GbE? Are there any recommended best practices for connecting an Agilex to a slower device like the DE1-SoC via Ethernet? Any guidance or experience would be greatly appreciated. Thank you!4Views0likes0CommentsLPDDR5 single VDD2 rail mode - why is it not supported?
A knowledge base article was published on Jan 30,2026 that says Agilex-5 EMIF does not support single-rail VDD2 for LPDDR5. Can you provide more information about this restriction? The choice between single-rail and dual-rail VDD2 configuration should be dependent on whether the application is using DVFS - Dynamic Voltage and Frequency Scaling. DVFS is a low-power mode which can be selected when the data rate is 1600 Mb/s or less. The memory controller sends a mode register command to the memory to transition to DVFS mode. When that happens, the memory IC will switch the power source for the internal circuitry from the VDD2H (1.05V) pins to the VDD2L (0.9V) pins. So, when DVFS mode is active, the internal circuitry is operating at 0.9V, and the data rate is lower, so there is a power savings. If the application has no use for the lower power mode, DVFS is not required. In that case, the VDD2L pins can be connected to 1.05V and the result is 'single-rail VDD2 mode'. The memory controller will know that DVFSC mode is not required, so it will never activate it. My design has no use for DVFS mode and the power savings it provides is not worth it for my design. Therefore, I have implemented single-rail VDD2 mode in my Agilex-5 design, using A5EC043AB32AE2V. This means VDD2H and VDD2L are both powered at 1.05V. This conflicts with the knowledge base article which says that my design must implement dual-rail VDD2 mode. Can you tell me the restriction in the memory controller which forces the use of dual-rail VDD2 mode, even though I don't want it? Is Altera saying that the memory controller has enabled DVFS mode internally and there is no way to disable that mode? My design is in layout and will be released to manufacturing soon. If I have to add a 0.9V regulator for dual-VDD2 mode, I need to act now to change the design. I would prefer to continue using single-rail mode if possible. If I absolutely must use dual-rail mode, do you know if the LPDDR5 will be OK if VDD2L is 1.05V instead of 0.9V? I realize there will be no power savings in this case, but I don't care about that.11Views0likes0CommentsAgilex5 HPS running bare-metal code does not access FPGA fabric
I started with the following "Hello World" HPS OCRAM example: https://altera-fpga.github.io/rel-25.1/baremetal-embedded/agilex-5/e-series/premium/ug-baremetal-agx5e-premium/ I built the GHRD image with FPGA boot load set to "fabric first" and compiled the C code. With these changes, I am able to run the code and I can see the heartbeat LED toggle on the A5E premium development kit board. I am also able transmit data by writing the UART transmit register with my REG32 macro. However, I cannot access either H2F or LWH2F interfaces. I put Signal Tap on all arvalid/awvalid signals I and I do not see them toggle (I sanity checked the setup using the heartbeat counter). After looking at the documentation and the provided bare-metal drivers code, I cobbled together the following code to attempt to enable the HPS2 FPGA bridges: #define REG32(address) (*(volatile uint32_t*)address) #define REG64(address) (*(volatile uint64_t*)address) // Read the Reset manager registers uint32_t value32; value32 = REG32(0x10D1102C); printf("Reset manager initial value = 0x%08x \n", value32); // Drop the reset for SOC2FPGA bridges REG32(0x10D1102C) = 0; value32 = REG32(0x10D1102C); printf("Reset manager value after modification = 0x%08x \n", value32); printf("Enable FPGA bridges (NOTE: is this really an enable?)\n"); REG32(0x10D1205C) = 0x3; value32 = REG32(0x10D1205C); printf("Bridge enable register value after modification = 0x%08x \n", value32); Running this code I see: Reset manager initial value = 0x0000004f Reset manager value after modification = 0x00000000 Enable FPGA bridges Bridge enable register value after modification = 0x00000003 However, this loop does not show AWVALID come up on either AXI interface (I tried two different write macros to see if there is a difference): while (1) { printf("H2F: FPGA OCRAM write\n"); REG64(0x40000000) = 0x11223344; printf("H2LWF: LED controller write\n"); mem_quick_write_32(0x20010080, 0); } I feel like I am missing something obvious (like another enable) but I keep going over the code examples and the documentation and I can't find anything that could help. Any help is greatly appreciated.107Views0likes11CommentsAgilex-5: WCK to CK Ratio for LPDDR5
In general, LPDDR5 memory devices support two ratios for the WCK to CK clocks: 4:1 and 2:1. The Micron datasheets refer to this ratio as 'CKR'. From the perspective of the memory datasheet, there is apparent freedom to select one ratio or the other, although there is a requirement to be in 2:1 mode during the 'WCK2CK Leveling Procedure'. The ratio can be changed on the fly. The Altera EMIF seems to be enforcing a 2:1 ratio, and it seems like there is no option to select a 4:1 ratio. Do you know if the CKR can be changed in the EMIF configuration, or is this hard-coded to be 2:1?5Views0likes0Comments
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,294 Topics
- fpga dev tools quartus® prime software pro4,175 Topics
- FPGA Dev Tools Quartus II Software3,159 Topics
- stratix® 10 fpgas and socs1,522 Topics
- agilex™ 7 fpgas and socs1,387 Topics
- arria® 10 fpgas and socs1,341 Topics
- stratix® v fpgas1,310 Topics
- arria® v fpgas and socs1,222 Topics
- cyclone® v fpgas and socs1,049 Topics
- Configuration950 Topics
Recent Blogs
As the industry accelerates its transition from DDR4 to DDR5 and LPDDR5, memory choices are becoming a defining factor in system longevity, performance, and supply continuity. Altera is uniquely positioned to help customers navigate this shift with production-ready DDR5 and LPDDR5 solutions available today across a broad FPGA portfolio. DDR5 Is the New Standard Major memory vendors have announced plans for DDR4 end-of-life plans or significant production reductions, with full transitions to DDR5, LPDDR5, and next-generation memory already underway. While DDR4 will remain available for long lifecycle segments through multiple suppliers, new design starts today are increasingly looking to DDR5 and LPDDR5. Altera’s Head Start in DDR5 and LPDDR5 While DDR5 and LPDDR5 support is emerging across the industry, Altera stands apart with the broadest set of production devices supporting these standards across high-performance, mid-range, and power-optimized platforms: Agilex™ 7 M-Series and Agilex™ 5 devices support DDR5 and LPDDR5 for high-performance and embedded applications Altera is also planning to add LPDDR5 support within Agilex™ 3 devices, reinforcing its long-term design scalability. Competitive Advantage Across Every Market Tier Altera’s memory leadership spans across a range of design requirements: - High-Performance designs: Agilex™ 7 AGM032 and AGM039 support: DDR5 up to 5,600 MT/s LPDDR5 up to 5,500 MT/s - Mid-Range designs: Agilex™ 5 D-Series support: DDR5 up to 5,600 MT/s LPDDR5 up to 5,500 MT/s - Power/Cost-optimized designs: Agilex™ 3 support: LPDDR5 up to 2133 MT/s Unlike FPGA-only devices, Agilex integrates an optional HPS that allows DDR5 and LPDDR5 to function as a shared memory resource for both processing and acceleration, delivering higher effective bandwidth and system efficiency. Key Takeaway With DDR5 and LPDDR5 moving from ‘next-generation’ to ‘now,’ Altera offers customers a clear advantage: production-ready memory leadership, a broad and scalable FPGA portfolio, and a smooth transition path from DDR4 to DDR5—without waiting for future silicon. Download the The Agilex™ 5 SoC Memory Advantage with DDR5 and LPDDR5 White Paper
1 day ago0likes
Using FPGAs and MCUs Collaboratively FPGAs and microcontrollers can be used alternatively in some applications, but they can also be used cooperatively. FPGAs provide ultimate flexibility, but microcontrollers often include peripherals like USB or wireless interfaces that may be more convenient for communications and updates. Both devices require supporting circuitry such as power, reference clocks, and storage. Fortunately, these can often be shared when using FPGAs and microcontrollers together. This blog introduces an open-source tool that enables microcontrollers to load a programming file into a programmable device, and the practical application of this with the Raspberry Pi RP2350 MCU. An Open Standard for Loading Programmable Devices Loading programmable devices from embedded processors is a common task. The Jam Standard Test and Programming Language (STAPL) was originally developed by Altera engineers to address challenges in programming programmable logic devices (PLDs) in-system, such as proprietary file formats, vendor-specific algorithms, large file sizes, and long programming times. It provides a software-level standard for in-system programming (ISP), enabling flexibility and platform independence. Figure 1. In-system programming using the Jam File & Jam Player via an embedded processor. In August 1999, JAM/STAPL was adopted as JEDEC standard JESD-71, making it an industry-recognized solution for JTAG-based programming. The language introduced features like compact file formats, branching, and looping, which reduced programming time and file size—ideal for embedded systems. JAM/STAPL consists of two main components: Jam Composer: Generates Jam Files (.jam) containing programming algorithms and user data. Jam Player: Interprets these files and applies JTAG vectors for programming and testing devices. Over time, JAM/STAPL gained widespread support from PLD vendors, programming equipment makers, and test equipment manufacturers, becoming a cornerstone for in-field upgrades, prototyping, and production programming. Its evolution also included a byte-code format (.jbc) for even smaller files, making it suitable for resource-constrained embedded processors. Recently, Altera updated the license terms of the JAM and JBC players source code to MIT-0, to better clarify the usage rights. A Practical Example The CycloMod board is an example of an FPGA and microcontroller working cooperatively. The board combines a Raspberry Pi RP2350 MCU with a Cyclone® 10 LP FPGA in the SparkFun MicroMod form factor. In this board, the FPGA is connected to some of the edge connector I/O, while the RP2350 is used to provide a flexible USB interface. The boot ROM in the RP2350 is leveraged extensively for firmware and FPGA image updates. Figure 2. CycloMod Board At 22mm x 22mm (including the card-edge connector), the MicroMod form factor is quite compact. This necessitates sharing resources, as there is not much room for multiple oscillators or flash devices. The 12 MHz crystal oscillator in the RP2350 is easily shared by routing it to one of the GPIO clock outputs. Both the Cyclone 10 LP device and RP2350 rely on external storage, but this can also be shared. On this board, the flash is connected to the RP2350 to take advantage of the UF2 loading provided in the boot ROM, and the RP2350 loads the Cyclone FPGA. The Cyclone 10 LP device supports active configuration with an external SPI flash device, but it can also be configured/programmed passively through JTAG. Figure 3. CycloMod Block Diagram The STAPL byte code format (sometimes referred to as JBC) is compact enough to be used with microcontrollers like the RP2350. Altera provides source code for implementing the “players” to process these files in embedded systems. They offer players for the ASCII (JAM) and bytecode (JBC) versions of the files. Altera’s Quartus® software provides the option to generate JAM and JBC files. Since STAPL is a JEDEC standard, other FPGA vendors also support generating these files. Using the open-source code provided by Altera, the RP2350 is able to read a JBC file from flash and load the Cyclone 10 LP FPGA through the JTAG interface. A Python script is provided to convert the JBC files to the UF2 format, which the RP2350 uses for drag-n-drop programming. The script also adds a header with the file length and other details. Thanks to the ingenuity of the UF2 format created by Microsoft, this enables cross platform field updates with zero software to install. Results and Link to Source Porting Altera’s JBC player to the RP2350 eliminated the need for a second flash device and enabled user-friendly drag-n-drop FPGA updates. The port is available on GitHub if you want to use this in your system. https://github.com/steieio/pico-jbc
2 months ago0likes
The expanded Agilex™ 5 D-Series FPGA and SoC family delivers a big leap in capabilities for mid-range FPGA applications, offering up to 2.5× more logic, memory, DSP/AI compute, and up to 2× external memory bandwidth. These enhancements make it ideal for designs that demand high compute performance in power and space-constrained environments.
2 months ago1like
We’re gearing up for AOC 2025! From December 9–11, we’ll be at the Gaylord National Resort & Convention Center in National Harbor, Maryland for AOC2025—one of North America’s premier events dedicated to electronic warfare and radar. Visit us at booth #505 to discover the latest innovations in our Agilex™ 9 Direct RF and Agilex™ 5 product families. What to Expect at Altera’s Booth #505: 1. Wideband and Agility Demo using Agilex 9: Overview: Discover the power of frequency hopping with Altera’s Direct RF FPGA, enhancing system resilience and adaptability. Key Features: Demonstrates swift frequency changes and wideband monitoring. 2. Wideband Channelizer Demo using Agilex 9: Overview: Wideband Channelizer features polyphase filter and 65 phases FFT blocks with variable channel support. Key Features: Demonstrates sampling rate that supports 64 GSPS with 32GHz instantaneous bandwidth. 3. Direction of Arrival Demo using Agilex 5: Overview: Explore Direction of Arriaval estimation and signal detection using AI-based approach with deployment of neural networks. Key Features: Demonstrates neural networks implementation using DSP Builder Advanced Blockset (DSPBA), showcasing end-to-end operation running real time inference. 4. Altera COTS Partner Showcase: Come see our Agilex based COTS boards from partners including Annapolis Microsystems, CAES, Hitek, iWave Global, Mercury Systems, & Spectrum Controls. We are hosting customer meetings at the event, contact your local Altera salesperson to schedule a slot.
2 months ago0likes
5 MIN READ
The computing world is hitting a wall. As AI models grow to trillions of parameters, as in-line databases scale to massive sizes, and as high-performance computing (HPC) workloads push bandwidth and memory to their limits, the need for more efficient data movement has never been greater. Traditional approaches to scaling bandwidth and capacity can’t keep pace without unsustainable cost expenditures on power usage and infrastructure build-out. Compression offers a practical and elegant solution to this challenge. By reducing the size of data that moves across interconnects, we can stretch bandwidth, improve memory efficiency, and lower system power—all without requiring a fundamental re-architecture. The Open Compute Project (OCP) has recently recognized this reality, highlighting compression as a key enabler for modern workloads. The combination of ZeroPoint Technologies (an Altera Partner), advanced compression IP, and Altera’s CXL Type 3 IP and FPGAs results in a 2–3x increase in bandwidth, giving the industry a proven path to meet the growing demand head-on. The Problem: Data Bottlenecks in Today’s Workloads AI and LLMs Large language models are exploding in size—parameters have grown from millions to billions, and now to trillions, in just a few short years. Training and inference of these models are fundamentally constrained by memory bandwidth and capacity. Without compression, these models would require even larger amounts of data movement, which increases latency, power consumption, and cost. In-line Databases Databases are increasingly run in-line with applications, from analytics pipelines to transaction processing. These in-line databases demand high throughput and low-latency access to massive datasets. Without compression, systems are forced to overprovision bandwidth and memory resources, dramatically increasing the total cost of ownership (TCO). High-Performance Computing (HPC) From climate modeling to genomics, HPC workloads require immense amounts of parallel data movement. Without compression, HPC centers must continue scaling raw interconnect bandwidth, which is unsustainable in terms of energy and cost at exascale levels. CXL Expansion (CXL Device Type 3) CXL (Compute Express Link) has emerged as the industry-standard protocol for memory pooling and expansion. Yet, as more systems adopt CXL for disaggregated memory, the sheer volume of data moving across CXL links risks overwhelming interconnect bandwidth. Without compression, the benefits of CXL expansion hit a hard ceiling. Demo Video: ZeroPoint demonstrates 2–3x increased bandwidth using its CXL compressed memory tier solution at the Future of Memory and Storage (FMS) 2025 CXL Acceleration (CXL Device Type 2) Beyond memory expansion, CXL enables accelerators to share memory seamlessly with CPUs. But in accelerator-heavy environments, data transfer volumes explode. Lack of compression makes accelerator scaling inefficient, power-hungry, and cost-prohibitive. Contact Altera to see the demo video: 2x–6x higher QPS running a VectorDB workload using a CXL 2.0 interface. Without compression, every one of these workloads faces a bottleneck that would be extremely difficult to solve with hardware scaling alone. OCP Introduces Compression into its Specification The Open Compute Project (OCP) organization recently underscored the importance of compression by including it in its specifications. This is a landmark shift: compression is no longer viewed as optional but included as a supported feature for next-generation compute infrastructure. James Kelly, VP Market Intelligence and Innovation at the OCP Foundation, said: “Within the OCP Community, our Composable Memory Systems Project, leveraging CXL and compression technologies, is driving the development of interoperable, scalable memory architectures that empower AI workloads with unprecedented efficiency and flexibility. By enabling disaggregated memory resources to be pooled and allocated across heterogeneous systems, we’re directly supporting OCP’s Open System for AI strategic initiative, fostering open specifications and standards that accelerate innovation and accessibility in AI infrastructure.” Klas Moreau, CEO of ZeroPoint Technologies, added: “What excites us about working with Altera’s CXL Type 3 IP is not just its performance, but its flexibility. Unlike other FPGA providers, Altera’s CXL solution gives us the low-latency, high-bandwidth fabric we need to showcase the full potential of our compression IP. Together, we’re able to deliver measurable gains—up to a 2–3x effective bandwidth increase—without changing the underlying hardware footprint. That’s a game-changer for customers scaling AI, HPC, and database workloads.” The Solution: ZeroPoint Compression IP + Altera CXL Type 3 IP and FPGA-based Boards ZeroPoint Compression Technology ZeroPoint brings a powerful, low-latency, hardware-efficient compression engine designed specifically for memory and interconnect applications. Unlike general-purpose compression algorithms, ZeroPoint’s IP is optimized for inline operation at wire speed, ensuring data is compressed and decompressed seamlessly without introducing overhead. Key benefits include: High compression ratios across AI, HPC, and database workloads Ultra-low latency to avoid bottlenecks on memory paths Energy savings by reducing data movement requirements Proven scalability across CXL and memory expansion use cases Altera CXL Type 3 IP Altera’s CXL Type 3 IP provides the foundation for memory expansion and pooling. It enables compute nodes to access disaggregated memory resources efficiently and securely. By integrating ZeroPoint’s compression IP, Altera’s solution extends even further—allowing CXL links to move more effective bandwidth, reduce congestion, and scale system capacity without increasing physical resources. There is a wide variety of CXL-capable FPGA-based boards available from Altera or partners. Together: Meeting the Market Need When combined, ZeroPoint’s compression IP and Altera’s CXL Type 3 IP address the OCP-driven specification requirements and solve the core problem facing data-intensive applications, ranging from AI to databases: moving massive amounts of data efficiently. Benefits to customers include: More bandwidth without more lanes: Compression effectively multiplies CXL throughput. Boost performance, cut costs: Unleash untapped performance in your current infrastructure with minimal new investment. Future-proof compliance: Alignment with OCP specifications ensures long-term viability. This combination delivers not just a technology improvement, but a market-ready solution that meets both current and emerging requirements. Conclusion The computing industry is shifting to adjust to new demands. AI, HPC, databases, and disaggregated systems are demanding exponential growth in bandwidth and memory efficiency—growth that hardware scaling alone cannot deliver. One answer is compression. OCP’s inclusion of compression in its specifications validates this direction and creates a mandate for solutions that integrate compression seamlessly with interconnect technologies like CXL. Through the combination of ZeroPoint’s cutting-edge compression IP and Altera’s CXL Type 3 IP, customers can now confidently deploy systems that are not only faster and more efficient but also aligned with the industry’s forward-looking standards. The future of computing depends on smarter ways to move and manage data. Compression + CXL is that smarter way—and with ZeroPoint and Altera, the future is already here. Learn More Presentations or videos are available for on-demand viewing or download: FMS 2025 session (video | slides) OCP 2025 session (video | slides) Next Steps Learn more about Altera’s CXL IP core. For technical details, partnership discussions, or general inquiries, please contact: nilesh.shah@zptcorp.com — CXL compression solutions phillip.swart@altera.com — FPGA-based CXL IP and boards
3 months ago0likes