Quartus Prime 25.1 Lite - Display Issues
Dear Altera / Intel, I have noted a large obstruction while trying to work with the latest version of Quartus Prime Lite. I have made two screenshots that show the display issues I am having with this version. They are two-fold: The mega-wizard plugin manager dialog for the ALT_PLL megafunction: All "windows-controls" panels that house the controls for the various wizard pages are set to transparent on my system. All controls of all wizard pages are visible and make it near impossible to work with for me. The first screenshot says it all. The second issue is syntax-highlighting for the Verilog HDL. I've followed developments in this area for years and as a software developer, for visual recognition performance I do rely on syntax-highlighting a great deal. Since version 23 this seems to have gone fubar. It's the 2nd screenshot. When it comes to the syntax highlighting I noted that now port identifiers are now regarded HDL key words which I think they are not as they are still identifiers. The word "port" for as far as I can remember is not a Verilog keyword either (unlike "modport"). Further, it's also parameter/constant identifiers that are regarded keywords which they are not. Funny though is that the parameter identifier must be full caps to be regarded a keyword. (the word "low" in the screenshort, contary to "HIGH"). I would love to see the syntax highlighting be addressed and have this work fluently if possible; too detailed a high-light may be too hard to add or require too much work, I don't know. If I am to supply a wish-list it would be short: Syntax highlighting as of Quartus 20.1.1 as a basis Port highlighting with its own element "Verilog Port Identifier" is indeed useful and nice. That's it. Parameters / constants are no specific desire, but if you wish to colorize these, please try to be consistent and not let this be case sensitive as it is now. And an obligatory disclaimer: It may be possible all of this works like fine on everyone else's systems and it's just me (lol). For what its worth, I use an old though established components custom PC. (i7 920, Foxconn bloodrage board and an Asus RTX2060 TUF as its main components, all with drivers up to date and the CPU and board still supported by windows 10. Thanks in advance! Arno
The best way to implement SignalTapII
Hello Altera SigalTap Experts, I have been trying to use Signal Tap in my MAX10 FPGA with Quartus STD 25.1 project. I was trying to use the Signal Tap GUI at first. The problem seems to be that for the signals i want to add to my Signal Tap probes, even after i add a constraint such as: (* keep = "true" *) logic vio_init_source; for example in System Verilog on ALL the signals i want to see in Signal Tap, they keep getting synthesised away. So i don't see a lot of the signals i need post synthesis / post fitting. If i do a node search for them they either don't appear after the search OR if they appear and i try to add them to my Signal Tap probes list they appear in RED {meaning Signal Tap can't use them i guess}. Then you seem to be forced into doing a 'Rapid Recompilation' which in my experience always means that i need to do a full FPGA compilation. This seems a bit crazy when i already did a full FPGA compile to get to this stage in the first place and i did it with all my 'keep' constraints applied to all the signals i wanted to use with Signal Tap. I have also tried using the Signal Tap Instantiation in my RTL, but that method also has the same sort of problems. My Question is: what is the best method(s) to use to guarantee that Signal Tap can find my signals after doing a Synthesis and Fitting run ? The other question is that it seems (unlike with AMD/Xilinx VivadoScope) that every time i make a change to my trigger equation, signa tap needs to do a full recompile. This is surely wrong and a bit crazy too ! Signal Tap already knows all the signals i am using for my trigger logic so why does it need to do a full FPGA compile { or 'Rapid Recompilation' in Signal Tap speak } when i just change the trigger function ? Is there a better way to use Signal Tap to prevent this sort of behaviour ? Thanks for your help, Dr Barry H
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.
