Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor III
2,908 Views

Problem with downloading of a NIOS II program

Hello,  

 

Here below - the screenshot resulting from my attempt to download and run a simple NIOS II program on my Terasic DE1 card. 

Any comments ? 

 

Thanks in advance. 

 

http://www.alteraforum.com/forum/attachment.php?attachmentid=13329&stc=1
0 Kudos
22 Replies
Highlighted
Valued Contributor III
19 Views

I'm not sure, but probably the problem comes from memory issues. 

Here below - the system composition in qsys

Note, that on-chip memory size is 20k (red cadre). 

Memory base address is 0x8000 and the base address of one of the components (i.e. sysid) is 0x11048

Subtracting 0x8000 from 0x11048 gives more than 20k

If this is the issue, why it was not signaled when I generated system in qsys

 

Regards. 

 

https://www.alteraforum.com/forum/attachment.php?attachmentid=13330
0 Kudos
Highlighted
Valued Contributor III
19 Views

I've created another application and have tried to download it to ma board. 

The same result - problem occurred. downloading elf process failed

And no any other hints/suggestions for workaround ! 

Is it a known problem ... or there is something wrong with settings in my hardware ? 

Thanks.
0 Kudos
Highlighted
Valued Contributor III
19 Views

Hi, 

 

The start address is 0x8000 and end address is 0xCFFF which results in 20K memory thus I don't think there is anything to do with memory.
0 Kudos
Highlighted
Valued Contributor III
19 Views

Another observation - absence of the memory driver in the board support package (please, see the screenshot below). Is it normal ? 

 

https://www.alteraforum.com/forum/attachment.php?attachmentid=13352
0 Kudos
Highlighted
Valued Contributor III
19 Views

Here below - the message in NIOS console after downloading fails. 

Well ... there are 2 accompanying files generated while project is built: {proj_name}.map and {proj_name}.objdump

Can I check some sections in this files that could me give a hint that something is wrong ? 

Thanks. 

 

https://www.alteraforum.com/forum/attachment.php?attachmentid=13353
0 Kudos
Highlighted
Valued Contributor III
19 Views

I've found a workaround for a case, similar to mine, on Altera site ... at least, the console messages are similar (screenshot below) 

I doubts that the hint can be applied to my case - in my case the program isn't downloaded 

 

https://www.alteraforum.com/forum/attachment.php?attachmentid=13354
0 Kudos
Highlighted
Valued Contributor III
19 Views

Problem resolved ! 

I modified system composition ... in this new working version I included pll, that generated new clock 143mhz for all for other blocks. 

Before all blocks were clocked by external clock of 50mhz

Apparently the role of pll is crucial. It would be nice to find some source (e.g. book, article) that treats such issues. 

 

https://www.alteraforum.com/forum/attachment.php?attachmentid=13359  

 

However while compiling this new system, another issue wondered me. Here is the extract from compiling report: 

 

Warning: RST port on the PLL is not properly connected on instance nios_led:u0|nios_led_pll:pll|altera_pll:altera_pll_i|general[0].gpll

The reset port on the PLL should be connected. If the PLL loses lock for any reason, you might need to manually reset the PLL in order to re-establish lock to the reference clock. 

 

Quite strange, because as we can state from the Qsys screenshot, the signal reset of the pll block is connected to the clk_reset of the clk block. 

 

Thanks.
0 Kudos
Highlighted
Valued Contributor III
19 Views

Problem resolved. 

I've modified the qsys system. After adding of the pll block and applying of the pll-generated clock (143 MHz) instead of external clock 50MHz, the nios ii code is downloaded and system works correctly. 

Apparently the pll block plays a fundamental role in the system construction. I wonder if exists some document that treats this issue. 

 

http://www.alteraforum.com/forum/attachment.php?attachmentid=13360&stc=1  

 

The only issue remains incomprehensible. Here is extract of the design compilation report. 

 

Warning: RST port on the PLL is not properly connected on instance nios_led:u0|nios_led_pll:pll|altera_pll:altera_pll_i|general[0].gpll

The reset port on the PLL should be connected. If the PLL loses lock for any reason, you might need to manually reset the PLL in order to re-establish lock to the reference clock. 

 

After all, as one can state from qsys screenshot, the reset signal of the pll block is connected to the clk_reset of the clk block. 

 

Thanks in advance.
0 Kudos
Highlighted
Valued Contributor III
19 Views

The Pll is not necessary in a Nios design. It's possible that your previous design didn't have timing constraints set up properly, and that using the pll somehow helped a bit the fitter, but I'm just speculating. 

As for the warning, I'm like you I don't know. It looks like it's connected fine.
0 Kudos
Highlighted
Valued Contributor III
19 Views

Indeed, I've just tried another design, that uses SDRAM memory (instead of on-chip memory) and the issue repeated. 

 

Here is Qsys screenshot of this design: 

https://www.alteraforum.com/forum/attachment.php?attachmentid=13367  

 

Concerning timing constraints, compilation report didn't reveal any violation. Here they are: 

create_clock -name clk -period 20 [get_ports clk] 

 

create_clock -name {altera_reserved_tck} -period 40 {altera_reserved_tck} 

set_input_delay -clock altera_reserved_tck -clock_fall 3 [get_ports altera_reserved_tdi] 

set_input_delay -clock altera_reserved_tck -clock_fall 3 [get_ports altera_reserved_tms] 

set_output_delay -clock altera_reserved_tck 3 [get_ports altera_reserved_tdo] 

derive_clock_uncertainty 

set_false_path -from [get_ports sw*] 

set_false_path -from [get_ports key*] 

set_false_path -from [get_ports sdram_dq*] 

 

set_false_path -from * -to [get_ports led*] 

set_false_path -from * -to [get_ports hex*] 

set_false_path -from * -to [get_ports sdram*] 

 

So, apparently, the issue with failed nios ii downloading is quite recurrent, and there is no any reliable remedy against it. 

Am I right ?
0 Kudos
Highlighted
Valued Contributor III
19 Views

Yes, you are right. The presence of pll isn't panacea for this issue. 

I've created another design, a little bit more complicated - more peripherals and on-chip memory is replaced by sdram

And with this new design I've met the same problem - the nios ii code "refuse" to be downloading into board. 

In this new design I also used pll, but this time it didn't help (please, see the qsys screenshot below) 

As I understood, this issue is quite recurrent and apparently there is no any reliable workaround. 

http://www.alteraforum.com/forum/attachment.php?attachmentid=13368&stc=1  

Concerning your remark on Timing issues, Timing analysis didn't reveal any issues. 

Here is the content of .sdc file: 

create_clock -name clk -period 20 [get_ports clk] 

 

create_clock -name {altera_reserved_tck} -period 40 {altera_reserved_tck} 

set_input_delay -clock altera_reserved_tck -clock_fall 3 [get_ports altera_reserved_tdi] 

set_input_delay -clock altera_reserved_tck -clock_fall 3 [get_ports altera_reserved_tms] 

set_output_delay -clock altera_reserved_tck 3 [get_ports altera_reserved_tdo] 

derive_clock_uncertainty 

set_false_path -from [get_ports sw*] 

set_false_path -from [get_ports key*] 

set_false_path -from [get_ports sdram_dq*] 

 

set_false_path -from * -to [get_ports led*] 

set_false_path -from * -to [get_ports hex*] 

set_false_path -from * -to [get_ports sdram*] 

 

This post largely repeats the previous one due to confusion, caused by website maintenance. Sorry for this misunderstanding 

 

0 Kudos
Highlighted
Valued Contributor III
19 Views

Finally resolved, 

 

The qsys system lacked one important connected - debug_reset_request on the nios cpu. 

Once connection established, the problem disappears. 

 

https://www.alteraforum.com/forum/attachment.php?attachmentid=13416
0 Kudos
Highlighted
Valued Contributor III
19 Views

I hurried with the announce that the issue is resolved. 

When I modify system configuration in Qsys, the problem returns. Solutions that worked earlier, don't help with new configuration. 

So, this problem is recurrent. 

If my comprehension is correct, for the moment there is no any straightforward approach allowing to manage this issue. 

A real disaster !!!
0 Kudos
Highlighted
Valued Contributor III
19 Views

Here is resume of testing of 4 different configurations of the system, composed with following elements: 

  • cpu NIOS II 

  • memory 

  • buttons 

  • switches 

  • LEDs 

  • 2 timers 

  • System ID 

  • PLL* 

 

* PLL is used to generate clock for cpu and all peripherals. It wasn't present in all configurations (please, see the table below). When pll isn't used, the external clock (50mhz) was employed to clock everything 

 

These 4 configuration differ in type of memory (on-chip or SDRAM) and presence or absence of PLL. Here is resume: 

 

 

configuration feature 

system test with eclipse 

 

 

Memory: on-chip, PLL: Yes 

Works 

 

 

Memory: on-chip, PLL: No 

Downloaded, but hangs immediately 

 

 

Memory: SDRAM, PLL: Yes 

Failed to download 

 

 

Memory: SDRAM, PLL: No 

Failed to download 

 

0 Kudos
Highlighted
Valued Contributor III
19 Views

 

--- Quote Start ---  

If my comprehension is correct, for the moment there is no any straightforward approach allowing to manage this issue. 

A real disaster !!! 

--- Quote End ---  

Not really. Once you get a project configured correctly it will work each time. From what you are describing (changing a few things in the QSys project, and the whole CPU not working any more) it looks like you have a timing problem. 

I noticed in one of your post that you defined the SDRAM interface as a false path. This will probably don't work because the SDRAM requires a very tight timing and you should fully constrain it. Check also that your clock input is constrained correctly with the correct frequency. When you are using a pll the derive_pll_clocks commands in the timequest sdc file will define for you the generated clocks. You can have a look at the clocks list in the Timequest report to check that Quartus identified all your clocks and gave them the correct frequency. 

How good is your 50MHz clock source? If there are glitches it could also explain qhy the design isn't working properly when not using a pll. 

Did you enter all the information in the SDRAM controller configuration, with values adapted to the SDRAM chip you are using?
0 Kudos
Highlighted
Valued Contributor III
19 Views

And I forgot to add... once you have fully constrained your design, you should check that the compiled project actually meets all the timing requirements. Timing failure will not generate an error in Quartus, but only a critical warning. If it doesn't meet your timing requirements, you can use Quartus' timing advisor to see what you can do to your project to fix the problem.

0 Kudos
Highlighted
Valued Contributor III
19 Views

 

--- Quote Start ---  

And I forgot to add... once you have fully constrained your design, you should check that the compiled project actually meets all the timing requirements. Timing failure will not generate an error in Quartus, but only a critical warning. If it doesn't meet your timing requirements, you can use Quartus' timing advisor to see what you can do to your project to fix the problem. 

--- Quote End ---  

 

 

I've revisited the case memory: on-chip, pll: no. This time it also worked. 

Concerning cases with SDRAM, I (according to your suggestion), removed false constraints on SDRAM interface. 

Indeed, timing analysis revealed violations. 

 

Here is the content of .sdc file I used for for the case memory: sdram, pll: yes

 

create_clock -name clk -period 20 [get_ports clk] 

 

create_clock -name {altera_reserved_tck} -period 40 {altera_reserved_tck} 

set_input_delay -clock altera_reserved_tck -clock_fall 3 [get_ports altera_reserved_tdi] 

set_input_delay -clock altera_reserved_tck -clock_fall 3 [get_ports altera_reserved_tms] 

set_output_delay -clock altera_reserved_tck 3 [get_ports altera_reserved_tdo] 

 

derive_pll_clocks 

derive_clock_uncertainty 

 

set_false_path -from [get_ports sw*] 

set_false_path -from [get_ports key*] 

# set_false_path -from [get_ports sdram_dq*] 

 

set_false_path -from * -to [get_ports led*] 

set_false_path -from * -to [get_ports hex*] 

# set_false_path -from * -to [get_ports sdram*] 

 

Here are timing analysis violations for 2 SLOW models 

https://www.alteraforum.com/forum/attachment.php?attachmentid=13459  

 

They concern clock derived from pll. But, according to quartus handbook, vol. 3, the command derive_pll_clocks should resolve all pll issues (if my comprehension is correct). 

So my 1st question: should I add some constraints on the u0|pll|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divclk ? 

 

Another issue from timing analysis - unconstrained path to sdram (input and output). 

The datasheet of this SDRAM chip is quite intricate ... so (2nd question) is there some straightforward approach to specify such constraints without having to consult SDRAM datasheet ... using only information on SDRAM clock frequency ? 

 

And finally 3rd question - timing constraint on SDRAM paths should include only the following: 

  • set_input_delay commands for input ports (in my case only dq data bus) 

  • set_output_delay commands for output ports (all control signals, address bus and also dq data bus) 

 

 

or should I also specify in some way the information on sdram clock (that is 3 times external clock) ... setup virtual clock or something like this ? 

 

Concerning external clock quality ... the external clock is generated by the "Silicon Labs" CMOS clock generator si5350c-b. So I believe that quality should be Ok, but of course, nobody can be 100% sure. 

Moreover, this external clock passes through "Clock Source" component in Qsys and then is applied to all components. 

I'm not aware what this "Clock Source" is exactly ... if it's some kind of IP, probably the input signal is reshaped (???) and output clock "looks" better ? 

 

To my opinion, the timing section is one of the most obscured in the Altera documentation. 

Do exist some other sources of information on this topic ? 

 

Thanks in advance for your comments and suggestions.
0 Kudos
Highlighted
Valued Contributor III
19 Views

I've advanced in my investigations ... and discovered enormous howler in the system with SDRAM: system, built in qsys lacked clock to external sdram

I've added 2nd PLL output (please, see the qsys screenshot below) 

 

https://www.alteraforum.com/forum/attachment.php?attachmentid=13464  

 

The 2nd PLL output I parametrized as inspiring from an example that I've found in the board CD (though in that example SDRAM is used for different purposes) 

There is phase shift on 2nd output ... and I'n not aware how its value was calculated. 

 

Not finding an example how to build constraint file for design that interacts with external memory, I did it on my own. Here it is: 

create_clock -name clk -period 20 [get_ports clk] 

create_clock -name {altera_reserved_tck} -period 40 {altera_reserved_tck} 

 

derive_pll_clocks 

derive_clock_uncertainty 

 

set_input_delay -clock altera_reserved_tck -clock_fall 3 [get_ports altera_reserved_tdi] 

set_input_delay -clock altera_reserved_tck -clock_fall 3 [get_ports altera_reserved_tms] 

set_output_delay -clock altera_reserved_tck 3 [get_ports altera_reserved_tdo] 

 

set_input_delay -clock [get_nets u0|pll|altera_pll_i|general[1].gpll~pll_output_counter|divclk] 3 [get_ports sdram_dq*] 

set_output_delay -clock [get_nets u0|pll|altera_pll_i|general[1].gpll~pll_output_counter|divclk] 3 [get_ports sdram_dq*] 

set_output_delay -clock [get_nets u0|pll|altera_pll_i|general[1].gpll~pll_output_counter|divclk] 3 [get_ports sdram_addr*] 

set_output_delay -clock [get_nets u0|pll|altera_pll_i|general[1].gpll~pll_output_counter|divclk] 3 [get_ports sdram_bank*] 

 

set_output_delay -clock [get_nets u0|pll|altera_pll_i|general[1].gpll~pll_output_counter|divclk] 3 [get_ports sdram_cas_n] 

set_output_delay -clock [get_nets u0|pll|altera_pll_i|general[1].gpll~pll_output_counter|divclk] 3 [get_ports sdram_ras_n] 

set_output_delay -clock [get_nets u0|pll|altera_pll_i|general[1].gpll~pll_output_counter|divclk] 3 [get_ports sdram_cke] 

set_output_delay -clock [get_nets u0|pll|altera_pll_i|general[1].gpll~pll_output_counter|divclk] 3 [get_ports sdram_cs_n] 

set_output_delay -clock [get_nets u0|pll|altera_pll_i|general[1].gpll~pll_output_counter|divclk] 3 [get_ports sdram_we_n] 

set_output_delay -clock [get_nets u0|pll|altera_pll_i|general[1].gpll~pll_output_counter|divclk] 3 [get_ports sdram_dqm*] 

 

set_false_path -from [get_ports sw*] 

set_false_path -from [get_ports key*] 

 

set_false_path -from * -to [get_ports led*] 

set_false_path -from * -to [get_ports hex*] 

 

The essential in this constrained file is the part in bold. It manages SDRAM interface. 

Here I tried to constrain input and output with respect to sdram clock that is located on [get_nets u0|pll|altera_pll_i|general[1].gpll~PLL_OUTPUT_COUNTER|divclk] internal node. 

Seemingly this .sdc file isn't correct as timing analysis produced violations, e.g. setup violations for generated clocks and ... unconstrained paths for all SDRAM ports (!!!), despite my attempt (bold part in .sdc). 

but result was achieved, i.e. the "downloading issue" disappeared - in eclipse nios ii code is successfully downloaded and executed !!! 

 

So, probably for developing further the time violation issues should I start another topic ? 

 

Thanks.
0 Kudos
Highlighted
Valued Contributor III
19 Views

Yes the documentation from Altera on timing isn't very easy to use. You can have a look instead at this user contributed guide: 

http://www.alterawiki.com/wiki/timequest_user_guide 

IIRC there is a chapter on how to properly constrain an parallel interface such as your SDRAM using the setup and hold requirements from the datasheet. 

The derive_pll_clock command should be sufficient. You can have a look at the timequest report and see if it complains about any unconstrained clock. If it doesn't then you don't need to do anything more. 

Unfortunately I don't hav experience using SDRAMs so I can't help you about the pll settings and the phase shift. From what I know the phase shift to use depends on your layout and trace delays between the FPGA and the DRAM. 

If your SDRAM ports are still reported as unconstrained it means that Timequest didn't like the commands you put in bold. Look at the warnings from Timequest (you can search for the text "sdram_" to find them) and you should have an explanation on the reason why the command was rejected. My bet is that it didn't like the get_nets command to find the clock. You should find more information in the user guide from the Altera wiki, but as you suggested earlier the proper way to do it is to create a virtual clock and specify your input and output delays relative to that clock, if I remember correctly.
0 Kudos