McPAT is an integrated power, area, and timing modeling framework that supports comprehensive design space exploration for multicore and manycore processor configurations ranging from 90nm to 22nm and beyond [19]. The tool and the technical report describing it can be downloaded in the following link:
http://www.hpl.hp.com/research/mcpat
McPAT provides a flexible XML interface that can interact with a properly modified performance simulator. Through a plain-text file in XML format, McPAT receives the architectural parameters and technological features of the modeled processor, as well as some structure access statistics provided by a performance simulator. With this information, the tool dumps power, area, and timing statistics for the computed design.
McPAT uses the Cacti tool [20] to obtain the models for the on-chip data arrays, CAM tables, and cache structures. It also uses its own power, area, and timing models for combinational logic, such as functional units, results broadcast buses, instruction wakeup logic, or interconnection networks.
McPAT input file
The following is en excerpt of an XML McPAT input file specifying the characteristics and activity of the instruction cache:
<component id="system.core0.icache" name="icache">
<param name="icache_config" value="131072,32,8,1,8,3,32,0"/>
<param name="buffer_sizes" value="16,16,16,0"/>
<stat name="read_accesses" value="1000"/>
<stat name="read_misses" value="56"/>
<stat name="conflicts" value="3"/>
</component>
In this example, the <param> entries specify the cache geometry and cache controller buffer sizes, respectively. The<stat> entries give the read accesses, read misses, and cache line conflicts occurred during a performance simulation carried out previously on top of Multi2Sim.
By analyzing this data, jointly with some other global technological data such as feature size or clock frequency, McPAT can estimate the area, access time, and both dynamic and leakage energy
dissipated during the execution of the simulated benchmarks.
Interaction with Multi2Sim
Multi2Sim has been adapted to provide those statistics that McPAT requires in its input file. Though the processor models provided by McPAT and Multi2Sim are not exactly the same, still some common configurations can be obtained to estimate the global energy dissipated for a given benchmark
execution. The correspondence between the Multi2Sim statistics and McPAT input parameters is given in Appendix II at the end of this document.
McPAT output
Table 14.1 shows a list of the hardware components whose area, access time, and energy is detailed in the McPAT output. These components are classified hierarchically, and statistics are given both individually and in groups. For each of the listed elements, the following values are reported:
• Area (mm2).
Table 14.1: Hardware components reported by McPAT
• Peak dynamic power (W).
• Subthreshold and gate leakage power (W).
• Average runtime dynamic power (W).
Since these values are given separately for each processor structure, the energy dissipation associated to each component can be independently evaluated. For example, an alternative design can be proposed for a given processor structure (such as a register file or data cache), and its physical
properties can be evaluated with the Cacti tool [20]. Then, the Cacti results can be combined with the McPAT output, and the global power, energy, and area can be obtained for the proposed design.
Chapter 15
Coding Guidelines
Multi2Sim follows some standard coding guidelines closely resembling those for the Linux kernel. This chapter described some basic code formatting rules, and other standards followed by the Multi2Sim developers:
15.1 General Formatting Rules
Indenting
Tabs should be used for indenting. It is recommended to configure your editor with a tab size of 8 spaces for a coherent layout with other developers of Multi2Sim.
Line wrapping
Lines should have an approximate maximum length of 80 characters, including initial tabs (and
assuming a tab counts as 8 characters). If one line of code has to be split, two tabs should be inserted at the beginning of the next line. For example:
int long_function_with_many_arguments(int argument_1, char *arg2, struct my_type_t *arg3)
{
/* Function body */
}
Comments
Comments should not use the double slash (//) notation. They should use instead the standard/*
Text */ notation. Multiple-line comments should use a*character at the beginning of each new line, respecting the 80-character limit of the lines.
/* This is an example of a comment that spans multiple lines. When the
* second line starts, an asterisk is used. */
Code blocks
Brackets in code blocks should not share a line with other code, both for opening and closing brackets.
The opening parenthesis should have no space on the left for a function declaration, but it should have
it forif,while, and forblocks. Examples:
In the case of conditionals and loops with only one line of code in their body, no brackets need to be used. The only line of code forming their body should be indented one position.
for (i = 0; i < 10; i++)
Enumeration types should be named enum <xxx>_t, without using any typedef declarations. For example:
Dynamic memory allocation should be done using functions xmalloc, xcalloc, xrealloc, and xstrdup, defined in ’lib/mhandle/mhandle.h’. These functions internally call their corresponding malloc, calloc, realloc, and strdup, and check that they return a valid pointer, i.e., enough memory was available to be allocated. For example:
void *buf;
char *s;
buf = xmalloc(100);
s = xstrdup("hello");
Forward declarations
Forward declarations should be avoided. A source file.c in a library should have two sections (if used) declaring private and public functions. Private functions should be defined before they are used to avoid forward declarations. Public functions should be included in the.h file associated with the.c
source (or common for the entire library). For example:
/*
* Private Functions
*/
static void func1() {
...
}
[ 2 line breaks ] static void func2() {
...
}
[ 4 line breaks ] /*
* Public Functions
*/
void public_func1() {
...
}
Variable declaration
Variables should be declared only at the beginning of code blocks (can be primary or secondary code blocks). Variables declared for a code block should be classified in categories, such as type, or location of the code where they will be used. Several variables sharing the same type should be listed in different lines. For example:
static void mem_config_read_networks(struct config_t *config)
When a function takes no input argument, its declaration should use the (void) notation, instead of just(). If the header uses the empty parentheses notation, the compiler sets no restrictions in the number of arguments that the user can pass to the function. On the contrary, the (void)notation forces the caller to make a call with zero arguments to the function.
This affects the function declaration in a header file, a forward declaration in a C file, and the header of the function definition in the C file.
Example:
/* Header file or forward declaration */
void say_hello(void);
Conditions and expressions in parenthesis should be have a space on the left of the opening parenthesis. Arguments in a function and function calls should not have a space on the left of the opening parenthesis.
No spaces are used after an opening parenthesis or before a closing parenthesis. One space used after commas.
if (a < b)
void my_func_decl(int a, int b);
Spaces should be used on both sides of operators, such as assignments or arithmetic:
var1 = var2;
for (x = 0; x < 10; x++) a += 2;
var1 = a < 3 ? 10 : 20;
result = (a + 3) / 5;
Type casts should be followed by a space:
printf("%lld\n", (long long) value);
Integer types
Integer variables should be declared using built-in integer types, i.e., avoiding types instdint.h
(uint8_t,int8_t,uint16_t, ...). The main motivation is that some non-built-in types require type casts in printf calls to avoid warnings. Since Multi2Sim is assumed to run either on an x86 or an x86-64 machine, the following type sizes should be used:
• Unsigned 8-, 16-, 32-, and 64-bit integers:
– unsigned char
– unsigned short
– unsigned int
– unsigned long long
• Signed 8-, 16-, 32-, and 64-bit integers:
– char
– short
– int
– long long
Integer typeslong andunsigned longshould be avoided, since they compile to different sizes in 32- and 64-bit platforms.