|
|
### Overview
|
|
|
|
|
|
DESTINY is an acronym for 3D dEsign-Space exploraTIon tool for SRAM, eDRAM and Non-volatile memorY.
|
|
|
In its purpose, DESTINY is similar to CACTI, CACTI-3DD or NVSim.
|
|
|
|
|
|
DESTINY is a tool for modeling both 2D and 3D caches designed with five prominent memory technologies:
|
|
|
SRAM, eDRAM (embedded DRAM), PCM (or PCRAM), STT-RAM (or STT-MRAM) and ReRAM (or RRAM), which covers
|
|
|
both conventional and emerging technologies. DESTINY has been validated against several
|
|
|
commercial prototypes. It can be used to model technology nodes ranging from 22nm to 180nm.
|
|
|
Thus, DESTINY is intended to be a comprehensive tool.
|
|
|
|
|
|
DESTINY utilizes the framework for modeling 2D SRAM and 2D NVM from NVSim.
|
|
|
Also, the coarse- and fine-grained TSV (through silicon via) models are utilized from CACTI-3DD.
|
|
|
|
|
|
Matthew Poremba and Sparsh Mittal are lead-developers of DESTINY.
|
|
|
|
|
|
------------------------------------------------------
|
|
|
|
|
|
### Compiling DESTINY
|
|
|
|
|
|
DESTINY is developed in C++. It can be compiled on both Microsoft Windows and Unix-like OSes.
|
|
|
To build the tool under Linux, simply issue
|
|
|
|
|
|
$ make
|
|
|
|
|
|
-------------------------------------------------------
|
|
|
|
|
|
### Running DESTINY
|
|
|
|
|
|
DESTINY must be compiled with a user-specified configuration files, as follows:
|
|
|
|
|
|
$ ./destiny .cfg
|
|
|
|
|
|
-------------------------------------------------------
|
|
|
### The meaning and possible values of parameters added in DESTINY
|
|
|
|
|
|
-StackedDieCount - Number of dies over which the memory is distributed
|
|
|
|
|
|
-PartitionGranularity -
|
|
|
0: Coarse granularity: This assumes that address, control, and data signals are
|
|
|
broadcast to all stacked dies and decoded on the destination die.
|
|
|
1: Fine granularity: This assumes that address signals are pre-decoded on a
|
|
|
separate logic layer and the undecoded address signals are broadcast to all
|
|
|
stacked dies. The control and data are still shared.
|
|
|
Note that the total number of dies in fine granularity is StackedDieCount + 1
|
|
|
|
|
|
-LocalTSVProjection:
|
|
|
0: Use aggressive TSV projection from ITRS for local TSVs.
|
|
|
1: Use conservative values from industry measurements for local TSVs
|
|
|
|
|
|
Local TSVs are used in fine granularity partitioning to route pre-decoded signals
|
|
|
|
|
|
-GlobalTSVProjection:
|
|
|
0: Use aggressive TSV projection from ITRS for global TSVs
|
|
|
1: Use conservative values from industry measurements for global TSVs
|
|
|
|
|
|
Global TSVs are used in both fine and coarse granularity partitioning to
|
|
|
route broadcast signals (e.g., data and control signals)
|
|
|
|
|
|
-TSVRedundancy: Any floating point value from 1.0 or higher (reasonably, about
|
|
|
2.0 is the maximum). ((TSVRedundancy - 1)*100) is the percentage of extra TSVs
|
|
|
assumed for each TSV cluster for fault tolerance / TSV yield issues.
|
|
|
|
|
|
-MonolithicStackCount: Integer value e.g., 1, 2, 4. This is the number of memory
|
|
|
layers on the *same* die which are monolithically stacked.
|
|
|
|
|
|
Other important parameters added:
|
|
|
|
|
|
-AllowDifferenceTagTech: Allow the tag array of a cache to be a different
|
|
|
technology than the data array (e.g., SRAM tag array with STT-RAM data array).
|
|
|
|
|
|
-MemoryCellInputFile: This parameter can be specified multiple times
|
|
|
to consider multiple different technologies in the same simulation run.
|
|
|
|
|
|
-PrintAllOptimals: Print the optimal design for each optimization
|
|
|
target (can be used to find the best of multiple technology inputs).
|
|
|
|
|
|
-ForceBank3D: Dimensions of each bank in terms of number of Mats in each direction.
|
|
|
-ForceBank3DA: Same as ForceBank3D, except forcing the number of active Mats is not required
|
|
|
-ForceBankA: Same as ForceBank in NVSim, except forcing the number of active Mats is not required.
|
|
|
-ForceMatA: Same as ForceMat in NVSim, except forcing the number of active Subarrays is not required.
|
|
|
|
|
|
-------------------------------------------------------
|
|
|
|
|
|
### Hacking DESTINY code and possible extensions
|
|
|
|
|
|
We expect that end-users of DESTINY should be able to easily modify it to add
|
|
|
various features. We are also working to add new features to it and provide a documentation.
|
|
|
|
|
|
Some possible extensions to DESTINY include, adding MLC (multi-level cell) modeling capability,
|
|
|
modeling other memory technologies such as race-track memory (domain wall memory) etc.
|
|
|
|
|
|
We welcome any contribution from the end-users of DESTINY.
|
|
|
|
|
|
-------------------------------------------------------
|
|
|
|
|
|
### Relevant papers
|
|
|
|
|
|
The following DATE-2015 paper provides a general introduction of DESTINY and the technical report
|
|
|
describes the tool in more detail and also shows its use in performing design-space exploration.
|
|
|
If you use DESTINY in a research publication, we request you to cite any of the these paper/report.
|
|
|
|
|
|
Matthew Poremba, Sparsh Mittal, Dong Li, Jeffrey S Vetter and Yuan Xie, "DESTINY: A Tool for
|
|
|
Modeling Emerging 3D NVM and eDRAM caches", Design Automation and Test in Europe (DATE), 2015.
|
|
|
|
|
|
Sparsh Mittal, Matthew Poremba, Jeffrey S Vetter and Yuan Xie, "Exploring Design Space
|
|
|
of 3D NVM and eDRAM Caches Using DESTINY Tool", ORNL Technical Report no. ORNL/TM-2014/636, 2014. (available here http://goo.gl/qzyWFE)
|
|
|
|
|
|
|
|
|
-------------------------------------------------------
|
|
|
### Contact
|
|
|
|
|
|
For questions and comments, contact
|
|
|
Matthew Poremba (poremba@cse.psu.edu)
|
|
|
Sparsh Mittal(sparsh0mittal@gmail.com) |
|
|
\ No newline at end of file |