[SI-LIST] Re: DDR SDRAM layout considerations

  • From: "john lipsius" <johnlipsius@xxxxxxxxx>
  • To: <si-list@xxxxxxxxxxxxx>
  • Date: Mon, 15 Sep 2003 22:43:41 -0700

Ken,
Taking you at your word, a random characteristic for errors 
indicates to me one or more of the following below.  In short:
return paths, xtalk, timing budget in general since "random" 
indicates to me loss of margin.  Some review of the layout 
and patient measurement taking may be needed. 

In addition to mem. ctlr settings, DQS, plane fab errors, PLL, 
Vtt/termination, SDRAM chip out of spec, tline xtalk issues 
mentioned by others, I would wager on these:


1. Current return paths with mutual inductance to other signals, 
causing crosstalk that *can* push your timing budget over the 
edge.  Your exhaustive simulation included post-layout for accurate 
xtalk, including the mem. ctlr package and io timing?  Decaps placed 
near tline vias is required.  Decoupled Vtt & Vref is required, and a 
Vref both quiet and tightly tracking Vtt.  Check Vref and Vtt quality.  

2. Insufficiently matched DQ line lengths; for 64 bits a large challenge. 
On a  design I did like yours, chips were put on both sides of the 
board to achieve optimal "mirrored" routing.  Star topology with 
min. length & equal stubs to all DQ pins was the goal.  Elimination of 
the series terminations can be considered if simulation shows 
timing vs. noise budget is ok with it.  Read cycles are impaired more 
heavily by the stubs, of course, so ISI may have put your read timing 
budget over the edge. 

3.  Check clock & DQS timing & SI vs. data at each SDRAM and ctlr, 
both read & write, trying to catch the errors and characterize them!  
But ya better use top quality probes & methods.   


  ----- Original Message ----- 
  From: Ken Hayden 
  To: si-list@xxxxxxxxxxxxx 
  Sent: Monday, September 15, 2003 8:22 AM
  Subject: [SI-LIST] DDR SDRAM layout considerations


  I have been designing many kinds of electronic circuits for nearly three
  decades, and have done a fair bit of high speed logic since the early
  eighties.  But I have now for the first time produced a logic design
  with such poor signal integrity that it doesn't work.  I'm not just
  talking about EMI problems -- I'm talking about downright errorred logic
  signals.  This circuit is a DDR SDRAM interface.

  The interface couldn't be simpler:  It's just a microprocessor having a
  64-bit DDR SDRAM controller, and a set of embedded (not DIMM) memory
  chips to make up the 64-bit data width.  In between there is only the
  set of transmission lines and terminating resistors that make up the
  SSTL interface.  The memory has shown both read errors and write errors
  of quite random nature.  All of the transmission lines have been
  exhaustively simulated with Hyperlynx and the appropriate IBIS models.
  All timings and waveforms appear to be well within spec.

  In spending altogether too much time tyring to find the source(s) of
  these memory errors, I have come to the following conclusions.  I would
  greatly appreciate any comments relatve to any of these conclusions.   I
  would also, of course, appreciate being steered to the REAL problem, if
  it's not included in what I've thought about so far!

  1- Do other engineers have trouble getting reliable operation with DDR
  SDRAM, or am I unique in finding trouble where none exists?!  This
  circuit seems way too simple to be causing me this much trouble!

  2- I currently believe that most of my SI problems are involved in the
  treatment of the planes, and which signals are routed against which
  planes.  I know that if a signal switches layers, the image current must
  find its way from plane to plane.  I also know that any other signals
  which share this image current path will pick up crosstalk.  But I don't
  know how to quantify this crosstalk.  That is, I don't know whether this
  can get so bad that the logic will fail, or whether it "only" represents
  an EMI problem.

  3- It has occurred to me that DDR SDRAM is different from earlier memory
  types, in that it has three relatively independent clock domains
  (address/control, data write, data read).  For this reason, it becomes
  important to keep data from causing crosstalk in address/control lines,
  and vice versa.  (If data glitches address during memclk, for example,
  then the address could be corrupted.  Or if address walks on data during
  read-cycle data strobe, then read data could be corrupted, etc.)  So DDR
  SDRAM address and data must be separated from each other, unlike with
  "traditional" RAM, where it doesn't matter much, as long as the (only)
  clock is isolated from the rest of the signals.

  4- If the DDR SDRAM chips are on a DIMM assembly, all of the fanout
  wiring for address and control is taken care of on the DIMM.  This means
  it's possible to route these lines within a single layer on the mother
  board.  But with the memory chips embedded, it becomes necessary to use
  more routing layers.  This of course increases the potential for shared
  plane vias and bypass capacitors to cause crosstalk.  Has anyone else
  grappled with this?  Should I use a DIMM even though I don't need it,
  just to pick up this signal routing advantage?!

  5. I have seen a number of DDR designs that route much, if not all, of
  the memory interface on outside layers.  This has the advantage that
  traces can go from controller to series resistor to RAM to shunt
  resistor with no layer changes.  It also has the disadvantage of being a
  poor configuration for EMI control.  My application needs to pass fairly
  stringent EMI regulations as one of several cards in a card cage that
  has virtually limitless card configurations, and several types of cable
  connections to the outside.  I do not want to fill this chassis with
  RF!  Has anyone gotten good results on DDR SDRAM with all signals buried
  between planes?

  Thanks for any thoughts
  Ken Hayden






  ------------------------------------------------------------------
  To unsubscribe from si-list:
  si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field

  or to administer your membership from a web page, go to:
  //www.freelists.org/webpage/si-list

  For help:
  si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field

  List archives are viewable at:     
  //www.freelists.org/archives/si-list
  or at our remote archives:
  http://groups.yahoo.com/group/si-list/messages 
  Old (prior to June 6, 2001) list archives are viewable at:
    http://www.qsl.net/wb6tpu


------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list

For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field

List archives are viewable at:     
                //www.freelists.org/archives/si-list
or at our remote archives:
                http://groups.yahoo.com/group/si-list/messages 
Old (prior to June 6, 2001) list archives are viewable at:
                http://www.qsl.net/wb6tpu
  

Other related posts: