Questa-ModelSim UI scaling problems in Linux
Hello Has anybody been able to solve the issue of UI of Questa not scaling correctly on linux with wayland? I am using Ubuntu 26.04 with wayland and UI is just tiny, icons, are so small i cannot read any text. When opening a new project, file explorer is also tiny. Fonts i could change in the config file but icons, menus and everything else is just extremely small. Problem is even worse on high resolution displays. Regards, Haris
System Console master_read_memory fails above 7688 bytes on Agilex 5 (AXE5-Eagle)
A single master_read_memory of 7689 bytes or more never completes on an Agilex 5. It returns nothing, times out after 60 seconds, and leaves the JTAG channel closed so the next command fails too. 7688 bytes on the same master and the same address returns all 7688 values in under 0.1 second. The boundary is byte exact and repeats every time. I can reproduce this entirely with an unmodified example bitstream published by Arrow, so no design of mine is involved and there is nothing for me to send you. SETUP Board: Arrow AXE5-Eagle, device A5ED065BB32AE4SR0, IDCODE 0364F0DD Bitstream: axe5_eagle_voltage_temp.sof from https://github.com/ArrowElectronics/Agilex-5, path images/promo3/, md5 b391b9cd5226fe92fd2068ddc66f8442 That bitstream was built with Quartus Prime Pro 24.3 and reports "HPS present: FALSE", so it configures straight over JTAG with no bootloader merge and no HPS involvement. It exposes a Nios V node and a JTAG PHY master. Tools: Quartus Prime Pro 26.1.1 build 130, System Console from the same installation, Windows 10 Enterprise LTSC 21H2 Cable: Arrow USB Blaster ARA39943-TEI0004, JTAG clock pinned to 6 MHz, Altera JTAG Server running as a Windows service STEPS 1. Program the board over JTAG: quartus_pgm -c "Arrow-USB-Blaster [ARA39943-TEI0004]" -m jtag -o "p;axe5_eagle_voltage_temp.sof@1" 2. In System Console, open the JTAG PHY master and read: set m [lindex [get_service_paths master] 0] open_service master $m master_read_memory $m 0x0 7688 master_read_memory $m 0x0 7689 RESULT master_read_memory 7688 bytes -> 7688 values in 0 master_read_memory 7689 bytes -> nothing, 60.0 s, then: master_read_memory: This transaction did not complete e is giving up. After the failure the channel is closed and the next command reports "Channel closed" until the service is reopened. Recovering costs 20 to 60 seconds. WHAT I HAVE ALREADY RULED OUT Not the address. Identical behaviour reading from 0x0, 0x1000, 0x10000000 and 0x20000000, and shifting the base by 1, 2, 4 or 4092 bytes at a fixed size changes nothing. Only the requested byte count Not a timeout. Reads return in 0.0 s right up to 7688, then the very next byte fails. A timeout would show times rising as the limit approached, not an instant success becoming an outright fa Not the size of the reply. master_read_32 hands back a 45055 character answer without trouble, while master_read_memory fails while producing a 39044 character one. Not the design. The same byte boundary appears on two other unrelated bitstreams on this board, one with an HPS and one without, built with different Quartus versions. The Arrow example above is simy. master_read_32 IS NOT AFFECTED, AND HAS NO COMP On the same master and the same bitstream, master_read_32 was run at increasing sizes. Every one returned the full count, correctly, with no timeout and no channel closure: master_read_32 $m 0x0 4096 -> 4096 words, 16 kB spanned, 0.5 s master_read_32 $m 0x0 8192 -> 8192 words, 32 kB master_read_32 $m 0x0 16384 -> 16384 words, 64 kB spanned, 2.2 s master_read_32 $m 0x0 32768 -> 32768 words, 128 kB master_read_32 $m 0x0 65536 -> 65536 words, 256 kB spanned, 9.8 s That last one spans 262144 bytes, which is 34 times theead_memory cannot deliver, and it scales linearly at about0.15 ms per word with no sign of a ceiling. If the JTAG link, the Avalon bridge or the reply channel were the constraint, master_read_32 would degrade somewhere across that range. It does not. master_read_32 is therefore a usable workaround, but a slow one: master_read_memory returns 7688 bytes in under 0.05 s, roughly 150 kB/s, where master_read_32 sustains about 26 kB/s. Around 6 times slowp> QUESTIONS Is 7688 bytes an intended limit for master_read_memory on Agilex 5? If so, where is it documented, and does it vary by device family? The same tool version against Arria V hardware is rock solid and sh Whatever the limit is, could an oversized request return an error immediately instead of hanging for 60 seconds and closing the channel? The silent 60 second stall is far more expensive than a reject Happy to run any additional test on this board if neede
Introducing the Altera Community AI Responder — Beta
Altera is introducing the AI Responder, an assistant built into the Altera Community to help provide faster, context-aware guidance for Altera product questions. It uses relevant public Altera documentation and Knowledge Database content, with coverage continuing to expand. The AI Responder may provide source references and can hand off complex or out-of-scope questions to an Altera subject-matter expert. As a beta feature, responses may contain errors or omissions, so please review the sources and verify technical guidance against official Altera documentation before implementation. If the response does not fully address your question, add more context and tag ai_responder to continue the discussion. We welcome your feedback as we improve the Community experience.
How to organize a shared cache for qsys systems?
I have written a system to generate command lines and scripts/templates for various EDA tools. This will let me share the same same design across different implementations. The designs typically reside in a git (or some other VC) repository. For Altera IP's only the *.ip is kept in the git repository. The cache tag is generated from a hash of the content of the *.ip and the Quartus version used as this uniquely defines a single *.ip file. The build script will copy the '*.ip' file and run qsys-generate in the $cache/$tag location which will be added to the IP_FILE in the tcl build script. The next time the same Quartus version and same *.ip file is used it's referenced by the IP_FILE variable. This works pretty well. Putting the *.qsys itself into a similar structure works too. But distributing the *.ip and *.qsys children of the parent.qsys in the same cache seem to be problematic as the parent.qsys logicalView XML tag seem to contain a partial relative sub-path. Is there a way to make sure that only references to the child.ip or child.qsys will be present in the parent.qsys so that it can be located by the full absolute path specified in the IP_FILE? Also how are *_hw.tcl files located and what type of references and relations between these and their respective *.ip and/or *.qsys files are stored in these files? Or is the only solution to copy the full tree structure of the qsys into the cache and hash its full content? BTW I'm using Linux only.getting a licnese
Hello everyone, I just bought my DE10 standard board for my graduation project. Unfortunately, my university doesn't provide a license for the Quartus standard, and I need more than 90 days to finish the project. Is there any way to get a license as a student for free? My project is about an AI accelerator, so I need the standard version; the lite one isn't enough. Thank you,
Mailbox Client IP - SEND_CERTIFICATE command through FPGA fabric
Hi colleagues, under Agilex3C (A3CY135BM16A) Non-HPS with Quartus 26.1 (latest SDM, latest IPs) how one can send compact certificates to SDM through the internal FPGA fabric? I tried it with Mailbox Client (1024/1024 FIFO depth, AXI accelerator path disabled) + SPI slave/JTAG Avalon Master, all other SDM commands (incl. the complicated ones like SPI programming with larger payloads) are working fine except this one. The error I get back all the time is 0xF00000FF (which appears as 0x3FF in SDM level1 log), so generic error, no explanation. When I load the same certificate over JTAG (external JTAG not via JTAG Avalon bridge to Mailbox Client), then it is working fine (so signature and certificate content is right). I tried both burning fuse or just loading virtual fuse with/without test bit. All gives back this same answer if it has been sent over FPGA Fabric SDM mailbox. Does anyone know any example project for this? (I tried to make it work based on ATF-A mailbox driver's VAB certificate loading command implementation (which theoretically should accept other certificates too). I believe this is something supposed to work without HPS. (otherwise you should leave JTAG enabled in your system). Links: arm-trusted-firmware/plat/altera/soc/common/include/socfpga_mailbox.h at socfpga_v2.14.0 · altera-fpga/arm-trusted-firmware arm-trusted-firmware/plat/altera/soc/common/soc/socfpga_mailbox.c at socfpga_v2.14.0 · altera-fpga/arm-trusted-firmware Thanks, PeterSOLVED: 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.Starting Quartus GUI fails in docker version
Hi, Recently I found out Quartus is available for docker. I started to test and compile process worked well on an existing design with 25.1 Standard Edition on both native SUSE Linux and WSL (SUSE as well). But when I wanted to start the GUI, I got back the following error (in both cases): /mnt/c/Windows/system32> docker run --net=host alterafpga/quartus-std:25.1std-all quartus *** Fatal Error: Segment Violation at (nil) Module: quartus Stack Trace: 0x289a2: abort + 0x182 (c.so.6) 0xae55a: QtPrivate::lcNativeInterface() [clone .cold] (Qt6Core.so.6) 0xaedc4: QMessageLogger::warning(char const*, ...) const (Qt6Core.so.6) 0xf9dc2: QGuiApplication::restoreOverrideCursor() [clone .cold] (Qt6Gui.so.6) 0x18e5a1: QGuiApplicationPrivate::createPlatformIntegration() + 0x641 (Qt6Gui.so.6) 0x18ef00: QGuiApplicationPrivate::createEventDispatcher() + 0x30 (Qt6Gui.so.6) 0x1461f5: QCoreApplicationPrivate::init() + 0xbe5 (Qt6Core.so.6) 0x1921b3: QGuiApplicationPrivate::init() + 0x33 (Qt6Gui.so.6) 0x18bc59: QApplicationPrivate::init() + 0x9 (Qt6Widgets.so.6) 0xb3899: AFCQ_APP::AFCQ_APP(int&, char**) + 0x13 (gcl_afcq) 0x6863a: QUI_APP::QUI_APP(int&, char**) + 0x1e (sys_qui) 0x14fb9: QGQ_APP::QGQ_APP(int&, char**) + 0x9 (sys_qgq) 0x38b8: qgq_main(int, char const**) + 0x48 (quartus) 0x3e540: msg_main_thread(void*) + 0x10 (ccl_msg) 0x5c1c: thr_final_wrapper + 0xc (ccl_thr) 0x3e60a: msg_thread_wrapper(void* (*)(void*), void*) + 0x6e (ccl_msg) 0xc046: mem_thread_wrapper(void* (*)(void*), void*) + 0x96 (ccl_mem) 0x9188: err_thread_wrapper(void* (*)(void*), void*) + 0x27 (ccl_err) 0x5c5f: thr_thread_wrapper + 0x15 (ccl_thr) 0x4050a: msg_exe_main(int, char const**, int (*)(int, char const**)) + 0xa8 (ccl_msg) 0x39d5: main + 0x26 (quartus) 0x2a28b: __libc_start_main + 0x8b (c.so.6) 0x37aa: _start + 0x2a (quartus) End-trace Is this a compatibility issue with my Linux version? Or do I make something wrong? Best regards, Istvan
