ORION3.0: A Comprehensive NoC Router Estimation Tool

Transcription

1 IEEE EMBEDDED SYSTEMS LETTERS, VOL. XX, NO. Y, MONTH XX, ORION3.0: A Comprehensive NoC Router Estimation Tool Andrew B. Kahng, Fellow, IEEE, Bill Lin, Senior Member, IEEE, and Siddhartha Nath, Student Member, IEEE Abstract Networks-on-Chip (NoCs) are increasingly used in many-core architectures. ORION2.0 [9] is a widely adopted NoC power and area estimation tool but its estimation models can have large errors (up to 185%) versus actual implementation. We present, ORION3.0, a tool that implements parametric and non-parametric modeling methodologies that fundamentally differ from ORION2.0 logic template-based approaches in that the estimation models are derived from actual physical implementation data. When compared with actual implementations, our modeling methodologies achieve average estimation errors of no more than 9.8% across microarchitecture, implementation, and operational parameters as well as multiple router RTL generators. These methodologies are implemented in the ORION3.0 distribution [20]. I. INTRODUCTION Networks-on-Chip (NoCs) have proven to be highly scalable and low-latency interconnection fabrics in the era of many-core architectures, as evidenced by commercial chips such as the Intel 80-core [16], and IBM Blue Gene [15] processors. NoCs are part of uncore in the new 2013 International Technology Roadmap for Semiconductors (ITRS) [17] MPU model. Because of their growing importance, NoC implementations must be optimized for latency and power [11]. To facilitate early design-space exploration, tools that can accurately estimate NoC power and area are required. This paper describes ORION3.0, a comprehensive NoC router estimation tool that embodies both parametric and nonparametric models. We include new models of router component blocks using parametric [5] and non-parametric modeling [6] methodologies that fundamentally differ from approaches like ORION2.0 [9] in that the estimation models are derived from actual post place-and-route (P&R) data that corresponds to the actual RTL generator and target cell library. Following this paradigm, we describe two approaches that are implemented in ORION3.0. The first approach is based on parametric modeling. Our work in [5] is a substantial departure from the ORION2.0 approach because no logic template is assumed for any router component block. Instead, for each component block in the router RTL, appropriate parametric models are derived from the postsynthesis netlists by observing how instance counts change with A. B. Kahng is with the Departments of Computer Science and Engineering, and of Electrical and Computer Engineering, University of California at San Diego, La Jolla, CA abk@ucsd.edu. B. Lin is with the Department of Electrical and Computer Engineering, University of California at San Diego, La Jolla, CA billlin@ece.ucsd.edu. S. Nath is with the Department of Computer Science and Engineering, University of California at San Diego, La Jolla, CA sinath@ucsd.edu Copyright c 2013 IEEE. Personal use of this material is permitted. However, permission to use this material for any other purposes must be obtained from the IEEE by sending an to pubs-permissions@ieee.org. microarchitectural, implementation, and operational parameters. We call these models ORION NEW. We perform least-squares regression (LSQR) with actual post-p&r power and area data to refine these ORION NEW models. The resulting parametric models achieve worst-case errors significantly better than those of ORION2.0. Our parametric modeling methodology does not require the architect or developer to understand how the architectural components are implemented. Rather, the methodology relies on a one-time characterization of postsynthesis data to derive parametric models of component blocks, and automatic fitting of these models to post-p&r data using parametric regression. The second approach is based on non-parametric modeling. In this approach, estimation models are also derived from actual post P&R layout power and area data that correspond to the actual RTL generator and target cell library. The non-parametric modeling approach is powerful in that it can automatically derive accurate estimation models based on a sample set of post P&R results. In ORION3.0, we extend the ideas of [8] [3] by incorporating four other metamodeling techniques for automatic model generation: Radial Basis Functions (RBF), Kriging (KG), Multivariate Adaptive Regression Splines with linear and cubic splines, and Support Vector Machine (SVM) regression. The non-parametric modeling approach also does not require the architect or developer to understand how the architectural components are implemented. For backward compatibility, ORION3.0 also includes logic template-based models in ORION2.0. Based on requirements of modeling accuracy, availability of training and testing data for regression, users have the flexibility of choosing specific modeling methodologies. For example, when training and testing data for a technology or tool flow is not available, users may use ORION NEW models with scaled technology parameters. Our main contributions are as follows: 1) We describe a new parametric modeling methodology that derives accurate parametric models from actual postsynthesis netlists by observing how instance counts change with microarchitectural, implementation, and operational parameters. The post-synthesis netlists accurately capture contributions from both the control and data paths. 2) We demonstrate that popular non-parametric regression techniques, namely, RBF, KG, MARS, and SVM, can be highly accurate (worst-case errors less than 20%) in NoC power and area estimations. 3) We have released ORION3.0 on the web for download. There have been over 100 downloads since webpage opened for download in February The remainder of this paper is organized as follows. Section II presents ORION NEW models and describes our parametric modeling methodology, and Section III provides description of our non-parametric modeling methodology. Section IV describes

2 IEEE EMBEDDED SYSTEMS LETTERS, VOL. XX, NO. Y, MONTH XX, the software architecture of ORION3.0, possible extensions with newer user-defined models as well as training and testing datasets, and details on ORION3.0 distribution and tool citations. Section V concludes this work. II. PARAMETRIC MODELING Figure 1 shows example of a modern on-chip network router with input and output buffers, switch and virtual channel arbiter, and the crossbar. ORION2.0 uses logic template models for these router blocks. However, these models can be inaccurate because of mismatches between the actual RTL and the templates assumed. Moreover, typical design flows involve sophisticated design steps that have complex interactions among them, making their effects difficult to characterize. To illustrate the degree of inaccuracy, we show in Figures 2(a) and (b) power and instance counts estimation errors at 65nm for ORION2.0 when compared to two router RTL generators, Netmaker [19] from Cambridge and the Stanford NoC router [22], as a function of the number of input ports in the router. The maximum errors are greater than 100% and 1000%, respectively. For these two RTL generators, [5] reports significant improvements in power, area, and instance counts estimation using ORION NEW models. Fig. 1. Router architecture [11]. Fig. 2. Poor estimations by ORION2.0 [9]. (a) Power and (b) instance counts of Netmaker and Stanford NoC vs. ORION2.0 at 65nm as a function of #ports. A. Model Enhancements The ORION NEW router block models in ORION3.0 model instances (or gates) in each router block, which our studies show to be required for accurate estimations of area and power. The microarchitecture parameters used are #Ports (P), #VCs (V), #Buffers (B) and Flit-width (F). Crossbar (XBAR) Model. ORION NEW models comprehend modern router RTL implementations which use smaller crossbars instead of traditional matrix [11] and multiplexer tree [9] implementations in ORION2.0. The XBAR uses tri-state buffers (modeled as 2:1 MUX) to control each flit. Hence, the total number of such MUXes required is: P P F. Switch and VC Arbiter (SWVC) Model. ORION NEW removes the default overhead factor of 30% used by ORION2.0 because our analysis indicates that this overhead is not needed with frequencies in the range 400MHz-900MHz for process nodes 45nm to 130nm. SWVC is modeled as: 9 (P (P (V 2 + 1) + (V 2 1)). The constant factor 9 arises because six 2-input NOR gates, two INVerters, and one D-FlipFlop are used to generate one grant signal on each path. Input Buffer (InBUF) Model. ORION NEW models take into account control signals and housekeeping logic which are needed required to decode flits and manage VCs. ORION2.0 models lack these components and are hence inaccurate. In ORION NEW, FIFO buffers are modeled as: 2 P V B F, and control signals and housekeeping logic are modeled as: 180 P V + 2 P 2 V B+3 P V B+5 P 2 B+P 2 +F P+15 P. The constant factors are derived by using linear regression to fit the number of instances in the post-synthesis netlists to the microarchitecture parameters. Output Buffer (OutBUF) Model. ORION NEW models take into account hybrid output buffer implementations in modern router RTLs as well as control signals per port and VC associated with each buffer. Therefore, instead of modeling output buffers in exactly the same way as it models input buffers; OutBUF is modeled as: P (80 V + 25). The constant factors are derived by using linear regression to fit the number of instances in the post-synthesis netlists to the microarchitecture parameters. Clock and Control Logic (CLKCTRL) Model. ORION NEW models the clock buffers and clock routing resources as frequency scales. ORION2.0 does not model impact on these resources because of frequency scaling. ORION NEW models these resources as 2% of the sum of instances in the SWVC, InBUF and OutBUF component blocks. Frequency Derating Model. ORION2.0 models are agnostic to implementation parameters such as clock frequency and results in large estimation errors at high frequencies. We first find the frequency below which instance counts change by less than 1%. We derate instance counts by a multiplier Instance that is based on this frequency as: Instance = Frequency ConstantFactor. The constant factors are derived by using linear regression to fit the number of instances in the post-synthesis netlists to frequency and the microarchitecture parameters. B. Modeling Methodology Figure 3 shows our flow to derive new parametric models, ORION NEW, from post-synthesis netlists and subsequent refinement process by fitting the models to post-p&r area, power, and instance counts data. We use the Netmaker and the Stanford NoC router RTL generators, and a range of values of microarchitecture parameters (#Ports (P), #VCs (V), #Buffers (B) and Flit-width (F)) and implementation parameters (clock frequency and technology node) to configure the router. We synthesize the router RTLs using Synopsys Design Compiler vf sp4-64 (DC) [23] and Cadence RTL Compiler vedi10.1 (RC) [13], with options to preserve module hierarchy after synthesis because we analyze each router component block. We then analyze the post-synthesis netlists to derive ORION NEW models. To refine these models, we generate post-p&r power and area data. We place and route the synthesized netlists using Cadence SOC Encounter vedi10.1 (SOCE) with die utilization of 0.75 and die aspect ratio of 1.0. We use Synopsys PrimeTime-PX (PT- PX) [23] to run power analysis based on the post-p&r netlist,

3 IEEE EMBEDDED SYSTEMS LETTERS, VOL. XX, NO. Y, MONTH XX, NoC router RTL generators µarch params: P, V, B, F Synthesis and P&R: DC/RC, SOCE Analysis of blocks: XBAR, SW & VC arbiter, Input & Output buffers ORION_NEW models for each component block Implementation params: Clock Frequency Post-P&R area, power, instances LSQR New fitted models Fig. 3. High-level flow used to develop the ORION NEW and fitted models using post-p&r data. SPEF [23] and SDC [1]. Finally, we use the MATLAB [18] function lsqnonneg to fit the models to post-p&r data. C. Results We compare area and power estimation errors of ORION2.0 to those of ORION NEW fitted using our regression approach. Figures 4(a) and (b) plot estimation errors for power and area respectively at 45nm and 65nm technology nodes. The ORION NEW estimates are very close to actual implementation (average error of 9.8% in estimating Netmaker power at 45nm) and are robust across multiple microarchitecture, implementation parameters, and router RTLs. popular non-parametric regression or metamodeling techniques RBF, KG, MARS, and SVM. Detailed descriptions of these techniques are in [2]. A. Modeling Methodology We derive NoC area and power models by performing non-parametric fit of post-p&r data using 65nm and 45nm technology libraries. We first perform synthesis using Synopsys Design Compiler [23], followed by place and route using Cadence SOC Encounter [13], of the Netmaker [19] router RTL. Next, we generate area and power reports of these designs to use as training and test data points. Figure 5 shows our synthesis and P&R flow. We use two sampling methodologies to generate the training sets a modified Latin Hypercube Sampling (LHS) [4], and a restricted sampling methodology. The restricted sampling methodology does not include higher values of the microarchitectural parameters in the training set. More precisely, the resulting training sets omit all values of {B=7}, or of {P = 9}, or of {V = 7}, or of {F = 64}. Fig. 5. Non-parametric regression flow. Fig. 4. Least-squares regression fit vs. ORION2.0: (a) power estimation error and (b) area estimation error. III. NON-PARAMETRIC MODELING Non-parametric regression techniques provide another approach to estimate NoC power and area [8] [3]. Such techniques can considerably reduce modeling efforts because they require only the microarchitectural, implementation, and operational parameters as input variables. The models determine the interactions between these input variables and how they affect the output (or response). This alleviates the effort needed to model a NoC, as details of architecture-level implementations are avoided. At the same time, non-parametric regression approaches are scalable across multiple router RTLs, technology libraries and commercial tool flows. In ORION3.0, we implement four B. Results We use 256 data points of post-p&r power and area values using 45nm and 65nm technology libraries to generate training and test data points. The input variables to all the models are P, V, B and F and the responses are post-p&r power and area. We use two training set sizes sparse and restricted with 50 data points, and sparse only with 64 data points and test the accuracy of models in estimating area and power for input parameters which are beyond the range of values used for training. In each experiment, model generation takes around 3s and response estimation takes around 1.88s. We repeat all experiments 10 times for each training set size, and report the averages of all the error values across the 10 trials. Figures 6(a) and (b) show the percentage errors observed in estimating standard-cell area and power, respectively at 45nm and 65nm by training models using sparse and restricted training sets. The average errors are less than 10% in area and 20% in power. We observe that RBF performs better than other techniques at both technologies across area and power estimations. The maximum estimation error for RBF is less than 20% and can be up to 3x more accurate than KG, MARS and SVM. Figures 7(a) and (b) show similar plots by using only sparse training sets. We observe that RBF is more accurate than other techniques, but the difference in accuracy is not as significant with KG and MARS as compared to the sparse and restricted case. The improvement in accuracy for SVM is less than 23% for power, but 100% for area at 45nm. Across all training set sizes used in our experiments, we observe that area

4 IEEE EMBEDDED SYSTEMS LETTERS, VOL. XX, NO. Y, MONTH XX, and power estimation errors are the smallest for RBF and are the highest for SVM. In general, these techniques have smaller estimation errors at 65nm than at 45nm. Fig. 6. Estimation accuracy of (a) area and (b) power at 45nm with sparse and restricted training dataset (i.e. 50 data points for training). Fig. 7. Estimation accuracy of (a) area and (b) power at 65nm with only sparse training dataset (i.e., 64 data points for training). IV. ORION3.0 DISTRIBUTION We now describe ORION3.0 software architecture, extensibility with new models and training/testing datasets, and details of ORION3.0 software distribution. A. Software Architecture ORION3.0 uses a modular software architecture and is written in C and MATLAB. Figure 8 shows the high-level software architecture, how router configuration is read by the tool and how models get invoked. To this end, ORION3.0 adds several new command line options for the user to choose (1) ORION3.0 vs. ORION2.0 models, (2) ORION3.0 modeling techniques, namely, basic, lsqr, rbf, kg, mars, and svm, (3) training, and (4) training data points when the modeling technique is from the set {lsqr, rbf, kg, mars, svm}. As with ORION2.0, users can configure microarchitecture parameters such as, flit-width, #input and output buffers, #virtual channels, #pipeline stages, type of crossbar, #ports, etc. in the SIM port.h file. These parameters are used when user chooses either the ORION2.0 models or the ORION3.0 basic model. Furthermore, we updated the technology files with accurate leakage and internal power data from the TSMC 45nm technology libraries for all cell-types used in modeling. Users can specify implementation and operational parameters such as technology library, size of MUXes in the crossbar, and the input load on the router from the link. The tool uses ORION3.0 basic models by default when no options are specified by the user. The basic models refer to the ORION NEW models described in Section II. All models report area in µm 2, power in mw, and energy in J. Fig. 8. Software architecture of ORION3.0. to make sure that the input can be converted to a non-singular matrix. The user has the option to not provide either of these training or test data points; the tool uses default training and testing data points based on the technology configured in the SIM port.h file in the PARM TECH POINT field. In addition, users can develop their own regression models in MATLAB and integrate it with ORION3.0. They need to invoke a wrapper in orion router.c and invoke the model from a shell script. The shell script is invoked from orion router.c using the system method in C. C. Software Distribution ORION3.0 is available for web download from [20] and is referenceable as [6] [5]. We provide academic MATLAB toolboxes for RBF [21], KG [10], MARS [12], and SVM [14] under the same copyright and license agreements as available in their distributions. We provide doxygen-based documentation of all functions and structures implemented as part of the distribution. V. CONCLUSION Accurate modeling for NoC area and power estimation is critical to successful early design-space exploration in the era of many-core computing. ORION2.0, while very popular, has large errors versus actual implementation. This is because there is often a mismatch between the actual router RTL and the templates assumed. Also, typical design flows involve sophisticated optimizations that are difficult to characterize. We present ORION3.0, a tool that incorporates comprehensive parametric and non-parametric modeling techniques to accurately estimate NoC power and area. Our parametric models, ORION NEW, explicitly account for control and data path resources. We further refine these parametric models by performing leastsquares regression analysis (LSQR) on post-p&r data. Our nonparametric models are four popular techniques RBF, KG, MARS, and SVM. Our results show that these techniques can be low-overhead and highly accurate in estimating NoC power and area. Our results show that RBF can be more accurate than others for sparse and restricted training sets. ORION3.0 is now available for web download and distribution [20]. B. Tool Extensibility When user chooses lsqr or any of the non-parametric regression modeling techniques, namely, rbf, kg, mars, svm, then they have the option of providing their own training and testing data points. ORION3.0 does basic validation of the data points ACKNOWLEDGMENTS This work was supported in part by the NSF grant SHF , the MARCO GSRC focus center, and the SRC. We also thank Mr. Jeremiah Fong for developing the front-end interfaces for ORION3.0.

5 IEEE EMBEDDED SYSTEMS LETTERS, VOL. XX, NO. Y, MONTH XX, REFERENCES [1] J. Bhasker and R. Chadha, Static Timing Analysis for Nanometer Designs: A Practical Approach, Springer, [2] T. Hastie, R. Tibshirani and J. Friedman, The Elements of Statistical Learning: Data Mining, Inference, and Prediction, Springer, [3] K. Jeong, A. B. Kahng, B. Lin and K. Samadi, Accurate Machine Learning-Based On-Chip Router Modeling, IEEE ESL, 2(3) (2010), pp [4] R. Jin, W. Chen and T. W. Simpson, Comparative Studies of Metamodeling Techniques Under Multiple Modeling Criteria, Trans. Struct. Multidiscip. Optim. 23 (2001), pp [5] A. B. Kahng, B. Lin and S. Nath, Explicit Modeling of Control and Data for Improved NoC Router Estimation Proc. DAC, 2012, pp [6] A. B. Kahng, B. Lin and S. Nath, Comprehensive Modeling Methodologies for NoC Router Estimation, University of California San Diego Technical Report CS , 2012, pp [7] A. B. Kahng, B. Lin and S. Nath, Enhanced Metamodeling Techniques for High-Dimensional IC Design Estimation Problems, Proc. DATE, 2013, pp [8] A. B. Kahng, B. Lin and K. Samadi, Improved On-Chip Router Analytical Power and Area Modeling Proc. ASP-DAC, 2010, pp [9] A. B. Kahng, B. Li, L.-S. Peh and K. Samadi, ORION 2.0: A Fast and Accurate NoC Power and Area Model for Early-Stage Design Space Exploration, Proc. DATE, 2009, pp [10] S. N. Lophaven, H. B. Nielsen and J. Sondergaard, Aspects of the MATLAB Toolbox DACE, Technical University of Denmark Technical Report IMM-REP , [11] H.-S. Wang, L.-S. Peh and S. Malik, Orion: A Power-Performance Simulator for Interconnection Networks, Proc. MICRO, 2002, pp [12] ARESLab. [13] Cadence Design Implementation. [14] LIBSVM. cjlin/libsvm [15] IBM Blue Gene processor. [16] Intel 80-Core Report. [17] ITRS Edition Reports and Ordering. [18] MATLAB. [19] Netmaker. rdm34/wiki [20] ORION [21] RBF2 Manual. mjo/rbf.html [22] Stanford NoC. [23] Synopsys Tools.

6 IEEE EMBEDDED SYSTEMS LETTERS, VOL. XX, NO. Y, MONTH XX, Dear Editor and Reviewers: We are submitting ORION3.0: A Comprehensive NoC Router Estimation Tool. In this paper we describe ORION3.0, recently released on the web for download from which makes significant improvements on ORION2.0 (2009). Quality of the release is supported by over 100 downloads during the past several months. Improvements to NoC parametric modeling are described in our paper, Explicit Modeling of Control and Data for NoC Router Estimation that appeared in Proc. ACM IEEE EDAC Design Automation Conference, June We made the following enhancements in ORION3.0. We significantly improve accuracy of parametric models of NoC router blocks of ORION2.0 (2009) by implementing ORION NEW models described in our DAC12 paper. These models are derived from analysis of post-synthesis netlists of multiple router RTL generators and synthesized using multiple commercial tools. We also implement automatic fitting of post-layout data using least-squares regression to the ORION NEW models. We augment non-parametric models derived by applying well-known techniques such as Radial Basis Functions (RBF), Kriging (KG), Multivariate Adaptive Regression Splines (MARS) and Support Vector Machines (SVM). These models automatically fit post-layout data that is specific to a commercial SP&R tool flow and technology library. We provide our training and testing set of data points from NoC routers implemented using TSMC 45nm and 65nm technologies. We describe the software architecture and user interface of ORION3.0. A user can choose from the following modeling options: (1) ORION2.0, (2) ORION NEW models from DAC12, (3) ORION NEW fitted with post-layout data using least-squares regression, (4) RBF, (5) KG, (6) MARS, and (7) SVM. We demonstrate that ORION3.0 interfaces are highly flexible. These interfaces seamlessly allow users to add new nonparametric NoC models, training and testing set of data points to ORION3.0. Please contact me with any questions concerning the submission. Thank you for your consideration. Sincerely, Siddhartha Nath (on behalf of co-authors Andrew B. Kahng and Bill Lin) Department of Computer Science and Engineering University of California at San Diego La Jolla, CA sinath@ucsd.edu