Forum Discussion

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

nios2 processor non responsive

Hello everyone.

I have created a design in SOPC builder with a NIOSIIf core which has a MMU. The SOPC file for the same is here (https://docs.google.com/open?id=0b8b-p7uizx09ztfmnwi0ntqtmdcyni00mty5ltlkotutmwnkyjq5zgi1m2mw).

Furthermore, I am using a DE1 board so I have used the pin assignments that came with the CD. I instantiate the core in a BDF file and then attach pins to it. The entire project contents can be found here (https://docs.google.com/open?id=0b8b-p7uizx09otu2njewyzatndflny00mdg0lthlzjctmzrkodyyngm3mjc0). The quartus version is 11.1sp1.

After I instantiate I burn the design using nios2-configure-sof and then later I try to download the image of uboot which I created as described in the wiki (http://www.alterawiki.com/wiki/dasuboot). On issuing the following command: 

nios2-download -g u-boot

I get the following errors: 

Pausing target processor: not responding.
Resetting and trying again: FAILED
Leaving target processor paused

On searching the net, the most I could get was that the reset pin gets asserted and hence the processor is never able to get out of reset. But in my own case, I have connect the reset_n input pin to KEY[0] the first pushbutton switch which when pressed connects the pin to ground.

Some people were also told to try the design using an e core instead of an f core here (http://www.alteraforum.com/forum/showthread.php?t=32665&highlight=nios2+processor+non+responsive). By the way, is the DE1's 8MB of SDRAM that insufficient even for downloading the u-boot image? Which is hardly 530 KB. Then again it is not even getting downloaded in the first place

Some people said that it is time limited for the f version...which even my sof tells me..but this happened the very first time and then it never changed..

Some fellows were trying to use C++ libraries while creating a BSP. Where should I start looking?? Itd be great to hear some tips, pointers from people here.

Regards,

Aijaz

12 Replies

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

    Also Mheng also faced a simiar issue (http://alteraforum.org/forum/showpost.php?p=123526&postcount=1)and he solved it by changing his timing requirements (http://alteraforum.org/forum/showpost.php?p=123535&postcount=3)

    So how does one go about solving the timing requirements issue? I mean which component does one start with? Does one has to check clock skew first? (I used the PLL generated clock for all the components).

    Ive used the standard components in my design (nothing custom).

    I am going to read up about doing a timing analysis but I would like to know what to look out for as in what kind of a test bench does one need for this timing analysis?

    Id be glad if someone could give me some pointers.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    It looks like the timequest timing analyzer is telling me: 

    Warning (332060): Node: CLOCK_50 was determined to be a clock but was found without an associated clock assignment.

    I have at least a hot trail to pursue now..but if anyone has information about the same, be my guest and help me fix this one :). Im sure there are many out there out on the same trail as me..

    Regards,

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

    Hello people.

    I am not able to understand how I should proceed (if at all I am proceeding in the right direction here). I would be glad if someone could clarify a few sticking points I have:

    1. After analyzing many upon many threads, some related some not, I am hypothesizing that my non responsive processor could be mainly because I have not met timing requirements in my design. Am I correct on this one?

    2. The most troublesome warning for me was the one I showed above, which says that my node does not have an associated clock. After going through a couple of threads, I think that I should manually tell Quartus that that node is indeed being driven by an external clock. Is that correct? Or is it so that quartus has understood that it is so but the timing requirements have not been met (but how could that be possible since the oscillator core is not my component. Its an onboard component).

    3. Is there anything else besides the clocking issue that I should think about? I am not using any custom components.

    I am keen to hear from you folks
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    For a correct timing analysis, you should create a sdc file that describes all your clock sources. Timequest should get your timing requirements from that and will tell you if your design fullfills them. This should be the first thing you do.

    Are you using a pll? If yes have a look at its "locked" output, to verify that it is getting a correct clock signal. Also be careful with the reset signal. The reset input on a SOPC design is active low, so must be high when you try to communicate with the Nios processor.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Hello.

    Yes I am now using the timequest timing analyzer to constrain my clock. What I am doing is (after going through the timequest quickstart tutorial and the timequest cookbook):

    1. I run the compilation just before the fitter step so I can create a post map netlist (whats the difference between post fit and post map netlists by the way? The quick start guides and other documentation usually create a timing netlist based on post map. Any specific reason?)

    2. using 
      derive_pll_clocks -create_base_clocks
      to inform timequest about the presence of a PLL and automatically update all the places it is being used

    3. updating the timing netlist

    4. writing an SDC file out of that

    5. adding the SDC file in my project

    Now I see that there is already an SDC file called cpu_0.sdc or something in my project directory. I believe this is a default setting. I wonder what that does.

    Nevertheless, after doing that I rerun the entire compilation. This time the timing requirements are met (but I have not added the DMA controller yet, which was one of the components causing most, but not all, of the timing failures). Since I cannot get the usb blaster II driver to work in Linux (thats fodder for another thread), I recreate the entire design in the windows version of quartus doing exactly the same steps as I was doing in Linux but on windows the timing requirements are not met (despite not adding the DMA controller). This is puzzling me a lot..one thing I notice is that quartus reports (in the critical warning section) in windows that the PLL mode has been changed (automatically) to 'no compensation'. Perhaps that has got something to do with the timing requirements being not met..

    FYI I have tristated all unused pins with a weak pull up (at the project level), to avoid mistakingly resetting the reset pin (which is active low) so (I hope) no issues there. Additionally daixiwen suggested 'watching' the clocked output. So you mean I should actually watch the input to the PLL and the output waveforms using ..modelsim ?? But that will a purely simulational watching right? And since im using the web version, I cannot use signal tap too..could you please elaborate about this

    I have posted a lot I know but I believe this to be necessary since suggesting a way forward might require as much if not more input.

    To summarize I want to know the following:

    1. Why is a design which works on Linux fails to do so in windows as far as timing analysis is concerned

    2. Why is it that DMA causes the timing analysis to fail (even after constraining the PLL clock in the above mentioned fashion)? How do I go about fixing that? (I know this is easier said than done, but if pointed to in the right direction, I'd take that as an exercise and pursue it relentlessly keeping you guys posted here.)

    3. It was mentioned in the last post about 'watching the output of the PLL'. Id be glad if that could be elaborated more on (perhaps this question would get covered under the answer to the 2nd point which makes it redundant. But in case it isn't, here it is :) )

    I am keen to hear from you folks..

    Regards,

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

    Yes I was suggesting using Signaltap to control your signals. You can use Signaltap even with the web edition and the opencore license evaluation, even if it is a bit more complicated. You need to run the Quartus programmer outside of Quartus (run it directly from C:\Altera\xx\quartus\bin\quartus_pgmw.exe) and then you can still use the other Quartus windows (including SignalTap) when running in evaluation mode.

    Alternatively you can cable the Pll locked signal to a LED, but double check the polarity.

    Did you declare your clock source in the SDC file? This needs to be done manually, because Timequest won't get the source clock frequency automatically from derive_pll_clocks. It will just apply the multiplier/divider ratios, so if the source clock frequency isn't defined correctly, all the others will be bad too. In Timequest you can use the clocks report to check that all the frequencies were picked up correctly.

    What kind of timing failures do you have? It shouldn't be linked to PLL compensation.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I have never really used signal tap since my motive here is to quickly get a NIOSII system up and running so I can play around with Linux/uCLinux, but it looks like I'd have to delve a little deeper into EDA stuff than I had initially expected :rolleyes: . So Ill look into that.

    By the way, when you say connect the PLL out clk to the LED, it is in the schematic right? I mean just connect it directly to one of the LEDs so I can watch it go 'blinky'?? :o. But me as a human won't be able to distinguish between a steady LED and an oscillating one as 85MHz is to too much to keep track of using my human eye. May be I've got you wrong here. Could you please elaborate?

    Additionally I am using the 
    -create_base_clocks
    switch while using the 
    derive_pll_clocks
    timequest command so (as per the cookbook) the source clock setting is already calculated by timequest. You can take a look at the SDC file I am attaching with post.

    I am also attaching the timing failure reports along with this post. The 'Slow model' and the 'multi-corner timing analysis' failed. Hope these reports along with the SDC file will give us a clue..the sdc file has been appended the .txt extension.

    Keen to hear from you,

    Regards,

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

    Oh okay, I didn't know that option. In that case you are right, the derive_pll_clocks should be sufficient and you don't need to create the clocks in the sdc file.

    What frequency are you generating from the pll?

    It seems that most of your timing violations are on paths between the CPU and the DMA component (the "top failing paths" in Timequest is very useful for that). Try to add an Avalon Memory Mapped Pipeline Bridge between the CPU and the DMA component and see if this helps.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Oh and just to be sure... you do know that if you have the Opencore evaluation window open after having configured the FPGA, you de need to keep it open, don't you? If you close it then the Nios CPU will stop.