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 <config_filename>
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 <config_filename> -overwrite <new query string>
% ./dsent -cfg configs/example.cfg -overwrite "NumberInputs=5; NumberOutputs=6;"
To print out in a more human-friendly fasion:
% ./dsent -cfg <config_filename> -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 <expression>
print "<string_to_print>";
print "<string_to_print>" <expression>;
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.
e8ed7b1d1b