The first version of ORION, ORION1.0, was released in 2002. It embodied an architecture template approach to modeling NoC area and power . This template approach is based on modeling the circuit structure of each router component block (input and output buffer, crossbar, and switch and VC arbiter). ORION1.0 was extended in 2003 to incorporate leakage power models .
In 2009, a major revision of ORION, called ORION2.0 , was released that addressed a number of shortcomings of ORION1.0. Specifically, ORION2.0 added new clock power and flip-flop models, and new link power models, among other significant enhancements.
Despite significant enhancements to model new circuit-level and technology effects in ORION2.0, ORION2.0 still produces large estimation errors. There are several reasons for the discrepancy in the estimation results. First, ORION1.0 and ORION2.0 are based on circuit-level templates, which model specific logic structures for implementing the different router components. However, often there is a significant mismatch between the actual RTL code for the corresponding router component blocks and the logic structures assumed in the ORION2.0 templates. Second, typical ASIC design flows involve logic optimization, technology mapping, and placement and routing (P&R). In modern design flows, these design tools have complex interactions between them, and their effects are hard to predict. The final post P&R layout can deviate significantly from the logic template assumed even if the template matches the RTL code, which is often not the case. Logic template based approaches inherently cannot properly capture differences in RTL generators and the effects of design tools.
ORION3.0 fundamental differs from earlier versions of ORION in that the estimation models are derived from actual post P&R layout area and power data that correspond to the actual RTL generator and the actual target cell library. Following this paradigm, ORION3.0 incorporates two general categories of approaches. The first approach is based on parametric modeling . In contrast to ORION2.0, the parametric models are not based on assumed logic templates. Instead, for each component block in the router RTL, appropriate parametric models are derived from the post-synthesis netlist by observing how instance count changes with microarchitectural and implementation parameters. Using these parametric models, automatic parametric regression analysis by means of least-square regression (LSQR) with actual post-P&R area and power data is performed to refine the models, which produces highly accurate area and power estimates across multiple router RTLs, microarchitectures and implementation parameters. This approach does not require the architect or developer to understand how the architectural components are implemented. Rather, this methodology relies on a onetime characterization of post-synthesis 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, which was first described in . In this approach, estimation models are also derived from actual post P&R layout area and power data that correspond to the actual RTL generator and the actual target cell library. As described in , the non-parametric modeling approach is powerful in that it can automatically derive accurate surrogate models based on a sample set of post P&R results. In , Multivariate Adaptive Regression Splines (MARS) linear splines were used to derive the surrogate models. In addition to MARS, ORION3.0 incorporates four other metamodeling techniques for automatic model generation: Radial Basis Functions (RBF), Kriging (KG), Multivariate Adaptive Regression Splines with cubic splines and Support Vector Machine (SVM) Regression. This non-parametric modeling approach also does not require the architect or developer to understand how the architectural components are implemented. All the methods incorporated into ORION3.0 are described in .