Forum Discussion
Altera_Forum
Honored Contributor
20 years ago --- Quote Start --- originally posted by atjung@Feb 6 2006, 07:59 PM jdhar,
it sounds like you are on the right track to debug this problem by isolating the ddr peripheral.
since you mentioned signaltap works (jtag is probably not the problem), the issue could be how the ddr chip interfaces to the avalon switch farbic through the ddr controller.
have you used signaltap to probe the ddr pins and the ddr controller avalon interface signals? if the ddr controller is getting some bad signals from the ddr ram (i.e. poor solder connection, mis-wired ddr ram connections to ddr controller), it could be sending random signals into avalon perhaps tying up the whole system.
regards,
-atj
<div align='right'><{post_snapback}> (index.php?act=findpost&pid=12582)
--- quote end ---
--- Quote End --- Thanks for the reply. You can't use SignalTap to probe the DDR pins directly, as it adversely affects the timings. I don't see how the DDR can be getting bad signals since I have run Alteras Example Driver (generated with the IP Core) on the board, and the test does pass. I have verified that it is in fact testing the RAM by lifting one of the data pins, causing it to fail. 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!