NIOS II JTAG Download errors

--- Quote Start ---

originally posted by jdhar@Feb 7 2006, 10:06 AM

i have two oscillators going to two plls on the board; i use one of the plls for the ddr, and another to clock the rest of the system (processor included)... this is working much better. i can run the two at different speeds, and boot uclinux. if it wasn't for the extremely long compile time (1.5hours on my 3.2ghz dual core amd!!), i would try going back to a single clock, but i think i will just be happy with the way it is right now.

i'm not convinced it's jtag either since signaltap works, and i separated the core and processor and it still worked. but on the nios ii ep2c35 reference design by altera, they have it clocked by one clock, so i'm sure it's not a bug in sopc.... oh the problems!

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=12607)

--- quote end ---

--- Quote End ---

jdhar,

I wonder if the problem could be related to possible phase differences between the two oscillators/PLLs on the board causing the DDR controller to be in an unknown state. I believe the Altera 2C35 example uses one PLL to generate the clock to the system(c0 - sysclk) and DDR ram(c1 - write_clk_to_ddr_sdram). Looking at the PLL settings used the c1 clock used for the DDR ram has a -90 degree phase shift.

You should be able to narrow this down if you use SignalTap to probe the DDR peripheral interface to the Avalon switch fabric interface. Since the entire SOPC Builder system is an HDL file, you can grab nodes from the verilog/VHDL file. In fact, you can montior the Nios II processor interface signals to the Avalon switch fabric with SignalTap. I found the following App note on SignalTap (Using SignalTap II Embedded Logic Analyzers in SOPC Builder Systems) helpful in finding those internal nodes:

http://www.altera.com/literature/an/an323.pdf (http://www.altera.com/literature/an/an323.pdf)

I use ModelSim simulation to learn about the Avalon switch fabric interconnect signals (address, read/write, oe, readdata, writedata and waitrequest). All the Avalon signals should be synchronous at that stage so there should be no timing impact to the DDR pins.

By searching for the key Avalon control signals and monitoring them, it might offer a clue to why the target processor is "not responding" when you run SignalTap while downloading a program. You can probe the Nios processor signals or the DDR peripheral signals connecting to Avalon.

For example if the Nios II processor is trying to access DDR, but it has a waitrequest asserted from the DDR ram it will hold the Nios II processor in a wait state and could be locking out any other processor operations including JTAG debug used to download programs into memory. This might be the case since you mentioned when the DDR is removed from the system your programs download and run, but when you hook up the DDR ram to the system it starts to exhibit problems with connecting to the processor.

Regards,

-ATJ