User Profile
User Widgets
Contributions
Debug Know-How: Ashling* RiscFree* NIOS® V debug using Command Line
#sharing #debug #niosv Disclaimer: This article is provided as-is for educational purposes only, without warranty of any kind. Use the information at your own risk. Always verify implementations in your specific environment and consult official Altera documentation for production deployments. Introduction When a NIOS V design hangs and the RiscFree Ashling GUI becomes unresponsive, you can still debug effectively using the command line. This guide outlines clear, step-by-step instructions for setting breakpoints and monitoring system behavior using GDB server. Steps 1) Open a terminal and enter: >> niosv-shell 2) Run the following command three times to create three terminals: >> xterm& Terminal 1 is to open a port Terminal 2 is to control breakpoints Terminal 3 is to monitor output print messages 3) TERMINAL#1: Identify the JTAGIDCODE and Start GDB Server irst, display the connected JTAG device: >> jtagconfig Then start the Ashling GDB server and note down the port number (in this case is 38791): >> ash-riscv-gdb-server --auto-detect true --probe-type usb-blaster-2 --tap-number 1 --device 034BB0DD --core-number 0 4) TERMINAL#2: Load the ELF file Launch GDB: >> riscv32-unknown-elf-gdb run.elf Inside the GDB prompt: >> file run.elf >> target remote: 38791 >> load run.elf 5) TERMINAL#3: Run JUART Terminal Use JUART to monitor output: >> juart-terminal -c 1 -d 1 -i 0 This will display system logs, print messages, and output triggered by breakpoints. 6) TERMINAL#2: You may now begin debugging using standard GDB commands. Set a breakpoint: >> break <line number> Continue execution until the breakpoint: >> c Step line-by-line >> n 7) Repeat Step (6) as needed - run, monitor output via JUART, examine behavior, and continue. Tips and observations In some cases, the system hangs only when code runs continuously. This may indicate a insufficient time-to-execute issue. Running commands line-by-line (e.g., using `n`) adds implicit delay between operations, preventing hangs. If continuous execution hangs but step execution does not, consider adding delays such as: >> usleep (<value>) Start with a larger value, then gradually reduce it until the hang reappears to identify the required timing margin. For example, the following operations in the function have been identified as the root cause of insufficient time between issuing rd_word and wr_word: Use a large sleep value first to confirm that adding delay resolves the hang issue. >> #define SLEEP2 10000 If the initial delay proves effective, reduce it step‑by‑step until you find the minimum acceptable value that prevents the hang. >> #define SLEEP2 20 Conclusion This procedure should help you debug NIOS V designs reliably even when the GUI tools fail. Help the community grow—if this article was helpful, please mark it as a solution or give it a kudos so it can reach others.75Views1like0CommentsRe: Stratix 10 CKEXT Drive Level 32 GHz Clock
The +1.9 dBm lower CKEXT requirement should be viewed as a performance‑validated limit rather than a hard functional cutoff: if the CKEXT drive drops below +1.9 dBm, the Stratix 10 will generally continue to operate, but you may encounter reduced jitter margin, higher BER, or less‑stable PLL locking, and while a drive level around 0 dBm usually won’t prevent the clock path or PLL from functioning outright, it does fall outside Intel’s guaranteed operating conditions, meaning that signal integrity degrades and published timing and jitter specifications may no longer be met—so it’s best to treat +1.9 dBm as the minimum level needed for full, spec‑compliant transceiver and PLL performance.20Views0likes0CommentsRe: Cyclone V SX-GX connection
SGMII requires a line rate of 1.25 Gbps, which means it must utilize the FPGA's transceiver (XCVR) channels. However, the 5CSXFC6D6 device only provides 9 transceiver channels, while you're aiming to implement 10 SGMII interfaces—each needing a dedicated channel. This creates a shortfall of one transceiver channel for your intended design.76Views0likes0CommentsRe: USB3.x LFPS transmission and detection with FPGA transceiver
Based on this published paper, the concept should be similar wrt to LFPS implementation using FPGA https://arxiv.org/pdf/2301.11505v1 1. LFPS Reception: Does the FPGA transceiver provide any signal to indicate electrical idle state? Altera FPGA transceivers do provide a signal that can be used to detect the presence or absence of electrical idle. Specifically: See: https://community.intel.com/t5/FPGA-Wiki/Design-Example-PHY-Interface-for-PCI-Express-PIPE/ta-p/735980 The pipe_rxelecidle signal (or its equivalent depending on the PIPE interface implementation) indicates whether the receiver is in an electrical idle state. When RXELECIDLE = 0, it implies that LFPS is being received (i.e., the link is active). When RXELECIDLE = 1, it indicates that the link is in electrical idle, and no LFPS is being received. This behavior is consistent with USB 3.x PHY expectations, where LFPS detection relies on transitions between idle and active states on the differential lines1. 2. LFPS Transmission: Can LFPS be sent by controlling pipe_txdetectrx and pipe_txelecidle? Theorectically, LFPS transmission can be achieved by manipulating the transceiver's PIPE interface signals: To initiate LFPS transmission, the following conditions are typically used: TXDETECTRX = 1 TXELECIDLE = 1 txpd = 2'b00 and rxpd = 2'b00 (power-down controls) To wake up a link partner, the conditions change to: TXELECIDLE = 0 txppd = 2'b01 and rxpd = 2'b01 These control signals directly influence the raw data output of the SerDes block, allowing you to generate LFPS bursts by toggling the differential lines at low frequencies (typically 10–50 MHz square waves)1. Additionally, LFPS generation can be done in soft logic by bypassing 8b10b encoding and directly driving the transceiver with patterns like 0xFFFFFFFFFF to simulate high-level signals. Timing must be carefully managed to meet USB 3.x LFPS specifications (e.g., tBurst, tPeriod, tRepeat)690Views0likes0CommentsRe: where can find the PAC N3000 software package "n3000_ias_1_1_pv_rte_installer.tar.gz" ?
Good news! Both the CentOS and RHEL packages were re-uploaded to the same link as before i.e. Intel® FPGA PAC N3000 Acceleration Stacks v1.3.1 And, to re-emphasize, N3000 is discontinued and there is no update to the package nor support available.1.7KViews0likes1CommentRe: where can find the PAC N3000 software package "n3000_ias_1_1_pv_rte_installer.tar.gz" ?
Your voices are heard! I have filed to the internal team, and let the decision-makers reconsider putting the package into the web. Note that the N3000 is discontinued, even if the package were to be re-uploaded, there is no update to the package nor support available.2KViews0likes0CommentsRe: where can find the PAC N3000 software package "n3000_ias_1_1_pv_rte_installer.tar.gz" ?
It seems Intel is discontinuing the Intel® FPGA Programmable Acceleration Card N3000. Please read product discontinuance notification PDN2211 for more information, which led to the removal of the packages. May I know what is the effort is ongoing with the N3000?2.4KViews0likes0Comments