SDRAM Controller timing problem

Hi,

I think I have found the problem !! 
In fact my fpga was generating too much Refresh commands, I had a
period of 1.6�s instead of 15.6�s.
I did this to make sure datas will be good, but the fact is that it is
not the right way !

Peter > I already have a feedback for my DCM block. Otherwise I think
it will not work. What I was trying to say is that I already saw loops
that were external to the fpga, in order to deskew the external wires
that go to the Sdram clock pin. But like Pierre-Olivier said, if we
have one period of latency there is not any delay issue, even at
133MHz.

So thank you all trying to help me it is so greate to have such
support when we are in trouble, so much interesting suggestions have
been said here, and fpgas are very capricious when we begin using them
(even if this time it was not its fault :)

Etrac.


Ray Andraka <ray@andraka.com> wrote in message news:<400DCED6.3B9D5AB0@andraka.com>...
> Offset constraints have been around for a while, not new.  Anyway, if you
> register
> your I/O at the IOB, then the offset constraint isn't going to do anything for
> you except
> tell you when a flip-flop got pushed out of the IOB or that you set the drive
> strength/slew
> rate wrong.
> 
> SDRAM can be tricky, especially if you don't have external terminations.
> Higher slew
> rates and drive strengths can result in some nasty reflections that will sink
> even the most
> carefully executed FPGA design.  Use the minimum drive strength consistent with
> your
> timing analysis.  If possible use external terminations on the lines to the
> SDRAM (you can
> use DCI, but I've found that in addition to pushing the limits on package power
> dissipation,
> it is also slows the I/O down too much for SDRAM, especially without doing
> stuff with the
> DCM).
> 
> 
> 
> PO Laprise wrote:
> 
> > Once you've "pen and papered" your timing as Peter suggests, you might
> > want to look into the "OFFSET OUT" constraint in the constraint guide.
> > This allows you to give minimum "clock to off-chip" delays.  The router
> > will then take into account clock skew AND pad delays.  To constrain
> > your inputs, use the "OFFSET IN" constraint.  If your delays are already
> > minimal, it may not help, but at least you'll know.  Of course, you
> > still have to take all board delays into account yourself, which is why
> > it's important to pen-and-paper first.
> >
> 
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
> 
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759