People | Documentation | Download | OpenCores Mail list | Contact me

Description

The memory_sizer project is designed to automatically handle accesses to and from memory. It does not handle refreshing DRAM at all, but it does automatically generate the cycles needed to fulfil a memory request by a processor. For example, it can load 32-bit words from byte wide memory (if you want to boot from a single byte-wide flash chip, for instance). Alternatively, it could load 16-bit words from byte wide memory. It also handles loading and storing bytes from 32-bit wide memory and 16-bit memory, although the memory in this case must support the use of "byte enables." This is done dynamically, so that multiple widths of memory may be shared in the same address space. Moreover, memory_sizer can load and store data using misaligned adresses (as does the power PC architecture!) which is a very difficult proposition, if you need to do misaligned accesses, because it involves splitting an access across the boundaries of the given memory. The memory_sizer handles these misaligned accesses automatically. Also, memory_sizer can do "little endian" or "big_endian" accesses. A single input to the module determines which mode is used.

One particularly nice feature of this block is that it is scalable in size by changing the parameters. This means that if you want to generate accesses which are 64-bits wide, 128-bits wide, or even 256-bits wide, you may do so. Simply change the appropriate parameters, and the memory_sizer module will produce the appropriate access cycles, with address and byte enables being generated automatically, for both loads and stores. Of course, it will then consume more resources, there is no escaping that!

If you wish to simplify this module, in order to save resources on your target chip, then simply tie the unused inputs to the desired state to constrain them, and the synthesis tools will "optimize away" the unneeded portions of the logic. For instance, if you do not want little_endian/big_endian support, just tie that input to zero or one, and the resulting synthesis will take up less space, and run faster.

The code is written in Verilog, and was sythesized into a Xilinx SpartanII XC2S200 chip. Debugging was done in actual hardware, with an HP16500 series logic analyzer, and there is no simulation testbench for these modules.

The design team of memory_sizer welcomes any kind of help and feedback on these cores. If you are interested in further development of this project, please contact us.

Current Status:

• These cores have been coded completely, synthesized and tested for correct operation (and debugged!) inside a Xilinx XC2S200 chip. The tools used for development were the Xilinx Foundation 3.1i (non-ISE) tools.
• The original "memory_sizer.v" supports bus switching to re-use the same hardware for writes and reads. It was tested at 12.5 MHz, and uses 200 Virtex slices.
• The second version, "memory_sizer_dual_path.v" uses separate paths for writing and for reading. It is faster (tested at 25MHz) and uses 300 Virtex slices...
• There are no technology-dependent elements used in these cores, except for the block DPRAMs, which can be replaced by their generic equivalents.
• The cores are parameterized to allow changing timer values to accomodate different clock speeds.
• The code has good comments.
• An example interface is given, showing how the "memory_sizer" and "memory_sizer_dual_path" modules were tested using rs232_syscon commands through Windows hyperterm. (See opencores project "rs232_syscon" for further details on this interface.)
• The wait states needed by the memory are not defined in the "memory_sizer" module. A "memory_ack_i" line is used to indicate that the memory is ready to proceed with the access cycle, so that wait state logic may be defined as you wish it to be.

Maintainer(s):

John Clayton

Mailing-list:

jclaytons@opencores.org