JonWay_altera
Frequent ContributorUser Profile
Frequent Contributor
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.Re: 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.Re: 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.Re: 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.Re: 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.Re: 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?
