CARNEGIE MELLONDepartment of Electrical and Computer Engineering~

Behavioral Level HDL To Layout:Physical Design Path for

Synthesis Tools

Pinar Ceyhan

1996

Advisor: Prof. Thomas

Behavioral Level HDL To Layout: Physical Design Path

For Synthesis Tools

Pinar Ceyhan

Department of Electrical and Computer Engineering

Carnegie Mellon University

Pittsburgh, Pennsylvania 15213

April 1996

Submitted in partial fulfillment of the requirements for the degree of Master of Science in

Electrical and Computer Engineering.

Behavioral Level HDL To Layout: Physical

For Synthesis Tools

Design Path

Pinar Ceyhan

Department of Electrical and Computer Engineering

Carnegie Mellon University

Pittsburgh, Pennsylvania 15213

May 1996

Submitted in partial fulfillment of the requirements for the degree of Master of Science in

Electrical and Computer Engineering.

Acknowledgment

First and foremost I would like to thank my advisor, Don Thomas, for his invaluable guidance

throughout this project. I would also like to thank Shawn Blanton for reading this report and for

his useful feedback.

I would like to thank Herman Schmit and John Hagerman for their patience and help in answering

my many questions. I would also like to thank Sari "Scou" Coumeri, Alok "Tub Boy/Snake/

Lokie" Jain, Mark "Lingerie Boy" Mescher, and David Pursley for their patience during my many

anxiety attacks and for helping me stay relatively sane.

Last but not least, I would like to thank my parents and my brother for their constant love and sup-

port.

Abstract

Synthesis is the process of transforming a design from an abstract description into a detailed

implementation. The synthesis process can be divided into three subprocesses: High-Level Syn-

thesis, Logic Synthesis, Layout. High-level synthesis is the process of transforming a design from

a behavioral description into a register-transfer level description. Logic synthesis is the set of

transformations that are performed on the register-transfer level description to create the gate-level

implementation of the design. Finally, layout is the process of translating the design from logic

gates to geometric representation.

There are a number or Computer-Aided Design (CAD) tools to aide the designer in these pr¢~-

cesses. System Architect’s Workbench (SAW), Synopsys’s Design Compiler, and Cascade Dcsi~

Automation’s Epoch are three such tools. Each of these tools were developed t¢~ s¢~lvc a

part of the synthesis process. SAW was developed to perform high-level synthesis. Design

piler’s capabilities include logic synthesis and logic optimization. Epoch, on the other hand, can be

used for logic synthesis and layout.

In this project, we integrated the three tools into a synthesis path that covers the entire synthesis

spectrum. In doing so, we wrote translations to aid the design flow between various CAD tools.

Contents

1 Introduction1.1 Motivation and Goals ...........................................................................................................11.2 Related Work .......................................................................................................................21.3 Our Approach .......................................................................................................................3

2 Design Process2.1 Levels of Abstraction .............................................................................................................42.2 Synthesis Tools ....................................................................................................................6

2.2.1 SAW .......................................................................................................................62.2.2 Synopsys’s Design Compiler .................................................................................82.2.3 Cascade Design Automation’s Epoch ................................................................... 9

3 Our Implementation 13.1 Path 1: SAW-Design Compiler-Epoch ............................................................................... 123.2 Path 2: S AW-Epoch ...........................................................................................................16

4 Examples and Results4.1 Example In Detail: Greatest Common Divisor ............................................................... I4.2 Other Examples ................................................................................................................

4.2.1 Trigonometric Sine Function (Trig) .................................................................. 204.2.2 Handshaking Problem (Hand) .............................................................................244.2.3 Fifth-Order Elliptic Wave Filter (Flit) .................................................................244.2.4 Discrete Cosine Transform ..................................................................................25

4.3 Summary ............................................................................................................................265 Conclusions and Future Work 286 Appendix A 307 Appendix B 348 Bibliography 35

Chapter 1

Introduction

1.1 Motivation and GoalsThe design process for integrated circuits (ICs) has been moving towards higher levels of abstrac-

tion. As the levels get higher, the process of translating a circuit from the initial descripti~m ~t~ lht~

final layout becomes more complex. Fortunately, automated computer-aided design ((’AI) ttt

ease the process for the designer. These tools perform in fraction of the time the tasks thai would

otherwise be done by the designer by hand.

Synthesis is the process of transforming a design from an abstract description into a detailed hard-

ware implementation. The process comprises of transforming and adding detail to the design from

higher to the lower levels. A design can be represented in different levels of abstraction, Figure 1.

High Level System/Behavioral Level

Register-Transfer/Structural Level

Gate Level

Low Leve~~ ~ Transistor/Physical Level

Figure 1. Levels of Abstraction

The highest level describes the basic function of the desired design. At the next level, the register-

transfer description comprises of two parts: the controller and the datapath. The former is a finite

state machine that sets the control lines that activate and deactivate the datapath modules, which

consist of functional units, registers, multiplexers, I/O units, and buses. At the next level, the

design is mapped onto logic gates of the specified technology library. Finally, these gates are rep-

resented at the physical level by their transistor models, which can then be placed, routed, and fab-

ricated onto the chip[10][21][8].

There are many different CAD tools that are aimed at performing different tasks ~f the design prin-

cess. SAW [21], Synopsys’s Design Compiler [20], and Cascade Design Automation’s Epoch

are three such synthesis tools. Each was developed with the aim of solving a different problem

the design process. System Architect’s Workbench (SAW), developed at Carnegie Mellon Univer-

sity, performs high-level synthesis. Design Compiler performs logic synthesis and logic optimiza-

tion. Epoch, on the other hand, performs synthesis as well as layout operations such as placement,

routing, and buffer sizing.

In this project, we integrated these three tools into a synthesis path that covers the levels of

abstraction. We used SAW for high-level synthesis, Design Compiler for logic synthesis and opti-

mization, and Epoch for layout. We developed translations of the design descriptions between the

different systems. We also explored another synthesis path by using Epoch lbr logic synthesis and

layout.

1.2 Related Work

Synthesis has been a topic of research for the past number of years. Research has been performed

on different aspects of the synthesis process. Research in the area of high-level synthesis has been

done on the algorithms for the scheduling and resource binding problems is in order to improve the

final design for different performance objectives. Heijligers et. al. [13] propose to use Genetic

Algorithms to solve the scheduling and allocation problem, whereas Potkonjiak and Wolf [18]

integrate techniques from operating systems and high-level synthesis to lead to efficient resource

sharing and scheduling. Another approach to improving the scheduling problem is proposed by

Achatz [1]. He proposes building several schedules based upon the already existing one and thus

letting the allocation and binding phases of the process choose the best fitting schedule. The sched-

uling problem has also even been considered for low power. Mussoll and Corladclla I1 (~1 ci~nsidc1

power consumption issues at the scheduling and resource binding stages of the design princess.

Research has also been done at the other phases of the synthesis process. Hartenstein and Kress

[12] consider the synthesis of the datapath modules for mapping onto a reconfigurable datapath

architecture. Alidina et. al. [3] work to lower the power consumption by precomputing the output

logic values of the circuit to reduce the switching activity in the circuit. By reusing already avail-

able designs or design modules, Girczyc and Carlson [11] propose a method to eliminate the cost

overhead generated during optimization and to increase the integration of the design so that more

can be packed onto a single chip.

Research is also being conducted on behavioral synthesis for mixed hardware/software systems

[2] and for multichip modules [24], as well as array mapping within synthesis [191.

1.3 Our ApproachThe goal of this project is to present a path through the synthesis process for high-level systems.

The tools that are used in this path are SAW, Design Compiler, and Epoch. In order to enable inter-

action between the tools, we explored translation methods between the systems.

Chapter 2 of this report describes the synthesis process and the three synthesis tools in more detail.

Chapter 3 describes our approach to finding these paths and the translations between the systems.

Chapter 4 analyzes the different examples tested through this environment. Finally, Chapter 5

offers conclusions and future work.

Chapter 2

Design Process

2.1 Levels of AbstractionThe design process extends through a number of levels of abstraction, as seen in Figure 2. At the

highest level, the design consists of specifications and algorithms describing the function the

design is supposed to implement. The goal of the synthesis process is to create lower level imple-

mentations of the design, while meeting the required specifications and constraints as specified at

the beginning of the process. In doing so, the design is transformed through the different levels by

the different synthesis processes.

(a) System/BehavioralLevel

(b) Register-Transfer/51ructural Level

(c) Gate Level

(e) High-Level Synthesis

(f) Logic Synthesis

(d) Transistor/ (g) LayoutPhysical Level

Figure 2. Levels of Abstraction and The Synthesis Process

At the highest level, the design is an algorithm, Figure 2(a). The description at this level is similar

to a program; it is a set of operations, variables, and dependencies. It specities the functJ~n t~l tllc

design without being concerned about how it is realized. The transformations necessary t¢~ trans-

late the design from the behavioral level to the register-transfer level, Figure 2(b), is called High-

Level Synthesis (HLS), Figure 2(e). During high-level synthesis, the operations implementing

design are determined. These operations are then mapped onto datapath modules and assigned

control steps in the scheduling process. The control states create a finite state machine that imple-

ments the operation schedule. Figure 3 illustrates the Greatest Common Divisor (GCD) example

through high-level synthesis. Figure 3(a) is the behavioral description. During high-level synthe-

sis, >, <=, and - are identified as the operators of the design. These operations are scheduled at

states 8, 6, and 7 respectively. Finally, the datapath modules are determined to be three funct.i¢~nal

processors, two comparators and one subtracter, Figure 3(b).

At the register-transfer level, the design is separated into two parts: the controller and the dalapalh.

The controller is a finite state machine that operates the datapath modules by sending c~ntr~l sig-

nals to the datapath modules according to the schedule of operations determined during HLS. The

datapath modules comprise of memory units (registers, multiplexers), functional units, and inter-

connect units (busses, I/O). Logic Synthesis (LS), Figure 2(f), is the set of transformations that

performed on the register transfer level description to create the gate-level implementation of the

design. During logic synthesis, logic gates are mapped into the design to realize the function of the

controller and the datapath modules, Figure 2(c). Optimization criteria, such as area, timing, and

power, is also carried out during logic synthesis to achieve the best possible implementation of the

design at the gate-level. Figure 3(c) shows the gate-level Verilog of the GCD example and

Figure 4 illustrates the gate-level schematic of the GCD example.

Finally, a physical representation of the design must be generated in order Io fabricate lhe dcsi[21~

onto the chip, Figure 2(d). At this level, the design is transformed from logic gates t~ layers

metal, polysilicon, contacts, etc. during the layout process, Figure 2(g). The geometric representa-

tion of the design is produced. Partitioning and placement of the cells occur at this level, most

often reducing the overall size of the layout. The interconnections between the cells are provided

during the routing process.

always begin: godwait (Raset);done = 0;wait (start = 1);x=xi;y=yi;while (x > 0) begin

if (x <= y) begintemp = y;y=x;x = temp;

endx=x-y;endout = y;done = 1;wait (start = 0);

end

(a)Behavioral Description*tam~nv_2x U197 f .IN00.vt,~tct3]m~Im~nv_:Zx U1 ~ ( .IN00at~e[l] ), .Yfn~01) ~td~a3_2x U199 (J]N0(~593), ,IN113~tate[2] ), J/q2~a599), .y(n597)

ttdoai211 O201 (JN0(a580), JNI (a.~81), JN2(RS82), .llq3(a583), .Y0x9813] ~doai211 U202 ( ./Nn(a581 ), JNI (e584), .IN2(eS~), JN3(a58~, .¥0x9~[2]

attloei211 LI2t~ (JN0(a$81), JN 1 (n590~. JN2(~91 ), .IN3(a5929,~td~o21| U2~ ( .IN0(n593), .INl(a594), JN2(d~e), ~13(a595),.Y(~*~II*I02/~_0 ~ta*o222 O2O6 ( .n’,~yl3l ), .~(~3,.INJ(~t [3] )..YOyl0gD]~dao222 U207 ( JN0~[2]),.~5(e59S), .YtXy~0~[2] ) ~1ao222 U205 ( J/q0(~y[1]ar~5(a59~), .YOy~0e0] ) atdao222 U209 ( JN00y[0] ), .INI(e596), JN2~i[0]). Jl~3(a597), .1N4~[0]

~daei21 U210 (.IN0(a599), JNl(n600), JN2(a~0 l), .Y0aext_m*te404[3] ~/doai21 U211 ( ~10(~tat~[0] ), .1NI (~602), JN2(n603), .y0aext_state404[2] Itd~aad2 U212 (JJq0(a6~), JNI (n605), .Y0aext_~te404[1]Itdoai211 U213 ( ~10(W~e[0] ), ANI(a6~0), JN2(n60~, .IN3(n603),.Y0aext_*late40,t [0] ) );sta~toi211 U214 ( .l~l~’~a~[3] ), JNl(n607), J/q2(n~08)..1/OQ~.,Me[4] .YQa405[0] ) ); I~d~oi211 U216 (.[N0(Re~et), .INI(e599), .IN2(n611),J~0mteIt] ), .Y(a6~0)

~daed2 U218 (JN~a601),stdof313219 ( JN00state [4] ), .IN I 0~te[3] ), J]q2(a601), .Y(e593) ~tdac~3 I)220(.IN0(n614). JN 10state [4] ), .IN2(~99), .¥(n613) Mdaaad3 U221 (3N0(n601), $Nl(n611),I;UIII~3 U222 (.IN.n599), .INI (~tate~la~3 13223 (.1N~599), JNI fn593),adnand3 U224 (JN0(a$99), .IN 1 (n~02), .IN20stat~[2] ), .Y(n616)sldllet’2 U225 (J/~’n618), JNl(~yl}, .Y(~617)stc~t32 U226 ( JN0(n61~, JNI(n617)..Y(n~05) ~tdand213227 (JN0(n605), .INl(n619),stdnaad2 U2211 ( dN0(a6l 1), ~11 (~99), .y(1~94)~aad213229 ( JN0(n617), JN I ~tate[2] ), ,Y(m300)

ttdmux2 U231 ( JN0(out [3])..IN 1 (~y[3]), .~0(a595), .Y0outl 18[3]

, (c) Gate-Level Description

fu_pr ocr_leq(x,y,xleqy);fu_pr ocr~tr(x,0,xgtr0);fu_procr_minus(x,y, out);

always @(x or y or state) begincase (state)

1: begincase (Reset)

0: state = 1 ;1: state = 2;

endcaseend2: begin

case (start)0: state = 0;1: state= 3;

elldCaseend3: begin

x = xi; y = yi;state = 8;

end4: begin

out = y; done = 1;state = 5;

end5: begin

case (start)O: state = I;1: state = 5;

endcaseend6: begin

case (xleqy)O: state = 7;1: state = 9;

endcaseend7: begin

x = out;state = 8;

end8: begin

case (xgtrO)0: state = 4;1 : state = 6;

endstateend9: begin

temp = y; y = x; x = letup;state = 7:

end

(b) RT-Level Description

Figure 3. High Level Synthesis of the GCD

2.2 Synthesis Tools

2.2.1 SAW

The System Architect’s Workbench, SAW, is a tool that was developed at Carnegie Mellon Uni-

versity [21]. SAW was developed to transform behavioral descriptions into register-transfer level

Figure 4. Gate-Level Implementation of the GCD Example

descriptions. Thus, it is a purely high-level synthesis tool, Figure 5.

System/Be?vioral Level

SAW

RT/Struc~al Level

Gate ’Level

Transistor~hysical Level

Figure 5. SAW in the Design Process

SAW has two internal paths that can be used to synthesize the design. The firsl is the CSTEP/

EMUCS route. This is a two-step synthesis route. During CSTEP, control steps arc assigned

different operators that have been allocated to implement the function of the design. The ct~nlr~l

is created here. Using a list scheduling algorithm, CSTEP creates a control flow graph that

sents the design, where each state of the graph corresponds to a control step. EMUCS is a datapath

synthesis tool. Given the flow graph that was created during CSTEP, EMUCS determines, allo-

cates, and binds every necessary datapath module.

Constraints can be imposed on the design during both stages of CSTEP/EMUCS. During CSTEP,

timing constraints can first be imposed to set maximum and minimum times between operations.

Hardware constraints are also set during CSTEP to avoid any hardware scheduling conflicts.

EMUCS uses cost tables to set its constraints. The first cost table lists the cost of allocating new

registers, wires, functional units, etc. The second cost table is called the Add-Function Tablc. This

table states the cost for grouping a certain function with another function. These cosl lablcs

used in determining the least costly implementation of the design [211122l.

SAW’s second internal path is the Scheduling, Allocation, and Mapping (SAM) option. SAM per-

forms both of the individual goals of CSTEP and EMUCS in one single tool. SAM performs the

scheduling, allocation, and mapping tasks in parallel° It considers every possible option for the

three tasks in every cycle, thus allowing the algorithm to consider all consequences of any action

immediately [7].

CSTEP/EMUCS is the original path that was developed in SAW and is therefore a more estab-

lished route than SAM. Thus, we will use CSTEP/EMUCS in this project. Every reference to SAW

in the rest of this report is for the CSTEP/EMUCS path of SAW.

2.2.2 Synopsys’s Design Compiler

Synopsys’s Design Compiler is a widely used commercial logic synthesis tool 1201. I1 is desigtaed

to synthesize a design from the register-transfer level to the gate level, Figure 6. During this pro-

cess, it also performs logic optimization, making sure that the transformed design meets certain

performance specifications, such as area, timing, and power. Design Compiler performs this opti-

mization so that the end result is the best possible circuit that can be realized with the desired tech-

nology library and that meets the functional and performance requirements of the target design.

In optimizing the design, Design Compiler takes into consideration two types of constraints:

design rule constraints and optimization constraints. The design rule constraints are those that are

set automatically when the target technology library is chosen. Constraints such as maximum

fanout or maximum transition fall under this category. Performance constraints such as area and

speed are specified by the user and are thus considered after the design rule constraints. Design

System/Behavioral Level

RT/Structural Level

DESIGN COMPILERGate Level

Transistoi’/Physical Level

Figure 6. Design Compiler in the Design

Compiler allows the user to constrain all synchronous paths in the design by specifying lhc ch~ck

for the system. Design Compiler assigns costs to these constraints and optimizes the design such

that the final design is that with the mi~timal cost functions, both for the design rule constrainls and

for the user specified constraints [ 15][20].

2.2.3 Cascade Design Automation’s Epoch

Cascade Design Automation’s Epoch tool is designed to perform synthesis as well as layout [6].

Given a very structured register-transfer level description, Epoch has the capability to perform

logic synthesis. Epoch also performs automatic layout operations such as placement, routing, and

buffer railsizing, Figure 7.

The input for Epoch may be one of two possible formats. It is required to be either a register-trans-

fer level description or a gate-level implementation. In performing the synthesis process. Epoch

flattens the design hierarchy unless otherwise specified as a fixed block. After flatlcning is com-

plete, Epoch takes the design and partitions it into two new groups, the datapath and the chip c~rc.

Finally, it builds leaf cells.

The implementation of the datapath modules can be realized in three different ways. First, all the

modules can be implemented as standard cells only. Or, they can be implemented as already-

blocked Epoch Datapath library modules. Finally, they can be implemented as a combination of

the two previous methods. The goal of the tool is to find a good balance with both types of imple-

RT/Structural L~vel

Gate Level

Trans~~stor/Physi

Epoch

zal Level

Figure 7. Epoch in the Design Process

mentations, as using only standard cells will lead to too many blocks in the design and using only

Epoch’s ready modules will lead to too few blocks.

Epoch allows the user to either automatically place and route the design or perform these tasks

manually. The automatic compilation option deals with the design from the lowes! level of the

hierarchy to the current level. For placement, the user has the option to ch~ose from differcnl

methods of placement. One option is to carry out the task based on area efficiency and minimiza-

tion of wiring. Another option also considers these options as well as optimizing for timing

requirements. A third option is called the Incremental Placement. Here, if there is a change in the

netlist, the existing placement is preserved as much as possible while redoing the placement.

Finally, the last possible way of performing placement is by optimizing the datapath groups for

such constraints as routing and track usage.

Epoch also comes with an in-depth set of library parts that can be utilized by the user instead of

redesigning these parts. These library parts range from simple multiplexers to ALU’s to RAMs.

All of these library parts also come with functional Verilog descriptions and can be used to simu-

late the design after mapping in these library parts[6].

10

Chapter 3

Our Implementation

In the previous chapter, we saw that synthesis tools are developed for particular goals that may not

Design Compiler

Algorithmic ~ii Behavioral

::~;

~¢ RT Structurai

( Gate Functional

Epoch ~,~ L~out~ ~’Layout

(a) Individual Tool Spectra (b) Complete Paths

Figure 8. Possible Synthesis Paths

Key:SAW

Design ~

Epoch

necessarily cover the entire spectrum. As seen in Figure 8(a), the tools used in this project, SAW,

Design Compiler, and Epoch, each cover a certain range of the synthesis spectrum. Epoch also

holds the added advantage of covering multiple levels of the synthesis process.

In this project, we consider two possible paths that cover the entire spectrum. Figure 8(b) illus-

trates these two paths. In the first path, all three tools are used. SAW is used for high-level synthe-

11

sis, Design Compiler is used for logic synthesis, and Epoch is used for layout. In the second path,

we utilize Epoch for logic synthesis instead of Design Compiler.

Figure 9 shows a more detailed flowgraph, clarifying the design path. Since those paths thai c~wcr

only a portion of the spectrum are subsets of the "complete" paths, we will describe only thc paths

that cover the entire scope, from a behavioral description to layout.

Gate Level

TD~a~Path Con~ollerCon roller

]Module MappingI I Desil~n Compiler ]] Gate Level

Register-Transfer

Figure 9. Flowchart of the Different Paths

3.1 Path 1: SAW-Design Compiler-Epoch

The first path uses all three synthesis tools. SAW is used lbr high-level synthesis, Design Compilcr

for logic synthesis and optimization, and Epoch for layout, and module generation.

12

In performing high-level synthesis through SAW, we avoid any extra transformations and perform

only the necessary steps in carrying out the synthesis. We set resource constraints of 4 add opera-

tors, 4 subtract operators, 2 multiply operators, and 1 divide operator for scheduling of the control

states, One of our goals in using this design path is to be able to use Epoch’s library parts in our

datapath. In order to properly map these library parts to the datapath modules, we specify an add-

function table that prevents more than one function to be grouped together.

The synthesized design is a single Verilog file that contains the code for all the modules in the

design: the root module, the controller module, the top level datapath module, and all t~l lhc

vidual datapath modules. Before running the design through Design Compiler. however.

must be made to the Verilog code. First, the header, the root module, the controller, and lhc

level datapath module are separated into individual files. The controller module is then rewritten in

a format acceptable by Design Compiler. The current SAW output of the controller consists of two

always statements. The first statement disables the finite state machine when the Reset line is set.

The other always statement is the finite state machine that makes up the controller. It is clocked at

each state of the case statement and the current state register is simply rewritten. In order for the

code to be Design Compiler compatible, the first always statement is rewritten so that it is clocked

by the positive edge of the Clock and the disabling edge of the Reset lines. Within the always loop,

it consists of an if-else statement. If the Reset line is activated, the state register initialized. Other-

wise, the state register is updated to the next state. The second always statement is again an FSM.

However, this always statement’s sensitivity list consists of the current state register and the ccr~

taln select lines that are accessed within the finite state machine. Each state of the FSM ct~llSisls t~l

the next state register being updated. One has to be careful in writing Verilog code for Design

Compiler and include every possible scenario in a case statement or in if-else statements or all nec-

essary values in sensitivity lists. If something is omitted, Design Compiler will automatically infer

a latch in the design and this may affect the simulation of the design. Thus, a default state updating

the next state register to the initial state is added. Figure 10 shows the "before" and "after" control-

ler descriptions [23].

13

always @(negedge Reset)disable MAIN;

always begin :MAINwait(Reset);@(posedge Clock)current._state = 65537;stack_pointer = 0;forever begin

case (current_state)65537: begin

@(posedge Clock)current_state = 131073;

end131073: begin

@ (posedge Clock)casex ( state131073_select l’bl: begin

current_state = 196609end

l’bX: begincurrent_state = 262145

endendcase

end196609: begin

@(posedge Clock)current_state = 327681;

end

endcaseend

end (a) Post-SAW

always @(posedge Clock or negedge Reset) beginif (!Reset) begin

current_state = 65537:stack_pointer = 0;

endelse begin

current_state = next_state;end

end

always @(current_state or state131073 select orstate393217_select or state458~-53_select orstate917505_select) begin

case (current_state)65537: next_state = 131073;131073: begin

casex ( statel31073_select l’bl: begin

next_state = 196609;end

default: beginnext_state = 262145:

endendcase

196609: next_state = 327681 :

default: next_state = 65537:endcase

end

(b) Pre-Design Compiler

Figure 10. The Controller Verilog

Once the new controller code is written, it is run through Design Compiler for logic synthesis and

optimization. Because we will be using Epoch for module generation and layout later in the design

path, we specify the target libraries in Design Compiler to be those provided by Epoch.

The next step in the process is to map the datapath modules to Epoch’s library modules. We are

unable to map any functional unit with multiple functions directly onto Epoch. Thus, these mod-

ules have to be rewritten. The post-SAW format is in terms of assign statements, whereas the new

format consists of a single always statement. This always statement is made up of a case slalcmenl

where each state corresponds to a function, Figure 11

There are some functions that cannot be realized by a single Epoch module at the top level bu~ can

be realized by multiple modules at a lower level. An example of this is the "greater than or equal

to" function. Epoch has one module that determines whether two values are equal and another

module that determines whether one number is greater than the other. However, there is no single

14

assign #0 outl =((cttl} --’opconcat) ? (/* ( op: concat } */(inl,in2))

assign #0 outl =({ctrl} == ’oppadO) ? (/’*t op: padO ~ */{ ’bO,inl }) :

assign #0 out1 =(({ctrl} != ’opconcat) II ({ctrl} != ’oppad0)) ? ’bx

(a) Post-SAW

Figure 11. Functional Units

reg outl;always @(inl or in2 or ctrl) begin

case (ctrl)’opconcat: outl = {inl,in2};’oppad0: outl = {’d0,inl };

default: outl = 0;endcase

end

(b) Pre-Design Compiler

module to satisfy the ~ function. Thus, in this case, the module is rewritten so that it instalatiatcs

the equality checker and the comparator and "OR"s the results of the two instanliations I~ acqu~rt"

the desired result. Figure 12 illustrates this example.

module procr (inl, in2, outl ,ctrl);input [3:0} inI, in).;input ctrl;output outl;

reg outl, xgy, xly, geq, eql;

equal eq (inl, in2, eql);mcomp gtr (inl, in2, xgy, rdy);or2 gteq(eql, xgy, geq);

always @(inl or in2 or c~l) begincase (eta’l)

’opgeq: outl = geq;default: outl = 0;

endcaseend

endmodule

Figure 12. Functional Unit with Epoch ModuleInstantiations

Another module construct that cannot be mapped directly into the Epoch library is the descripti~m

for register modules where values are written to the register. The new construct for this case is

similar in style to the format that was described earlier for the controller, Figure Ill. Figure 13

illustrates the old and the new Verilog code styles for the register modules.

initial if (!Reset) state_reg = always @(negedge Reset) state_reg =

always @(posedge Clock)case (tmp_ctrl)

"opfwrite: state_reg=/*{ op: fwrite }*/tmp_data;endcase

endmodule

(a) Post-SAW

Figure 13. Output and Register Module

always @(posedge Clock or negedge Reset) beginif (!Reset)

state_reg = 0;else

state_reg = n_state_reg;end

always @(tmp_ctrl or tmp_data) begincase (tmp_ctrl)

"opfwrite: n_state_reg=/*{ op: fwrite }*/trap_data;default: n_state_reg = state_reg;

endcaseend

~ndmodule

(b) Pre-Design Compiler

15

Every module that cannot be directly mapped onto Epoch should be rewritten in the lbrmats dis-

cussed above° The datapath modules that can be implemented by the Epoch modulcs arc mapped

directly in the top level datapath module file. Table 1 lists some of the frequently seen operations

and their mapped Epoch modules.

TABLE 1. Frequently Seen Functions and Their Mapped Epoch Modules

SAW operations Epoch Modules

FREAD barrelright

EQL equal

GTR mcomp

LSS mcomp

PLUS alu

MINUS alu

MULT mult

MUX (2-, 3-, 4- input only) mux2, mux3, mux4

NOT inv

OR (2-input) or2

AND (2-input) and2

Finally, once all the datapath modules have been mapped or rewritten, Design Compiler is used to

perform logic synthesis and Epoch is used to acquire the layout of the design. In order to preserve

the hierarchy of the design in the layout, the controller and the unmapped datapath modules are

classified as "precompiled fixed blocks". This prevents Epoch from flattening these modules when

it flattens the rest of the design. For these modules, the comment

//epoch set._attribute FIXEDBLOCK = 1

is added to each of the synthesized modules before running Epoch. To the top level datapath mod-

ule, the comment

//epoch pre_compiled <module_name>

is added for each module that was declared to be "FIXEDBLOCK = 1". We proceed with Epoch

by compiling all of the unmapped datapath modules and the controller. We then compile lhe lop

level datapath module that instantiates these cells and obtain the layout for the design.

3.2 Path 2: SAW-Epoch

The second path we explored is similar to Path 1 but it does not utilize Design Compiler. Instead,

Path 2 takes advantage of Epoch’s synthesis capabilities. Once again, before logic synthesis can

16

take place, the register-transfer level Verilog description needs to be translated to a format accept-

able by Epoch. However, Epoch’s Verilog compiler accepts the identical format of Design Com-

piler. Thus, the translations that need to be done are identical to those discussed in the previous

section in preparation for Design Compiler. However, the same comment lines that were added in

the previous section after logic synthesis must be added here before synthesis with Epoch can bc

performed.

//epoch set_attribute FIXEDBLOCK = 1 added to individual datapath modulc.~//epoch pre._compiled <module_name>added to the top level datapath module

Once the translation is complete, the design is compiled to layout through Epoch. The next sccti~n

will discuss the various examples we ran through these paths and their results.

17

Chapter 4

Examples and Results

In order to verify the validity of our translations and our design paths, we ran five different design

examples through both paths. The five designs are Greatest Common Divisor, the Trigon~m~ctric

Sine Function, a handshaking problem of two parallel sine functions, a FiI~h-Order Elliptic Wave

Filter, and the Discrete Cosine Transform. These designs vary in complexity, the GCD example

being the smallest and the DCT example being the largest designs within the set.

While running either path, we need to simulate the resulting design at each level, before and alter

the translations have been made in order to check that the function of the design has been pre-

served. A very important goal of the design path is to give the best possible implementation of the

design without losing its functionality. The test vectors used in these simulations were selected

specifically for each design. GCD is a mathematical function. Thus, its simulation test vectors is a

set of randomly generated numbers. For the three following examples, the simulation file sent the

design a stimulus and appropriate requests and acknowledgments. In the Trig example, the stimu-

lus starts at 0 and increments by 1536 at each iteration, whereas in the handshaking example, il

increments by only 6. Tt~e Filter example different in that the initial stimulus is I and the rest arc

In this example, the state registers are not initialized between iterations and thus lead I~ unique

results at each iteration for the same stimulus. Finally, the DCT design is tested by putting thr~mgh

an actual image.

18

During optimization, Design Compiler performs some buffer-sizing and uses special gates that

have been buffer-sized. This, however, has no effect on the function of the gate. Therefore, for

simulation, we remove all of the buffersizing information and replace those gates by instantiating

their basic implementations. However, when running Epoch, we use the buffersized gates in the

input. In the following sections, each of the designs that were passed through the synthesis paths

will be described.

4.1 Example In Detail: Greatest Common DivisorThe smallest design among the examples is the Greatest Common Divisor (GCD). The GCD

example is a simple algorithm that finds the largest number that divides the two given integers

evenly. The algorithm repetitively computes the difference between the two integers, replacing the

larger integer with this difference at each iteration, until the difference of the two integers is no

longer greater than zero. At this point, the other number is returned as the greatest common divi-

sor. The main behavioral loop of the GCD example was seen in Figure 3 on page 6.

The GCD example was synthesized into a register-transfer level description with SAW. The Vet-

flog code for the controller and the datapath is illustrated in Figure 14. There are 14 functional pro-

cessors, 3 multiplexers, 3 inputs, 2 outputs, and 1 register module in the datapath. Bcli)rc

continuing with the synthesis process through Design Compiler, transformations arc made tt~

design. The 14 functional processors are mapped to 7 barrelshitl units, 1 ALU, I magnitude

parator, 2 equality checkers, and 1 inverter from the Epoch libraries, Figure 15.

The unmapped datapath modules are transformed into synthesizable Verilog and synthesized to

gate-level using Design Compiler for path 1 or to layout using Epoch for path 2. The gate-level

implementation of the controller for path 1 can be seen in Figure 16.

(a) Datapath

262145 131073

19660965537

327681

393217

X

655361

720897 786433

458753

589825 851969

(b) Controller

Figure 14. GCD Datapath and Controller

4.2 Other Examples

4.2.1 Trigonometric Sine Function (Trig)

The second example is based on the series expansion computation of the sine function [9]:

X 1 .17 3 X5 X7sin (x) = 1-~ - 3~ + ~.l -~ +"" (EQ 1)

20

Figure 16. Gate-Level Implementation of GCD Controller

The behavioral description of this equation consists of a single while statement that computes each

of the quotients and adds them successively, Figure 17. Since the original expansi~)n (EQ.

21

always begin: trig/*{RESET}*/wait (!Reset):InSync = 1:qx = InVal;#100 wait(l);//tnextInSync = 0;qterm = qx;qtsin = qx;qi= 1;qtemp = qx * qx;qx2 = qtemp[29:14];while (qterm) begi~

qi = qi + 2;qtemp = qterm * qx2;qtop = qtemp[29:14];qbot = qi * (qi-l);qterm = qtop / qbot;

if (qi[1]) qtsin = qtsin - qterm;else qtsin = qtsin + qterm;

end

OutVal = qtsin;OutSync = 1;#100 wait(l);//tnextOutSync = 0;

end

Figure 17. Algorithm for Series Expansion Sin(x) Function

implies that there is no upper limit on the summation, a limit is imposed to stop the compulation

when the summation is longer changing "significantly". The error value of 1.0xl0-6 is imposedi

as the controlling value, i.e., if the term x~ is smaller than the error value, this term is considered

insignificant to the summation and the computation is terminated.

This example was also successful when run through Pathl. Due to the nature of Eq. 1, this design

requires a functional unit that performs the divide operation. However, there is no such unit that

can be mapped through the Epoch library parts. Additionally, Design Compiler does not allow the

division operation performed on variables, only static numbers. In order to maintain the function-

ality of this design, we wrote a behavioral description for a dividing urdt that is based on subtrac-

tion, similar to the GCD example, Figure 18.

The divide function was written in order to simulate the design correctly. Because this module was

simply instantiated from the functional unit, Design Compiler was able to synthesize the l~nc-

tional unit by classifying the divide unit as an "unresolved reference" and instantiating it from the

gate-level description. However, in order to create the layout of the complete system, the divide

22

module div(xi,yi,out);II class: BEHAVIOR

input[ 15:0]xi, yi;output[15:0] out;

reg[15:0] x, y, temp, out,count;

always @(xi or yi) beginX = xi;y= yi;count = 0;while (x > 0)

beginif(x < y)beginx=0;

endelse if (y == 0) begin

count = 0;endelse begin

x=x-y;if (x >= 0)

count = count + 1;end

endout = count;

end //alwaysendmodule

Figure 18. The Division Problem

function needs to be synthesizable. The above description cannot be directly synthesized through

Design Compiler nor Epoch. Thus, we wrote it in the register-transfer level before synthesizi ng it.

One problem that commonly occurs in synthesis is the treatment of delays in the original dc,~crip-

t.ion. Most synthesis tools, including SAW, Design Compiler, and Epoch, ignore these delays and

consequently the behavior of the synthesized model changes due to the missing delays. The Trig

example includes two places where delays are essential for it to simulate correctly. In order to indi-

cate the start and end of the computation, a pulse is created. When this pulse is removed, the

design will iterate indefinitely. Thus, it is essential to describe this event with a delay statement.

However, during the synthesis process, it is lost.

Because Trig is a relatively small example, we were able to locate the multiplexer that controls

these pulses and add the appropriate delay, restoring the original behavior of the design. We were

then able to proceed with the synthesis and layout processes for both paths from the altered RTL

description.

23

4.2.2 Handshaking Problem (Hand)

The next example instantiates two parallel sine functions and uses a handshaking method as a

means of control between the two functions. Figure 19 illustrates this algorithm. We note that the

always begin: hand/*{reset}*/wait (! Reset);forever begin

wait( inReq );inl = inVal;/*{lpg:in}*/wait( 1 );inAck = 1;wait( ! inReq );inAck = 0 ;gol = 1;in2 = ’h60 - inl;go2= 1;wait (! rdyl);gol = 0;wait (! rdy2);go2 = 0;wait (rdyl);wait (rdy2);outVal = outl + out2 ;/*{lpg:out}*/wait( 1 );outReq = 1 ;wait( outAck );outReq = 0;wait( ! outAck )

endend

Figure 19. Handshaking Example

structure of this example at the algorithmic level consists mainly of wait statements and register

value assignments. These assignments and statements enact the sending and receipt of acknowl-

edgments and requests that comprise the handshaking procedure. Like the two previous examples,

this design was easily translated for, synthesized through, and simulated for both paths.

4.2.3 Fifth-Order Elliptic Wave Filter (Filt)

The fourth example implements a fifth-order elliptic wave filter. It uses a shift-and-add implemen-

tation multiplier. This example makes use of the Verilog function "task" to implement the mulli-

plier in zero delay. Additionally, the behavioral description of this example contains a large

number of additions that create a number of Read-After-Write hazard conditions on the rcgislcrs.

This constrains the parallelism of the design, as well as the hardware constraints set during the

SAW synthesis, Figure 20.

24

forever beginwait( inreq); iol = invai; /*{lpg:in}*/wait( 1 );

inack = 1; wait( ! inreq ); inack = 0 ;op3 = iol + sv2;op32 = sv33 + sv39;op12 = op3 ÷ svl3;op20 = op12 + sv26;op25 = op20 + op32;mult(op21, el, op25);mult(op24, c2, op25);op19 = op12 + op21;op27 = op2a + op32;opll = op12 ~- op19;op22 -- op19 + op25;op29 = op27 + op32;mult(op9, c3, opl 1);sv26 = op22 + op27;mult(op30, c4, op29);op8 = op3 + op9;op31 = op30 + sv39;op7 = op3 + opS;oplO = op8 + op19;op28 = op27 + op31 ;op41 = op31 + sv39;mult(op6, c5, opT);op15 =opl0 +svlS;op35 = sv38 + op28;mult(io43, c6, op41);op4 = iol + op6;mult(op 16, c7, oplS);mult(op36, c8, op35);sv39 --- op31 + io43;sv2 = op4 + opS;svl8 ~ op16 + svlS;sv38 = sv38 + op36;svl3 = op15 + svlS;sv33 = sv38 + op35;outval = io43 ; /*{lpg:out}*/wait( 1 );outreq = 1; wait( outack);outreq = O; wait( ! outack )

endend g FILT

Figure 20. Main Function of the Filter Example

The SAW-synthesized output of this design is not simulatable. However, in order tt~ verify that the

translations are valid for the larger designs, this example is put through the design paths. The pars-

ing of this example into both Design Compiler and Epoch, for paths 1 and 2 respectively, was suc-

cessful, as was the logic synthesis through Design Compiler in Path 1. However, in both cases, the

design was too big for Epoch and it was unable finish the compilation of the design into its layout

after overnight simulations.

4.2.4 Discrete Cosine Transform

The Discrete Cosine Transform (DCT) algorithm is a transformation from the spatial domain

the frequency domain. This particular DCT example is the first part of the JPEG (Joint Photo-

graphic Experts Group) function. In the spatial domain, the "image" is divided into 64 pixels, each

consisting of 8 bits/pixel. In order to transform this 2-dimensional image into the frequency

2.5

domain, the process is separated into two 1-dimensional DCT processes, one for the rows of pixels

and the other for the columns. Within each 1-dimensional DCT function, the values representing

the image are read and transformed through a series of adds, subtracts, and most importantly mul-

tiplies by cosine fractional coefficients. Because the two 1-dimensional DCT operations are so

similar, we are only concerned with one of these operations.

Like the Filter of the previous example, this design also ceases to be simulatable once synthesized

with SAW. Because of the large size and complexity of this design, it is nearly impossible to pin-

point the source of the simulation problem and alter the description to "fix it", as was done in the

Trig example in Section 4.2.1. Once again, in order to verify the validity of the translations and the

design paths, we transform and synthesize the SAW-output description through both paths. Once

again, the description was parsed into Design Compiler and Epoch successfully, verilying the

compatibility of the translations for both tools. However, once again, the designs were too large

for the machine running the tools. Similar to the previous example, we also wrote a register-trans-

fer level description to pass through Design Compiler and Epoch. The RT-level description was

successfully synthesized through Design Compiler, but once again was too large for to success-

fully finish through Epoch.

4.3 Summary

In order to verify our translations and the design paths, we synthesized five designs of various

sizes, constructs, and complexity through these paths. We stopped and simulated each design

before and after every translation was performed to verify that the new description preserved the

function of the design.

The smaller examples remained correctly simulatable throughout the process. However. the larger

examples stopped simulating properly after the high-level synthesis process. SAW is known t~

contain some minor bugs that were not resolved during its development. Some of these bugs lead

to bit mismatches, port size mismatches, and incorrect assignments of registers. Another property

of SAW that may be the cause of the simulation problems is the cyclic nature of the register-trans-

fer level description. This can affect the timing of the datapath modules and may lead to early or

26

late assignments of register values. Finally, as discussed in Section 4.2, any delay statements in the

behavioral code is ignored by the synthesis tool and may also lead to incorrect simulation.

27

Chapter 5

Conclusions and Future Work

We have explored and presented possible design synthesis paths for high-level systems. We used

System Architect’s Workbench, Synopsys’s Design Compiler, and Cascade Design Automation’s

Epoch tools in these paths. We explored a path that used all three tools, SAW for high-level syn-

thesis, Design Compiler for logic synthesis, and Epoch for layout. We also explored an alternate

path that used only SAW and Epoch. The smaller examples run through these tools showed that

these paths are effective in the design process.

There are different ways in which the design process utilizing these paths can be extended. This

project dealt with the actual presentation of these paths. An extension of this project is to compare

the resulting designs of each path in terms of performance criteria, such as area, timing, power, etc.

In the previous section, we briefly discussed various reasons why some of the designs simulaled

incorrectly after high-level synthesis with SAW. One of these reasons was that the synthesis

ignore delay statements in the original description of the design. Other reasons were bil

matches, port mismatches, incorrect assignments, and the cyclic nature of the synthesized descrip-

tion. Research can be done to identify and solve these and other problems with SAW that lead to

the incorrect simulation.

In this project, we used library parts that were made available from Epoch. Research is currently

underway at Carnegie Mellon University in creating application specific libraries for Design Corn-

28

piler. Extending that research, we could create application specific Epoch libraries. The timing,

area, power, etc. specifications would be specific to the project for which they arc crcatcd.

Another extension of this project is to automate these paths. Finally, these paths can be utili/c0

an actual design project.

29

Appendix A

SAW- Design Compiler- Epoch Synthesis Path

Tutorial

Purpose:The SAW-Design Compiler-Epoch Synthesis Path is a design flow that covers the entire synthesis spectrumby utilizing SAW for high-level synthesis, Design Compiler for logic synthesis, and Epoch for layout. It is amulti-part system that takes a design through these levels.

Syntax:

Part 1: saw2syn <design>

Part 2: dc_shell

Part 3: syn2csd

Part 4: epoch

Brief Description:SAW2SYN:This part of the process requires as input a completely behavioral-level Verilog description of

the design. SAW2SYN calls the appropriate tools to transform the behavioral description into avalue-trace description using VERIVT and to a register-transfer level, structural description,using SAW. It then calls the program RTPARSE to translate the SAW-written Verilog into astructure acceptable by Design Compiler.

RTPARSE is a program that generates files that are used in synthesis. This program has theability to generate Verilog files acceptable by Design Compiler and Epoch or blif files used insynthesis using the Berkeley Octtools synthesis tools in designing FPGAs. RTPARSE automat-ically parses the structural Verilog into its own internal data structure. It can then perform avariety of functions. It can output the design in structural Verilog for Design Compiler, Epoch,or SAW. It can output the design as blif files, to be synthesized to gate-level Verilog using Ber-keley Octtools. It can minimize the controller by stripping away any unnecessary logic.Finally, RTPARSE can also partition the design. For this path, we are going to utilize theDesign Compiler write options.

At the end of this program, the design is split into multiple files, including the controller andthose datapath modules that were not mapped onto Epoch library modules.

DC_SHELL:This is the non-graphical interface for Synopsys Design Compiler. It is run on an interactivemode so there is no script file to run this in batch format. Design Compiler is used t~ synthesizethe register-transfer level descriptions of the controller and the unmapped datapath modules t~gate-level.

SYN2CSD: This program just adds some necessary comments to the Design Compiler-generated Verilogfiles in preparation for compilation by Epoch.

EPOCH: This is the Epoch tool for compilation the gate-level description into layout. This tool runs onSUN SPARCs, so the user will have to telnet into a SUN SPARC machine, such as Hendrix.

30

Compilation Information:The programs saw2syn and syn2csd are shell script programs and thus need no rccompilation. Anysary changes can be made directly to the files.

Saw2syn calls 3 programs: verivt, saw, and rtparse, The source files for these programs are found under thedirectory ~/SAW/src/. Every directory under -/SAW/src/has an individual Makefile. Therefore, files thatwere additionally written needs to be linked during compilation by including it in the Makefile in the direc-tory to which the file was added. To compile, you need to go to the top level directory, -/SAW/src, and enter"make <program>" at the prompt, i.e. ’~nake rtparse" to compile RTPARSE. The executable files will bestored in the directory -/SAW/PATH/bin/.

Syn2csd uses 2 programs: preesd and precsdseq. The source files for these two programs can be found inthe -/S AW/src/ directory. They are individually compiled using the GNU- C compiler, gcc~

Set-upYour .cshrc file should contain the following lines:

setenv CASCADE/afs/ece/usr/cascadesetenv SYNOPSYS/afs/ece/usr/synopsyssetenv DISPLAY <your-machine-name>:0.0

Your Andrew .cshrc file should contain the following lines:

setenv CDA_LICENSE_FILE/afs/ece/usr/cascade/licenses/license.datsetenv CASCADE/afs/ece/usr/cascadesetenv DISPLAY <your-machine-name>.ece:0.0setenv PATH :${PATH }:${CASCADE}/bin

Create the following directories:

<design><design>lverilog<desi gn>lverilogl~b_parts.dir

Copy the following file named .synopsys_dc.setup into the <design>/verilog and the <design>/verilog/lib_parts.dir directories:

designer = "<your name>";company = "CEDA at ECE";SYNOPSYS = get_unix_variable ("SYNOPSYS");CASCADE = get_unix_variable ("CASCADE");RULESET = CDA.7u3m lpLIBS_DIR = CASCADE + "/tech/cmosf’ ÷ RULESETSYMBOL_LIB = CASCADE + "/data/synopsys/epoch_std.sdb"STDCELL_LIB = RULESET + " std cmos2.db"DPCELL_LIB = RULESET + "_dp_cmos2.db"search_path = {., LIBS_DIR }link_library = { STDCELL_LIB, DPCELL_LIB }target_library = {STDCELL_LIB }symbol_library = {SYMBOL_LIB }

Copy the behavioral description into the <design>/verilog directory under the <design>. v.behav extension.

Go to the <design>/verilog directory to begin the synthesis process.

31

Quick Reference Guide

% sawasyn <design>

% dc_shell

> read -f verilog <designname>_sequencer_syn.v

> analyze -f verilog <designname>_sequencer_syn.v

> compile

> write -f verilog -h -o <designname>_sequencer.v

> quit

% cd lib_parts.dir

% dc_shell

% cd ..

% syn2csd

Log on to a SUN SPARC (hendrix.ece)

% cd <design>

% epoch

Project -> Project -> New

enter the path for the design and an 3-character identification

Project -> Ruleset

from the list, choose Ruleset 7u3mlp

for every gate-level file, do the following:

Input -> Verilog Compile

select the appropriate verilog file

select the Synopsys Buffer Sizes option

select Run

close all information windows

Input->Netlist Input

select the current module

select Run

close all information windows

Physical Design -> Automatic Compile

select the current module

select Run

close all information windows

Physical Design -> Open

select the current design

select Run

will call verivt, saw, and rtparse

activate Design Compiler

change to directory containing Verilogdescriptions for the unmapped datapathmodules and repeat the above four DesignCompiler commands on each module

change back to <design>/verilog directory

prepare for Epoch Layout

activate Epoch

all options, except "M" which stands fl~r"Manual", should be green, signifying thatthe partitioning, placement, routing, zmd

32

buffer sizing during compilation was suc-cessful

Once done for every file in the lib_parts.dir directory and the sequencer module, repeat the above steps forthe module that instantiates the datapath and the controller

Simulation -> Simulation Output -> Verilog to save a Verilog description of the completedesign

Output -> CIF to save the layout in c/f format

32,

Appendix B

FILE ORGANIZATION DURING SYNTHESIS FLOW FOR GCD EXAMPLE

Set-upgcd/verilog/gcd.v.behavgcd/verilog/lib_parts.dir/

saw2synFiles that are

VERIVT:

SAW:

RTPARSE:

created from:gcd.vtr

gcd.allged.cfggcd.csgcd.vslgcd.v.str

ged.vcompute.vcompute_sequencer_syn.vlib_parts.dir/compute_fu_procr_ 1 _syn.vlib_parts.dir/compute_fu_procr_3_syn.vlib_parts.dir/compute_p_output_l_syn.vlib_pa~s.dir/compute_p_outpu t_2_syn .vlib_parts.dir/compute_regr_ 1 _syn .vlib_parts.dir/compute_regr_2_syn.v

top level moduleinstantiates all datapath modulescontrollerunmapped functional processorunmapped functional processoroutput registeroutput registerinternal registerinternal register

dc_shellFiles that are additionally created:

compute_sequencer.vlib_parts.dir/compute_fu_procr_l.vlib_parts.dir/compute_fu_procr_3.vlib_parts.dir/compute_p_output_l ovlib_parts.dir/compute_p_output_2.vlib_parts.dir/compute_regr_l.vlib_parts.dir/compute_regr_2.v

syn2csdIn directory lib__parts.dir, every file with the extension _syn.v is moved to a directory syn_dir. The rest of thefiles remain where they are.

34

Bibliography

[1] H. Achatz. "Generating Several Solutions for the Scheduling Problem in High-Level Syn-

thesis," EuroDA C Proceedings, 1995.

[2] J.K. Adams and D.E. Thomas. "Multiple-Process Behavioral Synthesis for Mixed Hard-

ware/Software Systems."

[3] M. Alidina, J. Monterio, and S. Devadas. "Precomputation-Based Sequential Logic Optimi-

zation for Low Power," Proceedings of the International Conference on Compuler-Aidcd

Design, 1994.

[4] M. Bombana, P. Cavalloro, S. Conigliaro, R.B. Hughes, G. Musgravc. and G Zaza.

"Design-Plow and Synthesis for ASICs: a case study," 32nd ACM/IEEE Design Ataomatio~

Conference Proceedings, 1995, pp. 292-297~

[5] M.R. Burich. "Design of Module Generators and Silicon Compilers," Silicon Compilation,

Reading: Addison-Wesley Publishing: 1988, pp. 49- 94.

[6] Cascade Design Automation. Epoch User’s Manual, 1994.

[7] R.J. Cloutier. "Synthesis of Pipelined Instruction Set Processors," Ph.D. Thesis, Carnegie

Mellon University, January 1993.

[8] G. De Micheli. Synthesis and Optimization of Digital Circuits, New York: McGraw-Hill

Inc., 1994.

[9] R.G. Dromey. How To Solve It By Computer, Prentice-Hall, 1982, pp.62.

[10] D.D. Gajski. "Essential Issues and Possible Solutions in High-Level Synthesis" Higt~-Lev~l

VLSI Synthesis, Boston: Kluwer Academic Publishers, 1991.

[11] E. Girczyc and S. Carlson. "Increasing Design Quality and Engineering Productivity

Through Design Reuse," 30th ACM/IEEE Design Automation Conference Proceedings,

1993, pp. 48-53.

[12] R.W. Hartenstein and R. Kress. "A Datapath Synthesis System for the Reconfigurable Data-

path Architecture," ASP-DAC Proceedings, 1995.

35

[13] M.J.M. Heijligers, L.J.M. Cluitmans, and J.A.G. Jess. "High-Level Synthesis Scheduling

and Allocation Using Genetic Algorithms," ASP -DA C Proceedings, 1995.

[14] D. Knapp, T. Ly, D. MacMillen, and R. Miller. "Behavioral Synthesis Methodology

HDL-Based Specification and Validation," 32nd ACM/IEEE Design Ataomation

ence Proceedings, 1995, pp. 286-291.

[15] Po Kurup and T. Abbasi. Logic Synthesis Using Synopsys, Boston: Kluwer Academic Pub-

lishers, 1995.

[16] E. Musoll and J. Cortadella. "Scheduling and Resource Binding for Low Power," Proceed-

ings of the Eighth International Symposium on System Synthesis, 1995, pp. 104-109.

[17] Y. Nakamura, K. Oguri, and A. Nagoya. "Synthesis From Pure Behavioral Descriptions,"

High-Level VLSI Synthesis, Boston: Kluwer Academic Publishers, 1990, pp. 205-229.

[18] M. Potkonjiak and W. Wolf. "Cost Optimization in ASIC-implementation of Periodic Hard-

Real Time Systems Using Behavioral Synthesis Techniques," Proceedings of International

Conference on Computer-Aided Design, 1995, pp. 446-451.

[19] H. Schmit and D.E. Thomas. "Array Mapping in Behavioral Synthesis," Pro~.’eeding.~ ~t

Eighth International Symposium on System Synthesis, 1995, pp. 90-95.

[20] Synopsys Inc. Synopsys Reference Manual.

[21] D.E. Thomas, E.D. Lagnese, R.A. Walker, J.A. Nestor, J.V. Rajan, and R.L. Blackburn.

Algorithmic and Register-Transfer Level Synthesis: The System Architect’s Workbench,

Boston: Kluwer Academic Publishers, 1990.

[22] D.E. Thomas. The System Architect’s Workbench User’s Guide, Version 2.0 Edition, May

1991.

[23] D.E. Thomas and ER. Moorby. The Verilog Hardware Description Language, Third Edi-

tion, Boston: Kluwer Academic Publishers, 1996.

[24] H. Wang, N. Dutt, A. Nicolau, and K.S. Siu. "High-Level Synthesis of Scalable Archilec-

tures for IIR Filters Using Multichip Modules," 30th ACM/IEEE Design Ataom, ati¢m

ference Proceedings, 1993, pp. 336-342.

36

37