OpenCores

Scratch DDR SDRAM Controller

Issue List
Problems with 1600E #1
Closed overclocked opened this issue about 15 years ago
overclocked commented about 15 years ago

Thanks for sharing this! After reading LOTS of posts with 500E/1600E Starter Kits owner who struggles with getting the DDR to dance foxtrot I think maybe your super-simple core could be the OPTIMAL solution! I will try to help you out as much as possible to get this baby running!

I've tried you the core on my Digilent/Xilinx Microblaze Starter Kit (featuring a 1600E) but cannto get the LED's to light up.

An idea to get more users of the core an simpler start-up for us non-pro's is to include a synth-library with ready-made ISE-project files which is possible to run right-away. I know there are lots of different versions and so on, but at least target the last released or best working just now. One of the problems that this may overcome is to get a working UCF-constraint file which is a job in itself.

Is there some signals missing/being incorrectly named in the committed last version? 50Mhz vs. 100Mhz maybe changed in one place but not in the other.. or have the DCM been cut away? Maybe this should be done in some other way..

In my case I've put together a UCF that maybe is correct for my board, included a 50=>100Mhz DCM on the top-level but it does not work. The 500E and 1600E shall have the same DDR-RAM connection but it seems to be missing some important signals: CAS/RAS/DQS_Div0 or is these not important when using the chip in simple ways? I'm a complete idiot with SDR/DDR to day.

If you could commit your whole project with all synth-specific files in a Xilinx/500E under folder that would make my day! :-)

lynn0p commented about 15 years ago

The testbench synthesized? The latest source files should not have synthesized with the testbench at all. I've neglected to keep the testbench in sync with the controller. For one thing, you now need to supply an external DCM or a native 100mhz clock to the controller now, and the testbench has definitely not been updated to do that :P

You definitely should update to the latest source, as I did discover some bugs and fixed them.

I'll update the testbench to work with the latest source and check that in.

As far as board pinouts and UCF parameters, I can't be of much help if it's not the same board that I'm using. You'd probably do best to ask someone who has the exact board type you're using. I can definitely say that those signals you mentioned are all vital to the SDRAM chip's function and that they must be routed to the right pins or a whole lot of nothing will happen.

Nevertheless, you're probably going to have to do some work to modify this code to run on your board. Fixes and ports are happily welcomed!

lynn0p closed this about 15 years ago
lynn0p commented about 15 years ago

Ok, I updated the testbench. It now synthesizes and I'm getting correct LED patterns from it when I upload it to my Spartan3e Starter Board. I'm closing this bug.

As far as configuring it to work on another board, you're probably going to need to talk to someone who has that exact board type and knows something about SDRAM controller design.

I'd be happy to do the port if someone donated hardware and maybe some other stuff to me :) :) :)

lynn0p commented about 15 years ago

I've gone ahead and checked in a tarball of the project I use to build the testbench on my machine.

From what I've looked at, the 1600 gate version of the starter board looks the same, but I'm taking a very conservative stance here. I don't know for sure that the project settings for the 500k gate board are compatible or not.

It's your responsibility to make sure the project settings won't do anything harmful to your board.


Assignee
No one
Labels
Request