Prev: Wrong DDR communication
Next: Any advice on which is the best book on CMOS digital circuit ?design?
From: KJ on 27 Mar 2010 18:09
On Mar 26, 11:28 pm, John_H <newsgr...(a)johnhandwork.com> wrote:
>
> I'm a little surprised that there are no cares about clock versus data
> from others.  CARE!
>

Guess you didn't read my post where I detailed the estimate of skew to
be ~5% of the timing budget (round trip delay)...and as I said, worth
keeping track of, but likely to be far overshadowed by clock to output
and setup time requirements. Actually I had originally computed it at
half that percentage, twas using 10ns rather than 5 ns clock period.

> Your synchronous SRAM doesn't have a DLL like SDRAMs.  There's one
> clock that you provide, nothing provided back.
>

Just like most synchronous logic...back in the old days...one clock,
nothing fancy.

> The amount of length matching required is determined by your timing
> budget.  You NEED to put together a timing budget to make sure your
> clock and data are related better than second cousins once removed.
>

To quote Eric Bogatin, "plug in the numbers". The largest length
difference between clock and data as reported by Radarman is 350 mils
which is approximately a 60 ps built-in skew...clock to output delays
and setup time requirements of the devices will be the primary
concerns since they will be roughly an order of magnitude larger.
Even differences in the delay caused by differences in the capacitive
loading would probably be more important than the PCB copper delay
differences.

Kevin Jennings
From: radarman on 27 Mar 2010 21:22
On Mar 27, 5:09 pm, KJ <kkjenni...(a)sbcglobal.net> wrote:
> On Mar 26, 11:28 pm, John_H <newsgr...(a)johnhandwork.com> wrote:
>
>
>
> > I'm a little surprised that there are no cares about clock versus data
> > from others.  CARE!
>
> Guess you didn't read my post where I detailed the estimate of skew to
> be ~5% of the timing budget (round trip delay)...and as I said, worth
> keeping track of, but likely to be far overshadowed by clock to output
> and setup time requirements.  Actually I had originally computed it at
> half that percentage, twas using 10ns rather than 5 ns clock period.
>
> > Your synchronous SRAM doesn't have a DLL like SDRAMs.  There's one
> > clock that you provide, nothing provided back.
>
> Just like most synchronous logic...back in the old days...one clock,
> nothing fancy.
>
> > The amount of length matching required is determined by your timing
> > budget.  You NEED to put together a timing budget to make sure your
> > clock and data are related better than second cousins once removed.
>
> To quote Eric Bogatin, "plug in the numbers".  The largest length
> difference between clock and data as reported by Radarman is 350 mils
> which is approximately a 60 ps built-in skew...clock to output delays
> and setup time requirements of the devices will be the primary
> concerns since they will be roughly an order of magnitude larger.
> Even differences in the delay caused by differences in the capacitive
> loading would probably be more important than the PCB copper delay
> differences.
>
> Kevin Jennings

I have already added a series termination resistor, since it really
isn't that big a deal. I pretty much figured it would be necessary,
and a 0402 is certainly doable. I'll just have to squeeze it in among
all the bypass caps. (normally, I use the back of the board for bypass
caps, but the SRAM is sitting right under the FPGA)

Also, I have a global clock input nearby I could bring a feedback
clock in on. (nearby being the same bank) The clock is sourced by a
PLL in the FPGA. The master oscillator is 100MHz, which I double to
create the SRAM clock. I'm assuming the idea here is that instead of
simply connecting the feedback to the output at the FPGA, I loop the
signal back from the SRAM clock input, and use that as the feedback
instead?

I apologize if that's a stupid question. I'm more of a VHDL/Verilog
modeler than a board designer - I'm trying to get my feet wet in
hardware.
From: John_H on 27 Mar 2010 23:23
On Mar 27, 6:09 pm, KJ <kkjenni...(a)sbcglobal.net> wrote:
>
> Guess you didn't read my post where I detailed the estimate of skew to
> be ~5% of the timing budget (round trip delay)...and as I said, worth
> keeping track of, but likely to be far overshadowed by clock to output
> and setup time requirements.  Actually I had originally computed it at
> half that percentage, twas using 10ns rather than 5 ns clock period.

Sorry, I thought you were suggesting the FPGA internal clock that
feeds the IOB that feeds the SRAM was all that was needed. The 5%
budget does not include the uncertainties for the path from FPGA
internals to the outside world. I'm happy to see that radarman's
looking to match those delays (and hopefully put together the full
timing budget!).

> Just like most synchronous logic...back in the old days...one clock,
> nothing fancy.

You've got to get fancy if you can't make the clocks behave. The SRAM
has nice Tsu/Th and Tco values published relative to the external
clock. The delays in the FPGA are a little more unbalanced despite
the femtoscopic sampling window at the input register. Getting the
DLLs to shift the right way to line up the small valid window from the
SRAM is a female dog. If *you* can get the FPGA's Tco and Tsu/Th to
balance properly for the SRAM interface (using those persnickety
single-ended IO standards) then I have my hat off to you in a deep bow
with respect.
From: KJ on 28 Mar 2010 13:22
On Mar 27, 9:22 pm, radarman <jsham...(a)gmail.com> wrote:
>
> I have already added a series termination resistor, since it really
> isn't that big a deal.
<snip>
> Also, I have a global clock input nearby I could bring a feedback
> clock in on. (nearby being the same bank)

If you're going to feed the clock back, then you'll want to parallel
terminate to ground rather than series terminate at the source.
Series termination makes the edge look good at the end of the run,
intermediate places along the net look like a step half way up and a
plateau and then another step up when the reflection comes back. By
feeding the clock back, the SRAM will now be right in the middle of
the net rather than at the end and will not have a clean edge (the
clean edge will be back at the FPGA where the terminator is located).

When you parallel terminate to ground, the signal looks the same
virtually everywhere on the net.

Again, depending on the edge rates of the FPGA, your runs are short
enough that you might not need any termination, so allowing for a
terminator is cheap insurance...but you want to have the right
insurance.

Kevin Jennings
From: KJ on 28 Mar 2010 13:33
On Mar 28, 1:22 pm, KJ <kkjenni...(a)sbcglobal.net> wrote:
> plateau and then another step up when the reflection comes back.  By
> feeding the clock back, the SRAM will now be right in the middle of
> the net rather than at the end and will not have a clean edge (the
> clean edge will be back at the FPGA where the terminator is located).
>

Oops, strike the "where the terminator is located" part. Was trying
to say that the series terminated clock would be clean at the input
pin on the FPGA where it comes back in...NOT at the FPGA output pin
where the terminator is located, that would be the location of the
worst case plateau.

In any case, at the SRAM, which is at the halfway point in the clock
net, there will be a plateau. How big of a plateau depends on the
edge rate of the FPGA output pin.

Kevin Jennings
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Wrong DDR communication
Next: Any advice on which is the best book on CMOS digital circuit ?design?