- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have something to read and ponder over here (http://seriallite.net/support/kdb/solutions/rd06092011_472.html). However if someone has something that is bound to work, please do educate us all...
Thanks- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:- 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?
- 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).
- Is there anything else besides the clocking issue that I should think about? I am not using any custom components.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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):- 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?)
- 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 - updating the timing netlist
- writing an SDC file out of that
- adding the SDC file in my project
- Why is a design which works on Linux fails to do so in windows as far as timing analysis is concerned
- 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.)
- 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 :) )
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi daixiwen..
thanks for the advice..adding the avalon MM pipelined bridge seems to work. Atleast I do not see any timing violations in my design in Linux.. Additionally I do not understand what you mean by --- Quote Start --- 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. --- Quote End --- What exactly is this window here? And do I need to close it before downloading the SOF?? or otherwise always keep it open as long as I want my nios2 to work?? Thanks in advance :)- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is a window that is opened if the Quartus programmer uploaded a time limited .sof (which happens when you compiled a design with cores you don't have the license for). It says something like "opencore plus evaluation" and prevents you from using the programmer further. You need to keep this window open, or else all the licensed components (including the Nios II CPU) cease to work.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page