hamster

SDRAM controller.

Recommended Posts

Hi, I've got my SDRAM controller up and running on the Papilio Pro as well as the Logi-Pi.

 

http://hamsterworks.co.nz/mediawiki/index.php/Simple_SDRAM_Controller

 

It is running at 96MHz, but as it currently does the full "row open, read or write two words, close row" cycle for every memory access it isn't too fast.

 

However, 24MB/s is more than fast enough if you have any audio projects in mind... flanger, delay, chorus, reverb etc

 

Maybe somebody will write a nice roomy reverb for on the RetroCade?? 8MB is enough for 43 seconds of 48k/16bit audio. That gets you an awful lot of reverb!

  • Like 2

Share this post


Link to post
Share on other sites

Mike, set the PLL's CLKFBOUT_MULT parameter to 25 and the various CLKOUT<n>_DIVIDE parameter to 8 and you get 100 MHz.  32 MHz * 25 yields an FB clock of 800 MHz.

 

Pages 56/57 of the spartan 6 data sheet (ds162) give the min/max PLL operating range.  Fvcomin is 400 MHz, and Fvcomax is 1000 MHz.  If you feed the PLL 32 MHz and specify MULT=3, DIVIDE=1, you will be out of spec.

 

BTW, the download link for your papilio pro zip file is messed up -- clicking on it leads to the message saying I don't have permission to upload that file!

  • Like 1

Share this post


Link to post
Share on other sites

Opps! The file now uploaded.

 

The 96MHz is just because I change the "times 16 divide by 8' used on the Logi-Pi (50MHz clock) and just added another 50% on (to make it "times 24 divide by 8"). It should be in spec for the PLL, but perhaps a bit light on the thinking for my part.  :)  I'll set up the PLL later again later today and give it another few hours testing...

 

Oh, and I forgot to thank Jim for his insightful code reviews - which most probably saved me a good many hours of bug spotting - only a Muppet like me would put "if whatever_signal <= '1' then" in their code!

Share this post


Link to post
Share on other sites

I've been able to get some time to work on it this weekend, and have implemented back-to-back transactions and the peak performance is now much improved.

 

At 100MHz blocks of reads from the same row get about 186MB/s, writes to the same row get about 124MB/s and interleaved single 32-bit reads and writes to the same row now get around 80MB/s (40MB/s reads, 40MB//s writes), 

 
These are best case numbers - interleaved transactions to different rows/banks are still about 25MB/s due to the overhead required for opening and closing the rows.
 
I've also done some testing at different frequencies, and on my board the design tests out from about 80Mhz to 120MHz, so I've removed the references for a second clock signal.
 
The code is now looking a bit ungainly in places, so maybe a rewrite might be in order!
 

Share this post


Link to post
Share on other sites

Hamster, you are the man!!!!

 

I was looking at hackaday this weekend and saw a post about a SDRAM controller. :) Sure enough it was about your SDRAM controller! Glad to see the word getting out about it already.

 

The backend for the new learning site is coming together nicely now. Out of the box it was a nightmare to write tutorials using the basic wordpress editor, but after many late nights of css hacking I have something that is actually enjoyable to use now.

 

So I'm hoping to test out this SDRAM controller with something like Pacman and then write a tutorial about using it.

 

This is way cool, I can't wait to get some time to dig into it.

 

Thanks!

Jack.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now