Proper way to infer Quad Port Ram?
I generated the Quad Port Template in Quartus 2025.3. I then wrapped it into a wrapper and finally into my design. This is then instantiated with the following generics: Info(19337): VHDL info at quad_port_ram.vhd(10): executing entity "quad_port_ram(data_width=578,addr_width=7)" with architecture "rtl" Info(19337): VHDL info at quad_port_ram.vhd(10): executing entity "quad_port_ram(data_width=578,addr_width=8)" with architecture "rtl" Info(19337): VHDL info at quad_port_ram.vhd(10): executing entity "quad_port_ram(data_width=578,addr_width=9)" with architecture "rtl" Info(19337): VHDL info at quad_port_ram.vhd(10): executing entity "quad_port_ram(data_width=578,addr_width=10)" with architecture "rtl" However I get the following errors: Warning(276002): Cannot convert all sets of registers into RAM megafunctions when creating nodes; therefore, the resulting number of registers remaining in design can cause longer compilation time or result in insufficient memory to complete Analysis and Synthesis Info(276012): RAM logic "stage_gen[13].pipe_fft_stage|math_fft_quad_port_ram_1_0_inst|quad_port_ram_inst|ram" is uninferred due to too many ports Info(276012): RAM logic "stage_gen[12].pipe_fft_stage|math_fft_quad_port_ram_1_0_inst|quad_port_ram_inst|ram" is uninferred due to too many ports Info(276014): Found 9 instances of uninferred RAM logic Info(276012): RAM logic "stage_gen[13].pipe_fft_stage|math_fft_quad_port_ram_1_0_inst|quad_port_ram_inst|ram" is uninferred due to too many ports Info(276012): RAM logic "stage_gen[12].pipe_fft_stage|math_fft_quad_port_ram_1_0_inst|quad_port_ram_inst|ram" is uninferred due to too many ports Info(276012): RAM logic "stage_gen[11].pipe_fft_stage|math_fft_quad_port_ram_1_0_inst|quad_port_ram_inst|ram" is uninferred due to too many ports Info(276012): RAM logic "stage_gen[10].pipe_fft_stage|math_fft_quad_port_ram_1_0_inst|quad_port_ram_inst|ram" is uninferred due to too many ports Info(276012): RAM logic "stage_gen[9].pipe_fft_stage|math_fft_quad_port_ram_1_0_inst|quad_port_ram_inst|ram" is uninferred due to too many ports Info(276012): RAM logic "stage_gen[8].pipe_fft_stage|math_fft_quad_port_ram_1_0_inst|quad_port_ram_inst|ram" is uninferred due to too many ports Info(276012): RAM logic "stage_gen[7].pipe_fft_stage|math_fft_quad_port_ram_1_0_inst|quad_port_ram_inst|ram" is uninferred due to too many ports Info(276012): RAM logic "stage_gen[6].pipe_fft_stage|math_fft_quad_port_ram_1_0_inst|quad_port_ram_inst|ram" is uninferred due to too many ports Info(276012): RAM logic "stage_gen[5].pipe_fft_stage|math_fft_quad_port_ram_1_0_inst|quad_port_ram_inst|ram" is uninferred due to too many ports Is there something that can be done to properly infer quad-port ram in 25.3? Here's the VHDL generated from the template: -- Quartus Prime VHDL Template -- Quad Port RAM with separate read/write addresses and -- single read/write clock -- This style of RAM cannot be used on Arria 10, -- which does not support Quad Port RAM library ieee; use ieee.std_logic_1164.all; entity quad_port_ram is generic ( DATA_WIDTH : natural := 2; ADDR_WIDTH : natural := 6 ); port ( clk : in std_logic; read_addr_a : in natural range 0 to 2**ADDR_WIDTH - 1; read_addr_b : in natural range 0 to 2**ADDR_WIDTH - 1; write_addr_a : in natural range 0 to 2**ADDR_WIDTH - 1; write_addr_b : in natural range 0 to 2**ADDR_WIDTH - 1; data_a : in std_logic_vector((DATA_WIDTH-1) downto 0); data_b : in std_logic_vector((DATA_WIDTH-1) downto 0); we_a : in std_logic := '1'; we_b : in std_logic := '1'; q_a : out std_logic_vector((DATA_WIDTH -1) downto 0); q_b : out std_logic_vector((DATA_WIDTH -1) downto 0) ); end quad_port_ram; architecture rtl of quad_port_ram is -- Build a 2-D array type for the RAM subtype word_t is std_logic_vector((DATA_WIDTH-1) downto 0); type memory_t is array(2**ADDR_WIDTH-1 downto 0) of word_t; -- Declare the RAM shared variable ram : memory_t; begin -- Port A process(clk) begin if(rising_edge(clk)) then if(we_a = '1') then ram(write_addr_a) := data_a; end if; end if; end process; process(clk) begin if(rising_edge(clk)) then q_a <= ram(read_addr_a); end if; end process; -- Port B process(clk) begin if(rising_edge(clk)) then if(we_b = '1') then ram(write_addr_b) := data_b; end if; end if; end process; process(clk) begin if(rising_edge(clk)) then q_b <= ram(read_addr_b); end if; end process; end rtl;
Quartus/Signaltap complains about wrong version
Hello, we are using Quartus prime V24.1.0 for a rather large project. We have various signaltap files stored within git for analysis. Now, from time to time, it happens that quartus throws the following warning/assertion. Obviously, this assertion can be suppressedwith ENABLE_VHDL_STATIC_ASSERTIONS OFF, and everything is working. However this is no soulution as we want to have ENABLE_VHDL_STATIC_ASSERTIONS ON Error (22148): VHDL error at sld_ela_control.vhd(1263): Failure: "The design file sld_ela_control.vhd is released with Q uartus Prime software Version 24.1.0. It is not compatible with the parent entity. If you generated the parent entity us ing the Signal Tap megawizard, then you must update the parent entity using the megawizard in the current release.": exi ting elaboration File: c:/intelfpga_pro/24.1/quartus/libraries/megafunctions/sld_ela_control.vhd Line: 1263 If I remove the signaltap(file) entirely, and readd it, everything works. However, this is very annoying and time consuming. Q1. Why is this assertion triggered in the first place? We do not use any other versions. Q2. How do I "update the parent entity using the megawizard"? I'm unable to find an "update" option. To me deleting signaltap and re-creating it is not an update.... Thanks, Michael
dut.p0_hip_status has no associated reset.
Hello Altera I am using Quartus Prime Pro 25.1.0 build 129 03/26/2025 SC Pro Edition. In my Agiliex 7 Design project, I have Intel R-Tile MCDMA for PCI Express intel_pcie_rtile_mcdma Version 5.3.1 Ip instantiated as "dut". in parameters settings I have enabled to have hip status interface. this interface is connected to a custom design QCP file. The QCP uses "app_clk" and "app_nreset_status" from dut ip as its clk and reset inputs. THey go through clock bridge and reset bridge. Clock and reser outputs from these bridges are used internally in QCP creation In platform designer as I connect "dut.p0_hip_status" and "custom_module_pcie_ep_hip_status_in" I get an error as following "Error: pcie_ed: Interfaces custom_module_pcie_ep_hip_status_in and dut.p0_hip_status must have matching associated resets, but dut.p0_hip_status has no associated reset." This Error does not make sense to me, as dut`s hip status interface and my qcp`s status interface ports shows correct clock and reset association in component instantiation tab; and my custom design uses same clock and reset to its clock and reset bridge inputs. can you please help me to understand what is this error about and how do i resolve it?
RAM inference not working for initialized RAM
According to documentation RAM initialization should work in VHDL by simply adding an initialization value to the memory array. https://www.intel.com/content/www/us/en/docs/programmable/683082/21-3/specifying-initial-memory-contents-at.html However, In my code (see attached), this is not the case. Without initialization value (resp. with initializing all content to zero) the code infers 8kb RAM - so the syntax seems fine for RAM inference. As soon as I add any other initialization content than zeros, registers are inferred (not RAM). I have attached my code containing both cases. With line 109 uncommented, RAM inferrence works: signal Mem_v : Data_t(Depth_g - 1 downto 0) := (others => (others => '0')); With line 108 uncommented, RAM inferrence fails: signal Mem_v : Data_t(Depth_g - 1 downto 0) := (0 => x"1234", 1 => x"5678", others => (others => '0')); Why is RAM inference not working? What can I do to make it work?
Diagnosing Congestions
Hello, our Arria 10 design suffers from routing congestions. We used the "Top Congested Nets" report to identify critical nets and reworked the design, e.g. by manual register replication, pipelining etc. Despite the elimination of several high-fan-out nets, routing still fails with congestions. Since we have seen designs containing nets with significantly higher number of overused nodes and fan-outs, we are questioning our metrics. How can we diagnose the root cause of router congestions? Please find attached the archived project. Best regards, NickFritzscheQuartus License Error: Invalid License Activation Code
Hi folks, I received 3 different activation codes for CXL IPs from my manager. But I found that they are all shown as invalid in Intel Self-service Licensing Center. All the 3 codes will show "Error: Invalid License Activation Code" after I pressed the "search" button. The related codes are for, IP-CXLTYP1-NC IP-CXLTYP2-NC IP-CXLTYP3DDR-NC I saw someone else in this communmity have the same issue. I submitted a ticket to Licensing Center and got no response. It's frustrating. Could anyone provide a fix to this? Thanks.
Issue in Quartus 16.1 with Windows 11 Pro
IssueHi, I am using Quartus Prime 16.1 Standard Edition and utilize schematic entry to create .bdf file. OS is Windows 11 Pro. I am facing issue to view 1) Block & Symbol names 2) Instance, bus, node & conduit names 3) Port name aliases 4) Comment & other text Check the Image. Text is cut from the end. In the image, a node CLK1_25E is not visible completely. “_” and “E” are missing in the view. They are completely visible when open Node Properties. I am trying by changing different Font Type, Size and Style in the Quartus Font setting but still the result is same. Also change the screen resolution but still the result is same. Please help to resolve the problem.Timing Violations: 8x F-Tile ETH Hard IP TX_CLKOUT
Hello Intel Team, In our design, we instantiated eight 10G F-Tile Ethernet Hard IPs (including ANLT) using the VHDL "GENERATE" construct. During timing analysis, we are encountering setup and hold violations on the "TX_CLKOUT" path of the F-Tile transceivers. The "REPORT_CLOCKS" command shows that these 8 clocks are being generated with a frequency of 402.83 MHz under the following names: gen_eth[0].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch23 gen_eth[1].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch22 ... gen_eth[7].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch16 The corresponding master clocks are: gen_eth[0].proc_ftile_eth_hardip|eth_f_0|tx_pld_pcs_clk_reg|ch23 TX_CLKOUT clocks are asynchronous to each other and operate independently. Therefore, we attempted to exclude them from timing analysis using the "set_clock_groups -asynchronous" constraint, like this: set_clock_groups -asynchronous \ -group { [get_clocks {gen_eth[0].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch23}] } \ -group { [get_clocks {gen_eth[1].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch22}] } \ -group { [get_clocks {gen_eth[2].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch21}] } \ -group { [get_clocks {gen_eth[3].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch20}] } \ -group { [get_clocks {gen_eth[4].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch19}] } \ -group { [get_clocks {gen_eth[5].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch18}] } \ -group { [get_clocks {gen_eth[6].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch17}] } \ -group { [get_clocks {gen_eth[7].proc_ftile_eth_hardip|eth_f_0|tx_clkout|ch16}] } However, this approach results in the following errors: - Warning(20314): Invalid collection filter: [get_clocks {gen_eth[0].proc...}] - Warning(332049): Ignored set_clocks_group: Argument -group with value could not match any element of the type clk. - Warning(332049): Argument -group is not an obejct ID. I’ve tried multiple approaches, get_nets, Get_pins, also using wildcards and "create_generated_clock", but nothing has resolved the issue. According to my understanding, a "create_generated_clock" constraint shouldn't be necessary, since these clocks are automatically generated by Quartus. When inspecting the design in the Timing Analyzer using "get_clocks *ch23, the clock names appear to be internally resolved to autogenerated IDs like "_co15660". However, these IDs are not stable and may change with each compile (fit), which makes them unsuitable for constraints. At this point, I am running out of ideas. Question: How can I properly constraint or eliminate the setup and hold violations on the eight "TX_CLKout" clocks generated by Quartus in the F-Tile Ethernet Hard IPs? Should I just use "Set_False_Path"? I used the "Generate" command in VHDL to instantiate the 8 F-Tile ETH Hard IP + 8 ANLT. Could be this a problem ? kind regards Jacob
