Template coding with LDS and applications of LDS in EDA

Template coding with LDS and applications of LDS in EDA

Ahmet Unutulmaz • Gunhan Dundar •

Francisco V. Fernandez

Received: 5 February 2013 / Revised: 4 September 2013 / Accepted: 11 October 2013 / Published online: 25 October 2013

� Springer Science+Business Media New York 2013

Abstract This paper presents the layout description script

(LDS), which is a domain specific language intended to

code layout templates to be used for layout-aware circuit

synthesis. LDS supports both sequential and constraint

programming and is suitable for both manual coding and

automatic code generation. LDS is compared with previous

approaches related to layout description. Code samples are

given for alignment, abutment, symmetry, and similar

constraints. Also, implementation of the LDS compiler is

discussed and a methodology for handling complex con-

straints is presented. Due to its support for constraint pro-

gramming, it is possible to constrain topological

representations and even combine them. It is also possible

to combine and constrain placement and routing in an LDS

template. Finally, a capture tool has been implemented.

This tool is designed to extract a template from an expert-

drawn layout. Capture converts a data structure extracted

through a guided user interface into a template. This tool

highlights the compatibility of LDS with electronic design

automation.

Keywords Layout-aware circuit synthesis � Layout

description script � Layout template � Constraints in

analog layout � Hybrid template language

1 Introduction

Nowadays, most ICs contain both digital and analog cir-

cuitry. Synthesis or re-mapping of digital blocks to new

technologies is almost fully automated. However, most

analog blocks are manually designed and require much

higher development time when compared to digital blocks.

Today’s trend is to replace analog processing by digital

computations, but some functions must necessarily remain

analog. Circuit designers need more effective computer

aided design (CAD) tools to overcome the analog design

bottleneck [1].

Many approaches have been proposed to automate

analog circuit and layout (physical) synthesis. According to

the methodology followed to combine circuit and layout

synthesis, these tools may be classified in three categories,

namely: traditional synthesis [2, 3], performance-driven

layout synthesis [4, 5] and the layout-aware circuit syn-

thesis [6–14].

In traditional approaches, circuit synthesis is not con-

nected to the layout synthesis quantitatively. During layout

synthesis, matching and coupling are qualitatively consid-

ered [3], but performance degradation due to the parasitic

effects, such as: resistance of interconnects, are not con-

sidered. Thus, the synthesized circuit is expected to deviate

from the original specifications, especially at high fre-

quencies. The second category, performance-driven layout

synthesis, feeds performance constraints, obtained from the

sized circuit, to the layout generator. The placement tool in

[4] tries to keep the performance degradation within

imposed margins where sensitivity analysis is used to

bound parasitics in [5]. The performance-driven layout

synthesis approaches may suffer when the performance

margins are not enough for the layout generator. Layouts

for the traditional and the performance-driven layout

A. Unutulmaz (&) � G. Dundar

Department of Electrical and Electronics Engineering, Bogazici

University, Istanbul, Turkiye

e-mail: [email protected]

F. V. Fernandez

IMSE, CSIC and University of Seville, Seville, Spain

123

Analog Integr Circ Sig Process (2014) 78:137–151

DOI 10.1007/s10470-013-0213-9

synthesis approaches are generally generated by an opti-

mization engine which tries to place and route the layout,

as shown in Fig. 1. These synthesis approaches do not

guarantee to fully satisfy the circuit performance specifi-

cations after post-layout simulation. Moreover, the optimal

sizing provided by the previous sizing step is not guaran-

teed to be optimal once accurate parasitics are considered.

Furthermore, as designers shift to nanometric technologies,

parasitic effects are becoming more significant. To com-

pletely fulfill the desired specifications, synthesized layouts

need to be modified and iterations between circuit and

physical synthesis are required, thus, abolishing the

advantages of automatic synthesis.

Recent works are based on layout-aware circuit syn-

thesis which aims to combine the physical and the circuit

synthesis into a single design loop. Three different tech-

niques are used to integrate layout induced effects into the

design loop:

1. Optimization-based layout synthesis is performed in

the loop and the parasitics [6, 7] are extracted as shown

in Fig. 2(a). To be usable in a synthesis loop, the high

computational time required for optimization may be

decreased by strictly constraining the solution space

[7, 8]. As more constraints are added, the solution

space becomes smaller and the optimization approach

turns into template instancing.

2. A layout is not generated in the synthesis loop, but

parasitic effects are estimated through a model, as

shown in Fig. 2(b). The model is generated by using a

template and a parasitic extractor [9]. This approach

annihilates the need for layout synthesis and extraction

in the loop. Thus it is fast, however necessity for a

template and parasitic models limit this approach. The

parasitic models are like an interpolation of several

layout instances. This is either very expensive if many

samples are used or very inaccurate if few samples are

used.

3. A template is used to instantiate a layout and then the

parasitics are extracted [10–13] as shown in Fig. 2(c).

Template-based synthesis makes use of stored design

knowledge and its advantage is fast layout instancing,

making it appealing for the layout-in-the-loop circuit

synthesis approaches. A template is required for this

approach. However, low flexibility of the templates

and hardness of template coding limits its usage.

Template-based layout synthesis approaches have

palliated the low flexibility of templates by structured

template construction and, in some cases, by including

the quality of the layout instance as an optimization

parameter [14]. However, a single template cannot

usually provide high quality layouts for the complete

search space of design parameters.

From the approaches reviewed above, optimization-

based sizing approaches with instantiation of layout tem-

plates in the loop provide the best speed/performance

trade-off. The drawback of these approaches is twofold:

1. Templates have been traditionally considered to have

low flexibility. Even when detailed parameterization

and optimization of the layout quality is performed

during the optimization process, as in [14], a single

layout template can hardly offer good performance in

all regions of the search space of the design variables.

2. Template construction requires deep expertise and

considerable effort.

The main objective of this paper is to introduce layout

description script (LDS), which is designed to ease tem-

plate coding and synthesis. This language was partially

presented in [15–17] and enables both, much cheaper

manual construction of templates and automated template

synthesis. This approach enables the design automation

paradigm illustrated in Fig. 2(d). It enjoys the advantages

of both, optimization-based and template-based layout

synthesis methods. The method is more flexible than con-

ventional template-based approaches because a new tem-

plate is synthesized when available ones do not provide a

good enough quality of the layout instance at the current

region of the search space in a given iteration of the circuit

sizing process. The efficiency is much better than optimi-

zation-based approaches, and close to template-based

approaches, because sizing relies on existing templates in

most iterations. In addition, LDS combined with the

approach in [18] enables area optimization on an LDS

template in a layout-in-the-loop approach.

LDS eases template coding and synthesis with its

capabilities to handle complex layout constraints. It is a

hybrid language, combining declarative and sequential

programming. Roughly speaking, a declarative program-

ming language defines what to acheive without describing

the control flow, whereas a sequential one describes how to

achieve a task. The LDS language eases layout coding in

the following ways:

1. LDS supports sequential programming, which allows

the designer to code parameterized device generators.

It is possible to call a parameterized device generator

CircuitSynthesis

Circuit

LayoutSynthesis

Layout

Fig. 1 Layout synthesized through optimization

138 Analog Integr Circ Sig Process (2014) 78:137–151

123

in a declarative program; however, it is not possible to

code one with a declarative language. This is due to the

fact that the number of elements of a parameterized

device is unknown. For instance, the number of fingers

is an input to a transistor generator and it is not known

a priori. Thus, it is not possible to define the required

constraints for each finger without using a loop, which

controls the program flow.

2. LDS also supports constraint programming. Align-

ment, boundary, symmetry and similar constraints,

mentioned in [19], may be coded without any concern

about the type of graph representation, the kind of

solver, etc. This drastically reduces the time required

to manually code a template and offers a straightfor-

ward procedure for electronic design automation

(EDA) tools.

3. Topological representations, commonly used in place-

ment tools, may be converted to LDS. This way,

different representations may be used to constrain a

layout. LDS may be considered as a superset of

representations.

The paper is organized as follows. A comparison of LDS

with the available representations is given in Sect. 2.1. The

CircuitSynthesis

Circuit LayoutSynthesis

Layout

(a)

CircuitSynthesis

Circuit

Parasitics(Model)

(b)

CircuitSynthesis

Circuit TemplateInstantiation

Layout

(c)

CircuitSynthesis

Circuit TemplateInstantiation

Layout

TemplateSynthesis

(d)

Fig. 2 Layout-aware circuit

synthesis loops. a Layout

synthesized in the loop through

optimization, b parasitic model

used in the loop, c template

Instanced in the loop,

d template synthesized and

reused

Table 1 Comparison of LDS

with other representationsRepresentation Constraint

programming

# Constraint

satisfaction

Parametrized

cells

Structured CIF [20] No 0 No

GDSII [21], etc.

Topological Slicing tree [22] Yes 1 No

Sequence pair [23]

B*-Tree [24], etc.

Sequential SKILL [25] No 0 Yes

PYTHON [26]

MSL [27]

MOGLAN [28]

BALLISTIC [29]

TDL [30]

LAYLA [31], etc.

CAIRO [11] Yes

(slicing tree)

1 Yes

Declarative PDI [32] Yes

(No symmetries)

1 No

RPL [33]

Hybrid ALI [34] Yes

(No symmetries)

1 Yes

LDS Yes – Yes

Analog Integr Circ Sig Process (2014) 78:137–151 139

123

syntax of LDS is presented in Sect. 2.2. Coding layout

constraints using LDS are discussed in Sect. 2.3. An

implementation to compile and instance LDS is presented

in Sect. 2.4. In Sect. 3.1, algorithms to convert topological

representations to LDS are given. Section 3.2 introduces a

template extractor tool which is based on LDS. Finally,

Sect. 4 concludes the paper.

2 Layout description script

2.1 LDS versus previous approaches

LDS is a domain specific language (DSL) intended to ease

template coding that combines the advantages of sequential

and declarative programming. It can be used for both,

interactive template construction by the designer and

automatic construction by EDA tools. A comparison of

LDS against the available layout representations is given in

Table 1. The comparison is made in terms of constraint

programming, number of constraint satisfactions, and

capability to handle parameterized cells. Constraint pro-

grams define the relation between variables and constraints,

whereas ordered assignments are used for this purpose in

sequential languages. The parameter ‘‘number of constraint

satisfaction’’ indicates the constraint satisfaction capabili-

ties of the language. A ‘‘0’’ constraint satisfaction value

means the language does not support constraint program-

ming; a ‘‘1’’ value means the language can solve a single

constraint problem. Using LDS, it is possible to solve an

unlimited number of constraint problems, thus it is possible

to code different parts of a layout with different represen-

tations and glue them. The capability to handle parame-

terized cells in column three of the table, indicates whether

a parameterized device generator can be coded with the

listed languages. In the table, available representations are

grouped into five classes, namely: structured, topological,

sequential, declarative and hybrid.

Structured representations [20, 21], where only the

absolute position of each rectangle is used, are specialized

a

b

c

(a)

b.right = c.right;

a.right = b.right;

(b)

a.right = b.right;// 1st assignment

b.right = c.right;// 2nd assignment

(c)

a

b

c

(d)

a

b

c

(e)

Fig. 3 Order of assignments

affect the layout if sequential

language used. Code to align

right edges (b) as in (a). If the

order of the assignment changes

as in (c), Placement after the

first assignment in (d),

Placement after the second

assignment (e)

if (a.width >= b.width) {b.left = a.left + (a.right – a.left)/2;

} else {a.left = b.left + (b.right – b.left)/2;

}

(a)

(right(b) + left(b))/2 == (right(a) + left(a))/2;

(b)

Fig. 4 Symmetry with a sequential code and b LDS

layout nmos {public nmos(…) {

default {Double width = 1e-6;Double height = 0.35e-6;Integer m = 1;…

}lds (x) {

// constraintsx(a.right) == x(b.right);// or func(a, b);

for (int i=1;i<m;i++)func(a, c[n].right);

…

…

}…

}private void func(Rectangle r1, Rectangle r2) {

x(r1.right) == x(r2.right);}…

}

Fig. 5 An LDS template


123

in storing the layout information. They have been com-

monly used for interfacing designers and fabrication

foundries. Topological ones [22–24] are built with tree

structures or name sequences. Fast algorithms are available

to convert these representations to absolute placements.

Topological representations are used with optimization-

based placement tools, where the layout constraints are

imposed by these representations. They are usually handled

by sequential programs and they do not contain any code

themselves. Sequential languages [11, 25-31] can also

represent a layout. Not only absolute positions, but also

templates or parameterized cells may be coded using these.

Some of the sequential languages listed in the table [25, 26]

are general programming languages and are also integrated

with commercial EDA tools. Some of them [27–31] are

specific languages for layout description. The work in [11]

resembles to an application programming interface (API)

offering functions to construct a Slicing Tree representa-

tion. Declarative languages in the table [32, 33] are

designed for layout coding through constraint program-

ming. The hybrid language in [34] generates a set of

inequalities and then solves these. This language is limited

to inequality constraints and constraints are not as flexible

as LDS in terms of constraint programming:

1. Constraints cannot be defined in functions.

2. It is not possible to combine the constraints of a

module and the constraints of its sub-modules. For

instance, it is not possible to get the constraints for the

ports of a module.

3. A single constraint problem can be solved.

An LDS program is converted into a sequential program

by a compiler. Then, a template in LDS is instanced by

running the compiled LDS program. Note that, generating

a sequential program from an LDS program is analogous to

generating a machine code from a C program. Any pro-

gram may be written by using directly machine code;

however, writing a machine code is harder and prone to

more errors. The following discussion tries to answer the

question: ‘‘Why do we need LDS?’’.

Unlike sequential languages, the order of constraints in

LDS does not affect the layout. In a sense, assignments are

automatically ordered during constraint satisfaction. For

instance, assume that a designer wants to align the right

edges of three rectangles as shown in Fig. 3(a), where these

rectangles may be metal pieces or devices, such as tran-

sistors. This can be achieved by using the code in Fig. 3(b).

However, if the order of assignments is reversed as in Fig.

3(c), the designer will end up with an incorrect layout. The

layout after executing the first assignment is depicted in

Fig. 3(d), whereas the layout after the second assignment is

provided in Fig. 3(e) which does not correspond to the

initially intended layout. If LDS were used instead of

sequential assignments in these figures, the order would not

affect the result.

If LDS is used, the designer is not responsible for taking

care of different conditions during template coding; in

other words, LDS constraints abolish the necessity for

conditional statements required for coding flexible tem-

plates. Assume that the designer wants to align centers of

two rectangles, namely: a and b. If the designer does not

know which rectangle is longer, every case must be

checked by if-else conditionals or min/max functions. Note

that the length of the rectangle may be undetermined in a

template. For instance, the length of a connection is not

known a priori and it is going to be determined after sizing

the devices, e.g., transistors. A simple sequential code to

align the centers of rectangles a and b is given in Fig. 4(a).

However by using LDS, the constraint in Fig. 4(b) would

suffice. Considering the case where the number of blocks is

high and the layout is complicated, which is often the case

for templates containing routing, template coding is going

to be very time consuming and prone to errors with a

sequential language.

Declarative programming capabilities in LDS, more

specifically, constraint programming, not only simplifies

template coding, but also yields more readable and cleaner

codes compared to sequential programs. Constraint pro-

gramming may be used to code a transistor generator for a

fixed number of fingers. However, pure constraint pro-

gramming is not enough to code a parametric device gen-

erator (parametric cell). LDS not only supports constraint

programming but also supports sequential programming.

The designer can freely control the flow of an LDS pro-

gram and can add independent constraint blocks (constraint

programs) into the flow, which makes LDS a hybrid pro-

gramming language. This allows the designer to constrain

topological representations and to satisfy different repre-

sentations at the same time. For instance, it is possible to

merge two or more sequence pair [23] representations,

lds (x) {a = 3;a = 5; // assignmentb = a;

}

(a)

lds (x) {a = 3;x(a) == 5; // constraintb = a;

}

(b)

Fig. 6 Sample LDS codes

a without constraint and b with

constraint


123

defined for different metal layers. Note that topological

representations only allow constraining a single layer.

LDS is a combination of sequential and declarative

programming and allows both constraint programming and

coding parameterized device generators. Furthermore, the

designer may solve an unlimited number of constraint

satisfaction problems with LDS. Thus, the designer may

exactly define the behavior of a rectangle when the layout

is resized. This way, topological representations may be

coded. Due to its support for constraint programming, EDA

tools may easily generate layout templates in LDS.

2.2 Syntax

An LDS template starts with the keyword layout. A

template contains a constructor to initialize the layout and

the template may contain functions. Each function may

contain if, for, while, default, and lds blocks. A

sample LDS program is given in Fig. 5. Code blocks if,

for, and while are common in sequential languages and

are used to control the flow of the program. Code blocks

default and lds are specific for LDS.

The default block is used to ease parameterization,

since layouts for analog devices may have many parame-

ters. For instance, a transistor has poly width, poly length,

and number of fingers as the primary parameters and lots of

secondary parameters such as: metal length, dummies, etc.

Most of the times, a transistor is instanced by assigning its

width, and the remaining parameters are set to their default

values. LDS supports functions with variable arguments. If

values are not specified for these variables, the default

values are going to be used. Default values for the

parameters of a function are set in the default block placed

at the beginning of the function.

Constraints are written in lds blocks. During compila-

tion time, these constraints are used to construct a linear

program and they are satisfied during execution. Types of the

constraints in anlds block are specified in parenthesis:(x)

for horizontal, (y) for vertical, and (x,y) or (y,x) for

x(c) == (left(a)+right(a))/2;

x(c) == left(b); a

b0 <= x1 – 0.5 * x2 – 0.5 * x3 <= 0

0 <= x1 – x4 <= 0

LDS Code

Linear Program Layout

c

Fig. 7 Relation between LDS

code, layout, and linear program

c1*func(r1)+c2*x(d1)+...+c3+(...)==c4*x(d2)+ ...

Term

Term

Constraint

Term

Term

==<=>=

Fig. 8 A Constraint is composed of Terms

b

abottom(a)>=top(b) //placement

ba

bottom(a)==bottom(b) //alignment

a

b

bottom(a)==top(b) //abutment

a1

b

a2

(right(b)+left(b))/2=(right(a1)+left(a2))/2

Fig. 9 Placement, abutment, alignment, and symmetry constraints

with LDS


123

both horizontal and vertical constraints. Consider the codes

given in Fig. 6(a, b). The lds blocks in these code samples

are defined as lds(x), which tells the compiler to generate

a linear program and to add a variable to this linear program

when a variable is input to function x. The code in Fig.

6(a) contains assignments and there is no constraint in this

block. First, the value 3 is going to be assigned to the variable

a, and then the value 5 is going to be assigned to a. At last,

value stored in a is going to be assigned to b. At the end, a

andb are going to have the value 5. However, the code in Fig.

6(b) contains a constraint, which is going to change the

behavior of the program. After the first assignment, a is

going to have the value 3. Following is a constraint and will

not change the value of a immediately. This constraint is

added into the generated linear program. After this con-

straint, the second assignment sets b to the value of a, which

is 3. At the end of the block, the linear program is going to be

solved and the values of the variables are going to be upda-

ted. Thus, the resulting value fora is going to be 5, and that of

b is going to be 3. If there were more constraints, they would

be satisfied together. This way, LDS supports constraint

programming.

Fig. 10 Constraints are handled

via special data structures

a b

c

(a)

b

c

a

(b)

ba

c

(c)

b

c

a

(d)

b

c

a

(e)

c

a b

(f)

Fig. 11 Overlap-free layout

with LDS: a initial placement

and sizes, b Rectangles b and

c are expanded, updates for

lds(x){lds(y){...}} are

(c) and (d), updates for

lds(y){lds(x){...}} are

(e) and (f)


123

Using LDS, the designer can define functions of x and y

to represent points in horizontal or vertical axes, respec-

tively. To ease layout description four functions are

embedded in LDS, namely: left, right, top, bottom.

For instance, left(r) is defined as x(r.left) a priori

and represents the left edge of rectangle r. The designer is

free to define new functions. Figure 7 illustrates the rela-

tionship between an LDS code, the corresponding layout,

and the generated linear program.

2.3 Layout constraints

Constraint programming in LDS eases coding layout con-

straints, where a constraint is defined as a collection of

terms. Figure 8 shows a constraint and some terms are

indicated. Placement, alignment, symmetry, and similar

constraints [19] can be easily coded in LDS. Examples for

placement, alignment, abutment, and symmetry constrains

are given Fig. 9. Placement constraints are required to code

the relative positions of the rectangles in a layout, and these

constraints are coded as inequalities in LDS. Alignment

and abutment constraints are similar to placement, but

equalities are used for these. Symmetry constraints,

essential for analog layouts, are coded with equalities and

7 5

6

12

4

3

(a)

H2

4

V1

H1

3V3V2

7 52H3

1 6

(b)

V3

H3 V2

H1 H2

V1

7 5

6

12

4

3

(c)

Fig. 12 Converting slicing tree

to LDS: a placement, b slicing

tree representation for (a),

c rectangles generated

void slicing2LDS(Node node){

// return if end of treeif (node.type != “H” &&| node.type != “V”)

return;// Go deeper in the tree, left child firstslicing2LDS (node.leftChild);slicing2LDS (node.rightChild);// if H place above, if V place afterif (node.type == “H”)

bottom(node.rightChild.boundary) >=top(node.lefChild.boundary);

else if (node.type == “V”)left(node.rightChild.boundary) >=

right(node.leftChild.boundary);// place right and left children into parentplaceinto(node.rightChild, node);placeinto(node.leftChild, node);

}

void placeinto(Node child, Node parent){

bottom(parent.boundary) <= bottom(child.boundary);top(parent.boundary) >= top(child.boundary);left(parent.boundary) <= left(child.boundary);right(parent.boundary) >= right(child.boundary);

}

Fig. 13 Algorithm generates

LDS constraints for a slicing

tree representation

e

ac

b

d

(a)

e

ac

b

d

(b)

Fig. 14 Converting sequence pair to LDS: a placement, b extracted

constraints


123

the designer can locate two rectangles symmetrically with

respect to a symmetry axis.

2.4 Instancing a template

An LDS compiler is used to build an executable code

from an LDS program. The compiler parses an LDS

program and generates Java code. Necessary code and

data structures to handle the constraints and the linear

program are added into the generated code. To keep the

text clear we omit the unnecessary details related to code

conversion. Each lds block defines a new constraint

satisfaction problem and at the end of each block, the

necessary code to solve the linear program is added. Note

also that an LDS template may be compiled for different

technologies.

Instantiation is done by running the generated code.

During the instantiation, constraints are calculated using

special data structures as shown in Fig. 10. Terms in

equality and inequality constraints are collected into the

left hand side and coefficients and constants for each term

are extracted and stored into a special data structure. The

variables in Term are considered as constants if x, y

functions or a function returning a Term with x or y are

not used. Otherwise, the addresses pointed by these

variables are recorded in the data structure. Then, a linear

// element holds the rectangle// and its position in gamma_plus and gamma_minusstruct element{

Rectangle rec;int pos, neg;

}

void sp2LDS(element[] pos, element[] neg) {// for each element efor (n = 1; n < pos.length+1; n++) {

// find the closest elements below enmax = pos.length+1;for (m = pos[n].neg-1; m >= 0; m--) {

if (neg[m].pos > n && neg[m].pos < nmax) {nmax = neg[m].pos;// add constraintbottom(pos[n].rec) >=

top(pos[nmax].rec);}

}// find the closest elements right to enmax = pos.length+1;for (m = pos[n].neg+1; m <= neg.length; m++) {

if (neg[m].pos > n && neg[m].pos < nmax) {nmax = neg[m].pos;// add constraintright(pos[n].rec) <=

left(pos[nmax].rec);}

}}

}

Fig. 15 Algorithm to generate

LDS constraints from sequence

pair representation

12

3 4

65

(a)

1

2 5

6

3

4

(b)

12

3 4

6

5

(c)

Fig. 16 Converting B*-Tree to

LDS: a placement, b B*-Tree

(horizontal) representation for

(a), c rectangles generated and

placed for each node


123

program is generated. This program is solved by a linear

program solver and the solutions are written to memory.

The objective function of the linear program depends on

the lds block definition. If the block is defined as

lds(x) or lds(y), the objective is to minimize the

width or height of the layout, respectively. On the other

hand, if it is defined as lds(x,y) or lds(y,x), the

objective is to minimize both, width and height, together.

Both width and height can be optimized if, and only if, all

the relative relations between the rectangles are defined.

If the relative positions are only defined in one dimension,

it is not possible to size a template in horizontal and vertical

dimensions, simultaneously. This is the case, if the layout is

not defined by a topological representation such as slicing

tree [22] or sequence pair [23]. An example is shown Fig.

11(a), where the rectangles b and c are going to expanded as

in Fig. 11(b). To prevent any overlap between b and c, the

constraints must be defined in concurrent lds blocks: either

lds(x){lds(y){...}} or lds(y){lds(x){...}}. If the

blocks are written as lds(x) {lds(y){...}}, the layout is

going to be first resized in the horizontal dimension and then

in the vertical one. Layouts corresponding to horizontal and

vertical updates are given in Fig. 11(e, f), respectively. Note

that during resizing the necessary space to prevent DRC

violations is also added. To add space between rectangles,

vertical and horizontal constraint graphs are extracted and

placement constraints are added to the generated linear

problem.

3 LDS in EDA

3.1 Topological representations

By modifying topological representations [35], new non-

overlapping layouts may be found. Thus, they are com-

monly used with placement tools. However, topological

representations may only represent a single layer. It is

possible to extend these representations by using LDS,

where different representations may be merged. Common

representations and algorithms to convert these into LDS

constraints are given, below.

Slicing tree [22] is a well-known topological represen-

tation. It slices the layout continuously into horizontal and

vertical pieces till a single rectangle is obtained. A slicing

placement and the corresponding graph representation are

given in Fig. 12(a, b), respectively.

The algorithm in Fig. 13, written in LDS, generates

necessary constraints for a slicing tree. Calling the

slicing2LDS function with the tree in Fig. 12(b), this

algorithm combines nodes into rectangles to obtain the

structure shown in Fig. 12(c). For instance, the sixth

void bst2LDS (Node n, Rectangle rec){// Place n in recplaceinto(n.boundary,rec);Rectangle rec1 = null, rec2 = null;if (n.rightChild != null) {

rec1 = new Rectangle();// Recursively go deeperbst2LDS(n.rightChild, rec1);// Place rec1 right to nleft(rec1) >= right(n.rightChild.boundary);// Place rec1 into recplaceinto(rec1, rec);

} if (n.leftChild != null) {rec2 = new Rectangle();// Recursively go deeperbst2LDS(n.rightChild, rec2);// Place rec2 above nbottom(rec2) >= top(n.leftChild.boundary);// Place rec2 into recplaceinto(rec2, rec);if (rec1 != null) {

bottom(rec2) >= top(rec1);}

}}void placeinto(Rectangle child, Rectangle parent) {

bottom(parent) <= bottom(child);top(parent) >= top(child);left(parent) <= left(child);right(parent) >= right(child);

}

Fig. 17 Algorithm to constrain

a placement for B*-Tree

representation


123

rectangle must be placed above the first rectangle, a

placement constraint is going to be added between these

two, and they are going to be placed into a rectangle named

H3. Then, the second rectangle is going to be placed to the

right of the new rectangle H3. Similarly, rectangles and

constraints are going to be added for each vertical and

horizontal node in the slicing tree.

Sequence Pair (SP) [23] is represented with two name

sequences. It may represent non-slicing layouts, which

obviously cannot be represented by a Slicing Tree. A

simple non-slicing layout is given in Fig. 14(a), which

cannot be represented by the Slicing Tree representation.

With SP, this layout is represented by positive and negative

name sequences as ðCþ;C�Þ ¼ ðecadb; cbaedÞ: If a rect-

angle x is above a rectangle y, the order of x is going to be

greater than the order of y in Cþ: And the order of x will be

smaller than that of y in C�: If the rectangle y is to the right

of rectangle x, then the order of y is going to be greater than

that of x in both sequences.

The algorithm in Fig. 15, written in LDS, generates con-

straints for the input sequence pair. The structure element,

defined in this figure, represents a rectangle and its order in

the positive and negative sequences. The function sp2LDS

adds placement constraints indicated by the arrows in Fig.

14(b). This algorithm scans the positive and negative

sequences and finds the closest rectangles above and to the

right of a rectangle. For instance, constraints from the rect-

angle c to the rectangles a, b and e are generated. No con-

straint is added from c to d because there already exists a

constraint to rectangle a, and a is closer than d.

B*-Tree[24] is a binary tree, and nodes in the tree rep-

resent rectangles in the layout. A left child of a node,

representing a rectangle, in the tree corresponds to a rect-

angle at its right side and a right child corresponds to a

rectangle above it. A sample placement and the corre-

sponding B*-tree are given in Fig. 16.

The algorithm in Fig. 17 adds two rectangles for each

node, one for the left child and one for right child. The

P

M1

Module M1

Port P on MET 2

R2 on MET1

Via V

R1 on MET2

(a)

M1

P R12

R

Dimensions of the module and position of theport are specified by the device generator.width(M1) == param1;height(M1) == param2;left(M1.P) == left(M1) + param3;...

Interconnect R1 is connected to port P.top(M1.P) >= top(R1);bottom(M1.P) <= bottom(R1);left(R1) == right(M1.P);

R1 connected to Vtop(V.MET2) >= top(R1);bottom(V.MET2) <= bottom(R1);right(R1) == left(V.MET2);

V

R2 connected to Vright(V.MET1) >= right(R1);left(V.MET1) <= left(R1);bottom(R1) == top(V.MET1);

(b)

Fig. 18 Capture extracts the

template in two steps a module,

port, and connectivity extracted

via the GUI and b LDS code

synthesized


123

(a) (b)

M12M5M13

M6M7M8M9

M1M2

M14 M15CC1 CC2

M3M4M10M11RZ1 RZ2

(c)

C21

C22 C12

C11

C41

C42 C32

C31

M3M4 M1M2

M7M8 M5M6

(d)

M12M5M13

M6M7M8M9

M1M2M14 M15

CC1 CC2

M3M4M10M11RZ1 RZ2

(e)

C21

C22 C12

C11

C41

C42 C32

C31

M3M4 M1M2

M7M8 M5M6

(f)

Fig. 19 Capture tool synthesizes template: a schematic of the fully

differential amplifier circuit and b schematic of the voltage doubler

circuit; c visualization of the extracted data for (a), and d visualization

of the extracted data for (b); e instance of the synthesized template

from (c), and f instance of the synthesized template from (d)


123

rectangle corresponding to the right child is placed above

the rectangle represented by the parent node and the one

corresponding to the left child is placed to the right of the

rectangle. This process is continued recursively, till the

bottom node is reached. The rectangles generated for the

tree in Fig. 16(b) are shown in Fig. 16(c). Finally, the

dummy rectangles are removed and the layout is com-

pacted, first in the vertical direction, then in the horizontal

direction.

3.2 Capture

To implement a layout-aware synthesis loop, either a pre-

coded or synthesized template is required. Sometimes, it is

convenient to benefit from the expert knowledge and

excellent performance of existing layouts. An example may

be to use a layout drawn for parasitic matching by an

expert. In this case, the template must be either manually

coded or extracted from the pre-drawn layout. Extracting a

template from a pre-drawn layout is obviously going to be

easier than manually generating a new code from scratch.

The capture tool is designed to assist the extraction of a

template from a conventional pre-drawn layout. A template

is constructed in two steps: component extraction and code

generation.

1. Component extraction is composed of three phases:

module extraction, port extraction and connectivity

extraction. A sample extraction is depicted in Fig.

18(a). Module extraction is done by extracting initial

positions of the modules, their sizes, and names. After

extracting the modules, user specifies the ports of these

modules. Finally, interconnect paths are defined and

the user specifies a style for each path.

2. LDS code is generated using the extracted data. First,

necessary code is generated to set all the rectangle

positions to their initial values in the original layout.

Then, LDS constraints are added to constrain the

positions of the ports in the extracted modules. Also,

paths are converted to LDS by adding alignment and

abutment constraints between interconnects. The rout-

ing widths are parametric and minimum width rules

may be used. Some of the generated constraints are

depicted in Fig. 18(b) for the extracted data in Fig.

18(a). Required spacing for DRC is automatically

added during template instancing.

The capture tool has been tested with different analog

circuits. Two examples are presented in Fig. 19, namely: a

fully differential amplifier circuit in Fig. 19(a) and a volt-

age doubler circuit in Fig. 19(b). First, the data structures

visualized in Fig. 19(c) and in Fig. 19(d), respectively, are

captured. Then, layout templates are generated from the

extracted data structures and used to instance sample lay-

outs. An instance of the template generated for the fully

differential amplifier circuit is shown in Fig. 19(e). Simi-

larly, a sample layout is instanced for the voltage doubler

circuit and shown in Fig. 19(f).

The capture tool generates an LDS template from an

extracted data structure. This data structure may also be

generated by a placement or a router tool and this shows

the compatibility of LDS with other EDA tools.

4 Conclusion

LDS has been presented, which is specific for template

coding and supports both constraint and sequential pro-

gramming. This language is specifically designed for lay-

out description, and eases manual and automatic template

construction. This language has the capability to constrain

topological representations, which are commonly used by

placement tools. LDS may represent both placement and

routing. A template extractor tool, capture, is implemented.

Via a guided user interface (GUI), this tool extracts data

from a pre-drawn layout and builds a template from the

extracted data.

Acknowledgements This research work has been supported by both

the 112E005 Project, funded by the Turkish Scientific and Technical

Research Council (TUBITAK) and the TEC2010-14825 Project,

funded by the Spanish Ministry of Economy and Competitiveness

(with support from the European Regional Development Fund).

References

1. Rutenbar, R. (2010). Analog layout synthesis: What’s missing?.

International symposium on physical design.

2. Rijmenants, J., Litsios, J. B., Schwarz, T. R., & Degrauwe, M.

G. R. (1989). ILAC: An automated layout tool for analog CMOS

circuits. IEEE Journal of Solid State Circuits, 24(2), 417–425.

3. Cohn, J., Garrod, D., Rutenbar, R., & Carley, L. R. (1994).

Analog device-level layout generation. Norwell, MA: Kluwer.

4. Lampaert, K., Gielen, G., & Sansen, W. M. (1995). A perfor-

mance-driven placement tool for analog integrated circuits. IEEE

Journal of Solid-State Circuits, 30(7), 773–780.

5. Malavasi, E., Charbon, E., Felt, E., & Sangiovanni-Vincentelli,

A. (1996). Automation of IC layout with analog constraints. IEEE

Transactions on Computer-Aided Design, 15(8), 923–942.

6. Tang, H., Zhang, H., & Doboli, A. (2003). Layout-aware analog

system synthesis based on symbolic layout description and

combined block parameter exploration, placement and global

routing. In Proceedings of IEEE computer society annual sym-

posium (pp. 266–271).

7. Habal, H., & Graeb, H. (2011). Constraint-based layout-driven

sizing of analog circuits. IEEE Transactions on Computer-Aided

Design of Integrated Circuits and Systems, 30(8), 1089–1102.

8. Martin, R., Lourenco, N., & Horta, N. (2012). LAYGEN-II:

Automatic analog IC layout generator based on template

approach. In Proceedings of genetic and evolutionary computa-

tion conference (pp. 1127–1134).


123

9. Agarwal, A., Sampath, H., Yelamanchili, V., & Vemuri, R.

(2004). Fast and accurate parasitic capacitance models for layout-

aware synthesis of analog circuits. In Proceedings of design

automation conference (pp. 145–150).

10. Onedera, H., Kanbara, H., & Tamaru, K. (1990). Operational

amplifier compilation with performance optimization. IEEE

Journal of Solid-State Circuits, 25(2), 466–473.

11. Dessouky, M., & Louerat, M. (2000). A layout approach for

electrical and physical design integration of high-performance

analog circuits. In Proceedings of IEEE international symposium

on quality electronic design (pp. 291–298).

12. Vancorenland, P., Van der Plas G., Steyaert, M., Gielen, G., &

Sansen, W. (2001). A layout-aware synthesis methodology for RF

circuits. In Proceedings of international conference on computer

aided design (pp. 358–362).

13. Ranjan, M., Verhaegen, W., Agarwal, A., Sampath, H., Vemuri,

R., & Gielen, G. (2004). Fast, layout-inclusive analog circuit

synthesis using pre-compiled parasitic-aware symbolic perfor-

mance models. In Proceedings of the conference on design,

automation and test in Europe (pp. 604–609).

14. Castro-Lopez, R., Guerra, O., Roca, E., & Fernandez, F. V. (2008).

An integrated layout synthesis approach for analog ICs. IEEE

Transactions on Computer-Aided Design, 27(7), 1179–1189.

15. Unutulmaz, A., Dundar, G., & Fernandez, F. V. (2011). LDS-A

description script for layout templates. In Proceedings of euro-

pean conference on circuit theory and design (pp. 857–860).

16. Unutulmaz, A., Dundar, G., & Fernandez, F. V. (2011). A tem-

plate router. In Proceedings of european conference on circuit

theory and design (pp. 334–337).

17. Unutulmaz, A., Dundar, G., & Fernandez, F. V. (2012). LDS based

tools to ease template construction. In Proceedings of international

conference on synthesis, modeling, analysis and simulation meth-

ods and applications to circuit design (pp. 61–64).

18. Unutulmaz, A., Dundar, G., & Fernandez, F. V. (2013). Area

optimization on fixed analog floorplans using convex area func-

tions. In Proceedings of the conference on design, automation

and test in europe (pp. 1843–1848).

19. Young, E. F. Y., Chu, C. C. N., & Ho, M. L. (2004). Placement

constraints in floorplan design. IEEE Transactions on Very Large

Scale Integration (VLSI) Systems, 12(7), 735–745.

20. Rubin, S. M. (1994). Computer aids for VLSI design—Appendix

B. Resource document. Accessed January 27, 2013, from http://

www.rulabinsky.com/cavd/text/chapb.html.

21. Rubin, S. M. (1994). Computer aids for VLSI design—Appendix

C. Resource document. Accessed January 27, 2013, from http://

www.rulabinsky.com/cavd/text/chapc.html.

22. Otten, R. H. (1982). Automatic floorplan design. In Proceedings

of design automation conference (pp. 261–267).

23. Murata, H., Fujiyoshi, K., Nakatake, S., & Kajitani, Y. (1996).

VLSI module placement based on rectangle-packing by the

sequence-pair. IEEE Transactions on Computer Aided Design of

Integrated Circuits and Systems, 15(12), 1518–1524.

24. Chang, Y. C., Chang, Y. W., Wu, G. M., & Wu, S. W. (2000).

B*-Trees: A new representation for non-slicing floorplans. In

Proceedings of design automation conference (pp. 458–463).

25. Wood G., & Law, H.-F. S. (1986). SKILL—An interactive pro-

cedural design environment. In Proceedings of custom integrated

circuits conference (pp. 544–547).

26. Pilgrim, M. (2004). Dive into Python. Resource document.

Accessed January 27, 2013, from http://www.diveintopython.net/.

27. Badaoui, R. F., Sampath, H., Agarwal, A., & Vemuri, R. (2004). A

high level language for pre-layout extraction in parasite-aware

analog circuit synthesis. In Proceedings of great lakes symposium

on VLSI (pp. 271–276).

28. Wolf, M., Kleine, U., & Schulze, J. (1998). New description

language and graphical user interface for module generation in

analog layouts. In Proceedings of circuits and systems symposium

(pp. 290–293).

29. Owen, B. R., Duncan, R., Jantzi, S., Ouslis, C., Rezania, S., &

Martin, K. (1995). BALLISTIC: An analog layout language. In

Proceedings of IEEE custom integrated circuits conference (pp.

41–44).

30. Croes, K., De Man, H. J., & Six, P. (1988). CAMELEON: A

process-tolerant symbolic layout system. IEEE Journal of Solid-

State Circuits, 23(3), 705–713.

31. Cory, W. E. (1985). Layla: A VLSI layout language. In Pro-

ceedings of design automation conference (pp. 245–251).

32. Oster, G. M., & Kusalik, A. J. (1998). Icola—incremental con-

straint-based graphics for visualization. Constraints, 3(1), 33–59.

33. Roach, J. A. (1984). The rectangle placement language. In

Proceedings of design automation conference (pp. 405–411).

34. Lipton, R. J., North, S. C., Valdes, J., Vijayan, G., & Sedgewick,

R. (1982). ALI: A procedural language to describe VLSI lay-

outs. In Proceedings of design automation conference (pp. 467–

474).

35. Graeb, H. E. (Ed.) (2011). Analog layout synthesis: A survey of

topological approaches. New York: Springer.

Ahmet Unutulmaz received his

B.S. and M.S. degree in Elec-

trical Engineering from Bogaz-

ici University, Istanbul, Turkiye

in 2006 and 2008, respectively.

Since 2008, he has been as a

research and teaching assistant

at the Department of Electrical

Engineering, Bogazici Univer-

sity. His research interests

include automatic synthesis of

analog layouts and language

development for templates.

Gunhan Dundar got his B.S.

and M.S. degrees from Bogazici

University, Istanbul, Turkiye in

1989 and 1991, respectively,

and his Ph.D. degree from

Rensselaer Polytechnic Institute

in 1993, all in Electrical Engi-

neering. Since 1994, he has

been with the Department of

Electrical and Electronic Engi-

neering, Bogazici University,

where he is currently a profes-

sor, with some temporary posi-

tions at the Turkish Naval

Academy, EPFL (Lausanne,

Switzerland), and the Technical University of Munich during this

period. Dr. Dundar has published more than 100 papers in interna-

tional journals and conferences and a book on analog design auto-

mation. During his career, he has received various awards, among

which are the best paper award in the IEEE ASAP conference in 2008

and the Turkish Scientific and Technological Council Encouragement

Award for Research in 2009. His research interests include analog and

mixed signal integrated circuit design and design automation, espe-

cially for analog circuits.


123

http://www.rulabinsky.com/cavd/text/chapb.html

http://www.rulabinsky.com/cavd/text/chapb.html

http://www.rulabinsky.com/cavd/text/chapc.html

http://www.rulabinsky.com/cavd/text/chapc.html

http://www.diveintopython.net/

Francisco V. Fernandez got

the Physics-Electronics degree

from the University of Seville in

1988 and his Ph.D. degree in

1992. In 1993, he worked as a

postdoctoral research fellow at

Katholieke Universiteit Leuven

(Belgium). From 1995 to 2009,

he was an Associate Professor at

the Dept. of Electronics and

Electromagnetism of University

of Seville, where he was pro-

moted to full professor in 2009.

He is also a researcher at CSIC-

IMSECNM. His research inter-

est lie in the design and design methodologies of analog and mixed-

signal circuits. Dr. Fernandez has authored or edited three books and

has co-authored more than 100 papers in international journals and

conferences. Dr. Fernandez is currently the Editor-in-Chief of Inte-

gration, the VLSI Journal (Elsevier). He regularly serves at the Pro-

gram Committee of several international conferences. He has also

participated as researcher or main researcher in several National and

European R&D projects.


123

Documents

Template coding with LDS and applications of LDS in EDA