Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
9 years ago

MAX 10 weird behaviour

Hey,

I kindly ask for your help as I'm totally lost.

Device: MAX 10 10M50DAF256I7G

The situation: I have a design that includes a Nios II/f processor and a software written to run on it.

Everything works fine. But when I make the smallest change in the design (not in the software, and not in the Nios) - it stop working! . The change could be anything , even a pin assignment, and it wouldn't work anymore.

If I undo the change, everything works again. I can make another change and it might work and might not work ( not work = nios application not running ) .

the interesting part is , that if I run the software through debug mode, it works all the time. and i can't see why a change on the "Hardware" side affect the application running or not.

For example: I make the following change: add an output to a led -> software won't work.

I make another change: connect the led to a switch -> everything works again.

Do you think the issue is the flash? its addressing? maybe memory initialization?

Appreciate your assistance,

Thanks, Eyar

Solution:

With the kind help of Elhanan Sharon (@imported_elsharon) and Eyal Sharon we solved the problem.

The issue had to do with a redundant bus from the processor - flash_instruction_master. All the settings had the Nios software loading from RAM except this and it is unclear why it sometimes worked with that bus present.

To remove that bus we needed to go t the parameters window of the Nios II processor component in Qsys -> Caches and Memory Interfaces tab -> Flash Accelerator -> set Line Size to None (was 128 bits before). Now that this line is gone the only instruction bus present is the instruction_master and it is connected to both memory.s1 and flash.data and only to those. After regenerate and recompile everything (Quartus, Qsys, BSP in Eclipse) - things worked and they keep working.

Worth noting is that we used the System Console (opens from eclipse -> Nios II menu) and the Tcl language to debug and understand the Nios processor state and come to conclusions and it was very handy.

9 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Hi,

    I think there are memory initialization problems.

    What memory initialization option do you use?

    Do you use .sof or .pof file to program MAX10?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    It could also be a timing related issue. Have you got timing specs for the entire design? Do you have any custom asynchronous logic?

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Thanks for your answers,

    --- Quote Start ---

    What memory initialization option do you use?

    Do you use .sof or .pof file to program MAX10?

    --- Quote End ---

    I use the default options (non of checkboxes checked).

    I tried programming both files.

    --- Quote Start ---

    Have you got timing specs for the entire design? Do you have any custom asynchronous logic?

    --- Quote End ---

    No and no.

    I can now verify that .sof part is works always and apperantly is not the problem.

    It is the .hex software part that only runs fine when I use debug/run from Eclipse, but not from the generated .pof to which I combine the .sof and .hex files after arbitrary changes.

    It seems like the internal flash is written properly (how can I verify it though?), but it doesn't load into memory.

    Can I program the .hex file separately? how?

    Thanks, Eyar
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    If you have no timing specs, then how can you tell if the design met timing?

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    I am having a similar problem:

    My Max10 design was having bizarre timing issues. It worked fine on an eval board, but in my produced design, the timing was really weird- seemingly random. I am programming this schematically. In an effort to diagnose the problem, I ran one signal out to a pin connected to a FET (which controls an LED). Once I did that, the signal I was trying to look at worked AND the whole FPGA timing problem disappeared!

    It seems I can completely fix the problem by feeding this one internal signal out to a pin (even an unused pin with no FET).

    Once I remove the pin assignment, the problem reappears.

    So, even though it now works, I would like to know *why* this fixed it before we go to production. Any clues? Sorta seems like it needs a pull-up, pull-down, or buffer(?).

    Thanks!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    --- Quote Start ---

    So, even though it now works, I would like to know *why* this fixed it before we go to production. Any clues? Sorta seems like it needs a pull-up, pull-down, or buffer(?).

    --- Quote End ---

    It fixed it because you changed the design, signals got re-routed and the problem went away. The compiled design will be different from one compile to the next even with the most minor of changes.

    There is no reason to believe the problem wont come back on a later compile, or when the chip heats up/cools down, or when you use a different chip. Without timing specs and analysis you're leaving yourself open to timing problems.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    --- Quote Start ---

    It fixed it because you changed the design, signals got re-routed and the problem went away. The compiled design will be different from one compile to the next even with the most minor of changes.

    --- Quote End ---

    Yes, obviously. No doubt about that! I was just wondering if anyone had an idea as to *why*.

    Maybe if I rephrase: Physically, inside the FPGA, you have internal connections between the LUTs. When I decide to feed one of those signals to a pin, I assume it must run through a buffer that was not there before. What is it about the buffer (or other aspects of this connection) that would change the circuit so dramatically? The ideal buffer has no effect on the input circuit-- and the whole reason I was feeding this signal to a pin was to see what it was doing, not to fix a problem.

    Does it have to do with a pull-up or pull-down changing a 1 to a 0, or vice-versa, for example? I tried to change this internally to test it, but it did not help. But maybe I did it wrong.

    Basically, something seemed to change when it should not have. I suspect it is a bug in the Quartus compiler, but I have been wrong on that sort of thing many times before! :)

    Thanks for your help!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    It will be the routing inside the FPGA. The circuit will likely be the same.

    When the design is compiled, the fitter uses a seed to place all the elements. This seed is dependent on your code and the project seed settings. Any change in the code changes the fit seed and hence where everything gets place.

    Timing specs help guide the fitting by giving limits on how far the routing can go. Without the timing specs, you let the fitter run wild where some builds work and some don't.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    So, I eventually solved the problem with the help of Elhanan Sharon (@imported_elsharon) and Eyal Sharon.

    The issue was a Nios issue and not a Quartus/schematics/vhdl issue.

    My Nios design in Qsys had the Nios II Processor component reading instructions from the flash with a flash_instruction_master, but all the other settings had the software booting and running from the on chip memory. We removed the flash_instruction_master bus in Nios II Processor Parameters window -> Caches and Memory Interfaces tab -> Flash Accelerator -> Line Size set to None (was 128 bit before). Then we connected the the instruction_master to the flash.data where the flash_instruction_master was connected before (data_master is also connected there). I ended up having instruction_master and data_master connected to both flash.data and memory.s1 .

    After regenerating and recompiling everything things worked.

    Worth noting is that we used the system console to debug the Nios operation using the Tcl language. One can view all the registers of the Nios and the memory with that.

    Eyar