[Milkymist-devel] DDR SDRAM layout considerations

[Sébastien Bourdeauducq]

Hello,

On Thursday 18 February 2010 14:18:21 Uwe Bonnes wrote:
> With two SDRAM in TSOP66 package with
>  22.2 mm body length, SDRAM trace length will reach 3 inches from FPGA to
>  PAD

well, depending on how the SDRAMs are placed and how the FPGA pins are 
allocated.

>  Pin on RAM 1 and DQ7 on RAM2 are spaced about 30 mm apart, and without
>  trace length equalization this will cause about 150ps.

As I said in a previous email, I think you can forget about trace length 
equalization and rely on Spartan6's IODELAY blocks to do their job without the 
signal integrity issues. I have not tested yet, and this sure will be a funny 
thing to do once the Milkymist One prototypes come out of the fab.
 
> How will Milkymist1 tackle that issue?
> - Can SDRAM access speed be sacrificed for relaxed timing margins
>  requirements?

Yes, if you disable the DLL (which is out of the manufacturer's specs) you 
might be able to run the SDRAM at near-DC frequencies as long as you meet its 
refresh requirements. 

>  - Milkymist1 will not use VTT termination?

No, VTT termination is a mess, and I'll try to avoid it as much as possible. 
Most designs do not use it. For example, the OLPC XO has 4 chips of TSOP66 
DDRAM running at 166MHz clock 
(http://wiki.laptop.org/go/Hardware_specification), and, as far as I can tell 
by examining the PCB, it does not have VTT termination.

> - Milkymist will not try to be compatible with the Spartan 6 Memory
> controller?

No. This controller:
- seems to have higher latency than Milkymist's HPDMC, resulting in lower 
overall performance even though its bandwidth might be higher than that of the 
current version of HPDMC (memory latency has a lot of impact when you have a 
cache miss in the CPU or TMU for example)
- would have its latency further increased by the glue logic necessary to 
interface its FIFO-based interface to Milkymist's FML (unless a major part of 
the SoC architecture is re-designed around the MCB)
- stifles portability of Milkymist to ASICs and non-Xilinx FPGAs. Milkymist is 
not only about technical aspects, it's also about freedom.

> - Will Milkymist1 use the DDR Ram in FBGA package?

No, TSOP66.

> - Any ideas for sensible DDR SDRAM routing?

Well, not really, except read Micron documentations and technical notes which 
are very helpful.
DDR designs seem to be a pain for everyone, even though Micron ironically says 
they "make it easy" (that being said, Micron has the best documentation and 
design support resources I've seen from a DRAM manufacturer)

> - Does the HPDMC32 core place any special pin requirements on the pin
>  usage?

No. HPDMC uses IDDR and ODDR primitives which are clocked from a low-skew 
global I/O network, removing most pin allocation requirements.

>  - SDRAM_CK and SDRAM_CK_N are placed on GCLK pins in the milkymist
>  One draft, for any reason?

Yes, to allow those pins to be easily driven from the clk0 and clk180 outputs 
of a DCM and routed through global networks. If it was not done this way, you 
would have to:
* route these signals manually inside the FPGA. Otherwise, the automatic PAR 
will probably change those routes every time the design is changed, resulting 
in SDRAM timing foul-up whenever you modify a line of RTL code.
* take into account the on-chip FPGA routing delays when calibrating the 
IODELAYs.
While it is certainly possible to do so, overall I think it's simpler to route 
these pins on GCLKs on the PCB.

Regards,
Sébastien