Extracting timing from a demo board (V2MB1000)

[PO Laprise]

Hello all, I'm trying to get a DDR SDRAM controller working reliably on
Insight/Memec's V2MB1000 development board, but I'm having some timing
issues. I'm trying to correctly constrain my timing, and verify using
timing simulations, but I'm running into problems because I have no
information about the board delays between the memory and the FPGA. I
especially need the clock feedback path delay (to set the DCM FEEDBACK
constraint), and the skew between the dqs lines and data (to know if I
can use dqs to latch data)

I don't have board layout information, and Insight/Memec hasn't yet
answered my requests (although, in their defence, it _has_ been less
than a week...), and I haven't found the info anywhere on their site or
in the provided documentation. As far as probing is concerned, I only
have access to the memory's pins, so I'm not sure how I can determine
the delays from this.

So, what I was hoping to get is either suggestions about how I might
measure these delays, or, if someone has already measured/received this
information, the actual min:typ:max board delays between memory and FPGA.

Thanks a lot in advance!

--
Pierre-Olivier

-- to email me directly, remove all _N0SP4M_ from my address --

 

[Martin Kellermann]

Hello,

if you have access to a Scope with a TDR (time domain reflectometer) you
can get that information out...

Cheers,

Martin


PO Laprise wrote:

Hello all, I'm trying to get a DDR SDRAM controller working reliably on
Insight/Memec's V2MB1000 development board, but I'm having some timing
issues. I'm trying to correctly constrain my timing, and verify using
timing simulations, but I'm running into problems because I have no
information about the board delays between the memory and the FPGA. I
especially need the clock feedback path delay (to set the DCM FEEDBACK
constraint), and the skew between the dqs lines and data (to know if I
can use dqs to latch data)

I don't have board layout information, and Insight/Memec hasn't yet
answered my requests (although, in their defence, it _has_ been less
than a week...), and I haven't found the info anywhere on their site or
in the provided documentation. As far as probing is concerned, I only
have access to the memory's pins, so I'm not sure how I can determine
the delays from this.

So, what I was hoping to get is either suggestions about how I might
measure these delays, or, if someone has already measured/received this
information, the actual min:typ:max board delays between memory and FPGA.

Thanks a lot in advance!

 

[Mike Treseler]

PO Laprise wrote:

So, what I was hoping to get is either suggestions about how I might
measure these delays, or, if someone has already measured/received this
information, the actual min:typ:max board delays between memory and FPGA.

Board delays are normally 1-2 nS which
should be much less than a clock period
which is the minimum wait for
a synchronous controller.

With a handshaking interface, you don't
need to measure the delays, you just
drive a READY wait for an ACK.

-- Mike Treseler

 

[John Williams]

Hi Pierre,

So, what I was hoping to get is either suggestions about how I might
measure these delays, or, if someone has already measured/received
this information, the actual min:typ:max board delays between memory
and FPGA.

I can't answer your question directly, but can offer a set of numbers
(parameters and constraints etc) for the EDK-provided DDR controller
that work on the v2mb1000 board... perhaps you can extract what you
need from these?

Regards,

John

 

[PO Laprise]

John Williams wrote:

Hi Pierre,

So, what I was hoping to get is either suggestions about how I might
measure these delays, or, if someone has already measured/received
this information, the actual min:typ:max board delays between memory
and FPGA.

I can't answer your question directly, but can offer a set of numbers
(parameters and constraints etc) for the EDK-provided DDR controller
that work on the v2mb1000 board... perhaps you can extract what you
need from these?

Regards,

John

(sound of hand slapping forehead)
Thanks for the idea, I should have thought of that myself... I already
have the EDK and all associated pcores, so I'll see what I can get from
that (unless you have stuff that isn't in the vhdl files?). Of course,
I always prefer to know as much as I can about the tools I use, so if
anyone has the information, I'd still be interested in getting it.
Thanks again,

--
Pierre-Olivier

-- to email me directly, remove all _N0SP4M_ from my address --