1DSENT (Design Space Exploration of Networks Tool) 2 3=============================================================================== 4Overview 5=============================================================================== 6DSENT is a modeling tool designed for rapid design space exploration of both 7electronical and emerging opto-electrical networks-on-chip (NoC). It provides 8analytic and parameterized models for various network components and is 9portable across a range of technology assumptions. Given architectural-level 10parameters, DSENT builds the specified models hierarchically from electrical 11and optical building blocks and outputs detailed power and area estimates. 12 13 14=============================================================================== 15Version 16=============================================================================== 17Current: 0.91 (26 June 2012) 18 19Latest version or additional information can be found at 20 21 https://sites.google.com/site/mitdsent 22 23=============================================================================== 24System requirements 25=============================================================================== 26We have tested DSENT on the following platforms: 27 28Linux GNU g++ 4.1.2 and glibc 2.5 29Linux GNU g++ 4.3.2 and glibc 2.7 30Linux GNU g++ 4.4.5 and glibc 2.11.3 31Cygwin g++ 4.5.3 and cygwin 1.7.14 32 33=============================================================================== 34License 35=============================================================================== 36Please refer to the LICENSE file for licensing and copyright information. 37 38If you use DSENT in your research, please acknowledge us by referencing our 39NOCS 2012 paper: 40 41Chen Sun, Chia-Hsin Owen Chen, George Kurian, Lan Wei, Jason Miller, 42Anant Agarwal, Li-Shiuan Peh, Vladimir Stojanovic, "DSENT - A Tool Connecting 43Emerging Photonics with Electronics for Opto-Electronic Networks-on-Chip 44Modeling." The 6th ACM/IEEE International Symposium on Networks-on-Chip 45(NOCS), May 2012, Lyngby, Denmark. 46 47 48=============================================================================== 49Contact information 50=============================================================================== 51If you have any questions or comments, please contact us through our mailing 52list at: mitdsent@mit.edu 53 54We will try to reply as soon as possible. 55 56 57=============================================================================== 58Build (installation) 59=============================================================================== 60To build DSENT: 61 62 % make 63 64By default DSENT is built with logging disabled. Logging keeps track of what 65happens while running DSENT. It is an option more for the DSENT framework and 66DSNET models developers. If you want to enable this option, simply type the 67following: 68 69 % make LIBUTIL_IS_LOG=true 70 71To clean the build: 72 73 % make clean 74 75 76=============================================================================== 77Usage 78=============================================================================== 79DSENT builds models and runs based on the specified configuration file. In the 80configuration file, you specify a model name and necessary information 81(parameters and properties) required to build the model. 82 83To run DSENT: 84 85 % ./dsent -cfg <config_filename> 86 87To check what models are available: 88 89 % ./dsent -available_models 90 91To overwrite the configuration file from command line: 92 Use ';' to separate different key/value pairs. 93 94 % ./dsent -cfg <config_filename> -overwrite <new query string> 95 % ./dsent -cfg configs/example.cfg -overwrite "NumberInputs=5; NumberOutputs=6;" 96 97To print out in a more human-friendly fasion: 98 99 % ./dsent -cfg <config_filename> -verbose 100 101To check what options are available: 102 103 % ./dsent -help 104 105Please see configs/example.cfg for an example of a configuration file. 106 107Please see configs/router.cfg for the router configuration file. 108 109Please see QueryString and EvaluateString specifications below to know more 110about the usage. 111 112=============================================================================== 113Advanced Usage 114=============================================================================== 115Since DSENT is a generic modeling framework for electrical and optical 116components, you can create your own models. We will release guidelines on how 117to create custom models on top of DSENT framework. You can use the provided 118models as references. 119 120 121=============================================================================== 122Quick start for Orion users 123=============================================================================== 124Instead of using the SIM_port.h file, DSENT uses a text-based configuration 125file to specify the router/link configurations. You do not need to recompile 126if you change parameters. Even though we use different parameter names, the 127ones we use should be self-explanatory. In this package, we provide template 128configuration files for the router and link: 129 130 router - configs/router.cfg 131 link - configs/electrical-link.cfg 132 133 Technology 134 ---------- 135 We currently support 45, 32, 22, 11nm. You can specify the desired 136 frequency but not the nominal voltage level since it is normally 137 fixed in different processes. 138 139 Router specs 140 ------------ 141 Currently we only support the model of a widely used 3-pipeline-stage 142 input-buffered virtual channel router and does not have distinction 143 from ports for different components (cache, memory controller, I/O). 144 145 Input buffer specs 146 ------------------ 147 The number of virtual channels used for different message classes 148 might be different; hence, DSENT uses NumberVirtualNetworks to 149 specify the number of message classes and use 150 NumberVirtualChannelsPerVirtualNetwork and 151 NumberBuffersPerVirtualChannel to define the buffers needed for a 152 virtual network (message class). 153 154 Currently only DFF-based RAM is supports. This is reasonable since 155 normally the buffer space needed at input port is small enough and 156 does not need to use SRAMs or RFs (register files). 157 158 Crossbar specs 159 -------------- 160 Currently DSENT only supports multiplexer-based crossbars 161 (MULTREE_CROSSBAR). You no longer need to specify the degree of the 162 multiplexers. 163 164 Switch allocator specs 165 ---------------------- 166 DSENT models a two-stage switch allocator. The first stage is used to 167 arbitrate between VCs in the same input port, and the second stage is 168 used to arbitrate between input ports. If there is only one VC in 169 the input port, then the energy/power/area cost for the first stage 170 will be zero. 171 172 Currently, DSENT supports MatrixArbiter. 173 174 VC allocator specs 175 ------------------ 176 We assume that the router uses a VC select scheme where the VC 177 allocation is done by just popping a FIFO. Currently DSENT ignores 178 this module since the FIFO that needs to keep the free VC information 179 should be small enough. 180 181 Clock distribution specs 182 ------------------------ 183 Currently DSENT provides a broadcast H-Tree model. You can specify 184 the number of levels of the H-Tree (normally 4 or 5 levels should be 185 enough). 186 187DSENT replaces the original orion_router_power, orion_router_area and 188orion_link with QueryString and EvaluateString (see below for more detailed 189information on how to use them). 190 191 192=============================================================================== 193QueryString specifications 194=============================================================================== 195DSENT is a query-based model evaluator. You use QueryString to specify what 196information you want DSENT to output. The syntax of a query string is shown as 197follows: 198 199 [Query type]>>[Instance name (with hierarchy)]:[Sub query type]@[Detail level] 200 201 E.g., Area>>Router->Crossbar:Active@4 202 * Query type: Area 203 * Instance name: Router->Crossbar 204 * Sub query type: Active 205 * Detail level: 4 206 207 Query type 208 ---------- 209 There are 9 types of queries: Parameter, Property, Energy, NddPower, 210 Area, InstHier, EventHier, NddPowerHier, AreaHier. 211 212 Parameter - Print the model parameters needed to be specified 213 Property - Print the design constraints or utilization 214 Use these to check what needs to be specified in the configuration 215 file for the model. No sub query type is needed for these two 216 types. 217 218 Energy - Print the data-dependent energy cost of an event 219 NddPower - Print the non-data-denepent power of an instance 220 Area - Print the area cost of an instance 221 Use these to obtain the costs of the specified model. 222 223 InstHier - Print the instance name hierarchy 224 Use this to know what sub-instances are built for this model 225 226 EventHier - Print the available events for Energy queries 227 NddPowerHier - Print the available non-data-dependent power types 228 AreaHier - Print the available area types 229 Use this to know what to specify in the "sub query type" field. 230 231 Instance name (with hierarchy) 232 ------------------------------ 233 The (sub)instance that you want to perform query. The name should be 234 hierarchical starting from the top level model. Hierarchies are 235 separated by the symbol "->". 236 237 Sub query type 238 -------------- 239 This field is not required for 'Parameter', 'Property' and 'InstHier'. 240 241 For 'Energy', this field stands for the event that cause this energy 242 cost, such as 'WriteBuffer'. 243 244 For 'NddPower' and 'Area', this field stands for the power and area 245 cost of the model, such as 'Leakage' and 'Active'. 246 247 For 'EventHier', if this field is not specified, all events of this 248 instance will be printed; if this field is specified, then only 249 the specified event will be printed. 'AreaHier' and 'NddPowerHier' 250 also have the similar behavior. 251 252 Detail level 253 ------------ 254 Defines the hierarchy depth to be printed. '0' means current level. 255 This field is needed for all query types for syntax correctness, 256 although it is not used for 'Parameter' and 'Property'. 257 258 Multi-line queries 259 ------------------ 260 Query strings specified across multiple lines in the config file 261 must have each line be terminated by a '\'. It is whitespace sensitive, 262 so make sure there are no spaces after '\'. Note that the parser 263 prunes everything after the comment '#' character, including '\'! 264 See configs/router.cfg as an example. 265 266 Examples of individual QueryString's: 267 268 Parameter>>Router@0 269 Property>>Router->Crossbar@0 270 InstHier>>Router->InputPort@2 271 Energy>>Router:WriteBuffer@2 272 NddPower>>Router->Crossbar:Leakage@3 273 Area>>Router->SwitchAllocator:Active@4 274 275 276=============================================================================== 277EvaluateString specifications 278=============================================================================== 279DSENT provides a way to let users do custom calculations by specifying the 280EvaluateString in the configuration file. EvaluateString constains a sequence 281of statements separated by one ';'. DSENT reads through the sequence and 282evaluates the statements one-by-one. 283 284Currently, DSENT supports: 285 Four arithmetic operations 286 -------------------------- 287 3 + 4 * (5 + 6) / 7; 288 289 Define local variables through assignments 290 ------------------------------------------ 291 variable 'a' will be mapped to 7 for future referencing 292 293 a = 3 + 4; 294 295 Global variable referencing 296 --------------------------- 297 $(var_name) indicates either a key in the configuration file or a 298 query string. If var_name exists in the configuration file, then the 299 corresponding value will be returned; otherwise, DSENT will do a query 300 using the string var_name@0 and return the query result. 301 302 b = $(Energy>>Router:WriteBuffer) * $(Frequency); 303 304 Printing outputs 305 ---------------- 306 DSENT prints the string following the keyword 'print'. 307 308 print <expression> 309 print "<string_to_print>"; 310 print "<string_to_print>" <expression>; 311 312 print 3 + 4; # Output: 7 313 print "Hello World"; # Output: Hello World 314 print "Hello World " 3 + 4; # Output: Hello World 7 315 316 Multi-line evaluate strings 317 --------------------------- 318 Evaluate strings specified across multiple lines in the config file 319 must have each line be terminated by a '\'. It is whitespace sensitive, 320 so make sure there are no spaces after '\'. Note that the parser 321 prunes everything after the comment '#' character, including '\'! 322 See configs/router.cfg as an example. 323 324 325=============================================================================== 326Units 327=============================================================================== 328DSENT uses only SI units for all inputs and outputs. For example: 329 time = s (second) 330 distance = m (meter) 331 capacitance = F (Farad) 332 power = W (Watt) 333 energy = J (Joule) 334 resistance = Ohm 335 loss = dB (Decibels) 336 337 338=============================================================================== 339Known Bugs and Issues 340=============================================================================== 341 3421. If timing is not met, the timing optimizer will put the model in a state 343where everything is the maximum size (huge power, area). Thus, model results 344can be considered a gross over-estimate when timing isn't met. This is just the 345nature of the greedy timing optimizer and it will be addressed in the future. 346 3472. The VC control and credit buffer component of the router is currently 348not modeled, as they have always been assumed to be lumped into the "negligible 349control cost" category in previous models and evaluations. Our recent 350experiments have shown that this is not true and we will be adding this in the 351next iteration. 352 3533. Some of the connectivity paths have not been checked thoroughly. Thus, 354timing optimizer may miss some of the paths. However, we tried to make sure 355that the critical paths are modeled properly. 356 3574. Local interconnect will have an ever-larger impact on power and timing as 358technology scales. So far we have not implemented a method for automatically 359estimating them but we will eventually address this. Evaluations for 22nm 360and below will tend to underestimate as a result. 361 362=============================================================================== 363Revision log 364=============================================================================== 365V0.91: 366 Bugs fix: 367 1. Leakage power calculation printout for router (configs/router.cfg). 368 369 New feature: 370 1. Area printout for router (configs/router.cfg). 371 372V0.9: 373 First release. 374 375