Master Informatique Recherche Mod`eles et M´ethodes pour les Syst`emes Intelligents R´epartis et la R´ealit´e Virtuelle (MMSIRRV) Universit´e de Bretagne Occidentale

NA B OO : A G ENERIC , E VOLUTIVE CAD F RAMEWORK FOR AUTOMATIC C IRCUIT L AYOUT ON E MERGING NANOSCALE A RCHITECTURES by Ciprian TEODOROV

under the guidance of Lo¨ıc Lagadec, Catherine Dezan, Bernard Pottier

Lab-STICC - Architecture & Syst`eme, CNRS UMR 3192 Universit´e de Bretagne Occidentale June 3, 2008

Contents

Introduction 1

4

Nanoscale Fabric Architectures 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 1.2 Common Characteristics of Nanoscale Architectures 1.2.1 Assembly Techniques . . . . . . . . . . . . 1.2.2 Fault Tolerance Techniques . . . . . . . . . . 1.2.3 Nano/CMOS interface . . . . . . . . . . . . 1.3 NASIC fabric architecture . . . . . . . . . . . . . . 1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

6 6 6 6 7 8 8 9

2

Symbolic Circuit Layout with NA B OO Framework 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Related Works: Madeo Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 NanoMadeo: A Flow for Application Design Automation onto Hybrid Nano/CMOS Fabrics 2.4 NA B OO Framework Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Metamodel-based Object-Oriented Framework . . . . . . . . . . . . . . . . . . . 2.4.2 Prospection Possibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3 NA B OO Framework Input Formats . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.4 Logical Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.5 Physical Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.6 Physical Tools and Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10 10 11 11 12 13 13 14 14 14 15 15

3

A Methodology for Creating Robust and Durable Frameworks 3.1 Extensive use of Software Design Patterns . . . . . . . . . . 3.1.1 Composite Design Pattern . . . . . . . . . . . . . . 3.1.2 Visitor Design Pattern . . . . . . . . . . . . . . . . 3.2 Tool Development around Stable Models . . . . . . . . . . . 3.3 Evolutive and Portable Models and APIs . . . . . . . . . . . 3.4 Platypus Integration Framework . . . . . . . . . . . . . . . 3.4.1 STEP standard . . . . . . . . . . . . . . . . . . . . 3.4.2 Express Language . . . . . . . . . . . . . . . . . . 3.4.3 STEP Standard Integration . . . . . . . . . . . . . . 3.5 Software Reuse and Refactoring . . . . . . . . . . . . . . . 3.5.1 CopyDown Method Refactoring Process . . . . . . .

16 16 17 17 17 18 18 18 18 19 20 20

1

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

3.6 4

5

6

3.5.2 Does not understand message interception . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Domain Models and Their Integration in NA B OO Framework 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Structured Circuit Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Model entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Model Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Madeo SCNode Refactoring . . . . . . . . . . . . . . . . . . . . . . . 4.3 Architectural Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 A Simple Model Targeting Nasic Fabric Architecture . . . . . . . . . . 4.3.2 The Specialization of the Model for Targeting other Nanoscale Fabrics . 4.3.3 Further Extensions of the Architectural Model . . . . . . . . . . . . . 4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21 22

. . . . . . . . . .

. . . . . . . . . .

23 23 23 24 24 25 25 26 26 26 26

On the way to a Generic, Evolutive CAD Framework 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Logic Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Pla Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Floorplanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Generic Simulated Annealing Implementation . . . . . . . . . . . . . . . . . . . 5.4.2 Specializing the Simulated Annealing Algorithm for the Floorplanning Problem . 5.4.3 TCG-S Floorplanning Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Nasic Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

28 28 30 30 30 31 31 33 34 35 35 36

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

Conclusions and Perspectives

37

A Models and Refactoring Techniques A.1 Isomorph Model Refactoring: Smalltalk Implementation . . . . . . . . . . . . . . . . . . A.2 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

42 42 44

List of Figures

1.1

Nasic NW FETs-based nanotile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 2.2 2.3 2.4

Madeo CAD flow . . . . . . . . . . . . . . . NanoMadeo flow . . . . . . . . . . . . . . . NA B OO Framework Flow . . . . . . . . . . . Logic Circuit Simulator and Schematic Editor

. . . .

11 12 13 14

3.1 3.2 3.3

Composite Design Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . STEP Standard Encoder and Decoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . Isomorph Model Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17 19 21

4.1 4.2

Structured Circuit Model integration and example . . . . . . . . . . . . . . . . . . . . . . Recursive composition of the Composite Design Pattern . . . . . . . . . . . . . . . . . . .

24 24

5.1 5.2 5.3 5.4 5.5 5.6

Detailed flow of the first NA B OO framework prototype Custom Adder Circuit . . . . . . . . . . . . . . . . . . Structured circuit instance of Custom Adder . . . . . . Generic model of the simulated annealing heuristic . . The floorplanning result of the Custom Adder circuit . Nasic Placement Results . . . . . . . . . . . . . . . .

. . . . . .

28 29 30 33 35 36

A.1 Structured Circuit Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2 Madeo SCObject hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.3 Architectural Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44 45 46

3

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

8

Introduction

”Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and weighs 30 tons, computers in the future may have only 1,000 vaccuum tubes and perhaps weight 1.5 tons.” Popular Mechanics, March 1949 One of the most exciting developments in science and engineering over the past few years has been the progress toward architectures, materials, and devices for nanoscale and molecular-electronics-based computing systems. These developments meet with the need of the microelectronic industry for ever increasing performances and smaller feature sizes. In the context where the current, CMOS, technology is certainly going to stop scaling because of its physical properties, the nanotechnologies are seen as a viable alternative. During the last years a number of computing architectures using nanoscale devices where proposed. These architectures include NanoPLA [10], CMOL [20], FPNI [34], NASIC [24, 40, 39, 38] - to name some of them. They are based on a variety of devices such as FETs, spin-based devices, molecular diodes and molecular switches. The fabrication process uses a a combination of lithography and bottom-up self assembly techniques. One of the consequences of this approach is the impossibility to realize defect free circuits, thus different techniques should be employed to render these fabrics usable even in the presence of defects. Furthermore, all these fabrics will not be able to operate using just nanoscale devices, thus they include some CMOS support circuitry. Some like FPNI will perform all logic operations using CMOS gates, others like NASIC will use CMOS just for control circuitry. The proposed architectures range from general purpose processors, to programmable logic arrays like FPGAs, and to specialized devices such as cellular arrays and cellular neural networks. For more details on these architectures the reader should refer to [37]. Design automation of applications on these fabrics is an important aspect, since the huge number of devices per cm2 and the presence of faults render the circuit design impossible without specialized tools. As most of the proposed architectures resembles current PLA/FPGA architectures, probably the classical FPGA CAD flow could be re-targeted for these architectures. A number of specific tools are already proposed for each architecture. These tools are eighter based on generic FPGA tools like VPR [7], or custom tools made specifically for the proposed architecture([10]). In the context of CAD tools for application design automation, in general, important metrics are the generality of the tool, and its capacity of adapting to new architectures. Some example of such tools are VPR[7] and Madeo[18]. In the case of nanoscale fabrics the need for general tools is even more stringent due to the rapid technological evolution. An early example of such a tool is NanoMadeo[11], a framework proposed to automate the application design on a wide range of nanofabrics. In this context, we already did a preliminary study as a commented bibliography[37] on the available nanofabrics, and the possibility of re-targeting the FPGA CAD flow on them. The research focus chosen was the design and development of an automatic circuit layout flow, based on a metamodeling approach, 4

trying to use high level tools and generic algorithms in order to calculate abstract circuit layouts on a wide range of nanoscale architectures. The framework would isolate and orthogonally compose the key aspects of the circuit layout problem in order to create a generic, evolutive set of tools capable of helping the circuit and architecture designers to easily do architectural prospection on the available and prospective nanoscale computational fabrics, thus enabling them to have a realistic measure of different aspects related to the designed circuit or to the underlying hardware model. The work presented in this report has been done in the Lab-STICC laboratory, at UBO, with the Architectures and Systems team which have experience in the field of FPGA application design automation and symbolic circuit layout. The team produced a CAD framework, namely Madeo[18], capable of synthesizing highly optimized operators and of mapping them on a wide range of FPGA architectures. The Madeo framework is divided in two parts: 1. A generic back-end offering a generic architectural modeling framework targeted to reconfigurable architectures and common support tools (placement, routing, visualization) enabling a transparent usage of the different reconfigurable architectures modeled; 2. An original front-end offering an object oriented programming environment for circuit specification. . Recently the back-end was extended to target also nanoscale architecture in collaboration with the Software Systems and Architectures team at UMass, and reconfigurable parts of systems-on-chip (MadeoPlus) in the context of the European project Morpheus[30]. The approach taken was to analyze the Madeo tool[18], in order to extract good features that we can reuse, and re-factorize them in order to adapt to the new constraints imposed by the nanoscale architectures. In a first step the Nasic architecture is used as a case study. During this work we developed a preliminary tool, NA B OO 1 , able to produce circuit layouts on Nasic fabric architecture. Report overview Chapter 1 presents the technological context of this work, discussing some characteristics of hybrid nano/CMOS architectures, with an emphasis on the Nasic architecture, which was chosen as the reference architecture for a first case study. In Chapter 2, a general overview of the proposed framework (NA B OO ) is given. The methodology used to build this framework is discussed in Chapter 3. The models used by this framework are detailed in Chapter 4. Chapter 5 presents a first implementation of the framework. The purpose of this chapter is to prove the viability of this approach in the context of nanoscale computing architectures. Finally, some conclusions and perspectives are presented in Chapter 6.

1 N A B OO

= Nano Back-end tOOl

5

1 Nanoscale Fabric Architectures

”Architecture is inhabited sculpture.” Constantin Brˆancus¸i

1.1 Introduction To be able to follow the trend imposed by Moore’s law we need to obtain higher and higher device densities at the lowest possible cost. Thus, providing abundant resources used to craft basic computational fabrics. Nanoelectronic devices provide today an alternative way of increasing device density by using nanoscale electronic components. But even though many nanoelectronics devices have been demonstrated in research laboratories[13], a crucial step is to integrate these devices into an architecture that takes advantage of their strengths and overcomes their limitations. Firstly, the nanoelectronic devices cannot be assembled into architectures that comprise only nano scale elements. Thus, first generation of fabrics using these tiny devices will consist of hybrid architectures with the CMOS technology playing an important role in the design and development of these circuits. Chapter outline This chapter starts by presenting some of the common characteristics shared by the nanofabrics proposed in the literature. Afterwards it details the Nasic architecture, that is used as a first case study for the development of the nano-oriented circuit layout CAD framework presented in this report.

1.2 Common Characteristics of Nanoscale Architectures Even though in detail the proposed nanoscale architectures are different one from another, they share a number of common characteristics due to the usage of the nano-devices. In the following subsection we will present some of these common characteristics.

1.2.1 Assembly Techniques With nanoelectronics one of the major problems is their small feature size that makes almost impossible the use of traditional lithography. Current approaches to overcome this problem include three major ideas: • Self-assembly: let the circuits assemble themselves; • Manipulation at a higher level: guide a group of wires so they line up in the same direction; • Stochastic assembly: place enough elements until they statistically form the desired device.

6

This bottom-up approach to assembly has a number of consequences that should be taken in account by fabric designers. The regularity of assembly is one of the constraints imposed by this assembly approach, this means that the computational fabrics will no longer be made of custom circuits but, more likely, of generic circuits configured with respect to the application needs. Most of the hybrid architectures[10, 36, 34, 42] proposed in the literature are using nanowire crossbars rather than arbitrary geometries as current designers are using in top-down VLSI. This regularity in the nanoscale structures is driving researchers to build architectures that resembles today’s PLA and FPGA fabrics. This inherent regularity in assembly can also play an important role in coping with the high rate of defects, that is yet another consequence of the bottom-up assembly techniques.

1.2.2 Fault Tolerance Techniques The sources of error expected to be present on the nanoscale fabric are, mainly, due to the bottom-up fabrication process, proposed as a cheaper fabrication technique. They can be classified into three categories: • Permanent Defects are definitive changes in the fabric structure. The manufacturing process is the principal source for such defects. The small nanowires and the bottom up assembly process are expected to contribute to high rates of defects in nanoscale fabrics. They also may appear during the circuit operations. Some examples of this type of defects are: broken nanowires, stuck open/short FETs. • Process Variations[26] are caused by speed deviations due to device parameter variations. They can occur for certain input parameters as a result of large unexpected delay for that combinations. They will occur due to doping variations of NW used for channels or by length variations caused by the metalization process used to separate FETs one from another. • Transient Faults are the variations of a circuit parameters during its lifetime due to internal or external noise(alpha particles, neutron, proton, etc). The circuits presenting this kind of faults are not permanently damaged, the faulty behavior disappearing once the noise source disappears. A number of fault tolerance techniques where proposed in literature to make the circuits more or less resistant to these possible faults. Some of these are: • Configuration around defects[6] approach used in the Teramac project. It consist in building a defect map of a circuit using special tester circuits. Once the defect map built, the application is placed and routed around the defects. This technique implies that the underlying fabric is reconfigurable, which is not a problem with the nanoscale architectures since the assembly process produces regular structures. This approach is used by most of the hybrid nano/CMOS architectures [10, 36, 34]. • Circuit level built-in redundancy[40] implies replication of NWs and of FET transistors in order to mask faulty signals, thus rendering a self healing fabric. This way the need for defect map extraction and special nano/CMOS interface for reconfiguration is eliminated. For further enhancing the fabric fault tolerance, along with this technique, at different granularity levels, other techniques can be used: – Interleaving of redundant NWs[40] thus limiting the area of the circuit where built-in redundancy does not work (the so called ”hard to mask regions”) . – Insertion of weak pull-up/down micro/nano wires[40] for broken NWs in order to be able to correct a faulty 1 before an OR gate. – Error correcting circuits[26] is the use of error correcting codes not at application level like in telecommunication applications but at circuit level. This implies adding redundant signals to the original input signals in order to achieve the desired Hamming distance. Furthermore error correcting FET are added in order to maintain a valid circuit.

7

– Triple modular redundancy[25] at tile level in order to further improve the fault tolerance. Each tile may be replicated 2 times and voting can be done at each stage or on the final output. The implementation of the voter circuit in CMOS is required in order to have trustworthy voters. As we can see, a large number of fault tolerance techniques has been proposed by the researchers on different projects. The NASIC team[40, 25, 39, 26] is building a self healing fabric which is a radically different approach to others[10, 36, 34] which are using, mainly, the defect map extraction and routing around defects technique to cope with the inherent defects at nanoscale level.

1.2.3 Nano/CMOS interface As discussed earlier in this section, the first architectures using nano scale devices will be hybrid architectures having nano and CMOS parts. So, another important aspect, in designing computational fabrics using nanoelectronics, is the role played by CMOS technology in the resulting circuit. The CMOS technology is used, depending on the architecture, for logic, for interconnect, clocking, power, ground, configuration wires, I/O. In order to be able to use CMOS devices and nanoelectronic devices on the same circuit an interface between the two have to be made, for addressing the nanoscale wires from the microscale ones. Directly driving the nanowires with microscale wires is not feasible because the feature size of the microscale wires will negate the potential benefits of the minuscule devices. To solve this problem different approaches where proposed. In nanoPLA[10], the approach is to use a stochastic decoder proposed by DeHon. In CMOL[36] and FPNI[34] a 3D structure of the fabric is used. The nano layer is on top of the CMOS layer and connection pins provide the communication between the two.

1.3 NASIC fabric architecture At UMass, Moritz et al.[42] proposed an application specific nanoscale integrated circuit, namely Nasic. Nasic1 is a hierarchical fabric architecture using FETs on 2-D semiconductor NWs to implement logic functions. The basic building blocks of Nasic architecture are the nanotiles (see figure 1.1(b), for a generic view of a nanotile), build up as a grid of NWs with FETs at the junctions. Around each such grid we have microwires providing the control and power circuitry.

a)

b)

Figure 1.1: a) Nasic NW FETs-based nanotile implementing 1-bit adder[38]. b)Area breakdown of a typical Nasic nanotile.[38] The Nasic circuits operate based on temporary storage of data on a nanowire, each nanowire having transistors at both ends connected to a clock phase. The logic implementation is based on the PLA model, but since the complementary signals are required additional lines appear in the actual implementation. The product terms of the function are realized with P1 Nasic

= Nanoscale Application-Specific Integrated Circuits

8

doped nanodevices and the sum of product terms are realized using N-doped nanodevices. In figure 1.1(a), we can see the implementation of 1-bit adder using one Nasic nanotile. The Nasic approach has been presented through the implementation of a Wire Streaming Processor (WISP)[38]. Wisp is a simple, but complete, design showing the principles of the Nasic fabric. The WISP processor is made up of 5 pipeline stages: 1. fetch, 2. decode, 3. register file, 4. execute, and 5. write-back.. This processor supports a simple ISA: 1. nop, 2. movi, 3. mov, 4. add, 5. mul. The Nasic architecture has raised a number of interesting issues in designing nano/CMOS integrated circuits. • Latching on the wire[24, 39] in order to build pipelined circuits without the use of explicit latching (which implies the use of registers); • In one of the latest papers [41] Moritz et al. showed the possibility to combine AND-OR and NORNOR logic styles in order to obtain denser logic (up to 48% better than the original WISP-0[38] processor using AND-OR logic); • In order to reduce the manufacturing requirement a single type FET Nasic architecture was investigated[27], the results showed that the performances of the fabric increase with no deterioration of the circuit density. • While in the first stages of the development[42] the fabric was conceived as being reconfigurable, in the later papers[40] the authors renounced at the reconfigurability. This new version of the fabric did not need a nano/CMOS interface for reconfiguration, this enabling denser circuits. But, on the other hand, without a reconfigurable fabric, another approach was needed in order to render the fabric fault tolerant. • To solve this problem, in [40, 25, 39, 26], novel fault tolerance techniques were proposed (ex.circuit level redundancy, Error correcting circuits, etc). An advantage of using this stack of fault tolerant techniques at once is that the obtained circuit can correctly behave also in the presence of transient faults. For the purpose of this report, we assume that the Nasic fabric architecture: • is not a reconfigurable architecture; • the circuit is realized with a set of heterogeneous (different dimensions) nanotiles; • uses AND-OR logic family based on two type (N and P doped) FETs for logic implementation; • uses the dynamic circuit style with latching on the wire; • no fault-tolerance techniques are used

1.4 Conclusion In this chapter we have presented some of the common characteristics shared by the nanoscale computing architectures proposed in the literature. We the presented the Nasic fabric pointing the reader to the specific research paper dealing with the specific details. The Nasic fabric architecture is used as a first target for NA B OO framework (presented in the following chapters).

9

2 Symbolic Circuit Layout with NA B OO Framework

”If you think good architecture is expensive, try bad architecture.” Brian Foote and Joseph Yoder

2.1 Introduction The problem of circuit layout framework is a difficult problem due to the large number of devices and to the physical constraints that should be met. With the apparition of the nanoscale architecture this problem will become even more complicated, due to the even higher device density, the presence of defects, and the unique characteristics of these tiny devices. A number of tools have already been developed to tackle this problem in the context of nanoscale architectures (see table 2.1). They are using algorithms already used for FPGA and PLA design automation problem, because of the regular structure of these novel fabrics. Table 2.1: CAD tools used for different fabrics Logic Tools

NanoPLA[10] Sis[32]

Partitioning PLAMAP[9]

Physical Tools

Placement

VPR[7]

Routing

NPR - custom tool (based on Pathfinder[21])

CMOL[20] Sis T-VPACK[7] Simulated Annealing (VPRlike) modified congestion function Custom tool (based on RSA heuristic)[31]

FPNI[34] Singh’s greedy algorithm (specific cost)[33] Simulated Annealing (VPRlike) maze router (Pathfinderlike) with several iterations

To determine the performance of a typical (CMOS) computing architecture there are many factors to be taken into account. The quality of the CAD tools used to map circuits on it, the quality of the architecture and the electrical design of the fabric are the main elements that combined determine the final performance of an architecture. In the context of nanofabrics an equally important factor is the fault tolerance policy employed to render the fabric usable even in the presence of defects. Two approaches are used by architecture designers to tackle this problem: (a) configuring around defects and (b) circuit level built-in redundancy. In order to investigate the quality of different nano architectures, one needs CAD tools capable of automatically implementing circuits on each fabric architecture of interest. Once a circuit has been implemented on the target architecture, accurate area, delay, and fault models are needed to evaluate the quality (speed, area, fault-tolerance) of the circuit. In the context of nanoscale computing architectures the ability of CAD tools for architectural prospection is very important since the field is relatively young the researchers need tools that will permit them to easily evaluate new architectures, to compare two different architectures in order to see which perform

10

better with a specific circuit. In order to do this, the CAD tools used must be flexible enough to target all architectures of interest. This precludes the use of specific tools for each architecture[7]. Chapter outline In this chapter we are presenting: in section 2.2 the Madeo framework is presented; in section 2.3, the general flow of the NanoMadeo framework is presented; in section 2.4 the a generic overview of the NaBoo framework is given;

2.2 Related Works: Madeo Framework Madeo[18] is an object-oriented CAD framework targeting application design automation in the context of FPGA architectures. It provides an integrated way of modeling and using real or prospective FPGA architecture via a decoupled software architecture. The architectural modeling is based on a object model capturing the important aspects of the FPGA domain (referred as abstract model in figure 2.1). For using this framework in a particular context this model is specialized in order to provide the specific characteristics of the targeted FPGA architecture. The tools, placement, routing, etc are common to all specialization of the model and they permit an unbiased evaluation of the hardware architecture. MADEO BET Textual description

Language

MADEO FET compile

prospect

Application code

Internal Model

Abstract Model

build

Data range

build

Graph of operators

Optimizations Concrete Model

Estimators

Application use

Circuit drawing Floorplanning

Place and Route

... Hardware Control

Figure 2.1: Madeo CAD flow In addition to the presented back-end (see figure 2.1, left) the Madeo framework has a original front-end (see figure 2.1, right) capable of synthesizing circuits specified in an object-oriented language1. In the context of the NanoMadeo proposition, an analysis of the Madeo framework identified a number of characteristics that may be replicated. In the NA B OO framework some of the functionalities of Madeo were integrated through a series of refactoring steps.

2.3 NanoMadeo: A Flow for Application Design Automation onto Hybrid Nano/CMOS Fabrics The NanoMadeo flow is a prototyping CAD flow that considers an explicit specification of the underlying nanofabric. It extends the classical design flow for designing an application from behavioral specifications 1

Smalltalk

11

(e.g., in VHDL, Verilog, or SystemC) onto physical designs. It is based on a range of transformations applied at different levels of description/abstraction of the application/problem that is mapped. The design flow proposed, in figure 2.2, incorporates a variety of models associated with the nanofabric to allow optimizations to occur on generic data structures. Through a computational model, an architectural model, a technological model, and a fault model key aspects of a particular fabric can be captured and abstracted. The proposed models interact with the behavioral tools and the physical tools to produce an abstract layout for the design - starting from a high-level description. Parts that are mapped to nanoscale are separated from parts that use conventional CMOS technology.

Figure 2.2: NanoMadeo flow Nanoscale fabrics under consideration, in NanoMadeo framework, have the following features: • The use self-assembly based manufacturing techniques, e.g., nano-patterning, fluidic alignment, DNA-based self-assembly, and di-block co-polymers, in conjunction with conventional lithography - this is driving their structure to be quasi-regular such as based on 2-D crossbars. • Nanoscale fabrics could be hybrid CMOS/Nano structures as opposed to just nanoscale. • Nanoscale fabrics are expected to have high defect rates, e.g., in the range of 10+%; thus, defect tolerance techniques need to be incorporated and taken into account in the design of any new CAD tool. In comparison, conventional CMOS designs in 90nm technology have only 0.4 defects per cm2 .

2.4

NA B OO Framework Overview

In the context of the NanoMadeo CAD flow, we designed and implemented NA B OO , a preliminary framework targeting the physical design part of the flow presented in figure 2.2. This framework aims at offering the architectural support, in terms of modeling and tools, for calculating circuit layouts on the different architectures targeted by the NanoMadeo flow. The NA B OO framework is, in part, based on concepts identified in the Madeo framework and reused in order to minimize the development effort. The physical synthesis part of Madeo framework consists of, mainly, three principal components: 1. an internal circuit representation; 2. an architectural model targeted at regular reconfigurable architectures; and 3. a large

12

set of tools with different functionalities (placement, routing, logic circuit simulation, circuit editor, architecture builders and viewers, etc).Our aim is to be able to identify and reuse different components of the Madeo framework that make sense in the context of nanoscale architectures. The purpose of this section is to give an overview of the NA B OO framework, and present its main features.

2.4.1 Metamodel-based Object-Oriented Framework Object-oriented design methodologies offer important opportunities for reducing application development and maintenance costs. The object oriented methodology recommends an analyze of the target domain in order to encapsulate it’s recurring characteristics. Object-oriented software is organized into classes and frameworks, that provide modularity and enhance re-usability. This can substantially reduce the cost of adding new functionality to a software product. Language features like inheritance also contribute to reuse and maintenance by allowing specialization of a class to be built without altering the original class. When all this features meet a metamodel-based approach to software development the results are highly modular, generic and evolutive software products that can be easily maintained. A metamodel-based process enables the designers to have a formal way to define domain models and tools. It also rise the level of abstraction in software development, from a code centric approach to a concept centric approach. The framework presented in this chapter uses a metamodel-based object-oriented methodology in order to tackle the problem of automatic circuit layout. The flow is based on two models, a circuit model and an architectural model. The physical synthesis tools operate on these two models in order to calculate the circuit layout on a target architecture. In figure 2.3, one can identify these two models (circuit model, the green box at left and architectural model the green box at right), and the stack of physical synthesis tools/algorithms (underneath the two models). Yal

Fabric Specifications Architectural Model

EDIF

Blif

Structured Circuit Model

Legend Input format Tool

Fabric Builder

...

...

Partitioning

Transformation Engine

Model instance

Floorplanning

Use model

Placement Fabric Viewer

Architectural Instance

Model

Structured Circuit Instance

Routing

Circuit Simulator

Tranformed by Flow

Figure 2.3: NA B OO Framework Flow

2.4.2 Prospection Possibilities The NA B OO framework flow proposes an orthogonal composition of the key aspects of circuit layout problem thus permitting to explore a complex solution space circuit/algorithms/architectures/metrics. This gives the ability to have three main prospection possibilities. Architectural Prospection This case corresponds to the situation when an user has to implement a circuit and he wants to make an objective architectural choice. The choice will be made by evaluating the physical synthesis results on different architectures using a specific metric. Algorithm Prospection This case corresponds to a layout algorithm designer wanting to measure the capabilities of a specific algorithm (ex. Pathfinder) in the context of a specific architecture. The evaluation will be made by varying the input circuits and measuring the output results according to a predefined metric. Circuit Prospection This is somehow the trivial case when the circuit designer tries to evaluate which algorithm performs best for an application, in the case of an specific architecture.

13

2.4.3

NA B OO Framework Input Formats

The NA B OO framework input points can vary according to the developer interest. If the integration of a new architecture in the flow is wanted a fabric specification language (similar to the one used in Madeo [18]) will be used. If the symbolic circuit layout computation on a specific architecture is wanted then the circuit description using blif[28] or edif format can be given. Other circuit description formats can be easily integrated by simply mapping their model to the internal circuit model (described in subsection 4.2). One specific example is the Yal format used in the MCNC benchmark suite which was integrated in the flow in order to benchmark the implemented floorplan algorithm (more details in chapter 5).

2.4.4 Logical Level At the right part of figure 2.3 we have the logical level of the framework. At this level we can identify the Structured Circuit Model which is the model used to build a logical representation of the circuit to be mapped. This internal model is very important because at this level functional circuit verifications can be performed, using a circuit simulator. Another important aspect of this model is the fact that it was not developed from scratch but it is the result of the re-engineering of the same model found in Madeo framework[18]. This permits us to reuse tools already developed in this framework.

a)

b) Figure 2.4: a) Logic Circuit Simulator[18]; b) Schematic Editor[18]

In figure 2.4(a) one can see a screen-shot of the circuit simulator, built in the Madeo framework and reused in this flow. Another example of reused tool is the Circuit Editor (figure 2.4(b)), which permits to visually build a complex circuit using a library of gates, and circuit parts already developed. The Structured Circuit Model is discussed in details in chapter 4.

2.4.5 Physical Level At the physical level of the flow the most important part is the Architectural Model which permits the description of the physical components (FET, wire, etc.), the description of the basic architectural primitives (NanoArray) and their hierarchical composition. In order to allow a realistic representation of a target architecture a number of physical characteristics are integrated in this model. To integrate support for new fabric architectures in the Architectural Model, the first step is to identify the principal architectural primitives of the fabric. The model evolves integrating the new identified primitives. The composition mechanism it is used afterwards to build valid instances of the model, that correspond to virtual representation of the targeted fabric. An architecture instance can be created by feeding the grammatical description of the fabric to a fabric builder (compiler) that will instantiate the architectural model in the way specified by the specifications, thus creating a valid instance of the architectural model. Another way of creating a fabric representation using this model can be by using a visual fabric editor with an WYSIWYG2 interface, but this method may become difficult due to the huge integration densities these fabrics can achieve. Another way could be to 2 WYSIWYG

- What You See Is What You Get

14

use an interactive interface to describe the basic architectural primitives, and a grammatical language to specify their hierarchical composition.

2.4.6 Physical Tools and Algorithms The tools used to calculate the physical circuit layout are organized in a stack (figure 2.3, middle). These tools interact with the circuit and architectural instances in order to extract specific information from them (ex. the connectivity of the logical operators from the circuit instance, the physical characteristics like nanowire pitch from the architectural instance). The algorithms used by these tools are basically generic algorithms (like Pathfinder[21]) adapted to work on the two models, but they are not restricted to these. Specific algorithms can easily be integrated according to the specific needs a nanoscale computing architecture may have.

2.5 Conclusion In this chapter we have presented an overview of the NA B OO architecture in the context of NanoMadeo framework. NA B OO can be defined as a generic CAD tool targeting automatic circuit layout computation on nanoscale architectures. The role of NA B OO is to provide early tools allowing the evaluation of new technologies from applicative point of view. We have also seen how an orthogonal composition of circuit synthesis main aspects can help the designer understand better the problem it is working on.

15

3 A Methodology for Creating Robust and Durable Frameworks

You should use iterative development only on projects that you want to succeed. Martin Fowler Object-oriented frameworks promise higher productivity and shorter time-to-market of application development through design and code reuse (than possible with non-framework based approaches). Object orientation comprises object-oriented analysis, object-oriented design, and object-oriented programming. Using a small set of concepts (objects, classes, and their relationships), developers can model an application domain (analysis), define a software architecture to represent that model on a computer (design), and implement the architecture to let a computer execute the model. None of these activities (analysis, design, and implementation), nor the resulting models, are trivial. To carry them out effectively, developers have invented additional concepts that represent the conceptual entities they are dealing with. One such key concept is the object-oriented framework. An object-oriented framework is a reusable design together with an implementation[15]. The design represents a model of an application domain or a pertinent aspect thereof, and the implementation defines how this model can be executed, at least partially. A good framework design and implementation is the result of a deep understanding of the application domain, usually gained by developing several applications for that domain. The framework represents the cumulated experience of how the software architecture and its implementation for most applications in the domain should look like. It leaves enough room for customization to solve a particular problem in the application domain. Developers who apply a framework reuse its design and implementation. They do so to solve an application problem that falls into the domain modeled by the framework. By reusing the design, application developers customize a (hopefully) well-understood software architecture to their own specific application problem. This helps them get the key aspects of the architecture right from the beginning. By reusing the implementation, application developers get up to speed more quickly. Through design and code reuse, frameworks help developers achieve higher productivity and shorter time-to-market in application development. Chapter outline In this chapter we will present the methodology used to create the NA B OO framework. This methodology combines the extensive use of design patterns[12] (section 3.1) with a standardized metamodeling approach to domain modeling (section 3.4). The NA B OO framework creation is a iterative process, using refactoring techniques to reuse components already implemented in the Madeo framework and to perform framework evolutions (section 3.5).

3.1 Extensive use of Software Design Patterns For most design problems there are effective solutions. Often it takes looking at the problem differently, and doing things in ways they have never been done before. Design patterns provide an alternative perspective 16

to problem solving that transfers a great deal of previous design expertise in a form that is easily transferable to solutions. The composite design pattern and the visitor design pattern are briefly described in subsection 3.1.1 and 3.1.2, respectively. These patterns are 2 of the 23 design patterns described in [12]. The reason of including a detailed description of these two patterns is that they are used throughout the NA B OO framework. The composite design pattern is used for the model structuration (in both the architectural and circuit models), and the visitor pattern is used as a generic way of interpreting and adding particular operations two the models.

3.1.1 Composite Design Pattern When dealing with tree-structured data, programmers often have to discriminate between a leaf-node and a branch. This makes code more complex, and therefore, error prone. The solution is an interface that allows treating complex and primitive objects uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a ”has-a” relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would a group of them. The operations you can perform on all the composite objects often have a least common denominator relationship. For example, if defining a system to portray grouped shapes on a screen, it would be useful to define resizing a group of shapes to have the same effect (in some sense) as resizing a single shape. In figure 3.1 a class diagram of the pattern is shown.

Figure 3.1: Composite Design Pattern

3.1.2 Visitor Design Pattern In object-oriented programming and software engineering, the visitor design pattern is a way of separating an algorithm from an object structure. A practical result of this separation is the ability to add new operations to existing object structures without modifying those structures. In essence, the visitor allows one to add new virtual functions to a family of classes without modifying the classes themselves; instead, one creates a visitor class that implements all of the appropriate specializations of the virtual function. The visitor takes the instance reference as input, and implements the goal through double dispatch.

3.2 Tool Development around Stable Models As it can be seen in Figure 2.3, the development of circuit layout tools in NA B OO framework is based on two different models: (1) A high level model able to capture and manipulate the functional description of the circuit to be mapped, and (2) A low level model that describes the target architecture. In order to be 17

able to build an easy maintainable, evolutive framework we need to be sure that these two models are stable and well defined. A stable model is a model that can accommodate changes without changing its semantics and/or its API interface. One step towards having a stable model is the use of a standardized method for the model design and implementation. In the following sections we will present such a method, namely the ISO 10303 standard.

3.3 Evolutive and Portable Models and APIs The development of tools based on data exchange requires the definition of a common format and a standard exchange protocol implemented by a normalized encode/decode mechanism of the exchanged data. The encoding produce the exchangeable representation of the data from the objects stored in a database, the decoding realize the opposite operation. The use of an independent format and the possibility to have an encoder and a decoder ensures the portability of the exchange system. The evolutivity of the system is ensured by the automatic generation of the encoder/decoder from a formal specification of the structure and semantic of the exchanged data. In the NA B OO framework the STEP[1] technology is used for the specification of the models and for the data exchange implementation. The system robustness comes from: (1) the formal definition of the models using the EXPRESS language[2], (2) the use of the STEP independent exchange format[3, 5] and (3) the automatic production of API interfaces and encoders and decoders for all the tools working on these models. In the following section we will present the Platypus Integration Framework[29], a meta-case tool for modelling and meta-modelling based on the STEP standard. In the context of this work this tool is used to automatically generate the models from an Express[2] specification. In the sections 4.2 and 4.3 of chapter 4we will detail the Structured Circuit Model and the Architectural model respectively. Both these models where developed using the Platypus Framework.

3.4 Platypus Integration Framework Platypus is a meta-case tool which embeds within Squeak[35] system a modelling and metamodeling environment based on the STEP standard. The models and metamodels are specified using the EXPRESS language.

3.4.1 STEP standard The STEP1 standard is the ISO 10303 standard developed by ISO TC 184/SC4 sub-committee. The standard’s objective is to provide a mechanism that is capable of describing product data throughout the life cycle of a product, independent from any particular system. The nature of this description makes it suitable not only for neutral file exchange, but also as a basis for implementing and sharing product databases and archiving.

3.4.2 Express Language EXPRESS [2] is a data oriented modeling language. The data are specified within a schema. A schema models a part of a domain with the structure of the used concepts, their relations and constraints. The schema embeds the definition of types, entities and constraints. One schema can reuse the contents of another schema. One entity can inherit one or many other entities. One entity contains a set of attributes and local constraints. The attributes can be explicit, derived (it’s value is computed using an expressing), or inverse (it’s value its computed and shows the inverse cardinality of an association between two entities). Listing 3.1 show a part of a Graph Model specification using the EXPRESS language. This model is used in NA B OO framework for the implementation of the TCG-S floorplanning algorithm[19]. This part of the graph model contains tree entities GraphNode, GraphNet and Graph. A GraphNode contains tree explicit attributes: content, nodeValue and size. Content and nodeValue both have the GENERIC 1 STandard

for the Exchange of Product model data

18

Listing 3.1: EXPRESS definition of a Graph Model. ENTITY GraphNode SUBTYPE OF ( A b s t r a c t G r a p h E l e m e n t ) ; c o n t e n t : GENERIC ; n o d e V a l u e : GENERIC ; s i z e : INTEGER ; END ENTITY ; ENTITY Gr ap h Net SUBTYPE OF ( A b s t r a c t G r a p h E l e m e n t ) ; s o u r c e : GraphNode ; d e s t i n a t i o n s : LIST OF GraphNode ; DERIVE i s H y p e r E d g e : BOOLEAN : = SIZEOF ( d e s t i n a t i o n s ) > 1 ; r e v e r s e : LIST OF Gr ap h Net : = r e v e r s e E d g e ( SELF ) ; END ENTITY ; ENTITY Graph SUBTYPE OF ( A b s t r a c t G r a p h E l e m e n t ) ; n o d e s : LIST OF GraphNode ; n e t s : LIST OF Gr ap h Net ; DERIVE s i n k s : LIST OF GraphNode : = g r a p h S i n k s ( SELF ) ; s o u r c e s : LIST OF GraphNode : = g r a p h S o u r c e s ( SELF ) ; END ENTITY ;

type, size’s type is Integer. A GraphNet contains two explicit attributes: source of type GraphNode and destinations of type LIST of GraphNode. It also contains two derived attributes: isHyperEdge and reverse. The Graph entity has 2 explicit attributes (nodes and nets) and two derived attributes (sinks and sources).

3.4.3 STEP Standard Integration The implementation of an Express schema is actually its integration in a data exchange context, see left part of figure 3.2. This context implements an standard data exchange format. The encoder and decoder components for an common model are automatically generated from the EXPRESS schema which describe the exchanged data. The standard data access interface (SDAI)[4] implements the actual data exchange protocol. This interface is, actually, an software interface (API) in a specific programming language. This API is used to build the encoders and decoders, but it is also used to check the data integrity (according to their model). Express Model

Encoder

STEP DB

Model Specification

Framework Tool

Decoder

Encoder Decoder

Model Instances

Code generation Data flow

Figure 3.2: STEP Standard Encoder and Decoder At the right side of figure 3.2 we can see the actual integration of the STEP methodology with the

19

framework tools. Each tool (using a model defined using the STEP methodology) has an encoder and a decoder automatically produced from the EXPRESS model specifications. Thus, each tool has the capacity to read and write instances of the model in a STEP repository. The use of such a repository permits the data exchange and inter-operability between the framework tools (they can be implemented using different programming languages, they can work on different platforms, etc.). In the current version of the Platypus[29] integration framework the supported target languages are: 1. Java, 2. C++, 3. Smalltalk.

3.5 Software Reuse and Refactoring In software engineering, ”refactoring” a source code module often means modifying without changing its external behavior, and is sometimes informally referred to as ”cleaning it up”. In extreme programming and other agile methodologies, refactoring is an integral part of the software development cycle: developers alternate between adding new tests and functionality and refactoring the code to improve its internal consistency and clarity. Automatic unit testing ensures that refactoring does not make the code stop working. Refactoring neither fixes bugs nor adds new functionality. Rather it improves the understandability of the code or changes its internal structure and design, and removes dead code, to make it easier for human maintenance in the future. In particular, adding new behavior to a program might be difficult with the program’s given structure, so a developer might re-factor it first to make it easier, and then add the new behavior. Code refactoring alone does not change or add functionality to a system, but it can simplify future additions, application of design patterns, and reuse through polymorphism, which otherwise could be impractical, expensive, or unmaintainable. An example of a trivial refactoring is to change a variable name into something more meaningful. A more complex refactoring is to turn the code within an if block into a subroutine. An even more complex refactoring is to replace an if conditional with polymorphism. While ”cleaning up” code has happened for decades, the key insight in refactoring is to intentionally ”clean up” code separately from adding new functionality, using a known catalogue of common useful refactoring methods, and then separately testing the code (knowing that any behavioral changes indicate a bug). The new aspect is explicitly wanting to improve an existing design without altering its intent or behavior. In the following two subsection we are presenting two similar refactoring methods that merge two isomorphic models into one in such a way that the existing tools working on the two models can still be used unchanged. The first method was used in the context of the work presented in this report to re-factor the circuit model in Madeo framework and to integrate it in the NA B OO framework.

3.5.1 CopyDown Method Refactoring Process The idea is to have a way of merging two isomorphic models into one in such a way to factorize the available functionality of the two models. One way to do that is to use the transformation chain presented in the figure 3.3(a). The smalltalk implementation of this refactoring method can be found in Appendix A.1. We start by inlining the calls to super methods in order to obtain inheritance hierarchy independent methods that can be safely copied to all subclasses of a specific node. After the inlining step we proceed to the CopyDown step where all superclass methods will be copied recursively to all subclasses. The next step is to remove the instance variables from the old model. This step is required because the new isomorphic model already contains these instance variables in the future superclasses of the old model. This step being done we can proceed to destroy the old class hierarchy, build around the inheritance mechanism, and to assign the new designed superclass to the old model classes. Because the two models have some classes with identical names we prevent the name clash by isolating the classes in different namespaces. In the figure 3.3(b) we can see the result of this refactoring method applied on an example. The different colors in class representation represents the different namespaces that isolate the classes with identical name. In the rightmost diagram we can see the method duplication through the classes of the old hierarchy in order to preserve their inherited functionality.

20

ClassA attr1 attr2

AbstractC

AbstractC

attrX m1

attrX m1

ClassA attr1 attr2

ClassA attr1 attr2

meth1

ClassC attr3 meth3 meth4

ClassB meth2

Old Model

Super calls inlining

ClassB

ClassX

ClassB

Result of the copy down refactoring process

ClassX

Equivalence

Copying−down superclass methods

ClassA meth1

ClassD attr4 meth5 ClassC attr3

Old Model

ClassB

ClassC attr3

meth2 meth1 ClassC ClassD attr4

Remove instance variables from the old model

ClassD attr4

New Model Isomorph with the old model

meth1 meth3 meth4

ClassD

New Isomorph Model

a)

Cut the superclass link Add the new isomorph class as the superclass of all old classes

meth1 meth3 meth4 meth5

b)

Figure 3.3: a) Isomorph model refactoring steps; b) Example model transformation using CopyDown method This refactoring method is a good solution to the model refactoring problem we encountered in the development of NA B OO framework (see section 4.2.3) since the old functionality is maintained, the old programs developed around the old model continue working without any modification, and the new model can be used freely without any execution delay. Another advantage of this method is that basically it does not change the execution mechanism of the object oriented language, and so it can be used almost unmodified with all object oriented languages. Still this method has its drawbacks principally because the classes of the old model contain duplicated behavior. The presence of the same method in more than one class: • is not recommended by the object oriented methodology; • decrease the maintainability of the system (one modification to a duplicated method has to be replicated in all similar methods); • render the classes less comprehensible due to the eventually huge number of methods that are copied in the class, during the CopyDown step, from its superclass (recursively). A solution can be the introduction of another refactoring step that will push up in the new hierarchy the equivalent methods. But, despite its inconvenients, this method can still be used taking some necessary precautions: • If the tools using the old model are mature enough so they can be used in their actual state without modifications; • If the developers intention is to replace the old model with the new one in all the tools using it. In this case the CopyDown method can be used as an intermediate evolution step, where some tools are ported to the new model and others are still using the old one;

3.5.2 Does not understand message interception Another method of refactoring two isomorphic models into one directly perform the last two steps of the previous technique (remove the instance variables; Cut the superclass link. Add the new isomorph classes as the superclass of all old classes) without copying-down the superclass methods. The old hierarchy must be stored (in a Dictionary for example) in order to be able to replicate the old hierarchy method inheritance. To be able to use the behavior declared in the old model classes, we can develop a mechanism

21

that intercepts the error message when a message is send to a class but its implementation was in the class’ old superclass. Once the error message intercepted we can start searching in the old inheritance hierarchy (that was previously saved) to find the implementation class of that message. If we find it we send the message to that class and return the result to the sending class. If the message was not found we simply throw the ”does not understand” error. This method solves the previous problems related to the message duplication throughout the old hierarchy. But it comes with new problems like: • The execution mechanism of the object oriented framework must be modified. While this is possible in an open framework like smalltalk in most object oriented framework will be difficult to implement this method. • Since all missing methods need to be searched in the old inheritance hierarchy this will add some overhead to the overall execution of code using this model. • If the new model classes implement one of the methods implemented in a class of the old hierarchy, say class X, all subclasses of the class X will execute the new implementation of the method instead of executing the implementation in class X. Thus rendering the tools using the old model unusable. That happens because the ”does not understand” error will not be triggered once a method with an identical signature is found in the new inheritance hierarchy.

3.6 Conclusion Frameworks are a practical way to express reusable designs. The software design patterns are powerful means of reusing successful solutions in the context of object-oriented design. The integration between the tools and the domain models they work on is another important aspect. In consequence we presented a metamodeling methodology for domain modeling and tool-model integration via a portable set of API and a common repository accessed through automatically generated encoders and decoders. The final point discussed in this chapter was code refactoring as a mean of reuse. We presented 2 similar refactoring methods capable of integrating 2 similar models into one model. This refactoring method permits the developers to perform model evolution without loosing the tools working on the old model. The combination of these three important aspects (1. design patterns, 2. standardized metamodeling approach to model creation and integration, and 3. refactoring for reuse.) are used throughout the NA B OO framework in order to create a robust, durable framework with the smallest development efforts.

22

4 Domain Models and Their Integration in NA B OO Framework

”It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures.” Alan J. Perlis

4.1 Introduction A model is a description of something. Usually a single model, like a diagram, represents the selected view of a system, a program, or a feature. To specify the complete system, we need several models and modeling concepts that specify different aspects of the system. In consequence for implementing a CAD framework as described in chapter 2 we need more different models: 1. a computational model; 2. a programming model; 3. a circuit model; 4. an architectural model. While some of these models (the first two), are imposed by the underlying execution platform and by the chooses programming paradigm (language), there are some models specific to the domain targeted by the modeled application. In our case these models are the Structured Circuit Model and the Architectural Model. These models need to be explicitly described by the designer of the framework. In the section 3.4 we presented a formal way to model design and generation using the EXPRESS language in the context of STEP standard. This approach assure a powerful modeling environment with semantic analysis and automatic code generation. Chapter outline In the last chapters we have seen an overview of the NA B OO framework (chapter 2) and the methodology used to build such a framework (chapter 3). The purpose of this chapter is to detail the heart of this framework, namely the models used to capture the logic and the physical characteristics of the circuit and architectures modeled using this framework.

4.2 Structured Circuit Model The Structured Circuit Model is an intermediate model that offers the support for: (1) representing the logical structure of a circuit, or (2) decomposing the problem (circuit) in subparts according to a specific logic. This representation serve as an stable intermediate support for the high level tools (logic synthesis), the simulation tools and the physical layout tools. Figure 4.1(a) shows the central place occupied by this model in report with the tools using it. This model is based on a similar model present in Madeo framework[18]. We designed this model isomorph to the on in Madeo in order to assure the portability of a number of tools and specific functions already implemented in Madeo framework (the circuit simulator, and the graphical circuit editor are some examples). More details about the integration of this model with the one in Madeo framework are given in subsection 3.5.

23

Pin

Logic Entry Level

EDIF

Blif

Logic

Logic Visualization Structured Circuit Instances

Verification/ Simulation

Import/Export

Port

Data flow

a)

Transformation Level

Physical Tools

Use case

b)

Net SCCompositeNode

Embedded Port

SCSimpleLogic

Figure 4.1: a) Structured Circuit Model tools and data-flow; b) Example: Structured Circuit Model instance (use of main model elements, and their composition)

4.2.1 Model entities The model contains 4 different entity types: • The SCNet and SCNetList classes, offering the means of connecting circuit elements. • The SCNode classes, permitting to represent primitive and composite circuit elements. • The SCAbstractPin classes representing components connection points. • The SCPort classes encapsulating the connection points and offering a structural organization of them.

4.2.2 Model Structure

Increasing composition level

The model is structured using a composition of the Composite Design Pattern[12] (see Chapter 3, section 3.1). This way the objects are classified according to their composition complexity creating a good structure of the concepts. Using this approach we have the SCAbstractPin (and its subclasses) as first level primitive, because they are the simplest elements. The SCPort and SCNet entities are second level primitives because they are composed of first level primitives (pins). SCNetList entity is a third level primitives as it assembles SCNets. And finally SCPrimitiveNode is a fourth level primitive. Object

L1Composite

L2Composite

L1Primitive

L2Primitive

LnComoosite

Ln+1Composite

Ln+1Primitive

Figure 4.2: Recursive composition of the Composite Design Pattern The main nodes of the hierarchy are SCNode and its subclasses (cf. Appendix A.2, figure A.1). The objects represented by these nodes can be primitives, composites or aliases. The primitive object can encapsulate or describe behavioral code (SCBlockNode)1, logic functions (SCSimpleLogic), blif and edif descriptions of circuit parts, memory elements, etc. The composite objects (SCCompositeNode) corresponds to a collection of circuit objects, primitives or composites, related or not by geometrical relations. 1 Smalltalk-80

blocks

24

These nodes are used to create hierarchical circuit representations used by the physical layout tools. The aliases (SCAliasNode) serves as a reutilization mechanism as it enables the reuse of a primitive or composite nodes without having to copy them. Each SCNode has communication ports with indexed elements. These ports will assure the connectivity of the model elements. In figure 4.1(b) we can see how the elements of the model can be composed together to represent a simple circuit. Another feature of the model that is worth mentioning is that all the model entities can encapsulate a list of objects containing additional informations specific to a tool. An example is the FloorplanInfo object that contains informations stored in by the floorplanning tool. These informations can be used, at will, by subsequent tools. Another example are NanoInfo and CMOSInfo object that add information regarding the preferred implementation medium of the circuit part they are bundled in. This way the low level tools identify the parts of the circuit that can be implemented using nanoscale devices and differentiate them from the parts that should be implemented using CMOS components. Other information entities can be added to the system as subclasses of the AIMObject. In this way a coherent information model can be developed orthogonally to the Structured Circuit Model. The construction of a coherent instance of the model can be done using an Abstract Factory design pattern which provides a way to encapsulate a group of individual factories. In normal usage, the client software would create a concrete implementation of the abstract factory and then use the generic interfaces to create the concrete objects that are part of the theme. The client does not know (or care) about which concrete objects it gets from each of these internal factories since it uses only the generic interfaces of their products. This pattern separates the details of implementation of a set of objects from its general usage. In order to work using this model the visitor pattern is employed. This way we have the possibility of interpreting one instance of the model differently according to the needs of a specific tool. For instance we can create a visitor that will produce a visual representation of the model instance, another visitor for simulating the circuit comportment, and yet another visitor capable of partitioning the circuit according to some specific logic.

4.2.3 Madeo SCNode Refactoring After the analysis of the Madeo framework we identified an object hierarchy similar (see Appendix A.2, figure A.2) to the one described in the last sections. Its usage is similar to the one we proposed, but its implementation is ad-hoc, without following the strong formal conception process proposed by the STEP standard and implemented in the Platypus framework. Nonetheless this model offers the basic data exchange mechanism in the Madeo framework. Around it an extensive set of tools have been built (Circuit simulator, circuit editor, etc...). In order to have access to these utilities we developed a refactoring process (see Chapter 3, section 3.5) that will produce an evolution of this model without affecting the available functionality. We started by designing the new model to be isomorphic with the one we want to reuse. In this way we have built the model presented in figure A.1 (Appendix A.2). Afterwards we devised a refactoring process (cf. Chapter 3) that will be able to perform the desired model evolution without affecting the old functionalities of it.

4.3 Architectural Model In the NA B OO framework the nano/CMOS architectures are described using an Architectural Model that permits the description of the physical components (FET, wire, etc.), the description of the basic architectural primitives (NanoArray) and their hierarchical composition. A number of physical properties and constraints are integrated in this model in order to allow a realistic description of the target architecture. This model is used differently according to different properties of the fabric. For example, for reconfigurable fabrics and instance of the model is created and the physical tools map the designed circuits on it. On the other hand, for non-reconfigurable architectures (like NASIC for instance) the architectural model is directly instantiated by the physical tools according to the implemented circuit characteristics. To integrate support for new fabric architectures in the architectural model, the first step is to identify the principal architectural primitives of the fabric. Then the model evolves integrating the new identified

25

primitives. The composition mechanism is used afterwards to create valid instances of the model, that correspond to virtual representation of the targeted fabrics. A number of redundancy based fault tolerance techniques (TMR2 for instance) can be applied at the composition level in order to render the fabric model instance fault tolerant.

4.3.1 A Simple Model Targeting Nasic Fabric Architecture In the Appendix A.2(figure A.3) we can see a simple model capable of representing the Nasic fabric architecture[38](see chapter 1 for details on Nasic fabric). The model is structured around a composite design pattern (see section 3.1.1). The primitive objects representing the physical components of the architecture: MicroWire, NanoWire, FET (NFET, PFET), etc. The composites represents architectural primitive like the NanoTile represented by the NasicNanoTile entity. Even though this model is very simple it is capable of capturing the physical organization of the Nasic architecture with enough details to permit detailed circuit placement, and routing. These model is used actively in the NA B OO framework prototype.

4.3.2 The Specialization of the Model for Targeting other Nanoscale Fabrics The model presented in the last section (section 4.3.1) can be extended to model other fabrics, like NanoPLA[10] for example. In the case of nanoPLA fabric one important architectural primitive is the Stochastic Decoder (used for interfacing nanoscale wires with their CMOS counterparts). In the model it will represent a new composite entity. It can be represented as a wire crossbar with one set of wires being instances of NanoWire entity and the orthogonal set instances of MicroWire entity.

4.3.3 Further Extensions of the Architectural Model But even though the model presented in the last section can be seen as being expressive enough for 2D architectures, that won’t be true in the case of 3D architectures (like CMOL[20]). In order to be capable of having a robust expressive model we believe that we should have an orthogonal composition between the geometrical characteristics of the architecture and the architectural primitives. Currently we are studying this aspect, and we believe that we can create a model capable not only of capturing architectural details of nanoscale architectures but also capable of modeling CMOS FPGA architectures. In this case the geometrical characteristics will be seen as a set of transformations applied to the architectural components according to some generic rules imposed by the architectural designer. One way of implementing this concept is by using a Wrapper hierarchy. The Wrapper hierarchy will contain entities like: • PositionWrapper - a generic wrapper used to specify the actual position of an architectural primitive in a specific architectural instance; • RotateWrapper - capable of rotating an architectural primitive with an specified angle (feature needed for modeling CMOL architecture); • LayerWrapper - able to encapsulate the architecture layers in order to permit 3D architecture modeling; • etc... Once having such a model, a generic set of tools can be build around it providing a durable, stable back-end for circuit synthesis on a large number of different architectures.

4.4 Conclusion In this chapter we have presented the models used in NA B OO framework: 1. the circuit model capable of capturing the logical structure of a circuit; 2. the architectural model, expressive enough to model the Nasic 2 TMR

= Triple Modular Redundancy

26

architecture.. We have, also, discussed how to improve the architectural model to enlarge its application domain to 3D nanofabrics, CMOS FPGAs, and even systems-on-chip. In the next chapter we will present a preliminary version of the NA B OO framework capable of placing circuits on the Nasic fabric architecture.

27

5 On the way to a Generic, Evolutive CAD Framework

”You can know the name of a bird in all the languages of the world, but when you’re finished, you’ll know absolutely nothing whatever about the bird... So let’s look at the bird and see what it’s doing – that’s what counts. I learned very early the difference between knowing the name of something and knowing something.” Richard Feynman

5.1 Introduction This chapter presents the first development efforts towards the NA B OO framework presented in chapter 2. This first prototype of the NA B OO framework was developed in the Smalltalk-80 object oriented language. The flow presented in this chapter can be used to map circuit, described in an object oriented language, to the Nasic fabric architecture. This is a first step towards having a generic software framework capable of application design automation on the emerging nanoscale technologies. ABC

Blif

Structured Circuit Model

Use hMetis Use

Structured Circuit Model instance generation

Legend Model

Pla generation for each blif reference command

TCG−S floorplanner

Partitioning

Use

Model Instance Structured Circuit Instance NaBoo tool

Floorplanning

Structured Circuit Instance transformed for Nasic

Architectural Model

Not implemented External Tool

Placement Circuit Viewer

Nasic Viewer

FloorplanViewer

External Format PathFinder

Use

Routing

Nasic instance

Figure 5.1: Detailed flow of the first NA B OO framework prototype In the figure 5.1 we can see the generic flow adopted for the first framework prototype. The entry point of the framework is a Blif file, generated by the logic synthesis tools. This Blif file is translated to a structured circuit model instance which then supports transformations in order to render it mappable on the Nasic architecture (a PLA like architecture). Thus, the logic nodes of the circuit are transformed into PLAs, using the ABC tool[23]. Once the transformation done the circuit is floorplanned and then placed on a Nasic model instance, build specifically for this circuit instance. For the time being the partitioning

28

and routing step are not implemented. A number of additional tools where developed in order to visualize the results of the different steps of the flow: • A circuit viewer, implemented using the Mondrian framework[22], used to build a visual representation of the input circuit (see figure 5.3). • A floorplan viewer used to visualize the floorplanning results(see figure 5.5). • An architecture viewer used to show the circuit placement results on the Nasic fabric architecture (see figure 5.6). It is worth mentioning that the presented flow was designed as an open framework, thus all the specific algorithms are implemented orthogonally to the flow in this way permitting the algorithm designers to easily integrate new algorithms in the framework. Another interesting point is that the floorplanning step (as well as the others: partitioning, placement, routing) is not mandatory this enabling the users to use other floorplaning tools, or to simply place predefined circuit structures -like loop constructs (external tools can be used to perform any other step too, at the expense of having to change circuit description to the format used by the tool - with the possibility of semantic lost). The technological specific constraints can be modeled by custom cost functions, or actual constrains (see section 5.4) in the different steps (algorithms) of the flow. For instance the constraints on routing are particularly important in the case of configurable fabrics where the connections are limited to certain routes. An cost evaluation of these routes can be done and the results integrated in the routing algorithm. The defects presents on a particular chip impose special placement and routing conditions. In such a case, the floorplanning algorithms should be able to adapt preplaced modules (the defect will be represented by these modules), the placement tool should be able to place the circuit components around these faulty zones and the routing tools must be able to route around the defects. The faulty regions may be represented by occupied regions of the chip, and them this problem becomes similar to the place-and-route problem in the context of partially reconfigurable architectures. In the preliminary NA B OO version, presented in this report, the floorplanning algorithm supports preplaced module, and, thus it can generate valid floorplans in the case when a default map is known. In this chapter, parallel to the presentation of the tools we will show a simple example. The idea is to calculate the physical layout of a custom adder circuit on the Nasic fabric. The a high-level schematic view of the circuit can be seen in figure 5.2. The inputs are m1,m2 (4 bits),v1,v2,vt1,vt2 (the last four parameters have one bit values). The circuit should calculate the sum of m1 and m2 according to the formula: (m1 ∗ |v1 − vt1|) + (m2 ∗ |v2 − vt2|). The result should be the first 6 bits of the result.

m1 m2

v1 v2

vt1 vt2

4 4 Custom Adder 6 r Figure 5.2: Custom Adder Circuit

Chapter outline The organization of the chapter follows the classical steps in the circuit synthesis flow: 1. logic synthesis, section 5.2; 2. partitioning, section 5.3; 3. floorplanning, section 5.4; 4. placement, section 5.5; 5. routing, section 5.6.

29

a)

b)

Figure 5.3: The structured circuit instance for the Custom Adder circuit a) The initial Blif based instance; b) The same circuit after the operator transformation to PLA

5.2 Logic Synthesis The first step of a application design automation CAD flow is to convert the user circuit description into a format that can be executed on the target technology. This, namely logic synthesis, is in charge of translating the high level description of the circuit into a netlist of logic gates and interconnections. For the purpose of this work the logic synthesis step is done with external tools capable of generating logic level hierarchical circuit representations according to the Blif format. For generating the Blif used in the given example we used Madeo framework’s front-end[18].

5.2.1 Pla Generation Since the Nasic fabric is a PLA based architecture and the Blif logic gates are LUT oriented specification. An extra step needs to be performed in order to render the Blif description of the circuit to be mapped in the PLA format. The blif description of the circuit is used to create a Structured Circuit instance (see figure 5.3, left). This instance is basically a SCCompositeNode containing instances of SCBlifNode as primitive elements. A special tool was developed in order to transform this instance to an circuit instance containing a SCCompositeNode with SCSimpleLogic (embedding the PLA description of the operators) as primitive elements. This tool uses the ABC[23] tool to flatten the possibly hierarchical Blif description of the operators and to transform it to a similar PLA description (see the result in figure 5.3, right).

5.3 Partitioning Traditionally, partitioning is used to split the technologically mapped netlist into small clusters such that the signal crossing cluster boundaries are minimized, for example. The idea being to obtain small enough cluster that can fit into one module of the target fabric. In the context of nanoarchitectures, and Nasic more precisely, the partitioning step can be used to determine the size of the nanotiles, the number of PLAs per nanotile such that the area of the chip is minimized and the tightly coupled PLAs are clusterised into the same nanotile, thus improving the fabric usage and reducing the communication delays. Currently the partitioning step is not implemented in NA B OO framework. The circuits used for floorplanning and placement are partitioned according to the operator structuration (data-flow graph) by the synthesis tool. But, in the near future, we intent to recondition and reuse for this task the hMetis algorithm[16] already implemented in Madeo[18].

30

5.4 Floorplanning Floorplanning has, traditionally, been important in classical CMOS architectures because it determines the top-level spatial structure of a chip. In the context of nanoscale architectures the floorplanning step can be used to plan the relative positions of the circuit modules in the presence of some high level constraints in order to optimize the circuit performance and to prepare it for the more complicated placement step. A number of different data structures are used to represent the spatial configurations of circuit modules, a presentation of some of them can be found in [8]. The differences between them are basically the quality of the floorplan (tighter packing is wanted) and the worst case complexity of the algorithms for different tasks. These are important metrics in evaluating the floorplan representation since typically they are used in local search algorithms (especially simulated annealing), and spend most of their runtime modifying and packing different configurations. The complexity of the architectures nowadays impose a number of constraints on the relative position of the modules. The most important constraints are the: • preplaced module constraints - used for partially reconfigurable hardware, and can be used in the context of nanoscale architectures that employ route around defects fault tolerance techniques. • boundary constraints - used to constraint the module position relative to the boundary of the chip • range constraints - restrict the position of a module within a range • alignement constraints - align two or more modules horizontally or vertically • abutment constraints - to abut two or more modules horizontally or vertically, so they will be aligned and no other module can be placed between them • clustering constraints - To cluster some modules around a point or another module In the context of the implemented prototype we choose the TCG-S[19] floorplan representation since it is a generic floorplan representation having good packing results, and it can be extended to encapsulate a large number of constraints. But other floorplan representations can be used at will. The TCG-S representation is a hybrid floorplan representation combining the advantages of the sequence-pair and TCG representations, and eliminating their disadvantages. In the reference paper the authors proposed a way of using TCG-S data structure and algorithms to floorplan module in the presence of boundary and preplaced module constraints. In [43] the authors proposed a simple way of integrating constraints in the floorplan representation using constraints graphs. From this point of view the TCG-S representation has the quality of already using constraints graphs for floorplan representation. Thus the integration of many constraints types can be supported by the TCG-S default data structure.

5.4.1 Generic Simulated Annealing Implementation Simulated annealing[17] is one of the best heuristic method used for combinatorial optimization problems. It is very time consuming but yields excellent results. It is an excellent heuristic for solving any combinatorial optimization problem, such as Traveling salesman problem[14], VLSI CAD problems such as PLA folding, partitioning, routing, logic minimization, floorplanning or placement. The basic procedure in simulated annealing is to accept all moves that result in a reduction in cost. Moves that result in a cost increase are accepted with a probability that decreases with the increase in cost. A parameter T, called the temperature, is used to control the acceptance probability of the cost increasing moves. Higher values of T cause more such moves to be accepted. In most implementations of this heuristic, the acceptance probability is given by exp(−∆C/T ), where ∆C is the cost increase. In the beginning, the temperature is set to a very high value so most of the moves are accepted. Then the temperature is gradually decreased so the cost increasing moves have less chance of being accepted. Ultimately, the temperature is reduced to a very low value so that only moves causing a cost reduction are accepted, and the algorithm converges to a low cost configuration. In the listing 5.1 we have the Smalltalk implementation of the simulated annealing procedure as it is currently used in the NA B OO framework.

31

Listing 5.1: Simulated annealing main procedure implementation. | o l d E n e r g y s t a r t T i m e endTime | s t a r t T i m e : = Time now . s t a t s : = O r d e r e d C o l l e c t i o n new . c u r r e n t S t a t e : = saMo d el . b e s t S o l u t i o n := c u r r e n t S t a t e . ” I n i t i a l best solution ” c u r r e n t S t e p := 0. ” En er g y e v a l u a t i o n c o u n t ” i d l e := 0. theCost := c u r r e n t S t a t e energy . currentTemperature := annealingSchedule i n i t i a l i z e T e m p e r a t u r e . [ e x i t C r i t e r i o n value ] whileTrue : [ ” Wh ile t i m e r e m a i n s & n o t good en o u g h ” oldEnergy := c u r r e n t S t a t e energy . nbMoves : = 1 . acceptedMoves := 0 . [ innerLoopCriterion value ] whileTrue : [ ” number o f moves p e r t e m p e r a t u r e ” | newState | ” P i c k some n e i g h b o r and co m p u te i t s e n e r g y ” newState := c u r r e n t S t a t e neighbour . newState energy < b e s t S o l u t i o n energy ifTrue : [” I s t h i s a new b e s t ? ” b e s t S o l u t i o n := newState ] . d e l t a := newState energy − c u r r e n t S t a t e energy . ( acceptanceProbability value : delta ) ifTrue : [ ” S h o u l d we move t o i t ? ” s t a t s add : ( ( S t a t s new ) energy : newState energy ; b est : b e s t S o l u t i o n energy ; temperature : currentTemperature ) . theCost := theCost + d e l t a . acceptedMoves := acceptedMoves + 1 . c u r r e n t S t a t e := newState ] . ” i n n e r l o o p end ” nbMoves : = nbMoves + 1 ] . c u r r e n t S t a t e energy = oldEnergy i f T r u e : [ i d l e := i d l e + 1] i f F a l s e : [ i d l e := 0 ] . c u r r e n t S t e p := c u r r e n t S t e p + 1. ” Up d ate t e m p e r a t u r e ” currentTemperature := annealingSchedule value ] . endTime : = Time now . s e l f r u n n i n g T i m e : ( ( endTime s u b t r a c t T i m e : s t a r t T i m e ) a s S e c o n d s ) . ˆ bestSolution

32

Figure 5.4: Generic model of the simulated annealing heuristic Since this heuristics can be used in many of the optimization problems in the circuit layout automatization field we decided to implement it in a generic way so all tools can use the same basic algorithm tuned for their needs. In the figure 5.4 we have a UML class diagram of our simulated annealing implementation. The algorithm can be tuned by creating a new class that inherits one of the parametric classes (ExitCriterion, InnerLoopCriterion, AcceptanceProbability, AnnealingSchedule, SAModel). This approach was used to tune the simulated annealing implementation for the floorplanning problem.

5.4.2 Specializing the Simulated Annealing Algorithm for the Floorplanning Problem The specialization of the simulated annealing heuristic in the context of the floorplanning problem was performed as described in the last chapter, by inheriting the parametric classes. This way we created 4 new classes: FPAnnealingSchedule, FPExitCriterion, FPInnerLoopCriterion, FPAcceptanceProbability. The annealing schedule we used is similar to the one used in VPR [7]. The initial temperature is calculated using the method presented in listing 5.2. The annealing schedule is calculated by the method in listing 5.3. The acceptance probability is given by exp(−∆C/T ), where ∆C is the cost increase. The number of inner loop iterations is equal to the number of modules to be floorplanned. The algorithm ends when the current temperature is smaller than 5% of the average cost or when the number of idle steps (steps during which no better solution was found) is equal to 50.

33

Listing 5.2: Simulated annealing initial temperature calculation[7] initializeTemperature | newModel v a r i a n c e n mean S s t d d e v | n := 0. mean : = 0 . S := 0. s a saMo d el c o n t e n t m o d u les do : [ : each | | delta | n := n + 1. newModel : = s a saMo d el n e i g h b o u r . [ newModel == s a saMo d el ] w h i l e T r u e : [ ] . d e l t a : = newModel e n e r g y − mean . mean : = mean + ( d e l t a / n ) . S : = S + ( d e l t a ∗ ( newModel e n e r g y − mean ) ) . s a saMo d el : newModel ] . v a r i a n c e := S / ( ( n − 1) = 0 i f T r u e : [ 1 ] i f F a l s e : [ n −1]). st d d e v := v a r i a n c e s q r t . ˆ20 ∗ std d ev

Listing 5.3: Simulated annealing cooling schedule[7] | f aRatio | a R a t i o : = s a a c c e p t e d M o v e s / s a nbMoves . f := aRatio > 0.96 ifTrue : [0.5] ifFalse : [ aRatio > 0.8 ifTrue : [0.9] i f F a l s e : [ aRatio > 0.15 ifTrue : [0.95] ifFalse : [0.8]]]. ˆ sa currentTemperature ∗ f

5.4.3 TCG-S Floorplanning Results In the figure 5.5 we can see the floorplan of the Custom Adder circuit, it has an area of 9.9408 µm2 . In table 5.1, we can see a comparison between the reference TCG-S[19] implementation, and NA B OO implementation. As we can see the results are close. The fact that for almost all circuits, except apte, NA B OO implementation doesn’t perform as well as the reference implementation, is a consequence of the different annealing schedule used, in NA B OO . For pragmatic reasons we choose to use a generic annealing schedule since our implementation is generic (we used graph structures instead of more compact matrices, etc), we needed an reasonable execution time, and we emphasize on the method of development (not on specific optimizations). In a production context (where the results are more important) the integration of a better annealing schedule would be similar to the one presented in section 5.4.2. The runtime (in table 5.1) is given just as an indication, the differences are due to different execution environments (processor, operating system, system charge).

34

Figure 5.5: The floorplanning result of the Custom Adder circuit Table 5.1: Area and runtime comparison between the reference results (presented in [19]) and the results we obtained with the Smalltalk implementation of the TCG-S floorplan representation used in conjunction with the simulated annealing heuristic presented in the last section. MCNC Circuit apte xerox hp ami33 ami49 1

Reference[19] Area (mm2 ) Time (sec) 46.92 1 19.796 5 8.947 7 1.185 84 36.398 369

NA B OO implementation1 Area (mm2 ) Time (sec) 46.92 1 20.386 1 9.574 5 1.678 110 58.44 401

The results are just informative. The implemention of a good annealing schedule for the floorplanning problem is beyond the scope of this work

5.5 Nasic Placement The placement step, in a general CAD flow, decides exactly what component on the chip will be used to implement each logic function. The placement main optimization goal is to minimize the communication cost by keeping communicating cells close to each other. In the implemented prototype the placement step uses a visitor to interpret the floorplanned circuit instance, to produce the Nasic nano-tiles corresponding to the PLAs in the circuit, and to place them at the positions pre-computed by the earlier phases of the flow. In the figure 5.6(a) one can see the resulting placement of the Custom Adder circuit on the Nasic fabric architecture. Figure 5.6(b) presents the result of the PLA mapping step on a single tile. For the time being our placement method is nothing but a simple PLA mapping algorithm. But we are investigating ways to efficiently map multiple tightly coupled PLA on the same nanotile in such a way to reduce the diagonal effect imposed by the PLA design style and to maximize the gain of using nanoscale devices.

5.6 Routing After placement routing compute builds (or identify, for reconfigurable fabrics) the interconnect resources to carry signals across the chip from one module to another. The classic optimization goal of routing is to 35

a)

b)

Figure 5.6: a) The Custom Adder circuit mapped on 8 Nasic tiles. b) A Nasic tile reduce the circuit delay without overusing the chip resources. In the context of reconfigurable nanoscale fabrics the routing step consists of interpreting the architectural model to identify the routing resources and, afterwards, to systematically try to find paths from source to target. Pathfinder is a typical algorithm used for FPGA routing. For the moment in NA B OO framework we don’t perform this step. But, since it is already implemented in Madeo framework[18] we can reuse it, after some reconditioning. In the case of Nasic, the routing problem may seem easier since we don’t have predefined routing resources so basically the problem is similar to the VLSI routing problem. But, the way the routing resources are implemented would differ. For example, for two nanotiles that are close together the circuit signals can be routed through nanowires, but if we need particularly long lines, or complex routing patterns, probably CMOS wires will be chosen for routing the signals. In the last case the nano/CMOS interfacing problem will appear, since we have to connect the outputs of one nanotile (NWs) with the microwires that will route the signals. The introduction of the stochastic decoder[10] proposed by DeHon is one solution for this problem. Nevertheless, the routing problem in the context of Nasic is not trivial.

5.7 Conclusion In this chapter we have presented the first development efforts around the NA B OO framework. In order have a complete back-end prototype, in the near future, we are planning to recondition and integrate in NA B OO the Madeo[18] variants of: 1. the Pathfinder[21] routing algorithm; 2. hMetis[16]-like partitioning algorithm. Another aspect that is worth mentioning is that currently we build each nanotile around just one PLA. Now we are investigating ways to efficiently map tightly coupled PLAs on the same nanotile this way greatly improving the density of the circuit.

36

6 Conclusions and Perspectives

”Research is to see what everybody else has seen, and to think what nobody else has thought.” Albert Szent-Gyorgyi The work presented in this report represents a first step taken toward designing and implementing a generic, evolutive CAD tool targeting the application design automation on a wide range of emerging nanofabrics. The framework, named NA B OO , will permit the designers to easily map circuits on the new nano/CMOS hybrid architectures and, at the same time, it will offer the support for architectural prospection on these emerging technologies. From an software engineering point of view the architecture of the NA B OO framework should be an orthogonal composition between the principal aspects of the circuit layout problem: the circuits, the architectures, the algorithms and the metrics. The first two aspects, the circuits and the architectures are captured by the two models described in the chapter 4, namely the Structured Circuit Model and the Architectural Model. The Architectural Model is the most important part of the system, because it will offer the expressive power of creating virtual representations of the available and/or prospective nano scale computing architectures. Our intention is to create a model powerful enough to capture the important details of these architecture and around this model to build a powerful set of back-end tools capable of exploiting it optimally. The Structured Circuit Model on the other hand should be capable of capturing all the functional parameters of the circuit and at the same time it should be a polymorphic model able to carry the circuit semantics all the way from logic synthesis to the hardware architecture. These models are composed with the rest of the framework by using a formal metamodeling approach to model creation, the STEP standard. The algorithms and tools should be modular, implemented in the most generic way and they should communicate with each other using the models described. In chapter 5 we presented a number of tools that have already been developed for the NA B OO framework. But finally, the metrics arbitrate the orchestration between the circuits, architectures and algorithms (tools). In our vision the development of a coherent set of metrics can improve rapidly the quality of the three. Even the first prototype developed has the capability to operate on benchmarks specific to the problem (like MCNC benchmark, see section 5.4.3). We believe that such a generic, evolutive framework is the key for greatly improving the understanding of how nano devices work, how they can be integrated into useful computing architecture and how to exploit these architectures with maximum benefits. The success of generic tools, like VPR[7], in the context of classical FPGA architectures re-enforce this belief. Furthermore the prototype presented in this report showed the feasibility of the approach. In the near future we plan to extend this prototype by including tools for logic partitioning, and routing. The design and the integration of a new, more expressive, architectural model is another aspect that we plan 37

to explore. The objectives are: (1) for short term - to have a complete CAD flow for application automation on the Nasic architecture; (2) for medium term - to extend the support to other nanoscale architectures and, to include different fault tolerance techniques in the framework; (3) for long term - to have a robust, scalable framework capable to automate the application design on a wide range of nanofabrics.

38

Bibliography

[1] ISO 10303-1. Part 1: Overview and fundamental principles, 1994. [2] ISO 10303-11. Part 11: edition 2, EXPRESS Language Reference Manual, 2004. [3] ISO 10303-21. Part 21: edition , Implementation method: Clear text encoding of the exchange structure, 2001. [4] ISO 10303-22. Part 22: Implementation method: Standard data access interface specification, 1998. [5] ISO 10303-28. Part 28: Implementation method: XML Representation of EXPRESS Schemas and Data, 2004. [6] R. Amerson, R. Carter, B. Culbertson, P. Kuekes, , and G. Snider. Teramac - Configurable Custom Computing. In IEEE Workshop on FPGAs for Custom Computing Machines, pages 32–38, April 1995. [7] Vaughn Betz, Jonathan Rose, and Alexander Marquardt. Architecture and CAD for Deep-Submicron FPGAs. Kluwer Academic Publishers, Norwell, MA, USA, 1999. [8] Hayward H. Chan, Saurabh N. Adya, and Igor L. Markov. Are Floorplan Representations Important in Digital Design? In ISPD ’05: Proceedings of the 2005 international symposium on Physical design, pages 129–136, New York, NY, USA, 2005. ACM. [9] Deming Chen, J. Cong, M. Ercegovac, and Zhijun Huang. Performance-driven mapping for CPLD architectures. Computer-Aided Design of Integrated Circuits and Systems, IEEE Transactions on, 22(10):1424–1431, Oct. 2003. [10] Andre DeHon and Michael J. Wilson. Nanowire-based Sublithographic Programmable Logic Arrays. In FPGA ’04: Proceedings of the 2004 ACM/SIGDA 12th international symposium on Field programmable gate arrays, pages 123–132, New York, NY, USA, 2004. ACM. [11] C. Dezan, L. Lagadec, M. Leuchtenburg, T. Wang, P. Narayanan, and C.A. Moritz. Building CAD Prototyping Tool for Emerging Nanoscale Fabrics. European Nano Systems, 2007. [12] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional, 1995. [13] D. Goldhaber-Gordon, M.S. Montemerlo, J.C. Love, G.J. Opiteck, and J.C. Ellenbogen. Overview of Nanoelectronic Devices. Proceedings of the IEEE, 85(4):521–540, Apr 1997.

39

[14] G. Gutin and A. Punnen. Traveling Salesman Problem and Its Variations. Kluwer Academic Publishers, 2002., 2002. [15] Ralph E. Johnson and Brian Foote. Designing Reusable Classes. Journal of Object-Oriented Programming, pages 22–35, 1988. [16] George Karypis, Rajat Aggarwal, Vipin Kumar, and Shashi Shekhar. Multilevel Hypergraph Partitioning: Application in VLSI Domain. In DAC ’97: Proceedings of the 34th annual conference on Design automation, pages 526–529, New York, NY, USA, 1997. ACM. [17] S. Kirkpatrick, C. D. Gelatt, and M. P. Vecchi. Optimization by Simulated Annealing. Science, Number 4598, 13 May 1983, 220, 4598:671–680, 1983. [18] L. Lagadec. Abstraction, mod´elisation et outils de CAO pour les architectures reconfigurable. PhD thesis, Universit´e de Rennes 1, 2000. [19] Jai-Ming Lin and Yao-Wen Chang. TCG-S: Orthogonal Coupling of P*-Admissible Representations for General Floorplans. In DAC ’02: Proceedings of the 39th conference on Design automation, pages 842–847, New York, NY, USA, 2002. ACM. [20] X. Ma, D. B. Strukov, J. H. Lee, and K. K. Likharev. Afterlife for Silicon: CMOL Circuit Architectures. IEEE-NANO, July 2005. [21] L. McMurchie and C. Ebeling. PathFinder: A Negotiation-Based Performance-Driven Router for FPGAs. Field-Programmable Gate Arrays, 1995. FPGA ’95. Proceedings of the Third International ACM Symposium on, pages 111–117, 1995. [22] Michael Meyer, Tudor Girba, and Mircea Lungu. Mondrian: an Agile Information Visualization Framework. In SoftVis ’06: Proceedings of the 2006 ACM symposium on Software visualization, pages 135–144, New York, NY, USA, 2006. ACM Press. [23] A. Mishchenko, S. Chatterjee, and R.K.Brayton. Improvements to Technology Mapping for LUTBased FPGAs. Computer-Aided Design of Integrated Circuits and Systems, IEEE Transactions on, 26(2):240–253, Feb. 2007. [24] Csaba Andras Moritz and Teng Wang. Latching on the Wire and Pipelining in Nanoscale Designs. 3rd Workshop on Non-Silicon Computation (NSC-3), ISCA’04, Germany, june 2004. [25] Csaba Andras Moritz and Teng Wang. Towards Defect-Tolerant Nanoscale Architectures. 6th IEEE Conference on Nanotechnology, IEEE Nano’06, june 2006. [26] Csaba Andras Moritz, Teng Wang, Pritish Narayanan, Michael Leuchtenburg, Yao Guo, Catherine Dezan, and Mahmoud Bennaser. Fault-Tolerant Nanoscale Processors on Semiconductor Nanowire Grids. IEEE Transactions on Circuits and Systems I, special issue on Nanoelectronic Circuits and Nanoarchitectures, november 2007. [27] Pritish Narayanan, Michael Leuchtenburg, Teng Wang, and Csaba Andras Moritz. CMOS Control Enabled Single-Type FET NASIC. IEEE Computer Society Annual Symposium on VLSI 2008, 2008. [28] University of California Berkeley. Berkeley Logic Interchange Format, 1992. [29] A. Plantec and V. Ribaud. PLATYPUS : A STEP-based Integration Framework. In 14th Interdisciplinary Information Management Talks (IDIMT-2006), September 2006. [30] Morpheus: Multi purpose dynamically reconfigurable platform for intensive heterogeneous processing. http://www.morpheus-ist.org. [31] Sailesh K. Rao, P. Sadayappan, Frank K. Hwang, and Peter W. Shor. The Rectilinear Steiner Arborescence Problem. Algorithmica, 7(2&3):277–288, 1992.

40

[32] E.M. Sentovich, K.J. Singh, L. Lavagno, C. Moon, R. Murgai, A. Saldanha, H. Savoj, P.R. Stephan, Robert K. Brayton, and Alberto L. Sangiovanni-Vincentelli. SIS: A System for Sequential Circuit Synthesis. Technical Report UCB/ERL M92/41, EECS Department, University of California, Berkeley, 1992. [33] Amit Singh and Malgorzata Marek-Sadowska. Efficient circuit clustering for area and power reduction in FPGAs. In FPGA ’02: Proceedings of the 2002 ACM/SIGDA tenth international symposium on Field-programmable gate arrays, pages 59–66, New York, NY, USA, 2002. ACM. [34] Gregory S. Snider and R. Stanley Williams. Nano/CMOS Architectures Using a Field-Programmable Nanowire Interconnect. Nanotechnology, 18(3):035204 (11pp), 2007. [35] Squeak. http://www.squeak.org/. [36] Dmitri B. Strukov and Konstantin K Likharev. CMOL FPGA: a Reconfigurable Architecture for Hybrid Digital Circuits with Two-Terminal Nanodevices. Nanotechnology, 16(6):888–900, 2005. [37] C. Teodorov. NANO CAD: Design Automation Methods for Emerging Nanoscale Technologies. A Survey of Nanoscale Computing Architectures and Associated CAD Tools. Technical report, Universit´e de Bretagne Occidentale, january 2008. [38] Teng Wang, Mahmoud Ben-Naser, Yao Guo, and Csaba Andras Moritz. Wire-Streaming Processors on 2-D Nanowire Fabrics. NSTI (Nano Science and Technology Institute) Nanotech’05, California, may 2005. [39] Teng Wang, Mahmoud Ben-Naser, Yao Guo, and Csaba Andras Moritz. Combining Circuit Level and System Level Techniques for Defect-Tolerant Nanoscale Architectures. 2nd IEEE International Workshop on Defect and Fault Tolerant Nanoscale Architectures (NanoArch’06), Boston, MA, june 2006. [40] Teng Wang, Mahmoud Ben-Naser, Yao Guo, and Csaba Andras Moritz. Self-Healing Wire-Streaming Processors on 2-D Semiconductor Nanowire Fabrics. NSTI (Nano Science and Technology Institute) Nanotech’06, Boston, MA, may 2006. [41] Teng Wang, Pritish Narayanan, and Casaba Andras Moritz. Combining 2-level Logic Families in Grid-based Nanoscale Fabrics. IEEE/ACM Symposium on Nanoscale Architectures(NanoArch’07), october 2007. [42] Teng Wang, Zhenghua Qi, , and Csaba Andras Moritz. Opportunities and Challenges in ApplicationTuned Circuits and Architectures Based on Nanodevices. In First Conference on Computing Frontiers Italy, pages 503–511, april 2004. [43] E.F.Y. Young, C.C.N. Chu, and M.L. Ho. Placement Constraints in Floorplan Design. Very Large Scale Integration (VLSI) Systems, IEEE Transactions on, 12(7):735–745, July 2004.

41

A Models and Refactoring Techniques

A.1

Isomorph Model Refactoring: Smalltalk Implementation Listing A.1: Recursive super calls inlining

i n l i n e S u p e r C a l l s : aNode | collection | aNode s u b c l a s s e s do : [ : s u b c l a s s | self inlineSuperCalls : subclass ]. c o l l e c t i o n : = s e l f f i n d S e l e c t o r s W i t h S u p e r C a l l s F o r : aNode . c o l l e c t i o n k ey sAn d ValuesDo : [ : key : v a l u e | v a l u e do : [: selector | | implementationClass | implementationClass := s e l f findImplementationOf : s e l e c t o r i n : aNode s u p e r c l a s s . implementationClass isNil ifFalse : [ self inlineMethod : s e l e c to r fromClass : implementationClass t o C l a s s : aNode method : key ] ifTrue : [ Transcript show : ’ s u p e r c a l l t o a i n e x i s t e n t method , source of the c a l l : ’ , aNode p r i n t S t r i n g , ’ − ’ , key ; c r ] ] ]

42

Listing A.2: Recursively copy-down superclass methods copyDownAll : a C o l l e c t i o n | subclasses | a C o l l e c t i o n isEmpty i f T r u e : [ ˆ t r u e ] . s u b c l a s s e s : = O r d e r e d C o l l e c t i o n new . aCollection collect : [ : each | | methList | methList := s e l f e x t r a c t M e t h o d s : each . ( CopyDownMethods copyDown : m e t h L i s t from : each ) e x e c u t e . methList := s e l f e x t r a c t M e t h o d s : each c l a s s . ( CopyDownMethods copyDown : m e t h L i s t from : each c l a s s ) e x e c u t e . s u b c l a s s e s addAll : ( s e l f e x t r a c t S u b C l a s s e s : each ) ] . s e l f copyDownAll : s u b c l a s s e s

Listing A.3: Remove instance variables from old model classes S t o r e . R e g i s t r y packageNamed : n ewPack ag e ) a l l D e f i n e d C l a s s e s do : [ : newClass | ( S t o r e . R e g i s t r y packageNamed : o l d P a c k a g e ) a l l D e f i n e d C l a s s e s do : [: oldClass | n e w C l a s s name = o l d C l a s s name ifTrue : [ o l d C l a s s instVarNames do : [ : e a c h | o l d C l a s s r em o v eI n stVar Nam e : e a c h ]]]].

Listing A.4: Change the superclass of old model classes ( S t o r e . R e g i s t r y packageNamed : n ewPack ag e ) a l l D e f i n e d C l a s s e s do : [ : newClass | ( S t o r e . R e g i s t r y packageNamed : o l d P a c k a g e ) a l l D e f i n e d C l a s s e s do : [: oldClass | n e w C l a s s name = o l d C l a s s name ifTrue : [( oldClass classBuilder ) currentClass : oldClass ; s u p e r c l a s s : newClass ; format : oldClass format ; reviseSystem ] ] ]

43

A.2

Models

Figure A.1: Structured Circuit Model

44

Figure A.2: Madeo SCObject hierarchy

45

Figure A.3: Architectural Model

46