JitLoonL_Altera
Occasional ContributorJoined 8 months ago
User Profile
Occasional Contributor
User Widgets
Contributions
Re: Unique ID registers in Cyclone V
Hi, A number of identification mechanisms exist on Cyclone V devices, but none of them function as a dedicated, per-device hardware serial number on the HPS side in the same way some other SoCs provide. What is available depends on which part of the chip you are accessing. JTAG IDCODE Cyclone V devices include a 32-bit IEEE 1149.1 IDCODE, and the documentation lists the values for each family member. This code identifies the device type, variant, and revision, which can be useful for checking what device is present in a chain. However, the IDCODE follows a fixed format (version + part number + manufacturer), so it does not differentiate one physical device from another of the same model. System Manager registers The HPS System Manager exposes some identification fields such as silicon revision, but the available fields generally describe the device class rather than provide a unique per-unit identifier. The fields tend to be constant across all devices of the same family/stepping. FPGA-side Unique ID There is also a Unique Chip ID feature available in the FPGA fabric through specific Intel IP. This can be used to retrieve a value that is tied to the FPGA die. If HPS access is required, it can be bridged into the HPS through lightweight AXI/Avalon interfaces. Whether this meets the use-case depends on the system architecture. Board-level alternatives Some systems instead rely on identifiers stored outside the SoC—for example: eMMC CID registers QSPI/NAND flash locations provisioned during manufacturing External EEPROM with a programmed serial number These methods provide stable per-unit identification when a silicon-level ID is not exposed.2Views1like0CommentsRe: 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.3.1KViews0likes1CommentRe: 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.390Views1like0CommentsRe: 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.3.3KViews0likes1CommentRe: 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.557Views0likes0CommentsRe: 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 Configuration393Views0likes0CommentsRe: 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.2.3KViews0likes0CommentsRe: 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.2.4KViews0likes0CommentsRe: 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.2.5KViews0likes0CommentsRe: 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.2.5KViews0likes0Comments