CS 294-4: Intelligent DRAM (IRAM)

Notes from discussion

January 26, 1996


This unstructured list of issues is a summary of points brought up by the last two talks.


Can't change basic DRAM technology

  • can we assume 2 layers of metal, poly, and doped poly?
  • keep the die size constant
  • don't change the core or individual bits
  • avoid changes to the sense amps
  • use sense amps as second-level cache?
  • use sense amps in logic?
  • The relationship with the vendor will be important
  • performance and area penalties will range between 30% - 200%, depending on who you talk to. Actual numbers will depend on who we work with.
  • Issues based on the noise from logic (potentially a major problem)

  • use different rails for cells and random logic
  • separate ground and power
  • use sense amps to reduce swing
  • how large a bus?
  • reduce the block size, the number of blocks, both?
  • save area by getting rid of multiplexors?
  • Can the processing be internally bit-sliced or interleaved with the blocks?

  • noise issues
  • use a module hierarchy?
  • carry chain delay an issue
  • Vector ISA vs on-chip caching strategies?

    IRAM applications

  • Cray-1 on a chip
  • Embedded controllers
  • DSP
  • Questions about the management of multiple IRAM chips

  • centralized, single instruction-stream scheme
  • bit slice approach
  • continuous state broadcast
  • multiprocessor/parallel processing approach
  • (see ``Multichip IRAM solutions'' under Short Design Assignments here)
  • Testing

  • how does the testing cost break down? Is it all in equipment time?
  • can we use software testing to reduce DRAM cost/amortize the processor cost?
  • built-in (hardware) testing?
  • self-repair to avoid laser treatment(s)?
  • (see ``Cost Justified IRAM'' under Short Design Assignments here)
  • How do we utilize the wide bus(es)?

  • vector ISA
  • VVLIW
  • reconfigurable logic configuration parameters
  • (see ``Explicit Memory Management'' under Short Design Assignments here)
  • Power issues

  • low Vdd
  • biased wells

  • CS 294-4 - IRAM - 1/26/96 - Discussion Summary

    CS 294-4: Intelligent DRAM (IRAM)

    Notes from discussion

    January 26, 1996


    This unstructured list of issues is a summary of points brought up by the last two talks.


    Can't change basic DRAM technology

  • can we assume 2 layers of metal, poly, and doped poly?
  • keep the die size constant
  • don't change the core or individual bits
  • avoid changes to the sense amps
  • use sense amps as second-level cache?
  • use sense amps in logic?
  • The relationship with the vendor will be important
  • performance and area penalties will range between 30% - 200%, depending on who you talk to. Actual numbers will depend on who we work with.
  • Can the processing be internally bit-sliced or interleaved with the blocks?

  • noise issues
  • use a module heirarchy?
  • carry chain delay an issue
  • Issues based on the noise from logic (potentially a major problem)

  • use different rails for cells and random logic
  • separate ground and power
  • use sense amps to reduce swing
  • how large a bus?
  • reduce the block size, the number of blocks, both?
  • save area by getting rid of multiplexors?
  • Vector ISA vs on-chip caching strategies?

    IRAM applications

  • Cray-1 on a chip
  • Embedded controllers
  • DSP
  • Questions about the management of multiple IRAM chips

  • centralized, single instruction-stream scheme
  • bit slice approach
  • continuous state broadcast
  • multiprocessor/parallel processing approach
  • (see ``Multichip IRAM solutions'' under Short Design Assignments here)
  • Testing

  • how does the testing cost break down? Is it all in equipment time?
  • use software testing to reduce DRAM cost? Can it even completely amortize the processor cost?
  • built-in (hardware) testing?
  • self-repair to avoid laser treatment(s)?
  • (see ``Cost Justitified IRAM'' under Short Design Assignments here)
  • How do we utilize the wide bus(es)?

  • vector ISA
  • VVLIW
  • reconfigurable logic configuration parameters
  • (see also ``Explicit Memory Management'' under Short Design Assignments here)
  • Power issues

  • low Vdd
  • biased wells