Why output register cannot be enabled when inferred RAM depth is larger than 2048?
Description Due to limitation with the Quartus® Prime Pro Edition software, the output register in M20K cannot be enabled when inferred RAM depth is large than 2048. Resolution To work around this problem in the Quartus Prime Pro Edition software, use the template below to enable output register for inferred RAM. module ram_template #( parameter DATA_WIDTH=8, parameter ADDR_WIDTH=12, parameter SPLIT_RAM_INTO_SUB_BLOCKS=1 ) ( input [(DATA_WIDTH-1):0] data, input [(ADDR_WIDTH-1):0] read_addr, write_addr, input we, read_clock, write_clock, output reg [(DATA_WIDTH-1):0] q ); localparam MAX_ADDR_BITS = 11; localparam SPLIT_RAM = (ADDR_WIDTH > MAX_ADDR_BITS) ? SPLIT_RAM_INTO_SUB_BLOCKS : 0; localparam SPLIT_ADDR_BITS = SPLIT_RAM ? (ADDR_WIDTH - MAX_ADDR_BITS) : 1; localparam NUM_RAM_SUB_BLOCKS = SPLIT_RAM ? (1 << SPLIT_ADDR_BITS) : 1; wire [(DATA_WIDTH-1):0] ram_out; reg [(SPLIT_ADDR_BITS-1):0] read_addr_reg0, read_addr_reg1; wire [(NUM_RAM_SUB_BLOCKS-1):0][(DATA_WIDTH-1):0] ram_out_channels; wire [(NUM_RAM_SUB_BLOCKS-1):0] we_channels; genvar i; generate if (SPLIT_RAM) begin always @(posedge read_clock) begin read_addr_reg0 <= read_addr[(ADDR_WIDTH-1):(ADDR_WIDTH-SPLIT_ADDR_BITS)]; read_addr_reg1 <= read_addr_reg0; end for (i=0; i<NUM_RAM_SUB_BLOCKS; i=i+1) begin : SUB_RAM_BLOCKS ram_template_sub_ram_block #( .DATA_WIDTH(DATA_WIDTH), .ADDR_WIDTH(MAX_ADDR_BITS) ) sub_ram_block ( .data(data), .read_addr(read_addr[MAX_ADDR_BITS-1:0]), .write_addr(write_addr[MAX_ADDR_BITS-1:0]), .we(we_channels[i]), .read_clock(read_clock), .write_clock(write_clock), .q(ram_out_channels[i]) ); end assign we_channels = {NUM_RAM_SUB_BLOCKS{we}} & (1 << write_addr[(ADDR_WIDTH-1):(ADDR_WIDTH-SPLIT_ADDR_BITS)]); assign ram_out = ram_out_channels[read_addr_reg0]; end else begin ram_template_sub_ram_block #( .DATA_WIDTH(DATA_WIDTH), .ADDR_WIDTH(ADDR_WIDTH) ) sub_ram_block ( .data(data), .read_addr(read_addr), .write_addr(write_addr), .we(we), .read_clock(read_clock), .write_clock(write_clock), .q(ram_out) ); end endgenerate always @(posedge read_clock) begin q <= ram_out; end endmodule module ram_template_sub_ram_block #( parameter DATA_WIDTH=8, parameter ADDR_WIDTH=12 ) ( input [(DATA_WIDTH-1):0] data, input [(ADDR_WIDTH-1):0] read_addr, write_addr, input we, read_clock, write_clock, output reg [(DATA_WIDTH-1):0] q ); reg [(ADDR_WIDTH-1):0] read_addr_reg; // Declare the RAM variable reg [DATA_WIDTH-1:0] ram[2**ADDR_WIDTH-1:0]; always @ (posedge write_clock) begin // Write if (we) ram[write_addr] <= data; end always @ (posedge read_clock) begin // Read read_addr_reg <= read_addr; q <= ram[read_addr_reg]; end endmoduleWhy does the dynamic reconfiguration simulation of Phylite IP design fail in the Questa* – Altera® FPGA Edition ?
Description Due to a problem in the External Memory Interfaces (EMIF) IP, simulation running in the Questa* – Altera® FPGA Edition might fail when you set the use dynamic reconfiguration on Agilex® 7M R0 devices. Resolution To work around this problem, change the device selection to a non-R0 OPN during simulation.Why does the High Bandwidth Memory (HBM2E) Interface Agilex® 7 IP fail generation after disabling Reserve Channel 2 and Channel 3 for HPS boot from HBM?
Description Due to a problem in the Quartus® Prime Pro Edition Software version 26.1.1, the High Bandwidth Memory (HBM2E) Interface Agilex® 7 IP Interface IP GUI does not correctly handle the "Reserve Channel 2 and Channel 3 for HPS boot from HBM" option when it is disabled after being enabled. After enabling the option and subsequently unchecking it, the IP may enter an inconsistent configuration state and fail during IP generation. Users may observe interface mismatch errors similar to the following: Error: hbm2e.hbm_fp_0: Interface t_ch2_u0_axi4noc is not the same type as exported interface tniu_ch2_u0.target_inst_0 (should be a hps_axi4noc) Error: hbm2e.hbm_fp_0: Interface t_ch2_u1_axi4noc is not the same type as exported interface tniu_ch2_u1.target_inst_0 (should be a hps_axi4noc) Error: hbm2e.hbm_fp_0: Interface t_ch3_u0_axi4noc is not the same type as exported interface tniu_ch3_u0.target_inst_0 (should be a hps_axi4noc) Error: hbm2e.hbm_fp_0: Interface t_ch3_u1_axi4noc is not the same type as exported interface tniu_ch3_u1.target_inst_0 (should be a hps_axi4noc) Error: hbm2e.hbm_fp_0: Interface t_ch2_ch3_sb_axi4noc tried to export unknown interface tniu_ch2_ch3_sb.target_inst_0 The issue is only observed after toggling the HPS boot from HBM option from enabled to disabled. Resolution As a workaround, if the "Reserve Channel 2 and Channel 3 for HPS boot from HBM" option is enabled by mistake, close and restart the IP Parameter Editor GUI without saving any changes. Reopen the IP and continue the configuration with the desired setting. This problem is scheduled to be resolved in a future release of the Quartus® Prime Pro Edition Software.Why do I see RRESP=2 if ECC is enabled in External Memory Interfaces (EMIF) IP?
Description When ECC is enabled in External Memory Interfaces (EMIF) IP of Agilex® 7 FPGA M-Series, Agilex® 5 FPGA, and Agilex® 3 FPGA devices, you might receive RRESP=2 during data readback if any of the following conditions is true. DDR4 Component: Data size of the first write command to the associated AXI4 address ≠ 256 bits * N DDR5 Component/DDR5 DIMM/LPDDR4/LPDDR5: Data size of the first write command to the associated AXI4 address ≠ (Channel DQ width * 16) * N where N is a positive integer (1, 2, 3, ...). The hard memory controller uses fixed DQ burst length. The above conditions generate partial access to the memory. The uninitialized portion of data in the memory will cause uncorrectable ECC error, leading to RRESP=2. Below are some example scenarios that showcase this RRESP problem. Example #1: When using a x16+ECC DDR4 Component interface in fabric accessing mode, the first write command to an AXI4 address is a partial access with the use of WSTRB. WDATA width = 256 bits, AWLEN = 0, WSTRB = 0x0000FFFF: Data size of the first write command to the associated AXI4 address = 128 bits Example #2: When using a 1chx32 LPDDR5 interface with in-line ECC enabled in fabric accessing mode, the first write command to an AXI4 address has only one WDATA beat. WDATA width = 256 bits, AWLEN = 0: Data size of the first write command to the associated AXI4 address = 256 bits Channel DQ width * 16 = 512 bits Example #3: When using a x32+ECC DDR5 RDIMM interface in 256-bit NoC accessing mode, the first write command to an AXI4 address uses an even number AWLEN value. WDATA width = 256 bits, AWLEN = 2: Data size of the first write command to the associated AXI4 address = 768 bits Channel DQ width * 16 = 512 bits Resolution To work around this problem, ensure the data size of the first write command to the associated AXI4 address equals to either 256 bits * N or (Channel DQ width * 16) * N, depending on the memory protocol. An alternative method is available starting with Quartus® Prime Pro Edition Software version 26.1.1. When IP parameter Initialize Memory in the Advanced Calibration Settings section is enabled, on calibration passing, and before handing off control of the memory to user logic, the memory will be initialized with all zeros in the data section and the corresponding ECC codes in the ECC section. With this approach, there is no special requirement on the data size of the first write command to the associated AXI4 address. Note: To avoid leading to long simulation time, only the first 256 bytes of memory will be initialized in simulation when Initialize Memory is enabled. Additional Information DDR4 DIMM interface and LPDDR5 interface using link ECC are not affected by this RRESP problem.Why does U-Boot initially read incorrect information from the EMIF controller Read-Only registers, but later retrieve the correct information on Agilex® 3, Agilex® 5, and Agilex® 7 FPGA M-Series devices in Quartus® Prime Pro edition software 26.1.1 and earlier?
Description Due to a synchronization issue between U-Boot and the IOSSM firmware, U-Boot may read incorrect values from EMIF controller read-only registers, such as MAILBOX_HEADER and MEM_TOTAL_CAPACITY_INTF. This occurs when U-Boot accesses these registers before the IOSSM firmware has completed their initialization. Once the IOSSM firmware initializes the registers, subsequent reads return the correct values. This issue is observed in Agilex® 3, Agilex® 5, and Agilex® 7 FPGA M-Series devices when using Quartus® Prime Pro Edition Software version 26.1.1 and earlier releases. Resolution A permanent fix is planned for a future release and will include the following enhancements: The IOSSM firmware will set the MB_READY bit (bit 31) in the MAILBOX_HEADER register of the EMIF Controller to 1, indicating that the read-only registers have been fully initialized. U-Boot will poll the MB_READY bit in the MAILBOX_HEADER register and wait for it to be asserted before reading any other read-only registers in the EMIF Controller. This behavior will be enabled only when the CONFIG_IO96B_MB_READY Kconfig option is selected. To maintain compatibility with earlier IOSSM firmware versions that do not support the MB_READY bit, the CONFIG_IO96B_MB_READY option will be disabled by default.Why does the Agilex® 7 FPGA HPS EMIF and fabric EMIF hang after core reconfiguration when both interfaces share the same IO bank in x72 configuration?
Description Due to a problem in the Quartus® Prime Pro Edition Software version 24.2, when Agilex® 7 FPGA F-Series and I-Series HPS EMIF and fabric EMIF share the same IO bank in x72 configuration and the design operates in HPS-first mode, the initial configuration can succeed, but subsequent core reconfigurations can cause the fabric EMIF calibration firmware to hang for designs targeting in Agilex® 7 FPGA F-Series and I-Series devices. The observed failure signature is that, after the FPGA is reconfigured without a full board power cycle, the fabric EMIF no longer responds correctly and the calibration flow does not assert cal_success or cal_fail. Resolution A patch is available to fix this problem for the Quartus® Prime Pro Edition Software version 24.2. Download and install patch 0.70fw below. quartus-24.2-0.70fw-linux.zip quartus-24.2-0.70fw-readme.zip quartus-24.2-0.70fw-windows.zip A patch is available to fix this problem for the Quartus® Prime Pro Edition Software version 25.1.1. Download and install patch 1.54fw below. quartus-25.1.1-1.54fw-linux.zip quartus-25.1.1-1.54fw-readme.zip quartus-25.1.1-1.54fw-windows.zip This problem is resolved in Quartus® Prime Pro Edition Software version 26.1.1.Why does the EMIF and Ethernet IP report hold violations in Timing Analyzer?
Description Due to a problem in the Quartus® Prime Pro Edition Software version 25.1.1 and 24.3, you might see hold timing violations in Timing Analyzer when using the EMIF and Ethernet IPs. This problem only refers to Agilex™ 7 FPGA devices. Resolution This problem has been resolved in Quartus® Prime Pro Edition Software version 25.3.Why does the AXI ready signal assert when EMIF calibration fails in Quartus® Prime Pro Edition 25.1.1?
Description Due to a problem in the Quartus® Prime Pro Edition Software version 25.1.1, the AXI ready signal might assert when EMIF calibration fails for designs targeting Agilex® 5 FPGA E-series devices using the EMIF IP. The AXI ready signal is asserted as expected when calibration passes, but it is also asserted unexpectedly when calibration fails. This behavior can confuse users into thinking the AXI bus is ready to access even though calibration was not successful. Resolution This problem is scheduled to be resolved in a future release of the Quartus® Prime Pro Edition Software.Why does the slew rate value become unset after upgrading External Memory Interfaces (EMIF) IP in Agilex® 7 FPGA F-Series and I-Series devices?
Description Due to a problem in the Quartus® Prime Pro Edition Software version 24.3.1 and earlier, the slew rate values in the FPGA I/O tab of External Memory Interfaces (EMIF) IP might change to unset after upgrading the IP to a newer version. Resolution To work around this problem, follow these steps: Toggle the Use default I/O settings checkbox. Change slew rate to desired settings. This problem is fixed beginning with the Quartus® Prime Pro Edition Software version 25.1.
Error(18090): External memory and PHYLite interfaces must share common clock and reset signals when constrained to the same I/O column
Description The following fitter error may be seen in a project implementing two independent External Memory Interfaces Cyclone®10 DDR3 IP placed in I/O banks in the same I/O column which are sharing a reset signal connected to their global_reset_n ports but not sharing clocks : Error(18090): External memory and PHYLite interfaces must share common clock and reset signals when constrained to the same I/O column. The following conflicting signals were found: Info(18087): Signal: <emif_0_path>|arch|arch_inst|non_hps.core_clks_rsts_inst|global_reset_n_int Info(18087): Signal: <emif_1_path>|arch|arch_inst|non_hps.core_clks_rsts_inst|global_reset_n_int In this configuration, the DDR3 IP global_reset_n ports must be connected to the same reset signal. Note that DDR3 clock sharing (pll reference clock or core clocks) is optional. Resolution To work around this fitter error: Ensure that the Cyclone® 10 DDR3 IP parameter Diagnostics > Example Design > Enable In-System-Sources-and-Probes (ISSP) is not selected. If there is an ISSP assignment in the project .qsf file as shown below, comment it out or delete it. set_global_assignment -name VERILOG_MACRO "ALTERA_EMIF_ENABLE_ISSP=1" The enabling of ISSP in a project causes the DDR3 IP reset signals to be interpreted by the Quartus® Prime Pro Edition Software as being different, even though they are connected to the same signal source.
