sdram controller problems

Hi,

I've implemented an sdram controller on an fpga (to micron 128 MB memory)
and tested it with a sequence of write and subsequent read bursts. In around
1 in 5 attempts, the correct read data appears on the dq[31..0] data bus,
otherwise the memory read just returns 0xFFFFFFF. Could someone please give
pointers to why might this be?

Thanks,
Antti

Maybe you have a bug in your sdram controller.

You need to supply a bit more info. if you want some help. :)

"Antti" <antti1000@yahoo.com> wrote in message
news:%m%Vb.8944$g4.183754@news2.nokia.com...
> Hi,
>
> I've implemented an sdram controller on an fpga (to micron 128 MB memory)
> and tested it with a sequence of write and subsequent read bursts. In
around
> 1 in 5 attempts, the correct read data appears on the dq[31..0] data bus,
> otherwise the memory read just returns 0xFFFFFFF. Could someone please
give
> pointers to why might this be?
>
> Thanks,
> Antti
>
>

"Antti" <antti1000@yahoo.com> ha scritto nel messaggio
news:%m%Vb.8944$g4.183754@news2.nokia.com...

> I've implemented an sdram controller on an fpga (to micron 128 MB memory)
> and tested it with a sequence of write and subsequent read bursts. In
around
> 1 in 5 attempts, the correct read data appears on the dq[31..0] data bus,
> otherwise the memory read just returns 0xFFFFFFF.

Is there any pattern ? Is it time related ?
Did you do a good time budget analysis ?
Tried to lower the clock ?
Worth trying even if some delays are specified in clock cycles, not time...

But, more important: did you simulate your design using the right Micron HDL
model ?

I found that very very useful.
I stressed the controller + sdram model very heavily, with a nice testbench;
On hardware, it passed all tests at first shot. Really.
Surely I was lucky, but, nevertheless, that was HIGHLY rewarding, and a huge
time saver.

Samsung also has models online, and I suppose others, too.

Hi,

Did you implement it from scratch?  If so the datasheet indicates a fairly
complex IMO initialization procedure to get it in the right mode.  It seems
like it would be quite easy to miss something.

I had a burst read problem initially with the Nios SDRAM controller used
with the Micron mem.  It turned out to be a phase problem between the sdram
clock and the cpu clock.

Ken



"Antti" <antti1000@yahoo.com> wrote in message
news:%m%Vb.8944$g4.183754@news2.nokia.com...
> Hi,
>
> I've implemented an sdram controller on an fpga (to micron 128 MB memory)
> and tested it with a sequence of write and subsequent read bursts. In
around
> 1 in 5 attempts, the correct read data appears on the dq[31..0] data bus,
> otherwise the memory read just returns 0xFFFFFFF. Could someone please
give
> pointers to why might this be?
>
> Thanks,
> Antti
>
>

I did something similar several months back with a Spartan IIE.
Watch out for termination issues. In my case it appeared as 
double clocking. I was able to work around it because the Spartan
allowed me to reduce the drive current and edge rise times.
Once I did that, the strange behavior I ran into during hardware
testing
went away.

Also as mentioned in other posts, use the micron dram models and be
sure your controller works exactly as you expect in the simulator
before even thinking about trying it for real. Otherwise you are in
for a lot of frustration and head scratching.

"Antti" <antti1000@yahoo.com> wrote in message news:<%m%Vb.8944$g4.183754@news2.nokia.com>...
> Hi,
> 
> I've implemented an sdram controller on an fpga (to micron 128 MB memory)
> and tested it with a sequence of write and subsequent read bursts. In around
> 1 in 5 attempts, the correct read data appears on the dq[31..0] data bus,
> otherwise the memory read just returns 0xFFFFFFF. Could someone please give
> pointers to why might this be?
> 
> Thanks,
> Antti

Thanks for your replies,

As it turned out, the main (!) problem was timing related..but simply
clocking the controller and memory card with opposite clock edges seemed to
solve the problem..both in simulation and hardware :)

Once again many thanks for your comments,
-Antti


"db" <javaguy11111@yahoo.com> wrote in message
news:903bda3b.0402110541.30e4d887@posting.google.com...
> I did something similar several months back with a Spartan IIE.
> Watch out for termination issues. In my case it appeared as
> double clocking. I was able to work around it because the Spartan
> allowed me to reduce the drive current and edge rise times.
> Once I did that, the strange behavior I ran into during hardware
> testing
> went away.
>
> Also as mentioned in other posts, use the micron dram models and be
> sure your controller works exactly as you expect in the simulator
> before even thinking about trying it for real. Otherwise you are in
> for a lot of frustration and head scratching.
>
> "Antti" <antti1000@yahoo.com> wrote in message
news:<%m%Vb.8944$g4.183754@news2.nokia.com>...
> > Hi,
> >
> > I've implemented an sdram controller on an fpga (to micron 128 MB
memory)
> > and tested it with a sequence of write and subsequent read bursts. In
around
> > 1 in 5 attempts, the correct read data appears on the dq[31..0] data
bus,
> > otherwise the memory read just returns 0xFFFFFFF. Could someone please
give
> > pointers to why might this be?
> >
> > Thanks,
> > Antti

Hi ken, <p>Could you please tell me whether the phase problem that you had mentioned between sdram clock and cpu clock will be reflected in timing simulation? <BR>
&nbsp;&nbsp;I had done the timing simulation with micron SDRAM instantiated in the testbench. Read and write operations are proper. But the same is not working in virtex2 FPGA board.could you please give some suggestions to improve testing? <p>kams

Hi ken, <p>Could you please tell me whether the phase problem that you had mentioned between sdram clock and cpu clock will be reflected in timing simulation? <BR>
&nbsp;&nbsp;I had done the timing simulation with micron SDRAM . Read and write operations are proper. But the same is not working in virtex2 FPGA board.could you please give some suggestions to improve testing? <p>jenni

kams wrote:

>   I had done the timing simulation with micron SDRAM . Read and write 
> operations are proper. But the same is not working in virtex2 FPGA 
> board.could you please give some suggestions to improve testing?

Lack of synchronization is tough to find in simulation.
But the answer is the same in any case.
You need synchronization.
Consider running your cpu and sdram on the same clock.
That's the easiest way.

   -- Mike Treseler

"Antti" <antti1000@yahoo.com> wrote in message news:<Yo1Xb.9392$g4.191012@news2.nokia.com>...
> Thanks for your replies,
> 
> As it turned out, the main (!) problem was timing related..but simply
> clocking the controller and memory card with opposite clock edges seemed to
> solve the problem..both in simulation and hardware :)

Sounds like you had either a setup and hold problem, or perhaps you
didn't check your timing constraints, or you didn't set timing
constraints, or you have layout flight-time problems, or something. 
Or you have clock skew between the controller and the memory.

Describe your clock structure.  

---a