- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I have problem with system with two NIOS, therefore I'm asking for help. At power on, very often (around 30% of trials) second NIOS processor won't start. Details: In one qsys is present NIOS (let's call it A) with some simply additional components, like internal memory, PIO, UART, timer, etc.. In second qsys (B )also is present some simply modules. This nios has also switched on feature cpu_resetrequest/cpu_resettaken. Both qsys are included into main qsys. There is i.e. PLL dedicated to supply clocks for both NIOSes (A and B ). In NIOS A is present also one input and one output (let's call it IN and OUT) for managing reset of NIOS B (thanks to cpu_resetrequest feature). Of course these two lines are connected with proper pins form NIOS B outside qsys (in bdf file). This should work in following way: When FPGA is boot up, then memory of NIOS A is loaded from EPCS, it start up, then assert OUT connected to cpu_resetrequest. NIOS B after few clock should replay by 10101.. signal on cpu_resettaken, which is connected to IN. Then NIOS A should load SRAM with program dedicated for NIOS B. All these procedures are ready and stored in EPCS. It's working, but very often I see that NIOS B isn't responding by asserting signal cpu_resettaken. It's looks like processor is dead. Therefore preliminary I reject suspecting of incorrect code, wrong reset vector, etc. For me problem began earlier, during building in fpga "hardware of NIOS" (sorry for my not professional description of this process). Some comments: - I never saw problems with NIOS A. It always start correctly (I see logs in serial terminal), - Reset signal for NIOS B, cpu_resetrequest and cpu_resettaken I drag outside to outside pins and I monitor them on oscilloscope. So, I'm sure what is happen there, - into main reset is also added condition for pll locked for main PLL clock. So, both nioses will not start until PLL is not ready, - NIOS A and NIOS B use same clock's. So, I think that, problem isn't in it. - I check report in TimeQuest. There is some problems with timing, but all of them are in some old part of bdf file. This logic elements aren't connected at all with NIOS B, - I program same project in other board (same design). Result was the same, - I work on Cyclone III (custom board, old and verified by customers solution), Quartus 13.1. Is there anybody, who can give me any clues, how to find solution? I read about some problems with hierarchical qsys (i.e. interrupts). Is it possible that there is also other problems with such hierarchical qsys project? What else can cause blocking of cpu_resettaken signal? thank you in advance, GregorLink Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did you poll the cpu_resettaken before de-asserting the cpu_resetrequest signal? The cpu_resettaken is some sort of an acknowledgement/handshake signal for the incoming cpu_resetrequest. cpu_resetrequest should not be a toggling or de-asserted until the cpu_resettaken goes high.
The cpu_resettaken is also affected by Nios internal pipeline stalls. Maybe due to accessing long latency slave from the instruction or data masters. You can try to tap the signals at the Nios B interfaces to see whether there is any on-going activity.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page