SDR SDRAM controller for Xilinx Spartan-3E

Hello,

I would like to utilize a controller for a SINGLE data rate SDRAM
(Micron MT48LC16M16A2TG-75, to be specific). In the past I've used
Xilinx' MiG 1.4 to obtain a DDR2 controller, which I ended up pretty
happy with (after forgetting the via dolorosa to set it up...). Its
main benefit is a simple and convenient FIFO-based user interface.

For some reason, I thought that MiG would create an SDR controller as
well (it's simpler, after all), but it turned out I'm very wrong: The
last piece of attention on Xilinx' behalf to SDR, which I've managed
to find, is xapp134. That paper, along with its HDL code, originates
in 1999, and is more or less the same ever since. The controller
offered is hence adapted to Virtex-I and Spartan-II, and is yucky is
several respects.

Newer application notes (as well as MiG) relate to faster memory
classes (DDR, DDR2, QDR, you name it), with controllers eating up some
clock resources to solve timing problems. And all I wanted was a cheap
memory with reasonably simple access.

Given the situation, I'm considering to create a DDR controller with
MiG for a memory with similar attributes (bus width, array size, etc)
and then hack it down to SDR. Since the command interface is the same,
that should leave me with changing the data flow, and make the burst
timing right. Not much fun, but hey, after debugging the MiG DDR
controller, I should survive this one as well.

And here's the irony: I picked this SDRAM to make things simpler for
me.

So before I start this little self torture, does anyone have a better
idea?

Thanks,
     Eli

Eli Billauer wrote:

> And here's the irony: 
> I picked this SDRAM to make things simpler for me.
> So before I start this little self torture, does anyone have a better
> idea?

I would consider a revision to the circuit board.
How long will a MT48LC16M16 be stocked by distributors?

  -- Mike Treseler

On Aug 4, 3:38 pm, Mike Treseler <mike_trese...@comcast.net> wrote:
> I would consider a revision to the circuit board.
> How long will a MT48LC16M16 be stocked by distributors?

Well, the board is already assembled and under initial hardware
checkups. So it's a bit late for that...

And honestly, I can't see why DDR should be used when the bandwidth
isn't required. From my previous experience, it's far more complicated
than talking with an SDR chip, which is more or less like any
synchronous chip.

   Eli

NorthWest Logic provides a SDR controller for the Spartan-3E. Xilinx
only provides DDR and more complicated reference designs.

More info here:
http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=SDR_SDRAM&sGlobalNavPick=&sSecondaryNavPick=

Cheers
Jaco

On Aug 4, 1:04 pm, Eli Billauer <e...@billauer.co.il> wrote:
> Hello,
>
> I would like to utilize a controller for a SINGLE data rate SDRAM
> (Micron MT48LC16M16A2TG-75, to be specific). In the past I've used
> Xilinx' MiG 1.4 to obtain a DDR2 controller, which I ended up pretty
> happy with (after forgetting the via dolorosa to set it up...). Its
> main benefit is a simple and convenient FIFO-based user interface.
>
> For some reason, I thought that MiG would create an SDR controller as
> well (it's simpler, after all), but it turned out I'm very wrong: The
> last piece of attention on Xilinx' behalf to SDR, which I've managed
> to find, is xapp134. That paper, along with its HDL code, originates
> in 1999, and is more or less the same ever since. The controller
> offered is hence adapted to Virtex-I and Spartan-II, and is yucky is
> several respects.
>
> Newer application notes (as well as MiG) relate to faster memory
> classes (DDR, DDR2, QDR, you name it), with controllers eating up some
> clock resources to solve timing problems. And all I wanted was a cheap
> memory with reasonably simple access.
>
> Given the situation, I'm considering to create a DDR controller with
> MiG for a memory with similar attributes (bus width, array size, etc)
> and then hack it down to SDR. Since the command interface is the same,
> that should leave me with changing the data flow, and make the burst
> timing right. Not much fun, but hey, after debugging the MiG DDR
> controller, I should survive this one as well.
>
> And here's the irony: I picked this SDRAM to make things simpler for
> me.
>
> So before I start this little self torture, does anyone have a better
> idea?
>
> Thanks,
>      Eli

I have the same problems, just I want to SDR in an MB embedded system.
Luckily I know that Xilinx OPB SDRAM controller sucks so the new
Spartan3E boards will have DDR on board. If you need only 1kB FIFO
style burst transfers than I can provide you with some working
example.

Cheers,

Guru

Eli Billauer <eli@billauer.co.il> writes:

> Given the situation, I'm considering to create a DDR controller with
> MiG for a memory with similar attributes (bus width, array size, etc)
> and then hack it down to SDR. Since the command interface is the same,
> that should leave me with changing the data flow, and make the burst
> timing right. Not much fun, but hey, after debugging the MiG DDR
> controller, I should survive this one as well.
>
> And here's the irony: I picked this SDRAM to make things simpler for
> me.
>
> So before I start this little self torture, does anyone have a better
> idea?

Write one from scratch?  SDR SDRAM is (as you rightly say) fairly
straight-forward, especially if you don't need to maximise bandwidth,
so you can have a simple state machine controlling it.

I did one a very long time ago (my first bit of serious VHDL, so it
can't have been that hard :-)...

Alternatively, you could use a DDR controller and ignore every other
byte :-)

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

On Aug 4, 4:04 am, Eli Billauer <e...@billauer.co.il> wrote:
> Hello,
>
> I would like to utilize a controller for a SINGLE data rate SDRAM
> (Micron MT48LC16M16A2TG-75, to be specific). In the past I've used
> Xilinx' MiG 1.4 to obtain a DDR2 controller, which I ended up pretty
> happy with (after forgetting the via dolorosa to set it up...). Its
> main benefit is a simple and convenient FIFO-based user interface.
>
> For some reason, I thought that MiG would create an SDR controller as
> well (it's simpler, after all), but it turned out I'm very wrong: The
> last piece of attention on Xilinx' behalf to SDR, which I've managed
> to find, is xapp134. That paper, along with its HDL code, originates
> in 1999, and is more or less the same ever since. The controller
> offered is hence adapted to Virtex-I and Spartan-II, and is yucky is
> several respects.
>
> Newer application notes (as well as MiG) relate to faster memory
> classes (DDR, DDR2, QDR, you name it), with controllers eating up some
> clock resources to solve timing problems. And all I wanted was a cheap
> memory with reasonably simple access.
>
> Given the situation, I'm considering to create a DDR controller with
> MiG for a memory with similar attributes (bus width, array size, etc)
> and then hack it down to SDR. Since the command interface is the same,
> that should leave me with changing the data flow, and make the burst
> timing right. Not much fun, but hey, after debugging the MiG DDR
> controller, I should survive this one as well.
>
> And here's the irony: I picked this SDRAM to make things simpler for
> me.
>
> So before I start this little self torture, does anyone have a better
> idea?

I'm with Martin.  Write your own SDRAM controller from scratch.  It's
really not difficult, and you can optimize it for your particular
application.  It shouldn't take more than a couple of days to write,
simulate and verify it.

-a

Thank you for your answers. What I really wanted to verify, is that
there isn't an easy way which I've missed.

And writing a controller for a very specific purpose from scratch is
indeed not difficult, but writing one which makes a fairly good use of
the bandwidth for a reasonable, but unknown access pattern, well,
well...

So I'll stick to my previous plan to downgrade the MiG controller,
which has two great advantages: I know it, and I've seen it working.
>From what I've managed to understand, the only major difference is
startup sequence. I'll report back if I come across something worth
mentioning.

Thanks again,
    Eli

> Thank you for your answers. What I really wanted to verify, is that
> there isn't an easy way which I've missed.
>
> And writing a controller for a very specific purpose from scratch is
> indeed not difficult, but writing one which makes a fairly good use of
> the bandwidth for a reasonable, but unknown access pattern, well,
> well...
>
> So I'll stick to my previous plan to downgrade the MiG controller,
> which has two great advantages: I know it, and I've seen it working.
>> From what I've managed to understand, the only major difference is
> startup sequence. I'll report back if I come across something worth
> mentioning.

	Could you use the mch_opb_sdram controller from Xilinx EDK in your  
application ?

On Aug 7, 12:51 pm, PFC <li...@peufeu.com> wrote:
> > Thank you for your answers. What I really wanted to verify, is that
> > there isn't an easy way which I've missed.
>
> > And writing a controller for a very specific purpose from scratch is
> > indeed not difficult, but writing one which makes a fairly good use of
> > the bandwidth for a reasonable, but unknown access pattern, well,
> > well...
>
> > So I'll stick to my previous plan to downgrade the MiG controller,
> > which has two great advantages: I know it, and I've seen it working.
> >> From what I've managed to understand, the only major difference is
> > startup sequence. I'll report back if I come across something worth
> > mentioning.
>
>         Could you use the mch_opb_sdram controller from Xilinx EDK in your
> application ?

The mch_opb_sdram controller is the same shit. He would only get a
bunch of stuff that he does not need and low bandwidth.

Guru