- Moore” flows, that is, capable of simultaneously handling both “silicon complexity” and “system complexity.” Designing in the context of increased silicon complexity (i.e., the number of individual elements) is managed through the development of methods capable of handling multiple abstrac- tion levels and models of computation. - The urgency of this function- ality for current SoC/SiP design flows is only too apparent from the data available from the ITRS (see Table 19.1), where it is clear that the earliest bottlenecks stem from the integration of heterogeneous content.. - All ITRS Roadmaps (and intermediate updates) since 2003 clearly state that “Cost [of design] is the greatest threat to continuation of the semiconductor roadmap.. - Today, many design technology gaps are crises,” and identify this topic as one of the three main challenges to system design in the current post–45 nm era. - will require new modeling approaches, new types of creation and integration guidelines and rules, and, depending on the numbers of such design starts, may foster whole new toolsets.” The issues pertaining to heterogeneous systems design methods and associated tools thus form part of the spectrum of highly rele- vant and long-term research topics. - The European Commission also stresses the importance of design technology for nanoelectronic architectures of the future. - These approaches should be coupled with automatic translation of the resulting high-level designs into device manufacture.”. - A high-level vision of the maturity of existing abstraction levels for various physical domains is given in Table 19.2, with examples of adequate modeling languages or simulation engines where solutions exist.. - We first describe the architecture and philosophy of the RUNE II platform for the development of predictive design methods and tools for heterogeneous SoC, in a “More than Moore”. - 19.2 Rune II Platform. - The ongoing Rune II project ∗ aims at researching novel design methods capa- ble of contributing to the management of the increasing complexity of the. - The ultimate overall goals of the platform include. - The definition and development of a coherent design process for het- erogeneous SoC/SiP capable of effectively managing the whole of the heterogeneous design stages—through multiple domains and abstrac- tion levels. - A primary objective is to make clear definitions of the levels of abstraction, the associated design and modeling languages, and the properties of the objects at each level, whatever their natures (software components, digital/AMS/RF/multiphysics hardware). - We consider it to be necessary to clearly define the scheduling of the design stages (which one can also regard as transformation actions applied to the various components) in an approach of “V-cycles” or “spiral” type, as well as the rules necessary for the validation of each stage. - This makes it possible to establish the logistics of the design process, in particular for actions that could be carried out in parallel, and to take a first step toward a truly holistic design flow including economic and contextual constraints.. - The heterogeneous specification of the system by high-level modeling and cosimulation approaches. - intended to guarantee the transformation of the system specifications into a feasible set of components specified at a lower (more physi- cal) hierarchical level. - As shown in Figure 19.2, there is a clear bridge between system-level and physical-level (or domain-specific) phases of design—in our view this bridge. - FIGURE 19.2. - The main impact would be to combat the current inefficiency in design processes between (1) the a priori generation of component specification sets at the system level in the presence of uncertainty concerning the feasibility of these sets in the tar- get technology and (2) the a posteriori evaluation of the differences between specified and real component performance levels, generated at the physical level in the presence of uncertainty of their impact and potential degrees of freedom available at the system level. - A typical example of where such exploration would be required is in the optical interconnect demonstrator: based on software application con- straints, system optimization requires the analysis of tradeoffs between (for example) (1) the number of cores (and parallel software tasks) that can be linked efficiently by optical interconnect to reduce the power contribution of the data processing part of the application and (2) the technology char- acteristics leading to a specific data rate/power ratio and the power con- tribution of the data communication part of the application. - 19.2.1 Abstraction Levels. - FIGURE 19.3. - Figure 19.3 shows a Petri net style diagram [GIR2002] where the ovals (places) represent IP blocks with various levels of abstraction (F, functional/mathematical. - and at the circuit level, it concerns 0_A c , illustrating the nonsimulability of the overall system at circuit level.. - This approach enables clarification of the available/necessary steps in the design process. - It is quite clear that several routes exist to achieve com- plete top-down synthesis of each individual component in the system, and conversely several routes enable the bottom-up validation of the whole (the top-down and bottom-up routes do not necessarily pass through the same places).. - 19.2.1.1 Model for Synthesizable AMS/MT IP. - It is difficult to achieve because the IP hardening process (moving from a technology-independent, structure- independent specification to a qualified layout of an AMS/MT block) relies to a large extent on the quality of the tools being used to do this. - Table 19.3 summarizes the main facets necessary to AMS/MT IP, where each constituent element of design information is identified and the role of each is described.. - Figure 19.4 shows how these various facets of AMS/MT IP should be brought together in an iterative single-level synthesis loop. - First, the set S of the performance criteria, originating from the higher hierarchical structural level n + 1 in Figure 19.4, is used to quantify how the IP block should carry out the defined function. - Structure Internal component-based structure of the IP block.. - They have two distinct roles, related to the state of the IP block in the design process.. - This comparison between specified and real performance criteria values, the error function in Figure 19.4, drives ∗ m, the synthesis method, which describes the route to determine design variable values. - The number of design variables defines the number of dimensions of the design space. - Physical variables (in the set P, which outputs to the model parameter values in Figure 19.4) are directly related to design variables according to a mapping method ∗ r such that *r:V→P, and serve to parameterize all components in the structure definition during the IP block evaluation process. - The evaluation method ∗e, at the left of Figure 19.4, describes the route from the physical variable values to the performance criteria values such that *e:P→S, and thus completes the iterative single-level optimization loop.. - The latter describes the role of the parameter extraction method, which is necessary to define how the design pro- cess moves up the hierarchical levels during bottom-up verification phases.. - At the end of the synthe- sis process at a given hierarchical level, an IP block will be defined by a set of physical variable values, some of which are parameters of an IP sub- block. - 19.2.2 UML/XML Implementation. - From the user’s point of view, there are two main phases to AMS/MT synthesis: AMS/MT soft-IP definition, which can be done via UML, XML, or through a specific GUI (all inputs are interoperable—the internal database format is XML). - FIGURE 19.5. - In order to develop a UML-based approach to hierarchical AMS/MT syn- thesis, it is necessary to map the AMS/MT IP element requirements given in Table 19.3 to UML concepts. - Structural diagram, to express the static relationship between the building blocks of the system. - We used a class diagram to describe the properties of the AMS/MT IP blocks and the intrinsic relations between them. - Behavioral diagram, showing the evolution of the system overtime through response to requests, or through interaction between the sys- tem components. - By representing all this in a single diagram, shown in Figure 19.6a, we are in fact modeling a library of system components. - A class diagram constitutes a static representation of the system. - each facet of the AMS/MT IP requirements set out in Table 19.3 can be included in the various model types, as shown in Figure 19.6b. - 19.3 Multi-Technology Design Exploration Application:. - Rune II has been extensively used in the exploration of integrated optical interconnect tradeoffs, both (1) to automatically size interface circuits accord- ing to link specifications and technology characteristics, thus enabling com- plete sizing of the optical link. - Because of the very diverse nature of the exploration space variables, and the level of detail required in the investigations and analyses, this work could only be carried out using an automated and predictive simulation-based synthesis approach.. - the development and implementation of the specification- and technology-driven optical point-to- point link synthesis method. - and the definition of the performance metrics and specification sets to be used in the investigation program.. - 19.3.1 Models for the Simulation and Synthesis of an Optical Link In order to extract meaningful physical data from analyses where advanced CMOS technologies are involved and accurate device models are key to the relevance of investigation, it is essential to work toward design tech- nology including the simulation of a complete optical point-to-point link in an EDA framework. - A functional model will describe the behavior of a device according to its specifications and behavioral equa- tions, without defining the structure of the device. - The nonlinear behavior of the microsource laser was modeled (enabling the visualization of physical limits) and converges systematically in Spectre. - The organization of the interface circuit and active optoelectronic device model libraries, complying to the UML modeling rules set out in Section 19.2.3, are shown in Figure 19.7a and b respectively.. - The models were all implemented in the OVI-96 Verilog-A subset of Verilog-AMS, an extension of the IEEE 1364-1995 Verilog hardware descrip- tion language (VHDL). - This way, the optical and photonic devices can be simulated together with the interface circuitry and with the rest of the optical link given adequate simulation models. - Detailed description of these models is outside the scope of this chapter, but the device parameters for optical interconnect varied in this analysis are shown in Table 19.4, with minimum and maximum values defining the limits of the parameter variation. - 19.3.2 Optical Point-to-Point Link Synthesis. - The objective of our work was to carry out transistor-level sizing of the receiver and of the driver circuits according to complete link specifications.. - This includes, as shown in Figure 19.8a, a photonic communication layer integrated above a standard CMOS circuit above the metallic interconnect layers. - transmitter and receiver circuits modulate laser current and transform detector current respectively, through a via stack as represented by R via in Figure 19.8b. - In this design approach, no architectural variants are considered (i.e., the CMOS topologies used at the transistor level are fixed in terms of their structure—. - Communication between the different blocks is ensured using the synthesizable AMS/MT IP blocks, and the actual synthesis and evaluation scenario relies upon the instantiation of the generic top-level object in a testbench structure. - The procedure used to automatically synthesize an optical point-to-point link, and implemented as a synthesis scenario, is shown in Figure 19.10. - The value of the rms noise power, i n , is extracted from the simulation of the schematic, and updated for each synthesis loop, using the Morikuni formula [MOR1994] in the transimpedance amplifier noise calculations:. - FIGURE 19.10. - BER, defined as the rate of error occurrences, is one of the main criteria in evaluating the performance of digital transmission systems. - The value of the power that needs to be emitted by the laser source is evaluated from the calculated value of the minimum optical power at the. - receiver, and from the power losses induced by the geometry of the waveg- uide structure (length and intrinsic loss, number of bends, and loss/90˚ bend) and coupling. - The final sizing step is to calculate the driver and associated bias and buffer circuits using the emitted power value and the source characteristics in conjunction with the method shown in Figure 19.10. - This then enables the simulation of the complete optical link, using transistor-level schematics for the interface circuits and the developed behavioral models for the pho- tonic devices. - 19.3.3 Performance Metrics and Specification Sets. - In order to be able to evaluate and optimize link performance criteria cor- rectly, a clear definition of the performance metrics is required. - For interconnect density aspects, source and detector sizes must be taken into account, while the width, pitch, and required bend radius of waveguides is fundamental to estimating the size of the photonic layer. - The data rate is essentially governed by the bandwidth of the photore- ceiver: high modulation speed at the source is generally more easily attain- able than similar detection speed at the receiver. - This is largely due to the photodiode parasitic capacitance at the input of the transimpedance amplifier.. - 19.4 Integrated Optical Interconnect Investigation Program and Results. - In this section, we cover the values of the performance metrics generated by the synthesis procedures described in the previous section. - Two sets of optical device parameters as described in Table 19.4, which will be denoted in the following analyses as S1 (“pessimistic” values) and S2 (“optimistic” values). - Table 19.5 shows the sets of specifications used for analysis and interface circuit sizing and to demonstrate the capacity of the platform and imple- mented method to synthesize optical links subject to technological specifi- cations, both CMOS and optical. - The minimal output drive strength was set to that of the same inverter.. - 19.4.1 Gate Area Analysis. - The link sizing method described in Section 19.3.2 was applied according to the specifications for the PTM 65, 45, and 32 nm technologies. - Figure 19.11 shows the results in terms of gate area (i.e., transistor channel dimensions only), extracted as the sum of all transistor gate channel areas W · L. - These figures demonstrate an impressive reduction in gate area in favor of optical intercon- nect (of the order of 60x–90x for link lengths above 1 cm and for the two most advanced technology nodes) with respect to electrical interconnect. - 19.4.2 Delay Analysis. - FIGURE 19.11. - Figure 19.12 shows the delay results for varying link lengths.. - It can be seen that (a) the circuit delay (i.e., the difference between the total delay and the intrinsic waveguide delay) decreases with smaller gate lengths, and (b) the same quantity also decreases with longer interconnect. - The underlying reason for this is that delay for optical interconnect does not depend as strongly on interconnect length as electrical interconnect, because no additional circuit stages are added—the increase stems from higher intrinsic waveguide delay only. - 19.4.3 Power Analysis. - Fig- ure 19.13a shows the average static power results for varying link lengths.. - Figure 19.13b shows the dynamic power results for varying link lengths, calculated from rising and falling edge transitions (the average switching energy extracted from simulations as the integral of supply currents in edge transitions).. - FIGURE 19.12
Xem thử không khả dụng, vui lòng xem tại trang nguồn hoặc xem
Tóm tắt