On-Chip Memory

Home

VGA controller >>
<< SoC On-Chip Buses

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: Re: HowTo access a SRAM with a XC4000
Date: 26 Jan 1996 00:00:00 GMT
newsgroups: comp.arch.fpga

In <4e68e6$9c1@mailman.xilinx> "Steve Knapp (Xilinx, Inc.)" <stevek>
writes: 
>
>The concept seems feasible.  A few questions though:
>
>1.  How much RAM is required?  General the XC4000E RAM is good for
designs
>    requiring less than 64 words of memory.  Increasing the word width
does not
>    significantly increase the amount memory required.
>
>    Some example sizes:  A 32-deep memory of 16-bit words consumes 32
XC4000E
>    logic blocks.  A 64-deep memory of 16-bit words consumes 80 logic
blocks
>    (64 for the RAM, and 16 for bank select and output multiplexing).

Quite true, but sometimes you can take advantage of the 4000(E)'s
abundant 3state drivers to have deep (multi-bank) memories w/o having
to waste CLB gates multiplexing bank data outputs.  Assuming you are
already using horizontal long lines for an on-chip data bus of some
kind, multiplexing bank outputs is as simple as decoding more
significant address lines into bank enable signals which enable tbufs
to drive bank data outputs onto the shared data bus.  Fortunately, the
tbuf inputs are immediately adjacent to the SRAM/ROM CLBs so trivial
routing resources are consumed.  Floorplan-wise, the data bus runs
horizontally, each SRAM/ROM bank is a column of CLBs and TBUFs, with
addresses, WE, and bank select longlines running vertically.

For instance, my 4010-based 32-bit RISC has several banks of 16 words x
32-bits of on-chip boot ROM.  Address bits A[7:6] control bank output
enables, A[5:2] specify the word address across all banks, and A[1:0]
is decoded with the processor's data-width specifier (byte, halfword,
word) to derive byte enables.  The bank output enables and byte enables
are and'd together and each result drives 8 "data out" tbufs for some
byte in some bank.

Jan Gray

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