RAMBUS for FPGAs

Home

3-D rendering >>
<< Virtex speculation

Usenet Postings
  By Subject
  By Date

FPGA CPUs
  Why FPGA CPUs?
  Homebuilt processors
  Altera, Xilinx Announce
  Soft cores
  Porting lcc
  32-bit RISC CPU
  Superscalar FPGA CPUs
  Java processors
  Forth processors
  Reimplementing Alto
  Transputers
  FPGA CPU Speeds
  Synthesized CPUs
  Register files
  Register files (2)
  Floating point
  Using block RAM
  Flex10K CPUs
  Flex10KE CPUs

Multiprocessors
  Multis and fast unis
  Inner loop datapaths
  Supercomputers

Systems-on-a-Chip
  SoC On-Chip Buses
  On-chip Memory
  VGA controller
  Small footprints

CNets
  CNets and Datapaths
  Generators vs. synthesis

FPGAs vs. Processors
  CPUs vs. FPGAs
  Emulating FPGAs
  FPGAs as coprocessors
  Regexps in FPGAs
  Life in an FPGA
  Maximum element

Miscellaneous
  Floorplanning
  Pushing on a rope
  Virtex speculation
  Rambus for FPGAs
  3-D rendering
  LFSR Design
 

Google SiteSearch
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