Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12590 Discussions

Nios Processor Troubleshooting Help

Altera_Forum
Honored Contributor II
2,176 Views

Hello, this is my first post on these forums so excuse me if this is already covered elsewhere. I have searched for threads describing problems similar to mine but I haven't figured this out. 

 

I currently have a custom board setup with a Cyclone II device and an ISSI and EPCS device for memory. My design in Quartus includes some peripherals and a Nios II processor built using SOPC builder containing the processor, SDRAM controller, EPCS controller, as well as a module for a USB port.  

 

I am running a C++ program from a PC to communicate with the Nios processor via USB cable. I can send various commands to it, such as a "welcome" command which turns the LEDs on in a noticeable pattern. 

 

A few months ago, I lost the ability to program the FPGA board. The lights would stay dimly lit until I used Quartus programmer to put new firmware, but on reboot it would disappear. I was also having trouble loading the .elf file into the relevant area on the board (I'm still not sure where this would be, but I'm guessing the ram for the processor to be running?), because before I would load both the .sof and .elf file into the EPCS. 

 

When I tried to talk with the processor, it would say the port was opened but there is no answer. We guessed it was something to do with the EPCS chip and the .elf file wasn't ever getting loaded, so we replaced the EPCS chip. 

 

This seems to have fixed the reboot problem. The lights do not stay dimly light up anymore and the Quartus firmware gets loaded on reboot. However, I have no way of verifying whether the .elf file gets loaded. Before, the LEDs would light up in the "welcome" pattern every time the processor powered up (or the board was reset, etc), and I have not seen that yet. I can open the USB port still but again no answer. 

 

Something strange that happened: when I was switching my USB-Blaster cable from the Active Serial connector to the JTAG connector, as I was wiggling it out of the AS connector, the LEDs lit up in the "welcome" command pattern, as if the processor started up. However I wasn't able to open coms with the USB port in time to see if the processor was responding. 

 

The person who designed this setup isn't available and I am a novice in Quartus and Nios, so I might be missing something elementary. Any help in troubleshooting this? Perhaps a debug tutorial relevant to a setup similar to mine? I haven't had any luck tracking down tutorials or examples that can help. 

 

Could this be caused by a physical hardware issue, such as a bad USB port (though that doesn't explain the LEDs not lighting up)? Bad RAM? Bad Cyclone II?  

 

Thank you...
0 Kudos
14 Replies
Altera_Forum
Honored Contributor II
501 Views

If you power your board without anything connected to the AS or JTAG ports, does it start and show the welcome pattern? In that case it could mean the USB cable somehow disturbs the communication with the EPCS during power up. 

If you do everything through JTAG (load a .sof configuration through the Quartus programmer, load the .elf file through nios2-download, open a nios2-terminal) does it work?
0 Kudos
Altera_Forum
Honored Contributor II
501 Views

Hi, thanks for the reply! The welcome pattern would still not light up if I did that, however I think I inadvertently tracked the problem down. I am using a PLL to get a clock from my base 40 MHz to 400 MHz and run a bit stream. It looks like under 80 MHz, everything works fine, but when I increase the clock to 400 MHz, I receive errors that the Nios processor does not match the specified value, and/or that "erase failed at offset 3000" when I try to upload the .sof and .elf files.  

 

What could be causing this? I want to make a note, I had to build this system from a zipped archive and I haven't successfully got the Nios IDE to build, so I am stuck with making only minor changes to the .sof file that wouldn't necessitate rebuilding the .elf file.
0 Kudos
Altera_Forum
Honored Contributor II
501 Views

Going to move this to the Nios II section of the forum (you'll have more Nios II experts see your post this way)

0 Kudos
Altera_Forum
Honored Contributor II
501 Views

 

--- Quote Start ---  

Going to move this to the Nios II section of the forum (you'll have more Nios II experts see your post this way) 

--- Quote End ---  

 

 

Ah thanks, I suppose it fits better there.
0 Kudos
Altera_Forum
Honored Contributor II
501 Views

A Nios CPU at 400MHz is too much for a Cyclone II. A 100MHz system frequency would be more reasonable. Did you constrain all your clock and does the design meet all timing requirements after a compile?

0 Kudos
Altera_Forum
Honored Contributor II
501 Views

If you tune the design assuming it caters well to it, you could exceed 150MHz. Make sure you check the timing report. I have a saying..... "If Timequest shows red, your design is dead" :) (in your case you are using TAN since Timequest is only used on Cyclone III and up) Also meeting timing doesn't necessarily mean you have working design either.

0 Kudos
Altera_Forum
Honored Contributor II
501 Views

I started with a design that just contained the block the SOPC builder created, fed by a clock running at 40 MHz. With this I could communicate via USB cable and send commands. 

 

I needed to add a pseudo-random bit stream running at 400 Mbps so I took a second clock and fed it into a PLL to produce a 400 MHz clock. I then fed this into a linear feedback shift register and output to a LEMO pin. I have not added any timing constraints as this has never been as issue, is this important for a design to function correctly? I am a novice and I hoped I could add this bit stream next to the Nios system without affecting it. At the moment I can either communicate with the Nios CPU and have a slow bit stream, or get the Nios CPU error and have a fast bit stream.
0 Kudos
Altera_Forum
Honored Contributor II
501 Views

You CAN'T run 400 mhz inside a cyclone II. 

Also a time constraint file is fundamental to any design... make a SDC file and i bet you are going to see a lot of critical warnings
0 Kudos
Altera_Forum
Honored Contributor II
501 Views

http://www.altera.com/literature/hb/cyc2/cyc2_cii5v1_01.pdf 

 

In the table on 5-66, the maximum output for a global clock is 402.5 MHz for my speed grade. My clock is 400 MHz, and although the bit stream isn't as clear as at 40 MHz when measured on the oscilloscope, it still serves my purpose.
0 Kudos
Altera_Forum
Honored Contributor II
501 Views

That is a maximum FPGA fabric frequency. Interconnects and soft processors are fairly complicated so it's physically not possible to achieve those speeds in an FPGA. That maximum speed is achievable for logic like this: 

 

Register --> little bit of combinational logic --> Register --> little bit of combinational logic --> etc....
0 Kudos
Altera_Forum
Honored Contributor II
501 Views

Hm, so is that to say the signal I'm seeing on the oscilloscope isn't actually 400 Mbps? I'm seeing 10 bits per 25 ns, albeit the eye diagram isn't the prettiest. Anyway, would this be related to the Nios CPU at all? Or is that the timing constraints. I have found a tutorial on TimeQuest I will try to implement on my design...

0 Kudos
Altera_Forum
Honored Contributor II
501 Views

There is no limitation stopping you from connecting a 400MHz clock to logic. I'm just saying you'll never meet timing at 400MHz with something like a Nios II processor in today's FPGAs. Running a Nios II core at 400MHz would be like clocking an Intel Xeon at 16GHz (which won't work either for the same reason).

0 Kudos
Altera_Forum
Honored Contributor II
501 Views

I see. I suppose it was naive to think the Nios processor wouldn't be affected when I added an additional component to the FPGA running so fast, thanks for the clarification.

0 Kudos
Altera_Forum
Honored Contributor II
501 Views

Just an update, I seem to have fixed this issue. In case anyone has similar symptoms in the future: 

 

My original design had two PLLs, one producing the 40 MHz clock for the Nios system and one producing a 400 MHz for the LFSR. When I used a single PLL with two clocks, at 40 and 400 MHz, the issue disappeared.
0 Kudos
Reply