FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6343 Discussions

Can't get DDR2 ALTMEMPHY to work on Cyclone IV E

Altera_Forum
Honored Contributor II
1,017 Views

Greetings. 

 

I am having some difficulty getting the Altera DDR2 ALTMEMPHY SDRAM controller to work on my Cyclone4E EP4CE30F23. I have configured the DDR2 controller to run in half-rate mode where the controller runs at 80/160 MHz which it derives from a 24 MHz input clock. 

 

It all seems to build OK in SOPC Builder and Quartus and I don’t appear to be getting any timing violations. 

 

The odd thing is that the presence of the DDR2 SDRAM controller somehow causes the on-chip SRAM to not function properly. I have tried running the CPU and the on-chip SRAM at 24MHz (the input clock frequency) and 80MHz (the half-clock generated by the DDR2 controller), but neither one works. 

 

I have built a test project that contains only a NIOS2 CPU, a PIO, 32kB of on-chip RAM and the DDR2 controller. When I disable the DDR2 SDRAM controller (via the ‘Use’ column in SOPC builder), I can build and run NIOS2 code in the on-chip SRAM. When I enable the DDR2 SDRAM controller, I am no longer able to run code out of the on-chip SRAM. The Eclipse console window shows the following: 

 

Using cable "USB-Blaster [USB-1]", device 1, instance 0x00 

Processor is already paused 

Initializing CPU cache (if present) 

OK 

 

Downloading 00010000 ( 0%) 

Downloading 00010ED0 (60%) 

Downloaded 4KB in 0.0s  

 

Verifying 00010000 ( 0%) 

Verify failed between address 0x10000 and 0x10907 

Leaving target processor paused 

 

Any help with this matter would be greatly appreciated. 

I have attached the FPGA/BSP/App projects for my test application. 

 

Thank you 

Scott Wild
0 Kudos
6 Replies
Altera_Forum
Honored Contributor II
229 Views

Attached project files.

0 Kudos
Altera_Forum
Honored Contributor II
229 Views

Is your design properly constrained, and does it pass all timing requirements? Parts of one design affecting another are usually an indication of timing problems.

0 Kudos
Altera_Forum
Honored Contributor II
229 Views

I believe it is. 

 

I constrained my 24 MHz input clock and all PLL generated clocks with: 

create_clock -name {sys_clk_in} -period 41.666 -waveform { 0.000 20.833 } [get_ports {sys_clk_in}] 

derive_pll_clocks 

derive_clock_uncertainty 

 

and I made sure the megawizard generated files 'altmemddr_0_phy_ddr_timing.sdc' and 'cpu_0.sdc' are included in the project. 

 

Thanks 

Scott
0 Kudos
Altera_Forum
Honored Contributor II
229 Views

What about the I/O pins with the DDR chip? If they are not constrained they should appear in red in the Timequest report (Unconstrained paths).

0 Kudos
Altera_Forum
Honored Contributor II
229 Views

Hello. 

 

My TimeQuest report looks Ok. I ran the *_pin_assignments.tcl file and modified the default pin names to match the pin names in my design. 

 

Thanx 

Scott
0 Kudos
Altera_Forum
Honored Contributor II
229 Views

It looks like the problem was related to the fact that I was using two x16 memory parts in parallel (effectively creating a 32-bit external memory interface). 

 

When I reconfigured my DDR2 ALTMEMPHY controller to only use one of my two memory chips, it works. 

 

I guess the question is now 'How do I properly tell the DDR2 wizard to use two x16 memory chips'? The only change in the wizard configuration that I did to make it work was to change the 'Total Memory Interface DQ Width' from 32 to 16. 

 

Thanks 

Scott
0 Kudos
Reply