nios ii console shows nothing

[Altera_Forum]

Hi, 

 I am new to nios ii and find some strange things when running just hello_world or memory_test examples programs... First it works fine with these simple programs, but when I do synthesis again and run again, nothing appears in the Nios II console.  The downloading and verifying are good as below: Using cable "USB-Blaster [USB-0]", device 1, instance 0x00 Processor is already paused Initializing CPU cache (if present) OK  Downloading 00080020 ( 0%) Downloading 01000000 ( 0%) Downloading 01010000 (60%) Downloaded 107KB in 1.8s (59.4KB/s)  Verifying 00080020 ( 0%) Verifying 01000000 ( 0%) Verifying 01010000 (60%) Verified OK  Starting processor at address 0x01000000  However after showing this the Nios II console is just blank.  I also tried program the .soc file again or do synthesis again or build the SOPC system again, but it still doesn't work... I am sure the pin assignments are ok and it works before. Any one can tell me the reason?  Many thanks.

[Altera_Forum]

Maybe your JTAG_BASE_ADRESS changed?

[Altera_Forum]

Check if jtag_uart is selected as stdin/stdout/stderr device for terminal communication in Run/Debug properties. 

Also make sure your program is actually running: if you have a spare LED on your board, toggle it in the very beginning of your program.

[Altera_Forum]

aprado thank you for your reply 

but i didn't change JTAG_BASE_ADRESS in software... and I used a same sopc info file

[Altera_Forum]

Hi Cris, 

 thank you for your answer, but can you tell me how to check the jtag_uart config? I can't find it in the Nios II SBT, thanks a lot!

[Altera_Forum]

Hi srhikari, 

At the moment I have here only a machine with Quartus 9 and old Nios IDE. So I can't tell you the exact steps for Nios SBT for Eclipse you are probably using. Somewhere in bsp properties you should find the configuration settings for stdin/stdout/stderr: you must make sure jtag_uart is selected for them. Then after you have rebuilt the application, select the Run properties for your Nios II hardware: check if jtag_uart is correctly selected as terminal communication device.

[Altera_Forum]

I found the jtag configuration in the NiosII SBT and it is set as you said. 

However the bad case still happens sometimes... it really looks like that the program is running but the console doesn't show the result. Maybe I will try another board for my project. Thanks a lot for your time.

[Altera_Forum]

--- Quote Start ---  the bad case still happens sometimes...  --- Quote End ---   The 'sometimes' means you definitely have a timing problem. Did you get any critical warning upon Quartus compilation? Is your design correctly constrained?

[Altera_Forum]

I am new in FPGA design so don't know how to "correctly constrain" the design. 

Could you give me some advises what should I do for the timing constrain? I have a camera (D5M) streaming data at 50MHz and NiosII Processor working at 100MHz to store the pixels in SDRAM (by DMA) and do some processing. What should I notice to this design? Thank you very much!

[Altera_Forum]

You'd better read the TimeQuest tutorial for more comprehensive information. Anyway these are the minimal steps: 

 First of all check if the .sdc file generated by SOPC system is correctly included in project files. If not, add it (usually is cpu.sdc if you kept the default cpu name for Nios)  Then create a new sdc file for your project (if not already done) and insert at least these commands:  - create_clock for your input clock (if the input pin clock is clk50 it would be: create_clock -name {clk50} -period 20.000 -waveform { 0.000 10.000 } [get_ports {clk50}]  - derive_pll_clocks   - derive_clock_uncertainty Include also this file into the project and recompile. At the end, check if Quartus notifies any critical warning, about timing requirements not met. If you have them you can follow the hints from the timing optimization advisor (Tools menu). If you can't solve the problem immediately, further analysis with TQ is required in order to find out the failing paths.

[Altera_Forum]

It's very detailed thank you Cris! 

I also saw these steps without explanation in the reference design, it seems i have to further analysis with TQ for my asynchronous part.

[Altera_Forum]

Hi Cris,  

I added some timing constraints to my project. Although there is a Critical Warning doesn't meet the timing requirement, the project works most of times. Thank you for your help!

[Altera_Forum]

"most of the times" is not good. It must ALWAYS work. 

If you recognized there are critical timing paths you have to fix them. It can affect your system behaviour in very subtle and impredictable ways. Problems could appear also in other modules, not only jtag uart. First of all make sure you activated the timing driven synthesis option in Quartus settings. Sometimes these timing warnings can be avoided by placing jtag_uart behind a cc bridge and operating it at a lower frequency with respect to system clock. This can help a lot with meeting timing requirements; the price paid is a slight increase system complexity, then more fpga resource used.

[Altera_Forum]

Hi Cris, I tried to solve those critical timing warnings, but with the SDC file, the warnings appear just with 'create clock' lines. It is just: 

 # Original Clock Setting Name: CLOCK_50 create_clock -period "20.000 ns" \  -name {CLOCK_50} {CLOCK_50} --------------------------------------------- create_clock -period "50.0MHz" [get_ports GPIO_1[16]] create_clock -period "50.0MHz" [get_ports GPIO_1[0]]  I really don't understand why, CLOCK_50 is a real 50MHz clock pin and when I comment the last two lines the critical warning is still there. Could you help me?