fpgacpu.org - On-Chip Memory

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 <4e68e69ドルc1@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

AltStyle によって変換されたページ (->オリジナル) /