On-Chip Memory |
|||
Home VGA controller >> << SoC On-Chip Buses
Usenet Postings |
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. |