MIG (Memory Interface Generator)

[gszakacs]

It would be interesting to see a pair of traces to show the relative prop delay of the LVCMOS

vs SSTL cases tuned for similar wave shapes.  Just getting the termination correct is only

part of the battle.  At high speeds, the source-synchronous signals need low skew, and could

be hurt by mixing standards if the output delays are significantly different.

Of course, not knowing the underlying mechanism that implements the various standards,

it may be that the exact same transistors are used in both cases...

-- Gabor

[gerard.visser]

Hello Gabor,

 Yes the skew issue was also investigated, I know it would be no good to have beautiful waveforms but shifted in time w.r.t. the clock (which would continue to use the SSTL15_II driver and parallel differential termination). Please note that for all the measurements the scope is triggered on the auxiliary output (through one of the SMA connectors on the SP605 board) and that output uses always SSTL2_II. It is not on a nearby pin. I am of course making the assumption that changing iostandard on the CAS pin does not at all affect this auxiliary output waveform.

The first picture here below is a screen shot from the scope to show the auxiliary waveform (and the case of LVCMOS15 DRIVE=8 FAST).

In the second picture is perhaps the direct answer to your question, I replotted the data from SSTL15_II together with the data from LVCMOS15 DRIVE=8 FAST. You can see that the latter is skewed by about +130ps for the rising edge and +200ps for the falling edge. I think this is probably acceptable (for operation at 320 MHz clock which is my goal).

Of course, this is not at the SDRAM die as Bob points out, so should not be interpreted too literally.

I'm sorry if this skew comparison wasn't very clear in my document; I had thought about keeping it more explicit on all the plots but they seemed too cluttered and confusing that way. I have all the stored data though if anyone wants it.

Thank you,

   Gerard

p.s. By the way I do believe that as far as the output driver is concerned SSTL15_II is exactly the same as LVCMOS15, DRIVE=16, FAST. The waveform is completely identical. Of course the input structure must be different but it's not used here.

skew of LVCMOS15/8/FAST relative to SSTL15_II

[jamieson]

Thanks for this great note Gerard.  I have also suspected that parallel termination of addr/control lines with a single component DDR3 is overkill when the component is located close to the FPGA.  I realize that the Spartan 6 the memory controller is hard IP, but would this work also apply to V6 and 7 series parts?

[bhayes47]

Hi Gerard,

One detail I should have mentioned before, is that in my designs the trace lengths of control signals averages around 15mm, with the maximum around 20mm.

Whereas what Bob mentioned is true, that the signal shape is not effected by the clock frequency, the converse is not true, that is, the clock frequency that is usable is effected by the signal shape.  The size and spacing of the reflections, and how long they take to settle, is effected by the termination mismatch and the trace length, and the maximum usable frequency is driven by the signal settling time.

I also didn't mention before, that as part of my margin checking, I tested running the ram up to 500 MHz (on just one design instance), which is beyond what is supported on the MCB, but it still passed memory tests.

As was noted, the important signal is what is actual seen on the die, which for most of us is not visible directly  So whereas using the results of a memory test running on a design implementation is not a direct nor perfect view of the signal quality, neither is using a scope, and the memory test does at least take into account what the die actually sees.  It doesn't take into account the possible reliability concerns of excessive overshoot.

  You've done a nice job of instrumenting the signals on the board, given the practical realities of viewing these waveforms on a real board.  At the time I experimented with the DDR2 terminations, I had access to a better scope than I do now, although I didn't set up the instrumentation as well as you have.  In that case, without the terminations, although the design stayed functional, I did see a little overshoot, slightly more than the spec'd maximum.  At that time on that project, the uncertainty I felt about my instrumentation led me to restore the terminations to mitigate the risk.

There are always tradeoffs in an engineering design, and reducing power while keeping performance up was high on my list. Currently I'm happy with the decision to not use external terminations on my DDR3 designs.  I think that as long as you

keep your trace lengths reasonably short, you should be able to build a successful board.

Bill

[eteam00]

You can see that the latter is skewed by about +130ps for the rising edge and +200ps for the falling edge. I think this is probably acceptable (for operation at 320 MHz clock which is my goal).

This is where I get to remind everyone, experienced and inexperienced designers alike, that skew is every bit as much of a problem at any frequency.  The skew problem is a race condition between a data signal (even if it is an address bit or command bit) and a clock edge.  It does not matter in the least how often clock edges occur, it only matters that the race is properly won.

For perspective, 130pS is roughly the transit time of 1" or 22mm of circuit board trace length.  200pS translates to roughly 1.3" or 34mm of trace length.

-- Bob Elkind

[gerard.visser]

Hello all,

  For completeness sake I like to post here a revised version of my document ("lab notes" regarding measured waveforms on the SP605 evaluation board modified for no termination resistor on a memory control/address line). The two missing cases are now included (SSTL15_II with OUT_TERM=UNTUNED_25, and LVCMOS15 with DRIVE=8, SLOW). I had to wait a few days to get time with the scope.

  I set this aside now, we will proceed with our board design. I hope that these measurements might provide useful insight to others, but agree and caution that they have to be interpreted with care and certainly do not provide the ultimate answer.

  I thank all of you who have provided interesting and useful insights in reply. Sincerely,

    Gerard