Subject: RAMBUS for FPGAs -- was Re: Why is Intel *really* pushing rambus
         into desktop PCs ?
Date: 16 Aug 1998 00:00:00 GMT
Newsgroups: comp.arch,comp.arch.fpga

Joseph H Allen wrote ...
>RAMBUS terrifies me because I would not be able to hook them up to FPGAs
>as I can with SDRAMs.  Also they actually require a protocol.  Often I can
>do a FIFO-less continuous data design with SDRAMs, but I doubt this will be
>possible with RAMBUS.  Anyway, I hope RAMBUS goes away.


Interesting topic!

Interfacing to SDRAMs at full speed, sans PLLs, seems tricky -- e.g. Brad
Taylor's XCELL article "XC4000XL FPGAs Interface to SDRAMs at 100 MHz"
(http://www.xilinx.com/xcell/xl28/xl28_25.pdf) describes fairly narrow
margins :- "...Tco + Tsu = 6.0 ns + 3.0 ns = 9.0 ns (This allows 1.0 ns
slack for board delay and clock jitter.)..." ... "... requires the board
delay to compensate for clock jitter...".

I think DRDRAM will be a common DRAM interface.  So I wonder -- wishful
thinking -- *could* FPGA vendors license the RAC cell
(http://www.rambus.com/presentations/controller_design/sld001.htm) and build
on that to provide an on-chip, dedicated, easy-to-use DRDRAM controller?


For example, for a hypothetical XC4000- or ORCA-like device, this could be a
configurable DRDRAM interface adjacent to the right edge IOBs, with these
ports:

*** dout[n-1:0], din[n-1:0] (n = 16, 18, 32, 36, 64, 72, even 128, 144) --
sink and source DRDRAM data bits (through FIFOs :-) ) -- replaces
corresponding n IOBs, using their programmable interconnect (including IOBs'
longline TBUFs).  Subsumes either n fixed IOBs, or n/k programmable groups
of k IOBs, or n programmable arbitrary sequential IOBs (a la XC6200
programmable row scatter/gather idea).

*** addr[m-1:0] (m = 16 or 32) -- provide word or block burst address in one
(addr[31:0]) or two (addr[15:0]) cycles, either on dedicated addr[] port or
multiplexed onto dout[].

*** cmd[5:0] -- commands to reset, read/write/stream data into/out of fifos,
open/close banks, precharge, masks, whatever, but keep it simple!

*** clk -- the above signals are synchronous to clk, which is also
multiplied up (by some programmed constant) using a hypothetical integrated
DRDRAM clock generator (PLL) to <= 800 MHz.

This on-chip DRDRAM controller interface might well be easier to design to
than is off-chip SDRAM today.  And this hypothetical FPGA, configured with a
carefully floorplanned and pipelined 100 MHz, 64-bit datapath design, could
read 8 bytes and write 8 bytes per clock and thus consume the full DRDRAM
channel bandwidth.

Another application of FPGA RAC cells: virtual wires: you could (awkwardly)
stitch FPGAs together through RACs at 20 Gb/s/RAC
(http://www.rambus.com/presentations/controller_design/sld034.htm).


Speaking as an FPGA user, DRDRAM support seems cool, but then I don't really
understand the issues of economics, marketing, integration, clocking, RAC at
FPGA configuration time, RAC initialization and configuration, testing,
testing, testing, packaging, end-user board layout, debugging, etc.

(Also, is it likely that a DRDRAM clock generator
(http://www.rambus.com/presentations/controller_design/sld027.htm) can also
be integrated into our hypothetical FPGA+RAC device or does it require a
somewhat different process?)

Thanks.
Jan Gray

Copyright © 2000, Gray Research LLC. All rights reserved.
Last updated: Feb 03 2001