From e8ed7b1d1b5bef31e9874f679a5797c2e00d06f1 Mon Sep 17 00:00:00 2001 From: Nilay Vaish Date: Sat, 11 Oct 2014 15:02:23 -0500 Subject: ext: add the source code for DSENT This patch adds a tool called DSENT to the ext/ directory. DSENT is a tool that models power and area for on-chip networks. The next patch adds a script for using the tool. --- ext/dsent/README | 374 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 374 insertions(+) create mode 100644 ext/dsent/README (limited to 'ext/dsent/README') diff --git a/ext/dsent/README b/ext/dsent/README new file mode 100644 index 000000000..0143a43ef --- /dev/null +++ b/ext/dsent/README @@ -0,0 +1,374 @@ +DSENT (Design Space Exploration of Networks Tool) + +=============================================================================== +Overview +=============================================================================== +DSENT is a modeling tool designed for rapid design space exploration of both +electronical and emerging opto-electrical networks-on-chip (NoC). It provides +analytic and parameterized models for various network components and is +portable across a range of technology assumptions. Given architectural-level +parameters, DSENT builds the specified models hierarchically from electrical +and optical building blocks and outputs detailed power and area estimates. + + +=============================================================================== +Version +=============================================================================== +Current: 0.91 (26 June 2012) + +Latest version or additional information can be found at + + https://sites.google.com/site/mitdsent + +=============================================================================== +System requirements +=============================================================================== +We have tested DSENT on the following platforms: + +Linux GNU g++ 4.1.2 and glibc 2.5 +Linux GNU g++ 4.3.2 and glibc 2.7 +Linux GNU g++ 4.4.5 and glibc 2.11.3 +Cygwin g++ 4.5.3 and cygwin 1.7.14 + +=============================================================================== +License +=============================================================================== +Please refer to the LICENSE file for licensing and copyright information. + +If you use DSENT in your research, please acknowledge us by referencing our +NOCS 2012 paper: + +Chen Sun, Chia-Hsin Owen Chen, George Kurian, Lan Wei, Jason Miller, +Anant Agarwal, Li-Shiuan Peh, Vladimir Stojanovic, "DSENT - A Tool Connecting +Emerging Photonics with Electronics for Opto-Electronic Networks-on-Chip +Modeling." The 6th ACM/IEEE International Symposium on Networks-on-Chip +(NOCS), May 2012, Lyngby, Denmark. + + +=============================================================================== +Contact information +=============================================================================== +If you have any questions or comments, please contact us through our mailing +list at: mitdsent@mit.edu + +We will try to reply as soon as possible. + + +=============================================================================== +Build (installation) +=============================================================================== +To build DSENT: + + % make + +By default DSENT is built with logging disabled. Logging keeps track of what +happens while running DSENT. It is an option more for the DSENT framework and +DSNET models developers. If you want to enable this option, simply type the +following: + + % make LIBUTIL_IS_LOG=true + +To clean the build: + + % make clean + + +=============================================================================== +Usage +=============================================================================== +DSENT builds models and runs based on the specified configuration file. In the +configuration file, you specify a model name and necessary information +(parameters and properties) required to build the model. + +To run DSENT: + + % ./dsent -cfg + +To check what models are available: + + % ./dsent -available_models + +To overwrite the configuration file from command line: + Use ';' to separate different key/value pairs. + + % ./dsent -cfg -overwrite + % ./dsent -cfg configs/example.cfg -overwrite "NumberInputs=5; NumberOutputs=6;" + +To print out in a more human-friendly fasion: + + % ./dsent -cfg -verbose + +To check what options are available: + + % ./dsent -help + +Please see configs/example.cfg for an example of a configuration file. + +Please see configs/router.cfg for the router configuration file. + +Please see QueryString and EvaluateString specifications below to know more +about the usage. + +=============================================================================== +Advanced Usage +=============================================================================== +Since DSENT is a generic modeling framework for electrical and optical +components, you can create your own models. We will release guidelines on how +to create custom models on top of DSENT framework. You can use the provided +models as references. + + +=============================================================================== +Quick start for Orion users +=============================================================================== +Instead of using the SIM_port.h file, DSENT uses a text-based configuration +file to specify the router/link configurations. You do not need to recompile +if you change parameters. Even though we use different parameter names, the +ones we use should be self-explanatory. In this package, we provide template +configuration files for the router and link: + + router - configs/router.cfg + link - configs/electrical-link.cfg + + Technology + ---------- + We currently support 45, 32, 22, 11nm. You can specify the desired + frequency but not the nominal voltage level since it is normally + fixed in different processes. + + Router specs + ------------ + Currently we only support the model of a widely used 3-pipeline-stage + input-buffered virtual channel router and does not have distinction + from ports for different components (cache, memory controller, I/O). + + Input buffer specs + ------------------ + The number of virtual channels used for different message classes + might be different; hence, DSENT uses NumberVirtualNetworks to + specify the number of message classes and use + NumberVirtualChannelsPerVirtualNetwork and + NumberBuffersPerVirtualChannel to define the buffers needed for a + virtual network (message class). + + Currently only DFF-based RAM is supports. This is reasonable since + normally the buffer space needed at input port is small enough and + does not need to use SRAMs or RFs (register files). + + Crossbar specs + -------------- + Currently DSENT only supports multiplexer-based crossbars + (MULTREE_CROSSBAR). You no longer need to specify the degree of the + multiplexers. + + Switch allocator specs + ---------------------- + DSENT models a two-stage switch allocator. The first stage is used to + arbitrate between VCs in the same input port, and the second stage is + used to arbitrate between input ports. If there is only one VC in + the input port, then the energy/power/area cost for the first stage + will be zero. + + Currently, DSENT supports MatrixArbiter. + + VC allocator specs + ------------------ + We assume that the router uses a VC select scheme where the VC + allocation is done by just popping a FIFO. Currently DSENT ignores + this module since the FIFO that needs to keep the free VC information + should be small enough. + + Clock distribution specs + ------------------------ + Currently DSENT provides a broadcast H-Tree model. You can specify + the number of levels of the H-Tree (normally 4 or 5 levels should be + enough). + +DSENT replaces the original orion_router_power, orion_router_area and +orion_link with QueryString and EvaluateString (see below for more detailed +information on how to use them). + + +=============================================================================== +QueryString specifications +=============================================================================== +DSENT is a query-based model evaluator. You use QueryString to specify what +information you want DSENT to output. The syntax of a query string is shown as +follows: + + [Query type]>>[Instance name (with hierarchy)]:[Sub query type]@[Detail level] + + E.g., Area>>Router->Crossbar:Active@4 + * Query type: Area + * Instance name: Router->Crossbar + * Sub query type: Active + * Detail level: 4 + + Query type + ---------- + There are 9 types of queries: Parameter, Property, Energy, NddPower, + Area, InstHier, EventHier, NddPowerHier, AreaHier. + + Parameter - Print the model parameters needed to be specified + Property - Print the design constraints or utilization + Use these to check what needs to be specified in the configuration + file for the model. No sub query type is needed for these two + types. + + Energy - Print the data-dependent energy cost of an event + NddPower - Print the non-data-denepent power of an instance + Area - Print the area cost of an instance + Use these to obtain the costs of the specified model. + + InstHier - Print the instance name hierarchy + Use this to know what sub-instances are built for this model + + EventHier - Print the available events for Energy queries + NddPowerHier - Print the available non-data-dependent power types + AreaHier - Print the available area types + Use this to know what to specify in the "sub query type" field. + + Instance name (with hierarchy) + ------------------------------ + The (sub)instance that you want to perform query. The name should be + hierarchical starting from the top level model. Hierarchies are + separated by the symbol "->". + + Sub query type + -------------- + This field is not required for 'Parameter', 'Property' and 'InstHier'. + + For 'Energy', this field stands for the event that cause this energy + cost, such as 'WriteBuffer'. + + For 'NddPower' and 'Area', this field stands for the power and area + cost of the model, such as 'Leakage' and 'Active'. + + For 'EventHier', if this field is not specified, all events of this + instance will be printed; if this field is specified, then only + the specified event will be printed. 'AreaHier' and 'NddPowerHier' + also have the similar behavior. + + Detail level + ------------ + Defines the hierarchy depth to be printed. '0' means current level. + This field is needed for all query types for syntax correctness, + although it is not used for 'Parameter' and 'Property'. + + Multi-line queries + ------------------ + Query strings specified across multiple lines in the config file + must have each line be terminated by a '\'. It is whitespace sensitive, + so make sure there are no spaces after '\'. Note that the parser + prunes everything after the comment '#' character, including '\'! + See configs/router.cfg as an example. + + Examples of individual QueryString's: + + Parameter>>Router@0 + Property>>Router->Crossbar@0 + InstHier>>Router->InputPort@2 + Energy>>Router:WriteBuffer@2 + NddPower>>Router->Crossbar:Leakage@3 + Area>>Router->SwitchAllocator:Active@4 + + +=============================================================================== +EvaluateString specifications +=============================================================================== +DSENT provides a way to let users do custom calculations by specifying the +EvaluateString in the configuration file. EvaluateString constains a sequence +of statements separated by one ';'. DSENT reads through the sequence and +evaluates the statements one-by-one. + +Currently, DSENT supports: + Four arithmetic operations + -------------------------- + 3 + 4 * (5 + 6) / 7; + + Define local variables through assignments + ------------------------------------------ + variable 'a' will be mapped to 7 for future referencing + + a = 3 + 4; + + Global variable referencing + --------------------------- + $(var_name) indicates either a key in the configuration file or a + query string. If var_name exists in the configuration file, then the + corresponding value will be returned; otherwise, DSENT will do a query + using the string var_name@0 and return the query result. + + b = $(Energy>>Router:WriteBuffer) * $(Frequency); + + Printing outputs + ---------------- + DSENT prints the string following the keyword 'print'. + + print + print ""; + print "" ; + + print 3 + 4; # Output: 7 + print "Hello World"; # Output: Hello World + print "Hello World " 3 + 4; # Output: Hello World 7 + + Multi-line evaluate strings + --------------------------- + Evaluate strings specified across multiple lines in the config file + must have each line be terminated by a '\'. It is whitespace sensitive, + so make sure there are no spaces after '\'. Note that the parser + prunes everything after the comment '#' character, including '\'! + See configs/router.cfg as an example. + + +=============================================================================== +Units +=============================================================================== +DSENT uses only SI units for all inputs and outputs. For example: + time = s (second) + distance = m (meter) + capacitance = F (Farad) + power = W (Watt) + energy = J (Joule) + resistance = Ohm + loss = dB (Decibels) + + +=============================================================================== +Known Bugs and Issues +=============================================================================== + +1. If timing is not met, the timing optimizer will put the model in a state +where everything is the maximum size (huge power, area). Thus, model results +can be considered a gross over-estimate when timing isn't met. This is just the +nature of the greedy timing optimizer and it will be addressed in the future. + +2. The VC control and credit buffer component of the router is currently +not modeled, as they have always been assumed to be lumped into the "negligible +control cost" category in previous models and evaluations. Our recent +experiments have shown that this is not true and we will be adding this in the +next iteration. + +3. Some of the connectivity paths have not been checked thoroughly. Thus, +timing optimizer may miss some of the paths. However, we tried to make sure +that the critical paths are modeled properly. + +4. Local interconnect will have an ever-larger impact on power and timing as +technology scales. So far we have not implemented a method for automatically +estimating them but we will eventually address this. Evaluations for 22nm +and below will tend to underestimate as a result. + +=============================================================================== +Revision log +=============================================================================== +V0.91: + Bugs fix: + 1. Leakage power calculation printout for router (configs/router.cfg). + + New feature: + 1. Area printout for router (configs/router.cfg). + +V0.9: + First release. + -- cgit v1.2.3