tennm_mac in m18x18_sumof2 mode on Agilex 7 - spurious systolic register inserted in Quartus 25.3
Device: Intel Agilex 7 Quartus version: Quartus Prime Version 25.3.0 Build 109 09/24/2025 SC Pro Edition Atom: tennm_mac Mode: m18x18_sumof2 with pre-adder (operand_source_may = "preadder") Description I am directly instantiating tennm_mac atoms in m18x18_sumof2 mode for a high-throughput multiplications. The design uses the pre-adder on both multipliers (az/bz ports) and has all four pipeline stages enabled (ax_clken, input_pipeline_clken, second_pipeline_clken, output_clken all set to "0"). I observe incorrect result at the output of the multiplier. Inspecting the Resource Property Viewer confirms that systolic registers have been placed on the A* path inside the DSP block, even though: input_systolic_clken is explicitly set to "no_reg" Systolic mode is not selected — the operation mode is m18x18_sumof2 The systolic register is architecturally present only on the A* datapath; the B* datapath has no equivalent register, so the skew is asymmetric by design. The result is incorrect sum of multiplies output on hardware - the coefficient and data samples presented to the multiplier are misaligned by one clock cycle. Minimal defparam set that reproduces the issue: tennm_mac u_mac ( .ax(ax), .ay(ay), .az(az), .bx(bx), .by(by), .bz(bz), .clk(clk), .ena(3'b111), .clr(2'b00), .resulta(result) ); defparam u_mac.operation_mode = "m18x18_sumof2", u_mac.operand_source_may = "preadder", u_mac.operand_source_mby = "preadder", u_mac.ax_clken = "0", u_mac.bx_clken = "0", u_mac.ay_scan_in_clken = "0", u_mac.by_clken = "0", u_mac.az_clken = "0", u_mac.bz_clken = "0", u_mac.input_pipeline_clken = "0", u_mac.second_pipeline_clken = "0", u_mac.output_clken = "0", u_mac.input_systolic_clken = "no_reg", // <-- ignored u_mac.clear_type = "none"; Questions Are my assumptions that systolic registers are placed incorrectly correct? Is this a known issue in Quartus 25.3 / with Agilex 7 devices? Similar design compiled correctly on Quartus 17.1 for Arria 10. Any guidance to resolve this issue would be appreciated.
Connecting 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!
Constraints not being picked for DCFIFO
Hi, I am having various DCFIFOs in my design. I have applied constraints according to the ug_fifo. Attaching link for the reference https://faculty-web.msoe.edu/johnsontimoj/EE3921/files3921/ug_fifo.pdf In the DRC report, I am getting a violation of CDC-50007 which shows CDC bus with insufficient constraints and it is showing set_max_skew and set_data_delay are violated. This issue is not coming up for all the DCFIFOs in the design. The violations are there in the path of the delayed_wrptr_g[*] to rs_dgwp|dffpipe*|dffe and rdptr[*] to ws_dgrp[*] |dffpipe*|dffe. In the same DCFIFO, violation is coming only on either wr_ptr or rd_ptr. Could you suggest why this constraint is not being picked in some selected FIFOs and only in either wr / rd paths? set_data_delay is not prescribed as per the ug_fifo.Accessing registers in the PCIE IP beyond MCDMA using system console
Hi, I have compiled the MCDMA IP (R-Tile based) in EP mode. I have a custom controller IP interfaced with MCDMA IP. There is a CSR Lite Interface on the port list which is a master interface. I have a JTAG to Avalon master bridge through which I want to access the registers in the MCDMA as well as the controller beyond the MCDMA. As JTAG is a master interface and the CSR Lite is also a master interface, they can't be interfaced together. Please suggest how can I interface the JTAG master so that I can access the registers inside the controller as well as MCDMA IP. Also is there any way to access the registers inside MCDMA IP without using JTAG to Avalon master bridge?ALT PLL GUI MESSDED UP ON INVOCATION
Hi All ALTERA Experts, I have a problem setting up a new PLL due to the GUI looking like the mess you can see in my attached screenshot. I am using Quartus Standard edition Version 25.1 I am on a windows 10 machine and all of the other IP GUIs seem to work fine, its just this PLL IP GUI that seems to get messed up. I am using a MAX10 FPGA. Both my PC and Graphics card are working fine. Can anybody suggest why this occurs ? Thanks, BarryCan't find Agilex 7 M I/O PLL Reconfiguration Design Example
Hi, Recently updated document "Agilex™ 7 Clocking and PLL User Guide M-Series", 769001 2025.10.09 refers to a design example which uses an EMIF Calibration IP for I/O PLL reconfiguration: 6.1.7. Design Example for I/O PLL Reconfiguration I can't find this design on Intel or Altera sites. Can anyone please tell if it exists. I can find very similar Agilex 7 PLL reconfig examples but they use different calibration IP, not usable with Agilex 7M devices. I'm trying to utilize IOPLL's dynamic output phase adjustment only. This was easy with earlier generation devices as the I/O PLL provided a specific control interface for this purpose. Phase shift control port or something similar. Thanks, Ju-ti
MSGDMA: Is Linux Driver Mandatory? Using devmem2 & F2SDRAM Bridge
Hello everyone, I am currently working on an MSGDMA implementation. I have verified that I can read the MSGDMA CSR and Descriptor registers via the LWH2F bridge using devmem2. My setup is configured in Streaming-to-Memory-Mapped (ST-to-MM) mode. I have two specific questions regarding this setup: 1、Is configuring the MSGDMA Linux kernel driver a mandatory condition for the hardware to function correctly? Is it possible to bypass the driver and configure the MSGDMA to start data transfer directly using devmem2 (user-space access)? 2、I noticed that some implementations write to the PS-side memory via the FPGA-to-HPS bridge. However, my design utilizes the F2SDRAM link, as indicated by the numbered sequence in the attached diagram. Could you please confirm if this architectural approach is feasible?
Memory Mapped Interconnect Reset Net Polarity Conflict
I have developed a simple client Avalon Memory Mapped Interface custom IP block. The MM interconnect block automatically generated a width adapter component that is causing an LNT-30023 - Reset Nets with Polarity Conflict DRC. It is not affecting the functionality of my custom MM block, but I am still interested in understanding the root cause of this issue. Details to follow, thank you in advance for any help. Custom Avalon Memory Mapped Interface consists of the following signals: clk reset_n [7:0] writedata write [7:0] address Various conduit signals The master is the JTAG to Avalon Master Bridge which defaults to have 32bit address and writedata signals. For this configuration a merlin width adapter is automatically generated in the mm_interconnect block of the platform system designer. Both the custom IP block and the JTAG to Avalon Master Bridge are connected to an low-assert (reset_n) Reset Bridge IP Block. The custom IP block is configured to be an low-assert reset. I was under the impression all generated MM interconnect IP would inherit the low-assert reset. Instead my Design Assistant Summary declares the following DRC error: LNT-30023 - Reset Nets with Polarity Conflict. The detailed description is as follows, where <my_block> is a placeholder for my custom block name: Driver: u0|mm_interconnect_0|<my_block>_avalon_slave_0_cmd_width_adapter|use_reg Non-inverted signal: u0|mm_interconnect_0|<my_block>_avalon_slave_0_cmd_width_adapter|data_reg[16]|SCLR Inverted Signal: u0|mm_interconnect_0|<my_block>_avalon_slave_0_cmd_width_adapter|address_reg[1]|SCLR
