SOLVED: BSP Editor NullPointerException on Debian 13 Linux
SOLVED: BSP Editor "New BSP" menu command is grayed out, so can't make any new BSP's, and opening any existing one from another computer throws: SEVERE: Available BSP type values for the --type argument are: [] SEVERE: BSP type "hal2" unknown. SEVERE: NullPointerException Based on other forum posts with a similar error, it seems like this is because the BSP Editor couldn't locate some of its own files. That seems likely here too since this is the first time it's used on this computer. But there's no problematic install path etc since I used the default. THERE ARE NO SPACES IN THE INSTALL PATH NOR THE PROJECT PATH. Everything else is working already for the Max 10: I can generate with Platform Designer, synthesize with Quartus, program SRAM with SignalTap, debug Nios V with RiscFree. Details are: Quartus Prime Lite 25.1std.0 Build 1129 10/21/2025 SC Lite Patches: None OS: Debian 13. This is what Ubuntu is based on, so it's very similar. And like I said everything else already works. USB came online already, not too hard. All it took was the Altera udev rules file 92 as usual, and the correct LD_LIBRARY_PATH so jtagd could find its own shared libs. Installed quartus into regular user account, not whole system, not as root. This is offered as an option in the installer if I recall correctly. Install path is the installer's default: /home/myuser/altera_lite/25.1std The project files are irrelevant here, since BSP Editor is already off-track as soon as it launches. "New BSP" is grayed out. SOLVED: BSP Editor is unable to find its own files without Altera's environment vars, which are provided when running inside niosv-shell. That's nonsensical to me, since any brain-dead program off the street can detect where its own binary loaded from, on any OS, and walk up the path from there to find the rest of its files, as a default if no env vars were provided. That's the first line of every binary or Tcl script I've ever written. Quartus main GUI seems to do it exactly that way. Anyone else struggling with this inexplicable rough edge should make sure your desktop's launcher icon invokes niosv-shell first, like this: altera_lite/25.1std/niosv/bin/niosv-shell --run altera_lite/25.1std/niosv/bin/niosv-bsp-editor To Altera: if you're struggling to maintain or improve your software because it relies on Tcl, contact me through my forum account. I could clean up a whole mess of rough edges like this one, and some other much-needed improvements.
Quartus Licensing Issue
Recent versions of Quartus (both Std & Pro) for WIndows introduced a new problem with the license management (for node-locked licenses) which is a pain to work around. In Tools > License Setup panel, "NIC ID", a lot of "ghost" adapters appear now, while the normal behavior was to see the MAC Addresses of the Ethernet Adapters that show up in the device manager and in ipconfig /all. This seems aggravated by the use of the "Get no-cost licenses" button that apparently generates a license file for a (or many !) new virtual adapter(s)... I call them "ghost" or virtual because they don't show up in the usual commands (getmac /v, ipconfig /all, lmhostid etc) and do not correspond to a physical peripheral (network card). To make things worse, Quartus can apparently only handle a maximum of 10 (ten) Ids. The consequence is that your "real" adapter may fall out of the list and a node-locked license for this adapter becomes unusable. The only work around I found was to use the device manager, display the hidden devices, and to disable the numerous Microsoft "WAN Miniport" in the Network cards category. This should reduce the list enough to see the "real" address used for your node-locked license. I proposed a solution : allow the manual editing of the NIC Ids list (save in quartus.ini or registry). But today it seems a bit hard to be heard...Possible Quartus 24.1 bug?
Here is the code: interface myif #( parameter int W = 1 )(); typedef struct packed { logic [W-1:0] x; } MYSTRUCT; MYSTRUCT s; modport src ( output s ); modport dst ( input s ); endinterface module top; myif #( .w( 5 ) ) test_if(); test test_module ( .foo( test_if ) ); endmodule module test ( myif.dst foo ); typedef foo.MYSTRUCT MYSTRUCT_COPY; $info( "%0d %0d", $bits( foo.MYSTRUCT ), $bits( MYSTRUCT_COPY ) ); MYSTRUCT_COPY q; assign q = foo.s; endmodule Surprisingly, the info message will print "5 1" instead of "5 5". And for the assign Quartus will complain that it had to crop the 5 bit wide foo.s to match the 1 bit wide q. When processing the typedef, Quartus uses the interface definition's default W value instead of the actual value of the actual interface port. I believe that, according to the standard, that is not the expected behaviour.
dcfifo problem
In our project, we instantiate the parameterizable DCFIFO primitive provided by Altera. The design passes simulation verification without issues; however, mismatches occur between written and read data from the DCFIFO by signalTAP during board-level testing , which consequently causes driver loading failures. fpga device：agilex7 with quartus pro25.3 dcfifo wr_clk: 450M dcfifo rd_clk: 416M the instantiate example: is there better suggestion?Typedef inheritance in nested modules
Sorry for the formatting, but for some reason proper switching between paragraph and preformatted does not work. I have an interface, which contains a structure, which, in turn, contains a parametrised width vector: interface myif #( parameter int W = 1 )(); typedef struct packed { logic one; logic [W-1:0] many; } MYSTRUCT; MYSTRUCT x; modport src ( output x ); modport dst ( input x ); endinterface Now, there is a module which gets this interface. It needs to work with the data defined in the interface, so it needs to extract the structure definition (note that everything here is simplified to absolute bare bones). Easy enough: module my_outer_module ( myif.dst dest ); // Extract the typedef from the port typedef dest.MYSTRUCT MYSTRUCT; ... // other stuff ... // here will be a nested module, described below ... endmodule So far so good, the entity that instantiates my_outer_module also instantiates the interface, with whatever W parameter value it deems necessary and my_outer_module will use the correct MYSTRUCT definition, even though W has not been passed to it . Furthermore, if my_outer_module contains a nested module, as per SystemVerilog rules, it can refer to all types and parameters in the enclosing scope, so it will also be able to use MYSTRUCT without further ado. And, indeed, this works: module my_nested_module ( ... some signals in and out ... ); MYSTRUCT some_variable; ... endmodule However, if the typedef is used in the module port definition, Quartus Pro 24.1 spits the dummy: module my_nested_module ( input MYSTRUCT going_in, output MYSTRUCT coming_out ); assign coming_out = going_in; endmodule Quartus complains about undefined net type for both going_in and coming_out. How come? Help with this particular issue would be appreciated. I know that there are other ways of passing types to modules. There are reasons why I try to solve the problem this particular way and not through packages or macro trickery or anything else. I am looking for an explanation why Quartus reports an error on, I believe, perfectly valid SV source. I know that the simulator is a very different animal, but it accepts the code without a pip, and it works as expected. Thanks in advance. Interesting addendum: using old (non-ANSI) style module declaration makes Quartus happy. Which makes the whole thing more intriguing. This is accepted: module my_nested_module ( going_in, coming_out ); input MYSTRUCT going_in; output MYSTRUCT coming_out; assign coming_out = going_in; endmodule So Quartus clearly understands the concept of using a structure defined in the enclosing scope as the type of a port, but refuses to remember how to do it while processing an ANSI style module header.Issue with MIPI CSI2 Encrypted IP File During Project Integration
Hi, I am working on a project where I have integrated two separate projects into a single top-level design. Project A includes the MIPI CSI2 IP and other related components. Project B contains the logic to process the output data generated by the MIPI CSI2 IP. When I compile both projects individually, they complete successfully without any errors. However, after instantiating both projects together in a single top-level wrapper, I encounter a compilation error originating from the generated encrypted file of the MIPI CSI2 IP. I have attached the error snapshot for your reference. Could you please help identify the possible cause of this issue? Is there any known limitation or configuration requirement when integrating the MIPI CSI2 IP with additional logic in the same top-level design? Thanks.
Quartus 22.1 and 23.1 Synthesis Error
Hi, I am currently working on a project targeting a Cyclone V device using Quartus Prime versions 22.1 and 23.1. The design compiles and functions correctly with no issues. However, after adding an FFT IP core, Quartus frequently fails during synthesis with the error shown below. The issue is reproducible in both Quartus versions. Interestingly, the compilation succeeds only intermittently (approximately once every 5–6 attempts), while most synthesis runs fail. Another observation is that if I change the Synthesis Effort setting to Fast, the design compiles successfully every time. Has anyone encountered similar behaviour or have any suggestions on how to work around this issue? Thanks in advance.
