ContributionsMost RecentMost LikesSolutionsRe: enable bridge crashes Linux Hi @dpeng , Looking at your DT, the bridges are currently disabled, which explains why changing the clock in Linux DT alone didn’t help. For your setup: fpga_bridge@ff400000 (LW HPS-to-FPGA) is the one you likely need for HPS → FPGA communication. You should enable it in your DT like this: &fpga_bridge0 { status = "okay"; clocks = <&h2f_user2_clk>; /* match Platform Designer */ resets = <0x06 0x61>; /* keep original reset lines */ }; fpga-bridge@ffc25080 (FPGA-to-SDRAM) only needs enabling if your design specifically requires FPGA → SDRAM access. Remember, the DT in Barebox should match the Platform Designer settings. Enabling the bridge and assigning the correct clock there is necessary before Linux can use it. After this change, check the live DT in Linux - status should now be okay and the bridge should be functional. Re: FPGA-HPS DDR contention on Agilex5 SoC while running Linux: efficient data exchange strategies Hi @ppp2 , Yeah, you’re right to be concerned. On Agilex 5 SoCs, if your FPGA is streaming a lot of data straight into DDR, it can hog the memory interconnect and slow down Linux or even cause memory allocations to stall. I’ve run into similar issues before. A few things that usually help: Throttle the FPGA traffic via HPS-FPGA bridges: Use the bridges’ QoS settings or limit burst sizes on the FPGA side so the HPS always gets guaranteed memory bandwidth. This prevents the FPGA from starving the CPU. DMA + double buffers: Don’t let userspace hit the memory directly. Stream data via FPGA-to-HPS DMA using ping-pong or circular buffers. Userspace programs can then safely read from these buffers. Kernel mediation: A small kernel driver exposing these buffers via mmap or a character device keeps everything safe and avoids contention on DDR. Sync with userspace: Use interrupts, eventfd, or similar signaling mechanisms to notify userspace when new data is ready, rather than busy-waiting, which can also hammer the memory bus. The key idea is to control FPGA memory access through the bridges and have a structured path for Linux/userspace to consume the data efficiently without blocking the HPS. Re: enable bridge crashes Linux Hi @dpeng It looks like the board freeze occurs when the bridge drivers (lwhps2fpga/ hps2fpga) attempt to enable the bridges. Since FPGA programming works but enabling the bridges causes a hang, this is likely due to hardware configuration or base address mismatch between your Terasic boards and the Enclustra SA2 module. A few suggestions: Check bridge base addresses in your device tree against the Enclustra SA2 memory map; the addresses may differ from the DE0/ADC-SoC boards. Verify preloader / handoff settings – the bridges must be properly configured and clocked before enabling them. Enable one bridge at a time to isolate which one causes the hang. Reference Enclustra BSP,compare their provided socfpga.dtsi or device tree overlays for correct bridge configuration. Most hangs in regmap_write() indicate access to an unclocked or unmapped peripheral region. Once the bridge base addresses and clocks match your module, the overlay should work as expected. If possible, please share the live DT nodes for fpga_bridge0 and fpga_bridge1 after boot but before applying the overlay; that can help pinpoint the issue. Re: Unable to access rocketboards.org Thank you for raising this. We are aware that www.rocketboards.org is currently unavailable. Our team is looking into the issue, and we will provide an update once the site is back online. In the meantime, if you need access to GSRD resources, you may find some of the materials mirrored on the Intel FPGA GitHub repositories. We apologize for the inconvenience and appreciate your patience while we work to restore access. Re: Quartus Programmer works but Eclipse Flash Programmer doesn't work Hi, The Nios II processor and other IPs typically expect a stable internal FPGA clock. A raw external crystal (not a clock module) needs a PLL or oscillator circuit to become a usable internal clock. Without a PLL, the Nios system might not run, hence causing the “Target is broken” error. Fix: Add a PLL (ALTPLL) in Platform Designer and configure it: Input: 40 MHz Output: a stable clock (e.g., 50 MHz or 100 MHz) Connect this to the clock input of your Nios II system Then regenerate the system and recompile your project. Even if you have a clock input connected, if the FPGA fabric doesn't receive a valid toggling signal, Nios II won't start. Test: Add a blinking LED logic driven by the same clock to verify the FPGA "sees" a running clock. Or use a SignalTap logic analyzer to probe clock toggling internally. Run Quartus -> Tools -> System Console, then: tcl, jtagconfig bash, nios2-terminal If the Nios II does not respond, it's likely not clocking or reset properly. Verify: reset_n to the Nios II and other peripherals is correctly connected You’ve added a reset controller in Platform Designer The reset source is active-low and held long enough during power-up After regenerating Platform Designer system: Go to Eclipse: Right click the BSP → Regenerate BSP Clean and build the ELF file again Then try to flash Sometimes the Flash Programmer fails due to: Missing or incorrect Flash controller connection Try using Run → External Tools → Nios II Flash Programmer instead of Run Configuration Re: Configure NIOS firmware burning interface Additional info. When you don’t need to export JTAG pins: Standard Nios II and JTAG UART flow: If you are using the Nios II processor along with the JTAG UART IP (used for communication between the host and the processor), you don’t need to export physical JTAG pins. The JTAG interface (TCK/TDI/TDO/TMS) is already available and accessed directly through the FPGA’s built-in JTAG port, which is already on your development board. Toolchain like Quartus and the programmer tool automatically uses these JTAG ports without requiring you to manually export them. Examples of when no export is needed: Using Nios II Debug Interface with JTAG UART in your Platform Designer. Working with the built-in JTAG interface for debugging and programming. When you need to export JTAG pins: Custom or special JTAG interface: If you are designing a custom JTAG interface (for instance, creating your own soft JTAG in your IP), then you will need to manually export the JTAG-related pins. If your design requires a unique or non-standard JTAG setup (outside the typical Nios II + JTAG UART setup), this will require exporting the JTAG pins from Platform Designer. Examples of when export is needed: Designing your own custom JTAG interface. Implementing a soft JTAG in your IP that requires dedicated pins for TDI, TDO, TMS, and TCK. Re: Configure NIOS firmware burning interface 1) JTAG UART not inserted automatically This is expected behavior in newer Quartus versions. The Nios II processor does not auto-insert the JTAG UART or the JTAG-to-Avalon bridge. You need to: Manually add the JTAG UART IP (for terminal I/O) or JTAG to Avalon Master Bridge (if needed for memory access during debug). 2) Exporting JTAG Pins You do not export JTAG pins manually in Platform Designer — these are handled outside of Platform Designer in the top-level Quartus project. So for clarification: jtag_uart_0 is not a physical JTAG interface — it's a virtual UART over the JTAG debug cable, so it doesn't need export. The real JTAG pins (TDI, TDO, TMS, TCK) are already handled by Quartus I/O assignments (you don’t add them in Platform Designer). You only export other peripheral interfaces (e.g., clk, reset, external memory), not JTAG pins. Correct Setup Summary To get NIOS II + JTAG UART working: Add Nios II processor in Platform Designer. Add JTAG UART IP manually. Connect: clk to system clock. reset to system reset. irq to Nios II's interrupt line (optional but recommended). You do not need to export jtag_uart_0 — Quartus uses it automatically via USB Blaster. After generating HDL, compile the project. In Nios II SBT, you should see JTAG UART available for terminal connection. I recommend referring to the following official Intel resources, which provide clear guidance on working with Platform Designer and Nios II systems. These documents should help clarify many of your questions and allow you to explore the design flow in more detail. Intel Quartus Prime Pro Edition User Guide: Platform Designer https://cdrdv2-public.intel.com/817606/ug-683609-817606.pdf Nios II Processor Reference Guide https://cdrdv2-public.intel.com/666887/n2cpu-nii5v1gen2-683836-666887.pdf Nios II Software Developer Handbook https://www.intel.com/programmable/technical-pdfs/683525.pdf Embedded Design Handbook https://www.intel.com/programmable/technical-pdfs/683689.pdf Please go through these resources as they cover the fundamentals and should address most of the questions you've raised. Re: Configure NIOS firmware burning interface I understand you have many questions, and it's great that you're exploring the Nios II and FPGA ecosystem in detail. To help you more effectively, I’ve compiled a list of official documentation and resources that cover your topics thoroughly: Intel Nios® II Processor Handbook https://www.intel.com/content/www/us/en/docs/programmable/683127/latest/overview.html Covers architecture, boot flow, interrupts, memory setup, and more. Platform Designer (Qsys) User Guide https://www.intel.com/content/www/us/en/docs/programmable/683092/latest/overview.html How to build systems, assign IRQs, connect peripherals, etc. Nios II Hardware Development Tutorial https://www.intel.com/content/www/us/en/docs/programmable/683125/latest/introduction.html Step-by-step project, JTAG UART, IRQ config, ROM/RAM settings. Configuring Intel® FPGAs Using JTAG https://www.intel.com/content/www/us/en/docs/programmable/683209/latest/jtag-interface.html JTAG basics, pin names, hardware setup (TCK, TDI, TMS, TDO). Embedded Booting Options on Intel® SoC FPGAs https://www.intel.com/content/www/us/en/docs/programmable/683184/latest/overview.html Explains boot ROM, bootloader, firmware loading process. Cyclone 10 LP Device Handbook https://www.intel.com/content/www/us/en/docs/programmable/683157/latest/cyclone-10-lp.html For checking internal RAM sizes, flash options, and device-specific info. These should give you a solid foundation and answer most of your current and future questions. I'd recommend going through them first, they’re very detailed and well-structured. Re: Configure NIOS firmware burning interface Hi, 1) JTAG Programming In Platform Designer (formerly Qsys), if you're using a NIOS II system, you typically do not need to manually add a JTAG interface block. Instead: The JTAG interface comes automatically when you add a NIOS II processor, and it is used via the JTAG UART or JTAG Debug Module (DM). If you're looking for physical JTAG pin connections (TCK, TMS, TDI, TDO), those are part of the FPGA hardware design, not something inserted via Platform Designer. You handle them in the top-level Verilog/VHDL design or via the Pin Planner in Quartus. To check or export JTAG pins: Open the Quartus project’s top-level design file (e.g., top.v or top.qsf). Use Assignment Editor or Pin Planner to assign JTAG signals to the correct FPGA pins (these are often automatically assigned depending on your dev board). 2) IRQ Column: In Platform Designer: The IRQ column (Interrupt Request) defines the interrupt priority or vector number when you connect a peripheral (like a timer or UART) to the NIOS II processor. The number you enter (e.g., 1, 2, 3, etc.) determines the interrupt number that peripheral will use. Rules: Each IRQ number must be unique for each peripheral. Lower numbers can be treated as higher priority depending on your interrupt controller setup. Do you need to change them? Yes, if you have multiple interrupt-generating components, assign each a unique IRQ number. If your system only has one interrupt source, then you may just use 0 or any number as needed. Re: Configure NIOS firmware burning interface Hi, To answer your question 1. NIOS II Boot Sequence and Programming for the First Time Is there a boot ROM inside Cyclone 10? No — unlike microcontrollers (MCUs), FPGAs like Cyclone 10 LP do not contain built-in ROM or bootloader. Everything, including your NIOS II CPU and its program, is part of the FPGA bitstream. Boot Sequence Concept in NIOS: The boot sequence in FPGA (with NIOS) is: [FPGA configuration from Flash (e.g., EPCQ)] → [FPGA loads bitstream including NIOS + memory + bootloader] → [Bootloader runs from on-chip memory or external RAM] → [Loads firmware from Flash to RAM, starts application] How to program it the first time? Use Quartus Programmer + JTAG Cable. You design a bitstream that includes NIOS + small memory + bootloader. Program the FPGA or configuration flash (like EPCQ). After configuration, the FPGA will include NIOS running your bootloader or program. Prebuilt UART Bootloader Tool? You might be referring to SBT (NIOS II Software Build Tools) provided by Intel. One example is: nios2-flash-programmer: used to program flash devices via NIOS. If you want to boot over UART, you can create a simple UART bootloader using HAL. 2. Cyclone 10 LP On-Chip RAM Size Cyclone 10 LP does not have fixed "RAM" like a microcontroller. You add on-chip memory blocks manually in Platform Designer. However, the available amount depends on the number of M9K blocks in your FPGA. For 10CL120, the total available memory is 4320 Kbits, i.e., 540 KB of internal RAM (M9Ks). You can distribute this to your design however you want — for instruction memory, data memory, buffers, etc. 3. ROM Size in NIOS II There’s no physical “ROM” — what you're calling ROM is on-chip memory initialized with code (like reset vector). The maximum ROM size = total available on-chip RAM (M9K blocks). In Quartus, use "Fitter Resource Usage Summary" after compilation to see how much is used and how much is left. Platform Designer shows estimated M9K usage per memory block. 4. If I Use ROM, Do I Need a Bootloader? If you’re using on-chip initialized memory as ROM, it contains the firmware directly. No bootloader is needed if the firmware fits and is placed directly in this ROM. However, if your firmware is large and stored in Flash (e.g., EPCQ), then a bootloader is needed to load the firmware from Flash to RAM at runtime. 5. PLL Handling in Quartus Yes, Quartus will add a PLL if needed, but it’s best to insert and configure your own PLL if you want control over clock frequency. If you add your own PLL and connect clocks properly, Quartus will not insert another. No need to delete Quartus-inserted PLLs — just manage it from Platform Designer or Quartus IP Catalog. 6. JTAG Pins for Programming To connect an external JTAG programmer (like USB Blaster), you need to export these pins: JTAG Signal Cyclone Pin Name Direction TDI TDI In TDO TDO Out TCK TCK In TMS TMS In nTRST (optional) In These must be routed to a JTAG header on your board. You can refer to Intel JTAG header layout (10-pin or 6-pin).