Problem with downloading of a NIOS II program

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

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

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 !!!

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

--- 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?

--- 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.

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.

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.

Thanks Daixiwen,

Indeed the manual from your link looks much better than corresponding Altera chaptrer from Handbook, vol. 3.

I'will try to use the information from it to workaround my constraint file.

Unfortunately this document is incomplete - the sections 6 ... 10 are empty.

At first glance I didn't find chapter on how to manage SDRAM constraints ... perhaps the concerned information was in Section 9 "Examples", which is actually empty.