- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 WildLink Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page