Merge pull request #27 from JRPan/accelwattach-dev

Merge AccelWattach

1 files changed, 0 insertions, 226 deletions

diff --git a/src/gpuwattch/README b/src/gpuwattch/README
deleted file mode 100644
index 4887b10..0000000
--- a/src/gpuwattch/README
+++ /dev/null
@@ -1,226 +0,0 @@
- __  __      ____   _  _____   ____       _         
-|  \/  | ___|  _ \ / \|_   _| | __ )  ___| |_  __ _ 
-| |\/| |/ __| |_) / _ \ | |   |  _ \ / _ \ __|/ _` |
-| |  | | (__|  __/ ___ \| |   | |_) |  __/ |_| (_| |
-|_|  |_|\___|_| /_/   \_\_|   |____/ \___|\__|\__,_|
-
-McPAT: Multicore Power, Area, and Timing
-Current version 0.8Beta 
-===============================
-
-McPAT is an architectural modeling tool for chip multiprocessors (CMP)
-The main focus of McPAT is accurate power and area
-modeling, and a target clock rate is used as a design constraint. 
-McPAT performs automatic extensive search to find optimal designs 
-that satisfy the target clock frequency.  
-
-For complete documentation of the McPAT, please refer McPAT 1.0
-technical report and the following paper,
-"McPAT: An Integrated Power, Area, and Timing Modeling
- Framework for Multicore and Manycore Architectures", 
-that appears in MICRO 2009. Please cite the paper, if you use
-McPAT in your work. The bibtex entry is provided below for your convenience.
-
- @inproceedings{mcpat:micro,
- author = {Sheng Li and Jung Ho Ahn and Richard D. Strong and Jay B. Brockman and Dean M. Tullsen and Norman P. Jouppi},
- title =  "{McPAT: An Integrated Power, Area, and Timing Modeling Framework for Multicore and Manycore Architectures}",
- booktitle = {MICRO 42: Proceedings of the 42nd Annual IEEE/ACM International Symposium on Microarchitecture},
- year = {2009},
- pages = {469--480},
- }
-
-Current McPAT is in its beta release. 
-List of features of beta release
-===============================
-The following are the list of features supported by the tool. 
-
-* Power, area, and timing models for CMPs with:
-      Inorder cores both single and multithreaded
-      OOO cores both single and multithreaded
-      Shared/coherent caches with directory hardware:
-      	including directory cache, shadowed tag directory
-      	and static bank mapped tag directory
-      Network-on-Chip
-      On-chip memory controllers
-    
-* Internal models are based on real modern processors:
-  Inorder models are based on Sun Niagara family
-  OOO models are based on Intel P6 for reservation 
-  station based OOO cores, and on Intel Netburst and 
-  Alpha 21264 for physical register file based OOO cores.     
-
-* Leakage power modeling considers both sub-threshold leakage 
-  and gate leakage power. The impact of operating temperature 
-  on both leakage power are considered. Longer channel devices 
-  that can reduce leakage significantly with modest performance 
-  penalty are also modeled.
-  
-* McPAT supports automatic extensive search to find optimal designs 
-  that satisfy the target clock frequency. The timing constraint 
-  include both throughput and latency.
-
-* Interconnect model with different delay, power, and area 
-  properties, as well as both the aggressive and conservative 
-  interconnect projections on wire technologies. 
-
-* All process specific values used by the McPAT are obtained
-  from ITRS and currently, the McPAT supports 90nm, 65nm, 45nm, 
-  32nm, and 22nm technology nodes. At 32nm and 22nm nodes, SOI 
-  and DG devices are used. After 45nm, Hi-K metal gates are used.
-
-How to use the tool?
-====================
-
-McPAT takes input parameters from an XML-based interface,
-then it computes area and peak power of the 
-Please note that the peak power is the absolute worst case power, 
-which could be even higher than TDP. 
-
-1. Steps to run McPAT:
-   -> define the target processor using inorder.xml or OOO.xml 
-   -> run the "mcpat" binary:
-      ./mcpat -infile <*.xml>  -print_level < level of detailed output>
-      ./mcpat -h (or mcpat --help) will show the quick help message.
-
-   Rather than being hardwired to certain simulators, McPAT 
-   uses an XML-based interface to enable easy integration
-   with various performance simulators. Our collaborator, 
-   Richard Strong, at University of California, San Diego, 
-   designed an experimental parser for the M5 simulator, aiming for 
-   streamlining the integration of McPAT and M5. Please check the M5 
-   repository/ for the latest version of the parser.
-   
-2. Optimize:
-   McPAT will try its best to satisfy the target clock rate. 
-   When it cannot find a valid solution, it gives out warnings, 
-   while still giving a solution that is closest to the timing 
-   constraints and calculate power based on it. The optimization 
-   will lead to larger power/area numbers for target higher clock
-   rate. McPAT also provides the option "-opt_for_clk" to turn on 
-   ("-opt_for_clk 1") and off this strict optimization for the 
-   timing constraint. When it is off, McPAT always optimize 
-   component for ED^2P without worrying about meeting the 
-   target clock frequency. By turning it off, the computation time 
-   can be reduced, which suites for situations where target clock rate
-   is conservative.
-  
-3. The output:
-   McPAT outputs results in a hierarchical manner. Increasing 
-   the "-print_level" will show detailed results inside each 
-   component. For each component, major parts are shown, and associated 
-   pipeline registers/control logic are added up in total area/power of each 
-   components. In general, McPAT does not model the area/overhead of the pad 
-   frame used in a processor die.
-   
-4. How to use the XML interface for McPAT 
-   4.1 Set up the parameters
-   		Parameters of target designs need to be set in the *.xml file for 
-   		entries taged as "param". McPAT have very detailed parameter settings. 
-   		please remove the structure parameter from the file if you want 
-   		to use the default values. Otherwise, the parameters in the xml file 
-   		will override the default values. 
-   
-   4.2 Pass the statistics
-   		There are two options to get the correct stats: a) the performance 
-   		simulator can capture all the stats in detail and pass them to McPAT;
-   		b). Performance simulator can only capture partial stats and pass 
-   		them to McPAT, while McPAT can reason about the complete stats using 
-        the partial information and the configuration. Therefore, there are 
-        some overlap for the stats. 
-   
-   4.3 Interface XML file structures (PLEASE READ!)
-   			The XML is hierarchical from processor level to micro-architecture 
-   		level. McPAT support both heterogeneous and homogeneous manycore processors. 
-   		
-   			1). For heterogeneous processor setup, each component (core, NoC, cache, 
-   		and etc) must have its own instantiations (core0, core1, ..., coreN). 
-   		Each instantiation will have different parameters as well as its stats.
-   		Thus, the XML file must have multiple "instantiation" of each type of 
-   		heterogeneous components and the corresponding hetero flags must be set 
-   		in the XML file. Then state in the XML should be the stats of "a" instantiation 
-   		(e.g. "a" cores). The reported runtime dynamic is of a single instantiation 
-   		(e.g. "a" cores). Since the stats for each (e.g. "a" cores) may be different,
-   		we will see a whole list of (e.g. "a" cores) with different dynamic power,
-   		and total power is just a sum of them.  
-   		
-   			2). For homogeneous processors, the same method for heterogeneous can 
-   		also be used by treating all homogeneous instantiations as heterogeneous. 
-   		However, a preferred approach is to use a single representative for all 
-   		the same components (e.g. core0 to represent all cores) and set the 
-   		processor to have homogeneous components (e.g. <param name="homogeneous_cores
-   		" value="1"/> ). Thus, the XML file only has one instantiation to represent 
-   		all others with the same architectural parameters. The corresponding homo 
-   		flags must be set in the XML file.  Then, the stats in the XML should be 
-   		the aggregated stats of the sum of all instantiations (e.g. aggregated stats 
-   		of all cores). In the final results, McPAT will only report a single 
-   		instantiation of each type of component, and the reported runtime dynamic power
-   		is the sum of all instantiations of the same type. This approach can run fast 
-   		and use much less memory.        
-
-5. Guide for integrating McPAT into performance simulators and bypassing the XML interface
-   		The detailed work flow of McPAT has two phases: the initialization phase and
-   the computation phase. Specifically, in order to start the initialization phase a 
-   user specifies static configurations, including parameters at all three levels, 
-   namely, architectural, circuit, and technology levels. During the initialization 
-   phase, McPAT will generate the internal chip representation using the configurations 
-   set by the user. 
-   		The computation phase of McPAT is called by McPAT or the performance simulator 
-   during simulation to generate runtime power numbers. Before calling McPAT to 
-   compute runtime power numbers, the performance simulator needs to pass the 
-   statistics, namely, the activity factors of each individual components to McPAT 
-   via the XML interface. 
-   		The initialization phase is very time-consuming, since it will repeat many 
-   times until valid configurations are found or the possible configurations are 
-   exhausted. To reduce the overhead, a user can let the simulator to call McPAT 
-   directly for computation phase and only call initialization phase once at the 
-   beginning of simulation. In this case, the XML interface file is bypassed, 
-   please refer to processor.cc to see how the two phases are called.
-   
-6. Sample input files:
-   This package provide sample XML files for validating target processors. Please find the 
-   enclosed Niagara1.xml (for the Sun Niagara1 processor), Niagara2.xml (for the Sun Niagara2 
-   processor), Alpha21364.xml (for the Alpha21364 processor), and Xeon.xml (for the Intel 
-   Xeon Tulsa processor). 
-   
-   Special instructions for using Xeon.xml:
-   McPAT uses ITRS device types including HP, LSTP, and LOP. Although most 
-   designs follow ITRS projections, there are designs with special technologies. 
-   For example, the 65nm Xeon Tulsa processor uses 1.25 V rather than 1.1V 
-   for the core voltage domain, which results in the changes in threshold voltage,
-   leakage current density, saturation current, and etc, besides the different 
-   supply voltage. We use MASTAR to match the special technology as used in Xeon 
-   core domain. Therefore, in order to generate accurate results of Xeon 
-   Tulsa cores, users need to do make TAR=mcpatXeonCore and use the generated 
-   special executable. The L3 cache and buses must be computed using standard 
-   ITRS technology.    
-    
-
-====================
-McPAT is in its beginning stage. We are still improving 
-the tool and refining the code. Please come back to its website 
-for newer versions. If you have any comments, 
-questions, or suggestions, please write to us.
-
-Version history and roadmap
-
-McPAT Alpha:      released Sep. 2009 Experimental release
-McPAT Beta (0.6): released Nov. 2009 New code base and technology base
-McPAT Beta (0.7): released May. 2010 Added various new models, 
-                  including long channel devices, buses model; together
-                  with bug fixes and extensive code optimization to reduce 
-                  memory usage.  
-McPAT Beta (0.8): released Aug. 2010 Added various new models, 
-                  including on-chip 10Gb ethernet units, PCIe, and flash controllers.
-Next major release:     
-McPAT 1.0:        including advance power-saving states
-
-Future releases may include the modeling of embedded low-power 
-processors as well as vector processors and GPGPUs.             
-                  
-
-Sheng Li             
[email protected] 
-
-
-
-