Changes

Page history
minor additions authored by Mittal, Sparsh's avatar Mittal, Sparsh
Hide whitespace changes
Inline Side-by-side
home.markdown
View page @ 10138843
### 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 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.
Thus, DESTINY is intended to be a comprehensive tool.
DESTINY utilizes the framework for modeling 2D SRAM and 2D NVM from NVSim.
Matthew Poremba and Sparsh Mittal are lead-developers of DESTINY.
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.
------------------------------------------------------
### Relevant papers, acknowledgement and contact information
Matthew Poremba and Sparsh Mittal are lead-developers of DESTINY.
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 publications.
------------------------------------------------------
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.
(available here http://goo.gl/3nKAM2)
### Compiling DESTINY
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).
This work was supported by the Office of Advanced Scientific Computing Research in the U.S. Department of Energy, under the project “Blackcomb - Hardware-Software Co-design for Non-Volatile Memory in Exascale Systems” (https://ft.ornl.gov/trac/blackcomb/). For information, please see our webpage http://ft.ornl.gov/.
Support for DESTINY is provided on a best-effort basis. For receiving announcements, or sending questions and comments, please subscribe to the mailing list destiny-help@elist.ornl.gov by visiting the following webpage: https://elist.ornl.gov/mailman/listinfo/destiny-help
-------------------------------------------------------
### 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
$ make
-------------------------------------------------------
### Running DESTINY
### Running DESTINY
DESTINY must be compiled with a user-specified configuration files, as follows:
$ ./destiny .cfg
$ ./destiny <file>.cfg
-------------------------------------------------------
### The meaning and possible values of parameters added in DESTINY
-------------------------------------------------------
### 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.
......@@ -44,26 +62,32 @@ 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.
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
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
......@@ -75,41 +99,24 @@ 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.
-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
### 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.
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.
-------------------------------------------------------
### 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.
We welcome any contribution from the end-users of DESTINY.
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