README 6.68 KB
Newer Older
Jeffrey Vetter's avatar
Jeffrey Vetter committed
1 2 3 4 5 6
DESTINY : 3D dEsign-Space exploraTIon Tool for SRAM, eDRAM and Non-volatile memorY

Oak Ridge National Laboratory
Penn State University
University of California, Santa Barbara

7 8 9
Webpage: https://code.ornl.gov/3d_cache_modeling_tool/destiny
Mailing list: destiny-help@elist.ornl.gov
Archive of previous conversations: https://elist.ornl.gov/pipermail/destiny-help/
Jeffrey Vetter's avatar
Jeffrey Vetter committed
10 11 12

20 Feb 2015 

Sparsh Mittal's avatar
Sparsh Mittal committed
13
### Overview
sparshmittal's avatar
sparshmittal committed
14 15 16 17 18 19 20 21 22 23

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.  

24
Sparsh Mittal and Matthew Poremba are lead-developers of DESTINY.
Jeffrey Vetter's avatar
Jeffrey Vetter committed
25

sparshmittal's avatar
sparshmittal committed
26
DESTINY utilizes the framework for modeling 2D SRAM and 2D NVM from NVSim.
Sparsh Mittal's avatar
Sparsh Mittal committed
27
Also, the coarse- and fine-grained TSV (through silicon via) models are utilized from CACTI-3DD. 
Jeffrey Vetter's avatar
Jeffrey Vetter committed
28

29 30
### Documentation

sparsh's avatar
sparsh committed
31 32 33 34 35 36
The file ''DESTINY_Documentation'' under folder 'Doc' provides a brief manual of DESTINY. 
It shows an example configuration file and the corresponding output of DESTINY, 
which may be especially useful for a user who wants to get an overview of DESTINY 
even before installing it. The manual also provides ideas and suggestions for 
integrating DESTINY into architectural simulators and is expected to answer 
some of the ``frequently asked questions'' related to DESTINY.
37

Jeffrey Vetter's avatar
Jeffrey Vetter committed
38 39 40
### Sponsors

This work was supported by the Office of Advanced Scientific Computing Research in 
41 42
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/).
Jeffrey Vetter's avatar
Jeffrey Vetter committed
43 44
 For information, please see our webpage http://ft.ornl.gov/. 
 
sparshmittal's avatar
sparshmittal committed
45
------------------------------------------------------
Sparsh Mittal's avatar
Sparsh Mittal committed
46
###  Relevant papers, acknowledgement and contact information
sparshmittal's avatar
sparshmittal committed
47

Sparsh Mittal's avatar
Sparsh Mittal committed
48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64
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)

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). 

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

Jeffrey Vetter's avatar
Jeffrey Vetter committed
65

Sparsh Mittal's avatar
Sparsh Mittal committed
66 67 68
-------------------------------------------------------

###  Compiling DESTINY
sparshmittal's avatar
sparshmittal committed
69 70 71 72 73 74

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

Sparsh Mittal's avatar
Sparsh Mittal committed
75 76
-------------------------------------------------------
###  Running DESTINY
sparshmittal's avatar
sparshmittal committed
77 78 79 80 81 82

DESTINY must be compiled with a user-specified configuration files, as follows:

      $ ./destiny <file>.cfg

-------------------------------------------------------
Sparsh Mittal's avatar
Sparsh Mittal committed
83
###  The meaning and possible values of parameters added in DESTINY
sparshmittal's avatar
sparshmittal committed
84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133

-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.

134 135 136 137 138 139
Making output concise or detailed:
-PrintLevel: 0 -> does NOT produce CACHE DATA ARRAY DETAILS and CACHE TAG ARRAY DETAILS
Or
-PrintLevel: 1 -> produces CACHE DATA ARRAY DETAILS and CACHE TAG ARRAY DETAILS 
For more details on this, see Result.cpp file.

sparshmittal's avatar
sparshmittal committed
140 141
-------------------------------------------------------

Sparsh Mittal's avatar
Sparsh Mittal committed
142
###  Hacking DESTINY code and possible extensions
sparshmittal's avatar
sparshmittal committed
143 144 145 146 147 148 149 150

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. 
Jeffrey Vetter's avatar
Jeffrey Vetter committed
151 152 153


### EOF