Forum Discussion

steve_ht's avatar
steve_ht
Icon for New Contributor rankNew Contributor
1 month ago

NIOS does not start after SW download (timing issue?)

Hi,

Recently I got an old Arria V design to update. It is in Quartus II 15.0 containing the following main components (in Qsys design):

  • NIOS II soft processor
  • 2x UniPHY DDR3 RAM controller (soft version, not hard), 72 bit wide data running at 400MHz clock (800Mb/s)
  • 2x Triple Speed Ethernet with 4x SGDMA

The design uses only 40k ALMs out of 190k so it fits well but I have timing issues (slack) on pll_afi_clk for one or both DDR3 controllers. I can reduce it by a lot of fine tuning on synthesizer and fitter settings but when I change a bit in the design timing results go wrong and tuning has to be started again.

Both FW and SW are downloaded to SRAM by ByteBlaster. I found when the slacks are big (>0.1ns) NIOS never starts after downloading the SW. When it is small or completely eliminated, NIOS starts in most of the cases (but not always).

Is this normal for such a design, or am I doing something wrong? I have never seen such behaviour before.

Can this timing issue affect the NIOS processor on such a way or should I search in another direction to solve the problem?

general
Nios Cpu

16 Replies

  • kbrunham_altera's avatar
    kbrunham_altera
    Icon for New Contributor rankNew Contributor
    1 month ago

    Hi steve_ht,

    If the design fails to meet timing (i.e. negative slack) then it would be expected that the Nios processor would not run code and also not be able to use niosii-download to download a new FW image.

    I would recommend reviewing the design to ensure it is completely constraint, that all cross clock domain crossings are handled correctly, and that only designs that close timing are used in HW. The Quartus Timing Analyzer Cookbook (https://docs.altera.com/r/docs/683081/current) may also be a useful resource for creating timing constraints. 

    • steve_ht's avatar
      steve_ht
      Icon for New Contributor rankNew Contributor
      1 month ago

      Hi kbrunham,

      Thanks for sharing the document. I am familiar with the basics of timing constraints but I really have no idea how to add constraints to such a complex official IP cores like the Altera UniPHY DDR RAM controller.

      BTW, I added "Auto Global Clock" option to the fitter which made situation much better. Now timing seems to be OK. It is a bit surprising why this is OFF by default.

      I still have some starting problems with NIOS. It seems to be some bootloader issue at this point. I found that using a hex file from another NIOS project to init the NIOS dedicated OC RAM improves the situation.

      So should I generate my own bootloader regardless I download SW by nios2-download directly after downloading the FW? Or how should I handle this?

      BR,

      Istvan

      • kbrunham_altera's avatar
        kbrunham_altera
        Icon for New Contributor rankNew Contributor
        1 month ago

        Hi Steve_ht,

        Could you review the Multi-Corner Timing Analysis table from the timing analyzer to see if you have any clocks currently failing timing? Ensuring your design closes timing as a first step will be critical. 

        The DDR IP includes the timing constraints it needs. You shouldn't need to create your own constraints if you are using Altera IP.

        Global Auto Clock controls promotion of clocks that are not otherwise automatically on a global network. PLL outputs for example are automatically on global clocks. 

        There are many different bootloader options available for Nios. For example you can load from flash into RAM. Given that you are starting with an existing design I would suggest you just stay with what you currently have in your BSP. Can you review your BSP using the BSP Editor and let me know what it is? The most straightforward configuration is to execute code right from initialized block RAM.

  • FawazJ_Altera's avatar
    FawazJ_Altera
    Icon for Frequent Contributor rankFrequent Contributor
    1 month ago

    Hello,

    I have few comments here, and would appreciate your feedback:

    1. The timing issue has been resolved, so I would expect the DDR3 to operate normally. The Nios II ELF was successfully downloaded from the command line, which effectively eliminates any DDR3 calibration failures. If calibration had failed, the download would not have succeeded due to an unresponsive DDR3 controller.
    2. I am not sure which script did you use to download the ELF. I recommend including the -r option (if not used) while downloading the elf to issue a reset. I also suggest running the following command after the ELF download completes and before opening the UART terminal (or even while its open, and use another command line to run the command): nios2-download --reset-target
    3. I still need to review the linker script settings, so kindly share the screenshot with me. if possible, share the settings.bsp file.
    4. I also need to know which JTAG UART driver is being used—whether it is the standard driver or the fast driver. This can be checked in the BSP Editor under the General settings.
    5. Additionally, there is a warning in the BSP Editor indicating that .stdin, .stdout, and .stderr are not assigned to an output device. Although a JTAG UART instance appears to be present in the design, the standard I/O streams are currently set to “none.” I would recommend to update the BSP settings to redirect these streams to the JTAG UART.
    6. Finally, I would like to know if you tried running the hello world example before moving to the real SW or FW. Also, did you try running it from on-chip RAM instead of DDR3?

    Thank you

    • steve_ht's avatar
      steve_ht
      Icon for New Contributor rankNew Contributor
      1 month ago

      Hi FawazJ_Altera,

      Thank you for the detailed response.

      1. Yes, the download itself seems to be OK.
      2. I tried it with the -r option as you suggested but did not help.
      3. Unfortunately I could not attach the bsp file. But here are the linker script settings:
      4. Can you help me where I can find this section (General settings)?
      5. I updated but situation still did not change.
      6. No, I have not tried Hello World or to download to OC RAM. I got a 10 years old product with FW/SW which was fine originally. Board was redesigned and I updated the FW with some new functions and pins, removed some original ones and got the current unreliable FW/SW. When it works, it is always stable, when it doesn't, NIOS never starts while the SW works well if I build it to the original (old) FW version. (As NIOS-related pins did not change, I can test both FWs on both old and new boards with the same SW code.) This is a very strange behaviour to me and now I have no idea how to move on.

       

  • FawazJ_Altera's avatar
    FawazJ_Altera
    Icon for Frequent Contributor rankFrequent Contributor
    1 month ago

    Hello,

    The General Settings section is located at the top level of the BSP settings when the BSP Editor is opened. A snapshot is attached for reference. The stdin, stdout, and stderr are currently set to none, but they should be assigned to the JTAG UART instance in your system. Setting these IO streams to "none" would isolate your FW/SW from the console.

    From the linker settings, it appears that the system is using on‑chip memory rather than DDR3. In addition, the DDR3 region does not appear in the linker view. If a DDR controller is included in your Qsys design, this may indicate that it is not connected to the Avalon‑MM bus.

    Given the current on‑chip RAM configuration, it is recommended to create a simple Hello World application and run it to verify basic system functionality and help isolate any unexpected design issues.

    Thank you,

    Fawaz

     

    • steve_ht's avatar
      steve_ht
      Icon for New Contributor rankNew Contributor
      28 days ago

      Hi Fawaz,

      These points were set just after it was originally suggested but did not help. So it is not likely the issue is with the log console.

      You are right about the linker so the DDR3 areas are not listed. Perhaps because they are not connected to NIOS data bus directly but via address extenders. Now they are added to the list by hand (nios_ddr3 and trace_ddr3):

      SW code downloads well to 0x40000000 which is nios_ddr3 memory region so the DDR3 address range and the RAM itself should work well.

      We tested this bsp as well but the situation still did not change.

      Do you have any other suggestion what to check?

      BR,

      Istvan

    • steve_ht's avatar
      steve_ht
      Icon for New Contributor rankNew Contributor
      25 days ago

      Any idea?

      I am thinking on adding a Signaltap to discover what is happening. But which signals should be probed in this case? To get some usable information about the situation? Is there some useful internal signals to check, or just external Avalon MM?

      • FawazJ_Altera's avatar
        FawazJ_Altera
        Icon for Frequent Contributor rankFrequent Contributor
        25 days ago

        Hello Steve,

        Have you tried debugging the application using the Nios II Eclipse Debugger? Setting breakpoints after the function can help determine where the application is getting stuck. You can also use SignalTap to observe internal signals, and the Nios II plug‑in to capture the processor’s address and data activity. The external Avalon‑MM signals should be sufficient for this level of debugging. However, before relying on hardware traces, I recommend stepping through the application in the Nios II debugger to identify which specific function call is causing the issue.

         

        Thank you,

        Fawaz.

         

  • steve_ht's avatar
    steve_ht
    Icon for New Contributor rankNew Contributor
    18 days ago

    I have some progress with the debugging. I was able to start Hello World with the NIOS II Eclipse Debugger. Although it seems to be OK in the Debugger, I cannot see the output (standard I/O options are set to JTAG properly now).

    There are some more interesting findings about JTAG UART consol, with the original product FW as well:

    • On the board there is FTDI USB/JTAG bridge while we can connect USB Blaster via 10-pin header as well
    • 6, 16 and 24MHz clocks were tested on both and sof/elf download worked well in every case
    • With 6 and 24MHz JTAG clock rates we never get anything from JTAG UART consol
    • With 16MHz JTAG clock some FW versions are working with both FTDI and Blaster, some never works while there are some compilation versions which are not working with FTDI but shows up some random messages with the Blaster

    So perhaps the issue is somewhere around the JTAG consol. I checked and, unfortunately, did not find too much configuration options in the core or project/device settings so I have no idea what to set.

    Regarding the BSP settings, "Enable small driver" for JTAG consol is unchecked (so fast driver is used) while standard I/O options are set to JTAG properly now (as suggested before).

  • FawazJ_Altera's avatar
    FawazJ_Altera
    Icon for Frequent Contributor rankFrequent Contributor
    18 days ago

    Hello Steve,

    I need to review the design. Can you share the .qsys file, .sopicinfo, and settings.bsp ?

    Thank you,

    Fawaz

    • steve_ht's avatar
      steve_ht
      Icon for New Contributor rankNew Contributor
      11 days ago

      Hi Fawaz,

      Have you received my e-mail with the design files?