Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20707 Discussions

Cyclone V + Micron DDR3 + Uniphy + NiOS == always freezing

Altera_Forum
Honored Contributor II
1,858 Views

Dear All, I beg your support (and begging I meant serious :(), 

 

after three consecutive weeks of having burned engineering time, I decided surrendering with that Cyclone V Dev board and to post a thread at this forum. 

 

tools used 

ide Quartus 12.1 64Bit, Qsys, NiOS Eclipse Indigo 

fpga 5CGXFC7D6F31C6NES (2x Hard-IP DDR, 2x Hard-IP PCIe) 

board Altera official Cyclone V GX Dev Kit Board (with PCIe edge connector) 

ddr ram Onboard DDR3 RAM. Micron MT41J128M16JT-125 (x2, i.e. 32Bit data, 256MByte) 

 

troubles 

System containing NiOS + Uniphy DDR3 Soft-IP + DDR3 RAM wouldnt work when being debugged AND/OR free-ran

 

flow 

  • Qsys generates w/o significant warnings (ODT is disabled, Quick Simulation, nothing spectacular). 

     

  • Quartus Analysis/Synthesis performs w/o significant warnings (e.g. synthesized-away nodes, pin stuck at lo/hi, etc... usual round of suspects). 

     

  • After Analysis/Synthesis, Qsys generated pin assignemt .tcl script can be executed w/o any warning. 

     

  • Fitter/Assembler perform w/o significant warnings (e.g. time limited .sof, ... ). 

     

  • Download works just fine. 

     

  • NiOSII Eclipse IDE BSP generation, MAKE, download and debug works correctly -- as long as only onchip SRAM is accessed.  

  • As soon as DDR3 memory is accessed, debugger suspends, "stepping" is being shown and debugger would never return, neither is pausable.  

 

 

checks performed to date 

  • Probed all major pins using a GHz scope. Such as LVDS Clk_in (125MHz), LVDS MEM Clk_out (350MHz), MEM_RSTn, etc.... Pins' levels seem conclusive. Clocks running, no stuck at reset.  

  • NiOS Debugging-view provided memory dump works on onchip SRAM only  

  • a.s.a. DDR3 RAM address range is specified in memory dump window, "stepping" and subsequent freeze haunts me again.  

 

 

 

evidence (three screen shots) 

 

  1. NiOSII IDE - Source Code which proved to run as long as DDR3 (again) is not accessed 

  2. QSYS connectivity map 

  3. Quartus schematic (sorry for showing to you this vintage kind of block design, but I love having a schematic type of design file constituting the top level entity of my designs (I used to work with Max+PLUS II in former times, ahh... Flex10K FPGAs + MAX CPLDs, good old times, being reminiscent for a moment.... :rolleyes:) 

 

 

 

Thanks in advance for literally any kind of comment....I dont know how to proceed in this design... 

BRgds 

Kai 

 

P.S. The Uniphy DDR3 is configured for using Soft-IP only, since I wanted to start out low and get levels of complexity added subsequently one at a time, i.e. not messing around with Hard-IP or PHY-only too soon.
0 Kudos
4 Replies
Altera_Forum
Honored Contributor II
756 Views

I'm not familiar with your device or board, but the behavior described sounds like the controller is not accepting commands (leaving the Avalon "waitrequest" asserted indefinitely, and hanging your NIOS). 

 

What is the state of the local_init_done, local_cal_success, local_cal_fail signals?
0 Kudos
Altera_Forum
Honored Contributor II
756 Views

Dear Kai, 

 

Even i'm using same board(Cyclone V GX) & facing the issue same as you, please let me know whether you got any fix or work around to it. 

 

only difference b/w you & me is , I'm using Quartus 14.0 ver.  

 

 

 

please kindly help me.. 

 

thanks & regards, 

Amar
0 Kudos
Altera_Forum
Honored Contributor II
756 Views

Why not try running the External Memory Interface Toolkit (EMIF) and check the DDR3 margins? 

 

Post#5 in this thread 

 

http://www.alteraforum.com/forum/showthread.php?t=43992 

 

Has a DDR3 hard-memory-controller test for the BeMicro-CV board (read the readme.txt file in the DDR project folder). 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
756 Views

There is a bug in the memory controller, so you need to manualy change some lines of a file generated with Qsys. 

 

If you check in examples you got with the board in file: 

 

cycloneVGT_5cgtfd9ef35_fpga\examples\board_test_system\qts_ddr3\c5gt_ddr3.zip\c5gt_ddr3\c5gt_ddr3.v  

 

it says: 

 

 

/* !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !! You manually have to fix the HMC issue. !! Open the uniphy top RTL(q_sys_fpga_sdram.v) !! then, find the line that contains... !! .mp_cmd_clk_1(1'b0), !! change this to !! .mp_cmd_clk_1(mp_cmd_clk_0_clk), .mp_cmd_clk_1 (mp_cmd_clk_0_clk), // (terminated) .mp_cmd_reset_n_1 (mp_cmd_reset_n_0_reset_n), // (terminated) .mp_cmd_clk_2 (mp_cmd_clk_0_clk), // (terminated) .mp_cmd_reset_n_2 (mp_cmd_reset_n_0_reset_n), // (terminated) .mp_cmd_clk_3 (mp_cmd_clk_0_clk), // (terminated) .mp_cmd_reset_n_3 (mp_cmd_reset_n_0_reset_n), // (terminated)
0 Kudos
Reply