Brigham Young University Brigham Young University

BYU ScholarsArchive BYU ScholarsArchive

Theses and Dissertations

2011-03-17

Increasing Design Productivity for FPGAs Through IP Reuse and Increasing Design Productivity for FPGAs Through IP Reuse and

Meta-Data Encapsulation Meta-Data Encapsulation

Adam T. Arnesen Brigham Young University - Provo

Follow this and additional works at: https://scholarsarchive.byu.edu/etd

Part of the Electrical and Computer Engineering Commons

BYU ScholarsArchive Citation BYU ScholarsArchive Citation Arnesen, Adam T., "Increasing Design Productivity for FPGAs Through IP Reuse and Meta-Data Encapsulation" (2011). Theses and Dissertations. 2614. https://scholarsarchive.byu.edu/etd/2614

This Thesis is brought to you for free and open access by BYU ScholarsArchive. It has been accepted for inclusion in Theses and Dissertations by an authorized administrator of BYU ScholarsArchive. For more information, please contact scholarsarchive@byu.edu, ellen_amatangelo@byu.edu.

Increasing Design Productivity for FPGAs Through Intellectual

Property Reuse and Meta-Data Encapsulation

Adam Arnesen

A thesis submitted to the faculty ofBrigham Young University

in partial fulfillment of the requirements for the degree of

Master of Science

Michael J. Wirthlin, ChairBrad L. HutchingsBrent E. Nelson

Department of Electrical and Computer Engineering

Brigham Young University

April 2011

Copyright c© 2011 Adam Arnesen

All Rights Reserved

ABSTRACT

Increasing Design Productivity for FPGAs Through Intellectual

Property Reuse and Meta-Data Encapsulation

Adam Arnesen

Department of Electrical and Computer Engineering

Master of Science

As Moore’s law continues to progress, it is becoming increasingly difficult for hardwaredesigners to fully utilize the increasing number of transistors available semiconductor devicesincluding FPGAs. This design productivity gap must be addressed to allow designs to takefull advantage of the increased logic density that results from rising transistor density.

The reuse of previously developed and verified intellectual property (IP) is one ap-proach that has claimed to narrow the design productivity gap. Reuse, however, has proveddifficult to realize in practice because of the complexity of IP and the reluctance of designersto reuse IP that they do not understand. This thesis proposes to narrow the design pro-ductivity gap for FPGAs by simplifying the reuse problem by encapsulating IP with extramachine-readable information or meta-data. This meta-data simplifies reuse by providing alanguage independent format for composing complex systems, providing a parameter repre-sentation system, defining high-level data types for FPGA IP, and allowing arbitrary IP tobe described as actors in the homogeneous synchronous dataflow model of computation.

This work implements meta-data in XML and presents two XML schemas that enablereuse. A new XML schema known as CHREC XML is presented as well as extensions thatenable IP-XACT to be used to describe FPGA dataflow IP. Two tools developed in thiswork are also presented that leverage meta-data to simplify reuse of arbitrary IP. Thesetools simplify structural composition of IP, allow designers to manipulate parameters, checkand validate high-level data types, and automatically synthesize control circuitry for dataflowdesigns. Productivity improvements are also demonstrated by reusing IP to quickly composesoftware radio receivers.

Keywords: meta-data, FPGA, intellectual property reuse, interface synthesis, IP-XACT,synchronous dataflow, architectural synthesis

ACKNOWLEDGMENTS

I would like to thank my advisor, Mike Wirthlin, and my committee members Brent

Nelson and Brad Hutchings who have encouraged me in my work. I would also like to

thank my other professors at BYU who have mentored me through my undergraduate and

graduate studies and who have provided opportunities for learning and inspiration for my

studies. I am grateful for the support and help of Marc Padilla who helped me design

communication systems, Derrick Gibelyou for helping with algorithms and data structures,

and the other students in the BYU Configurable Computing Laboratory who have helped

me in my research

My family also deserves thanks for supporting me throughout my education. My

parents have encouraged my academic work from my elementary school years and have

always helped me to push myself to be my best. My loving wife Sarah also deserves my

deepest thanks. She has been patient and supportive as I have spent long hours in school

and research. She has been an unfailing source of love and support.

I would also like to thank Newton Peterson, HoJin Kee, and Jeff Washington at

National Instruments for their support of my ideas and their encouragement of me to pursue

my education.

This work was supported by a grant from The Rocky Mountain NASA Space Grant

Consortium, as well as by Brigham Young University CHREC center funded by the I/UCRC

Program of the National Science Foundation under Grant No. 0801876.

Table of Contents

List of Tables xiii

List of Figures xvi

1 Introduction: Design Productivity and Reuse 1

1.1 The Design Productivity Gap for FPGAs . . . . . . . . . . . . . . . . . . . . 2

1.2 Increasing Design Productivity . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 IP Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Enabling Reuse with Meta-Data . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.5 Thesis Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 IP Reuse and Meta-Data Descriptions 11

2.1 Meta-Data for HDL Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Meta-Data in Commercial Design Tools . . . . . . . . . . . . . . . . . . . . . 13

2.2.1 Xilinx CORE Generator . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.2 Xilinx EDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.3 Xilinx System Generator . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.4 National Instruments LabVIEW FPGA . . . . . . . . . . . . . . . . . 15

3 XML-Based Meta-Data for Reuse 17

3.1 XML as a Meta-Data Format . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 CHREC XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

vii

3.2.1 Segment 1: The Structural Segment . . . . . . . . . . . . . . . . . . . 20

3.2.2 Segment 2: High-Level Datatype Segment . . . . . . . . . . . . . . . 20

3.2.3 Segment 3: Temporal Behavior . . . . . . . . . . . . . . . . . . . . . 21

3.2.4 Weaknesses of CHREC XML . . . . . . . . . . . . . . . . . . . . . . 21

3.3 IP-XACT and Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3.1 Parameterization and Mathematical Expressions . . . . . . . . . . . . 24

3.3.2 Ports and Structural Interface . . . . . . . . . . . . . . . . . . . . . . 25

3.3.3 Generator Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3.4 Modifying IP-XACT for FPGA IP . . . . . . . . . . . . . . . . . . . 28

3.3.5 Extensions for High-Level Datatypes . . . . . . . . . . . . . . . . . . 29

3.3.6 Extensions for Temporal Interface Behavior . . . . . . . . . . . . . . 31

4 Meta-Data Enabled Design Environment 33

4.1 A Structural Design GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2 Parameter Representation and Manipulation . . . . . . . . . . . . . . . . . . 37

4.2.1 Traditional Low-Level Parameterization . . . . . . . . . . . . . . . . 37

4.2.2 High-Level Parameterization . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.3 Parameter Dependencies and Translation . . . . . . . . . . . . . . . . 39

4.2.4 A Parameter Manipulation GUI . . . . . . . . . . . . . . . . . . . . . 40

4.3 Language-Specific Wrapper Generation . . . . . . . . . . . . . . . . . . . . . 43

5 Meta-Data Enabled H-SDF Synthesis Using IP 45

5.1 Numerical Datatypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.1.1 Representing Datatypes . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.1.2 Utilizing Numerical Types . . . . . . . . . . . . . . . . . . . . . . . . 49

5.2 Representing Coarse-Grained IP as H-SDF Actors . . . . . . . . . . . . . . . 50

viii

5.2.1 The H-SDF Model of Computation . . . . . . . . . . . . . . . . . . . 50

5.2.2 Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.2.3 Data Introduction Interval . . . . . . . . . . . . . . . . . . . . . . . . 54

5.2.4 Sample Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.2.5 IP-XACT Extensions for H-SDF . . . . . . . . . . . . . . . . . . . . . 55

5.3 Applying H-SDF Synthesis Techniques to Coarse-Grain IP . . . . . . . . . . 56

5.3.1 Translating Schematics to H-SDF Graphs . . . . . . . . . . . . . . . 57

5.3.2 Applying Iterative Modulo Scheduling . . . . . . . . . . . . . . . . . 59

5.3.3 Control Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6 Meta-Data Enabled Rapid Radio Development 65

6.1 A Highly Parameterized IP Library . . . . . . . . . . . . . . . . . . . . . . . 65

6.2 Manually Constructing Radios . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.3 Automatic Radio Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7 Conclusion: Productivity Gains from Meta-Data-Assisted Reuse 73

7.1 Productivity Increases Demonstrated . . . . . . . . . . . . . . . . . . . . . . 73

7.2 The Role of Meta-Data in Reuse . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

7.4 The Need for Increased Design Productivity . . . . . . . . . . . . . . . . . . 79

Bibliography 81

A CHREC XML Extensions to IP-XACT 85

A.1 Extending IP-XACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

A.2 Parameter Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

A.3 Port Description Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

ix

A.4 High Level Datatypes Extension . . . . . . . . . . . . . . . . . . . . . . . . . 88

A.4.1 Bit Vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

A.4.2 Integer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

A.4.3 Floating Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

A.4.4 Fixed Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

A.4.5 Custom Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

A.5 Behavioral Layer Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

A.5.1 Pipeline Depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

A.5.2 Data Introduction Interval . . . . . . . . . . . . . . . . . . . . . . . . 91

A.5.3 Sample Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

A.5.4 Signal Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

B Dataflow Interface Automata 93

B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

B.2 Definition and Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

B.3 Visualizing DIA’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

C The IP-XACT Extensions Schema 105

C.1 CHREC Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

C.2 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

C.3 High-Level Datatypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

C.4 H-SDF Interface Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

C.5 Port Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

C.6 Supporting Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

D Generated VHDL from Ogre 123

x

D.1 Top-Level VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

D.2 Finite State Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

xi

xii

List of Tables

4.1 High-Level Parameters Example for Loop Filter . . . . . . . . . . . . . . . . 39

6.1 IP-XACT Enabled IP Core Library for Communication . . . . . . . . . . . . 66

6.2 Productivity Gains With Ogre vs. Manual Creation . . . . . . . . . . . . . . 71

xiii

xiv

List of Figures

1.1 The Design Productivity Gap . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 A Basic FPGA Fabric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.1 A Generic Design Flow Using Meta-Data . . . . . . . . . . . . . . . . . . . . 17

3.2 Independent Segments of XML in CHREC XML . . . . . . . . . . . . . . . . 19

3.3 The IP-XACT Design Environment . . . . . . . . . . . . . . . . . . . . . . . 24

3.4 Datatype Mismatch Caused by Matching Bitwidths . . . . . . . . . . . . . . 30

4.1 Tool Flow for Creating Wrappers from Multi-Segment CHREC XML . . . . 34

4.2 The CHREC XML Design Composition Tool . . . . . . . . . . . . . . . . . . 35

4.3 High Level Parameters Translated to Low-Level Parameters . . . . . . . . . 40

4.4 Parameter Manipulation GUI Based on CHREC XML . . . . . . . . . . . . 41

5.1 The Ogre Tool-Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2 The Simulink Front End to Ogre . . . . . . . . . . . . . . . . . . . . . . . . 47

5.3 Tools Synthesis of Datatype Conversion Logic . . . . . . . . . . . . . . . . . 50

5.4 The Homogeneous Synchronous Dataflow Model of Computation . . . . . . . 51

5.5 H-SDF Initial Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.6 Design Represented as H-SDF Graphs . . . . . . . . . . . . . . . . . . . . . 58

5.7 Scheduling H-SDF Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.1 A QPSK System For Input to Ogre . . . . . . . . . . . . . . . . . . . . . . . 69

xv

6.2 Bit Error Rate Curves for Software Radios . . . . . . . . . . . . . . . . . . . 70

B.1 Deterministic Dataflow Interface Automata (DIA) . . . . . . . . . . . . . . . 94

B.2 Deterministic DIA With Control . . . . . . . . . . . . . . . . . . . . . . . . . 96

B.3 Non-deterministic DIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

B.4 Non-deterministic DIA for core with required clear . . . . . . . . . . . . . . 99

B.5 A DIA for an Upsampling Core . . . . . . . . . . . . . . . . . . . . . . . . . 100

B.6 A DIA for a Downsampling Core . . . . . . . . . . . . . . . . . . . . . . . . 101

B.7 Full Example of Dataflow Interface Automata Operation . . . . . . . . . . . 103

xvi

Chapter 1

Introduction: Design Productivity and Reuse

As the density of transistors on a semiconductor device continues to increase following

Moore’s Law, designers in the electronics industry have found it increasingly difficult to

utilize the increasing transistor density that is available on silicon devices. The disparity

between the capability of technology and the designer’s ability to utilize it is called the

“design productivity gap.” The increase in the design productivity gap has concerned the

electronics industry for several years. If the gap is not closed significantly, then despite the

improvements in technology the designs the industry produces will not scale at the same

rate as the technology upon which they are implemented.

The trends in productivity and device capability when viewed on their own are en-

couraging because improvements are being observed in both areas as shown in Figure 1.1 [1].

Figure 1.1 shows that there have been improvements in the productivity of engineers de-

signing systems to be implemented on digital hardware. The productivity improvements

are encouraging because the engineer’s productivity is doubling about every 3.5 years. The

steady increase in design productivity is due in part to the progression of tools (verification

methods, design entry methods, etc.) and the ability of designers to design systems at a

higher level (i.e., System-on-Chip). Figure 1.1 also shows encouraging advances in device

capability. The transistor density is increasing as predicted by Moore’s Law, doubling every

1.5 to 2 years.

While both productivity and device capability are improving, comparing the rate of

improvement of productivity and of transistor density reveals the design productivity gap.

For each year that designer productivity increases at its current rate, the transistor density

is increasing at more than double that rate. If this gap continues to increase at its current

1

Figure 1.1: The Design productivity gap for hardware systems [1]. The gap between produc-tivity and technology capability is increasing.

rate, the ability of electronic systems designers to utilize the increasing computing resources

on available platforms will not be able to keep up with the increases in density.

1.1 The Design Productivity Gap for FPGAs

The design productivity gap observed for digital hardware circuits also exists for

field programmable gate arrays (FPGA) and other reconfigurable devices. FPGAs “allow

the computational capacity of the machine to be highly customized to the instantaneous

needs of an application while allowing the computational capacity to be reused many times

for different applications” [2]. FPGAs offer a flexible design implementation solution that

occupies a niche between software implementations that run on a processor and application

specific integrated circuits (ASIC) and other custom silicon solutions.

FPGAs provide an array of customizable hardware blocks and programmable inter-

connect as shown in Figure 1.2 [3]. The logic elements and interconnect can be configured

repeatedly to implement many different hardware designs. Designing for FPGAs is like de-

2

signing software in the sense that in FPGA designs hardware description language (HDL)

code is compiled and then “run” on a the device. The compiled FPGA code represents a

set of configuration instructions that define the behavior of logic blocks and the interconnect

routing in the FPGA fabric.

Figure 1.2: A basic FPGA fabric. Interconnect and logic block contents are both pro-grammable. Dots on interconnect represent programmable connections between wires thatenable signals to route between logic blocks.

Data-flow systems such as digital signal processing are often straight-forward to im-

plement on modern FPGAs because of the natural mapping of these types of systems onto

the FPGA fabric. Because of the abundance of resources, DSP systems can be pipelined and

logically optimized to perform at high clock frequencies. The reconfigurable nature of FPGAs

also allows for data-flow systems to be quickly upgraded as technology demands change. This

work will focus primarily on increasing designer productivity in designing data-flow systems,

particularly on DSP and communication systems implemented on FPGAs.

3

Design productivity challenges for FPGAs are different from the productivity chal-

lenges facing the electronics industry in general. Historically the design challenges for FPGA

design have included meeting timing closure and making designs compact enough that they

will fit on the fabric of a single device. This was especially true for early FPGAs which had

such a small logic density that even basic designs or sometimes a single complex core easily

consumed all of the computational resource available on the device. However, in recent years,

as FPGAs and other reconfigurable devices continue to increase their computing capability

following Moore’s law, the design productivity problem has become more pronounced. The

increase in transistor density has enabled production of devices with many more logic ele-

ments. As the number of available logic elements increases, it becomes increasingly difficult

to utilize all available FPGA logic with a single design.

Low design productivity continues to be a primary barrier to the more widespread

adoption of FPGAs as a computing platform. Unless design productivity for FPGAs signif-

icantly increases, FPGA adoption will be limited to a relatively few dedicated application

and hardware development experts who have the skills necessary to create low-level FPGA

circuits.

1.2 Increasing Design Productivity

The International Technology Roadmap for Semiconductors (ITRS) [1] has outlined

several ways of addressing the increasing design productivity gap for digital semiconductor

systems as well as for FPGAs. These ways include migrating to platform based design,

improving and simplifying high level synthesis, and increasing intellectual property (IP)

reuse.

Platform-based design is essentially a form of component or IP reuse. Platform-based

design is “a meeting-in-the-middle process”, where “successive refinements of specifications

meet with abstractions of potential implementations and the identification of precisely de-

fined layers where the refinement and abstraction processes take place [4].” This means that

platform-based design simplifies the process of mapping a concept system onto an implemen-

tation by providing a large variety of functionality on a single circuit board or even in a single

integrated circuit package. Because of the large amount of pre-built design implementation

4

circuitry, the mapping of ideas to that circuitry as well as the design space exploration are

simplified.

High level synthesis is generally defined as the process of automatically creating dig-

ital circuits by starting with an abstract behavioral specification of a digital system and

finding a register-transfer level (RTL) structure that realizes the behavioral specification [5].

These abstract systems can be specified in a traditional software language such as C and

then translated into a high performance hardware system [6, 7]. High level synthesis gen-

erally maps behavioral specifications to small-sized low-level primitives such as adders and

multipliers. This is a powerful approach to increasing design productivity [5].

Design reuse is the process of designing robust verified, IP and reusing that IP in

future designs. Reuse increases design productivity by avoiding duplication of core design

effort. If a core has been used successfully in an application in the past, the effort spent

designing and testing that IP should not be duplicated when the same functionality is needed

for another application. Leveraging IP reuse to increase productivity is the primary approach

used in this thesis.

1.3 IP Reuse

Reuse of previously verified and tested soft and hard intellectual property (IP) has

long been touted as a primary method of improving design productivity [8] because there

already exists an enormous amount of previously verified and tested hard and soft IP in

the electronic design industry. Easy access to this IP and the ability to quickly and easily

integrate it into designs would drastically narrow the design productivity gap.

Despite the potential of reuse to increase productivity, reuse has been hampered be-

cause it is often difficult to reuse IP. In most current design environments and methodologies,

in order for a designer to successfully reuse IP the designer must 1) manually find and select

the appropriate IP, 2) understand the details of the implementation of the core, and 3) un-

derstand the interface and timing protocol used in order to integrate the IP into an overall

system. Control and interface circuitry often must be manually generated. This is a complex

and time-consuming process that must be done very quickly in order for reuse to be feasible.

IP also often comes from many sources and in many formats, making reuse an intimidating

5

prospect. In fact, in order for any reuse process to be feasible, the entire process must not

require more than 30% of the effort required to create the same IP from scratch [9].

Reuse based on standard platforms and formats has long been used in software en-

gineering and has resulted in significant productivity improvements [10]. Software reuse, in

the form of libraries, is so commonplace that most programmers do not even realize they are

in fact reusing IP when they program. Programmers are able to develop systems by simply

reusing previously developed IP from a library to implement their software system with little

or no knowledge of how the underlying implementation of the IP operates. It is this reuse

and standard method of representing software of IP that has most significantly increased the

design productivity level in software development [11]. The success of this reuse scheme and

the role of standard methods are important to remember as reuse schemes are developed for

hardware IP.

The issues to be overcome to facilitate reuse of IP for general hardware design are

somewhat analogous to those that have been addressed for software reuse. In most hardware

design and integration methodologies, hardware designers are required to operate at a very

low level of abstraction; traditionally design is done at the hardware description language

(HDL) layer. This abstraction level could be considered analogous to assembly or low-level

C that was yesterday’s design entry level for software engineering. HDL code for hardware

and C for software both require an understanding of the underlying hardware. Raising the

abstraction, even slightly, away from the RTL layer and allowing tools to translate from the

abstraction to HDL can contribute to design productivity for hardware just as high-level

compilers have done for software. This increase in abstraction would provide part of the

common reuse scheme that is currently lacking for hardware design.

Despite the difficulty of reusing arbitrary hardware IP, IP reuse has been success-

fully used to increase design productivity. Designers often reuse their own previously de-

veloped IP in other designs. Design paradigms such as System-on-Chip (SoC), in which

cores are integrated using well-defined bus interfaces such as AMBA, PLB (core connect),

and Wishbone [12], have also helped increase reuse. Tools such as Xilinx EDK [13], System

Generator [14], and LabVIEW FPGA [15] have also leveraged reuse to obtain productivity

improvements in a particular design space. Even though it is difficult to reuse arbitrary IP

6

in FPGA designs, design productivity has improved through direct IP reuse and through

select tools that leverage reuse.

1.4 Enabling Reuse with Meta-Data

Successful reuse of IP depends on having extra information about IP in addition to

its actual implementation code. Such extra information constitutes meta-data about a piece

of IP. Reuse of IP for FPGAs can be enabled by encapsulating IP in meta-data that describe

the interface and other details of a core in a generic way. Meta-data can be used to describe

basic interfaces and low-level details of a core. Meta-data can also be used to define a higher

level more abstract view of the IP. Meta-data encapsulation and abstraction can enable the

development of tools to automatically manipulate, instance, and interconnect cores within a

design thereby removing this responsibility from the human designer.

All hardware IP have similar characteristics that can be represented in meta-data. IP

is developed in many languages and comes from many different sources. Despite this variety

in representation and source all hardware IP are similar in their fundamental makeup. All

have input and output ports, all have some representation in an external file, all have a name,

etc. Many reusable cores also have parameters and these parameters’ values often depend

on each other. Much of the IP for FPGAs operates on numerical data and communicates

its data in high-level numerical types (i.e., fixed point or floating point). Capturing these

types of information in meta-data allows for the interface or external view of the core to

be represented in a standard way that is independent of any particular hardware design

language (HDL) or design environment.

1.5 Thesis Contributions

This work introduces several techniques that exploit the common elements of IP in

meta-data to increase design productivity of FPGA-based systems. The meta-data encap-

sulation can enable reuse by removing low-level IP implementation details from designers

and allowing them to design at a higher level. This higher level view can be achieved by

leveraging meta-data to enable tools to do many of the low-level design tasks that have tra-

ditionally been time consuming for human designers, such as interface and control circuitry

7

generation. This work will discuss and demonstrate several ways that this encapsulation can

be done and discuss the benefits of such meta-data encapsulation.

Toward this end this thesis contributes several techniques that enable the develop-

ment of tools to increase design productivity by exploiting novel meta-data encapsulation

techniques. The specific contributions of this thesis include the following:

• This work demonstrates the benefits of representing the interface components of IP in

a standard, language independent format by automatically composing complex systems

based on IP from several different languages. A structural design tool is presented in

Chapter 4 that demonstrates the ability of meta-data to enable this type of language

independent structural composition.

• This thesis demonstrates the ability of meta-data to simplify resolution of complex

IP parameters. Complex parameter resolution is facilitated by meta-data that de-

scribes IP parameters and their relationships via mathematical expressions. Chapter 4

demonstrates the ability of a tool to leverage meta-data to automatically create param-

eterization interfaces. This parameterization manipulation tool also leverages mathe-

matical parameter dependencies to ensure proper parameterization of cores with many

inter-related parameters.

• Much of the IP for FPGA operates on numerical values. This work contributes a

meta-data description of high-level numerical data types for data-flow IP that enables

tools to check and resolve numerical datatypes between connected IP. This datatype

description is used as part of a design tool named Ogre presented in Chapter 5 to

verify compatibility of types in data-flow systems. The meta-data descriptions enable

designers to know when datatypes need to be converted to avoid data corruption.

• Many systems that are implemented in FPGAs can be modeled with the homogeneous

synchronous dataflow (H-SDF) model of computation. This work contributes meta-

data descriptions that allow coarse-grain IP to be represented as actors in H-SDF.

These descriptions enable architectural synthesis algorithms to use coarse grained IP

as “primitive” operators in much the same was as more fine-grained IP (i.e., adders,

8

multipliers) are traditionally used. Chapter 5 will discuss how meta-data is used in

Ogre to enable synthesis of control and interface circuitry based on an iterative-modulo

scheduling [16] approach.

• To demonstrate the productivity improvements provided by meta-data and meta-data

enabled tools, this work presents a study of the rapid construction of digital commu-

nications radio receivers. Radio receivers were built using synthesis techniques with

reusable IP described in meta-data. This rapid construction, discussed in Chapter 6,

demonstrates the ability of the contributed meta-data descriptions to enable improve-

ments in designer productivity. For radios developed in this work, design time was

reduced from 3 days to under an hour.

This thesis addresses the need to increase design productivity for FPGAs by intro-

ducing meta-data that enables tools to perform much of the work that has traditionally

been required of human designers. A standard meta-data description of the structure of IP

interfaces allows tools to structurally interconnect IP from different languages and sources.

A robust parameterization resolution mechanism based on mathematical expressions allows

tools to ensure valid parameterization of IP. Meta-data that describes the high-level numer-

ical datatypes associated with the inputs and outputs of IP can allow tools to ensure correct

representation of communicated data. Meta-data that describes coarse-grain IP as actors in

a an H-SDF system enables synthesis algorithms to automatically construct control circuitry

for data-flow systems. These meta-data elements enable tools to significantly decrease the

design time for complex data-flow systems for FPGA.

9

10

Chapter 2

IP Reuse and Meta-Data Descriptions

Meta-data descriptions of IP are essential to enabling reuse. Meta-data is any infor-

mation describing an IP core that exists separately from the actual IP implementation code.

Meta-data can include in-code comments, human-readable documentation, and any other

extra information regarding an IP’s interface or internal operation. Meta-data enables reuse

by providing designers and computer aided design (CAD) tools with the information needed

to properly integrate a piece of IP into a complete system. Without meta-data, the designer

would be left with only the raw HDL code which may be difficult to integrate without the

extra information meta-data provides.

Various existing design approaches leverage IP reuse. All of these reuse approaches

have leveraged some type of meta-data to enable reuse and design composition. Traditional

HDL-based IP reuse requires meta-data in the form of in-code comments and written doc-

umentation to be successful. Tools such as Xilinx CoreGen [17] require meta-data that

describes the parameters for generating a particular piece of IP. Design composition tools

such as Xilinx EDK, Xilinx System Generator, and National Instruments LabVIEW FPGA

all require meta-data that describes the IP that can be used in these systems.

While there are existing tools that exploit reuse by using meta-data, the meta-data

in these approaches are all proprietary and limited to a specific tool environment. This

thesis introduces a more general approach to representing IP meta-data and demonstrates

the ability of this approach to enable the construction of design tools that simplify the task

of reusing arbitrary IP. This chapter will present the use of meta-data in existing reuse

approaches and tools. The development of a standard XML-based meta-data format for

describing data-flow IP for FPGA will be presented. The CHREC XML representation

11

format developed in this work will be discussed along with the transition in this work from

using CHREC XML to extending the IP-XACT [18] standard.

2.1 Meta-Data for HDL Reuse

The most common way to reuse IP is to simply reuse HDL code that was previously

developed in a new design. Meta-data is essential to enabling this type of reuse. Meta-data

for HDL reuse primarily consists of written documentation. This documentation describes

the purpose for the different inputs and outputs on the core. It describes the proper timing

protocols to be used to communicate with the IP. For FPGA design this documentation will

also often contain information about the timing and area characteristics for IP implemented

in a particular device. For open-source HDL IP, meta-data also comes in the form of in-code

comments and in readable well-written HDL code.

Highly parameterized IP requires comprehensive documentation to enable the de-

signer to properly reuse that IP. Many IP cores are highly parameterized because com-

prehensive parameterization of HDL-based IP significantly increases their reusability [19].

Parameters allow IP to used in a variety of situations with no manual changes to the core’s

internal HDL code. Without exhaustive documentation describing valid parameter values

and the affect of the parameter’s on the core’s operation, it can be difficult or even impossible

to reuse parameterized IP.

Inconveniences arise when trying to reuse a core that was developed in one language

in a system primarily based on another. Reusable cores are commonly written in VHDL,

Verilog or other languages and when reusing these IP wrappers must be manually created

to include the IP in the system’s language. Machine-readable meta-data could simplify the

task of integrating IP from multiple HDL languages by enabling the automatic creation of

wrappers in the designer’s preferred language.

Meta-data in the form of documentation and in-code comments is essential when

reusing HDL directly. While HDL itself is often human readable, if the designer only has

access to the HDL code and no accompanying documentation, reuse will be nearly impos-

sible. However if that HDL is accompanied with meta-data in the form of comments and

documentation, reuse will be simplified and possible.

12

2.2 Meta-Data in Commercial Design Tools

Commercial design tools often leverage reuse. These tools typically target a specific

type of user and design domain and attempt to make the design process simpler by providing

a library of IP with associated meta-data and a design environment capable of composing

cores from the library into complete designs. This section will discuss the use of meta-data

in the Xilinx CORE Generator tool, Xilinx EDK, Xilinx System Generator and National

Instruments’ LabVIEW FPGA.

2.2.1 Xilinx CORE Generator

Xilinx CORE Generator tool is a tool that generates reusable IP based on a set of user

parameter [17]. CORE Generator facilitates the delivery of IP cores by allowing designers

to generate IP in a language or format that enables their reuse in a vendor-specific design

tool. This type of tool is essential to reuse because it provides easy access to a large variety

of IP. IP from generation tools such as CORE Generator also tends to be well tested and

verified and therefore can be reused without requiring additional testing.

CORE Generator and other IP generation tools use meta-data to describe a particular

IP that is to be generated. This meta-data describes the variety of IP available for generation

and also captures the different variations that can be created for a core. Meta-data for these

generation tools may also include code templates for different output languages as well as

directives on how to implement specific parts of IP. For example, meta-data may describe

that VHDL is to be generated, provide a template for that VHDL, and direct that all names

are to be case-insensitive. Meta-data may also be used to describe project- and IP-specific

parameters and the values that should be used for generation. The CORE Generator tool

describes this type of parameterization in two meta-data files. The .xco file describes the

parameters for the current CORE Generator project. This includes data about the target

device, the HDL synthesis tool that will be used, the implementation language that should

be generated, etc. The .xcp file also describes parameter used in generation but these

parameters are specific to a particular IP. For example, for the CORE Generator’s FIR filter

these parameters include the number of taps for the filter, the pipeline depth that should be

generated, and the type of memory that should be used in the design. CORE Generator also

13

uses a set of IP-specific .tcl files to generate a GUI that allows a designer to parameterize

the IP. These .tcl scripts are also a form of meta-data.

Meta-data is essential to the CORE Generator tool. Meta-data provides all of the

necessary information to generate a core in any number of languages or formats. Without

this meta-data the reuse facilitated by generation tools such as CORE Generator would be

impossible.

2.2.2 Xilinx EDK

Both of the large FPGA vendors, Xilinx and Altera, have design tools that leverage

reuse of IP to create System-on-Chip designs. The Xilinx Embedded Developers Kit (EDK)

[13] is a good example of such a tool. Xilinx states that the EDK is “a suite of tools and

Intellectual Property that enables you to design a complete embedded processor system

for implementation in an FPGA device.” [13]. The EDK environment provides a way for

designers to quickly access hardware IP and to integrate it into a complete SoC system.

EDK accelerates construction of designs that have a processor, a communication bus, and

peripherals that communicate over that bus. In EDK the designer selects processors, busses

and I/O components from a library and uses these to create an SoC system. The EDK also

enables the designer to reuse software components in the SoC.

The EDK uses meta-data to describe the reusable IP. An example of the meta-data

in the EDK is the files required when using custom IP in the EDK environment. When

a designer imports reusable IP into the EDK system they are required to create two files

the microprocessor peripheral definition (MPD) and peripheral analyze order (PAO) files.

These files define the mapping between different bus interfaces in the EDK to the ports on

the reusable IP. These files make it possible for the EDK to recognize reusable IP. These two

files are meta-data that are necessary to reuse IP in the EDK.

2.2.3 Xilinx System Generator

In addition to the EDK, Xilinx also has the System Generator design environment

which is intended for design and deployment of DSP systems to FPGAs [14]. System Gen-

erator allows designers to choose from a large library of generated and hard IP and to stitch

14

them together using point to point connections. System Generator utilizes the Xilinx CORE

Generator [17] system for many of its blocks and also allows users to specify “black box”

components that can contain arbitrary IP. In order for System Generator to correctly gener-

ate synchronous systems, it requires that all cores are clocked and have a clock enable signal.

System Generator uses these signals to control the flow of data between IP in the system.

System Generator uses meta-data both for “native” IP from CORE Generator and

for arbitrary IP in black boxes. When using CORE Generator IP, System Generator requires

that there be a mapping between the ports of the generated IP and the graphical represen-

tation presented to the user. This mapping is done with .m code that defines which ports

are presented to the user and which signals are the clock, reset, and clock enable signals.

When using a black box the designer must create a .m file that specifies meta-data about

the IP to System Generator. This .m file defines the mapping between ports on the HDL

and the ports that are needed for the System Generator simulation and synthesis tools. For

example, if designing a clocked system, the .m file defines which ports on the IP are clock,

clock enable, and reset. In order to use any type of IP in System Generator, meta-data in

.m code is required.

2.2.4 National Instruments LabVIEW FPGA

LabVIEW FPGA from National Instruments [20, 15] is a design environment that

allows a domain expert to access the computational power of FPGAs by providing the

user with a set of easily understood operations in a graphical programming environment.

Because these operations are not necessarily hardware operations nor are they tightly coupled

to a specific piece of IP, there must be a mapping between the user operation and some

synthesizable IP.

LabVIEW leverages meta-data to define the mappings between the high-level descrip-

tion of the algorithm and operations and the low-level implementing IP. This meta-data is

not defined in a user-editable file; however, the user is able to use the IP without having to

worry about implementation details because those are understood implicitly by the tool.

Efficient IP reuse always depends on meta-data. Direct reuse of RTL is simplified by

having documentation and comments in code. Each of the tools discussed in this chapter,

15

CORE Generator, EDK, System Generator, and LabVIEW FPGA, utilize meta-data to

facilitate reuse. Each tool defines meta-data in its own format and the meta-data does not

always contain the same information. While these differences in format can make it difficult

to migrate IP from one tool to another, the meta-data is a primary enabler of the tools for

which it was designed.

16

Chapter 3

XML-Based Meta-Data for Reuse

Because of the importance of meta-data in reuse, it is important that standard meth-

ods of representing meta-data be developed. Standard meta-data descriptions can enable

design environments to be built that depend only on the standard to simplify and enable

reuse. A standard would allow these tools to not rely directly on HDL implementations or

on proprietary or tool-specific meta-data.

An example of an environment that depends only on standard meta-data is shown

in Figure 3.1. This type of design environment would require that all IP are wrapped

in standard meta-data format. This format would enable a generic, language- and IP-

source-independent, design environment to compose designs from meta-data wrapped IP.

This design environment could also produce designs in such a way that the result is reusable

again in a meta-data enabled environment.

Figure 3.1: Meta-data encapsulating of IP enables a generic design tool to reason with thecores and integrate them in a common framework.

17

Several research and industry projects have addressed different aspects of standard

meta-data encapsulation of cores. MetaRTL is a language that was created from scratch to

describe the protocol information for a piece of IP [21]. MetaRTL describes only a high-level

view of a core and does not translate directly to a common implementation format. The

dataflow interchange format (DIF) is a similar attempt to capture the semantics of data-

driven computation using blocks of IP [22]. While these specifications address some of the

meta-data needs for reusable IP, they require custom parsers and tools to understand and

manipulate that meta-data and have not gain widespread acceptance.

3.1 XML as a Meta-Data Format

Any meta-data standard for IP reuse should depend on commonly available languages

and software tools. Extensible markup language (XML) is a powerful mechanism for rep-

resenting meta-data. Because XML is the standard for data transmission on the web [23],

it has the advantage of being widely known and used. Its real power is that it is extensible

and in conjunction with XML Schema [24] can represent virtually any type of data. XML is

also a good choice for meta-data representations because there are existing tools for reading,

manipulating, and saving XML data in almost any programming language. This base of ex-

isting code enables engineers to easily develop design environments using common software

techniques without the need to interpret custom meta-data formats.

The development meta-data done in this work leverages XML. This development

was done in two stages with the second stage building on the successes of the first stage

and correcting its weaknesses. The initial meta-data development attempt was an XML

schema called CHREC XML. This schema was built completely from scratch and attempted

to address specifically the needs of FPGA IP. Before developing this schema, the emerging

IP-XACT standard was reviewed and it was decided that it did not sufficiently represent

the description needs of FPGA IP [25]. CHREC XML is introduced and briefly discussed

in section 3.2. Upon completion of CHREC XML and its associated tools, the updated

versions of IP-XACT were reviewed and the determination was made that many of the

inadequacies of earlier versions had now been corrected. Because of these corrections, this

work chose to continue its meta-data description efforts by leveraging the IP-XACT schema

18

and augmenting it slightly to suit the needs of FPGA IP. The IP-XACT schema and the

extensions developed in this work are introduced in section 3.3.

3.2 CHREC XML

The CHREC XML schema organizes the core meta-data into several distinct segments

of abstraction: the structural segment, the datatype segment, and the temporal interface

segment. Organizing IP meta-data in segments that represent different levels of abstraction

allows IP core providers and tool vendors to support the integration of IP at different levels of

abstraction and to do this integration independently of other meta-data segments as shown

in Figure 3.2. For example, low level tools such as a netlisting tool may require only low-

level information such as port naming and bitwidths. High level synthesis tools, however, are

better served with a more abstract, higher level view of the interface, datatypes and timing

information of a core.

Figure 3.2: CHREC XML defines separate “segments” that represent different parts of meta-data descriptions. These segments are independent of each other in their interpretation andimplementation. Tools that use this type of representation need only understand segmentsapplicable to their own operation.

19

Figure 3.2 shows the three CHREC XML segments. Each of the segments of CHREC

XML is defined and used independently of the other segments, and when implemented each

segment is defined in a separate XML file. The segmentation approach allows for additional

segments of encapsulation information to be easily added without the need to modify the

other, unrelated segments. CHREC XML also supports describing cores from any source

language or environment. The abstraction segments of CHREC XML is described in detail

as follows.

3.2.1 Segment 1: The Structural Segment

The Structural Segment provides all of the needed information to instance and use

cores in a basic composition environment and is very similar to the schema described in

[25]. The Structural Segment is responsible for IP library taxonomy and naming of IP.

This segment also includes the naming of ports and a mapping of these ports to the actual

HDL ports. It further includes a list of parameters for the core as well as mathematical

expressions and enumerated values that these parameters may depend on. This segment also

contains a list of files required to simulate or synthesize the core. The structural segment is

especially useful to low-level simulation and hardware synthesis tools whose primary purpose

is the structural interconnection of cores and low-level communication between them. This

segment of CHREC XML defines the primary meta-data elements that enabled construction

of the IP language and source independent design environment and the parameterization

manipulation and dependency enforcement tool discussed in Chapter 4.

3.2.2 Segment 2: High-Level Datatype Segment

The high-level datatype segment primarily defines and associates high-level numerical

datatypes with their bit-level implementations. Types are specifically defined for bit vector,

integer, fixed point, floating point, and custom types. Separate XML element sets specify

each type. Each high-level type defines the mapping between fields of that type and bits in

the underlying signal. This meta-data segment defines the relationship between fields and

bits for each type and lists each of the signals from the HDL segment that are of that type.

20

The datatype segment is independently useful to a tool which reasons about the

details of actually wiring cores together and preserving data integrity. Other details of the

core such as parameters and naming are not important to this type of tool. The data typing

of signals and the associated bit-based signals described in this segment allow the tool to

correctly match bits from one signal to another and to automatically perform any needed

conversions of datatypes.

3.2.3 Segment 3: Temporal Behavior

Very little of this segment was actually implemented in CHREC XML. Some initial

attempts were made to describe interfaces as finite automata as described in Appendix B, but

these proved to be overly complex. This segment of CHREC XML represent the pipeline

depth, or latency, of a core and provided a starting point for the further development of

interface descriptions in extensions to IP-XACT.

3.2.4 Weaknesses of CHREC XML

There were two primary weaknesses in CHREC XML.

1. Support for parameter dependencies and mathematical relations was complicated and

difficult to use.

2. The method used for representing the bitwidth of ports was inadequate.

The method of representing the mathematical dependencies between parameters was

weak in CHREC XML. This weakness came primarily from the complex nature of represent-

ing dependent parameters. There were several reasons that parameter dependencies were

complex.

1. Variables in expressions were based on parameter names. There is no way in current

XML to enforce matching between the contents of an arbitrary XML element and text

elsewhere in the XML file. Because of this lack of enforcement, it is impossible to

verify if the parameter names used in expressions actually exist as parameters in the

meta-data description.

21

2. The mathematical operations defined for CHREC XML did not take into account the

syntactical structure of XML. Only expressions involving +, −, ×, /, and = were

experimented with in IP described in CHREC XML; however, if an expression needs

to use > or <, these would cause syntactical errors in XML.

3. The method of doing conditional statements in CHREC XML was incomplete and

complex. It involved a long series of overly-verbose XML tags that were difficult to

understand and write.

XML 1 CHREC XML allows for bitwidths to be described as constant values. This doesnot allow for determination of which bits of the underlying bit-vector should be treated asthe most significant bits.<chrec:rtlCore>

. . .

<chrec:port>

<chrec:name>x</chrec:name>

<chrec:sourceName>x</chrec:sourceName>

<chrec:direction>in</chrec:direction>

<chrec:portWidth>

<chrec:bitWidth chrec:resolve="static">31</chrec:bitWidth>

</chrec:portWidth>

</chrec:port>

. . .

</chrec:rtlCore>

The representation of port bitwidths was also weak in CHREC XML. Bitwidths in

CHREC XML were represented by a single integer value as shown in XML 1. While this may

be adequate for some uses, it did not describe which bit in the signal was the most significant

bit. Even with attached numerical types, this discrepancy was not addressed fully because

the high-level type simply stated how many bits were in each portion of the signal. This

detail was overlooked in CHREC XML because an assumption was made that the left-most

bit was always the most significant. While CHREC XML did allow for bitwidths to be

represented as a VHDL-style vector (left downto right), the allowance was made for a single

value description of bitwidth. This allowance created an ambiguity in the description that

was difficult to reconcile.

22

When evaluating newer versions of IP-XACT after the completion of CHREC XML,

these weaknesses were used as some of the evaluation criteria. IP-XACT addresses these

weaknesses well, influencing the decision to migrate to IP-XACT as the basis for meta-data

descriptions.

3.3 IP-XACT and Extensions

IP-XACT is a standard XML schema which defines meta-data for describing reusable

circuit cores in a vendor and language neutral manner. The IP-XACT [26, 18] standard was

developed by The Spirit Consortium and standardized as IEEE 1685 [27]. Targeted primarily

for System-on-Chip (SoC) design, IP-XACT defines the busses, ports, configuration, and

properties of a reusable core to facilitate core reuse in higher-level designs. IP-XACT enables

tools to allow designers to drag-and-drop arbitrary complex IP into an SoC design and

automatically use third party tools to generate and verify SoC designs. This type of design

paradigm simplifies the process of reusing IP by enabling a domain expert to quickly and

easily integrate IP from any environment into a new design.

Figure 3.3 provides an overview of the IP-XACT strategy for SoC IP reuse. Reusable

cores in IP-XACT are defined as components in XML and exist in a library accessible by an

IP-XACT enabled design environment. A designer can select IP from this component library

and create complex SoC designs with relative ease. After composing the design, external

third party tools, generators, are run in sequence as defined by generator chains to verify,

simulate, and synthesize the design.

The strength of IP-XACT is in describing cores that are intended for use in System-

on-Chip (SoC) designs, which are typically characterized by a centralized processor that is

connected to peripheral devices via a standard bus structure [12]. More recently SoCs are also

characterized by network-on-chip interconnection schemes [28]. The common denominator

between all SoC designs is that they leverage a standard interconnection scheme and protocol

for inter-core communication. The IP-XACT standard is specifically designed to describe

this scheme.

While the intent of IP-XACT was to describe IP for SoC, many of the strengths of

IP-XACT are easily adapted to the description of data-flow IP typically used on FPGAs.

23

Figure 3.3: The IP-XACT Design Environment includes several different types of XMLdescription files that work together to provide design entry and HDL generation. This typeof a graphical representation of a library can be automatically generated based on taxonomygiven in meta-data.

The general strengths of IP-XACT for describing large libraries of cores include strong pa-

rameterization support, hardware port information, and descriptions of interactions with

external tools. This research extends IP-XACT by adding descriptions of high-level nu-

merical datatypes and a description of the temporal behavior of data-flow IP. The native

IP-XACT elements along with these extensions make IP more reusable and more accessible

to designers and domain experts.

3.3.1 Parameterization and Mathematical Expressions

The parameterization approach in IP-XACT addresses the weaknesses of the CHREC

XML dependent parameterization method by utilizing the standard XPath expression lan-

guage [29]. XPath is an expression language that is used by XML parsers to find particular

XML elements within a document. In general XPath expressions look very similar to hier-

archical paths that might be seen in a file system. The nature of XPath as an expression

language enables it to address the weaknesses of CHREC XML’s parameterization scheme.

24

1. XPath provides the ability to add an identification tag to any XML element. XML

validation tools enforce uniqueness on these tags. This uniqueness enables expressions

to reference variables based on their ID as defined in XPath and removes the need for

expressions to have their variables based solely on parameter names.

2. Because XPath defines syntax for expressions and because that syntax is meant to be

used in conjunction with XML documents, there are never collisions with XML syntax.

For example, instead of using > and < XPath uses &gt and &lt.

3. XPath provides a standard way for doing conditional expressions. These conditionals

are based on datatypes and use common operators such as “*” and “+” to determine

values based on conditionals. An example of this type of conditional in IP-XACT is

shown in XML 2. This expression means that if Sregsize ≥ 2 then the value should be

Sregsize else if Sregsize < 2 then the value should be 2. Although this representation

may not be immediately intuitive, it is standard and can be easily evaluated when

parsed by a tool.

XML 2 Definition of a dependent parameter value that is evaluated based on a high-levelparameter named Sregsize and has a default value of 2. This dependent parameter utilizesthe XPath expression language [29].<spirit:value spirit:resolve="dependent"

spirit:dependency=

"(id(’Sregsize’) &gt;= 2) * id(’Sregsize’) + (id(’Sregsize’) &lt; 2) * 2">2

</spirit:value>

3.3.2 Ports and Structural Interface

In addition to providing a standardized, robust, parameterization framework, IP-

XACT also provides information about the structural interface of a core. IP-XACT describes

the structural nature of the ports with several important elements: a name, a direction, a

width, and a low-level type.

25

Port Naming

IP-XACT defines several naming elements for ports. It defines a mapping between

the meta-data description of the port and the name in the actual HDL with the ‘‘display

name’’ and ‘‘name’’ elements.. The ‘‘display name’’ provides easy understanding to

the user. An extra description element is also provided. An example of the port naming

meta-data is shown in XML 3.

XML 3 A port description in IP-XACT. Elements of interest include naming and vectorelements as well as mathematical dependencies and low-level types.<spirit:port>

<spirit:name>preMu</spirit:name>

<spirit:displayName>Previous Mu</spirit:displayName>

<spirit:description>The value of mu from the previous iteration</spirit:description>

<spirit:wire>

<spirit:direction>in</spirit:direction>

<spirit:vector>

<spirit:left spirit:resolve="dependent"

spirit:dependency="id(’preMu_length’) - 1">18</spirit:left>

<spirit:right spirit:resolve="immediate">0</spirit:right>

</spirit:vector>

<spirit:wireTypeDefs>

<spirit:wireTypeDef>

<spirit:typeName>unsigned</spirit:typeName>

<spirit:typeDefinition>ieee.numeric_std.all</spirit:typeDefinition>

<spirit:viewNameRef>source</spirit:viewNameRef>

</spirit:wireTypeDef>

</spirit:wireTypeDefs>

</spirit:wire>

</spirit:port>

Port Direction

The direction of the port is essential when connecting IP together. Input ports must

be connected to output ports and vice versa. Is is also important that inputs are not driven

by multiple outputs. There is also the possibility of having bi-directional, in/out ports.

This information is especially important when attempting to enable automatic synthesis

26

and verification of point-to-point connections. IP-XACT provides this description in its port

description as shown in XML 3.

Port Widths

In addition to naming and direction, it is essential to know how many bits wide each

port is. Typical HDL is written at a level of abstraction that allows a single logical port

to contain multiple bits. This is also an appropriate level for representation in meta-data.

There are two basic pieces of information that need to be represented: the number of bits in

the port and which side of the port contains the most significant bit (MSB).

Both the number of bits and the MSB information is contained in IP-XACT in a

‘‘vector’’ element. The ‘‘vector’’ defines the left and right ends of the vector with an

integer. The greater of these two integers defines which end of the vector is the MSB and the

absolute width of the port is given by width = left-right. The values of left and right can

be parameterized to provide flexibility in implementation. An example of how port widths

are represented in IP-XACT is shown in XML 3.

Low-Level Types

For meta-data wrapping of certain types of HDL, the low-level type of the signal

is important. For example, if the IP being wrapped is VHDL, it is important to know

the VHDL bit vector type. It is important, for example to differentiate between a VHDL

std logic vector and a VHDL unsigned signal. This information allows connections to

be made with the proper VHDL or other low-level HDL types to ensure that a completed

system will compile and build properly. Not all core wrappers will require a low-level type,

but for typed HDLs this is appropriate to represent in meta-data.

3.3.3 Generator Chains

One of the primary advantages of using meta-data to encapsulate core details is that

cores from any source can be composed and manipulated in a common environment which

is aware of that meta-data. While this is a large advantage, if there is no way to compile

27

or convert the various IP into a common synthesizable language, the meta-data descriptions

and the accompanying environment are worthless.

IP-XACT addresses this need with “generator chains” as shown in Figure 3.3. A

generator chain in IP-XACT defines sequences of external tools that should be run in order

to convert IP from its HDL to a low-level standard format for implementation or simulation.

Each IP then can point to one or more tool chains. A single IP may be compatible with

several different generator chains depending on the end implementation. For example, a

generator chain for a piece of IP in VHDL that is intended for implementation on a Xilinx

FPGA might include tools such as XST, PAR, and Xilinx bit-gen. This particular chain also

defines commands to download a completed bit file to an FPGA device.

The overall goal of IP-XACT is to encapsulate IP in a vendor and implementation

neutral manner in order to facilitate reuse. System-on-Chip is the primary target for IP that

are supported by IP-XACT, which provides appropriate meta-data wrappers for this type of

design. Native IP-XACT allows SoC designs to be created from arbitrary IP in any language

from any environment and allows generic environments to be created to allow designers to

reason with these designs.

3.3.4 Modifying IP-XACT for FPGA IP

Because IP-XACT is designed to support SoC design, new methods are needed to

meet the description needs of arbitrary non-SoC IP for FPGAs. Two primary concerns

need to be addressed in this description. First, many designs that are typically targeted

to FPGAs consist of fine-grained IP. They do not tend to fit the SoC design paradigm but

tend to be data-flow designs such as DSP applications in which cores communicate through

computational data dependencies rather than communicating on a standard interconnect

bus [30]. Second, the increasing availability of FPGAs has driven the development of tools

that make FPGAs available to users without a digital hardware development background [15].

The SoC model is not suitable and may be too complex for simple use by many of these

domain experts. In order to make the computing power of FPGAs available to these domain

experts, reusable cores should be encapsulated in meta-data in such a way that they can be

easily used in a non-SoC system.

28

Both of these inadequacies in IP-XACT can be addressed by representing wrapped

IP at a higher level of abstraction using meta-data. The abstraction chosen for a particular

piece of IP should be appropriate to its intended use [31]. For many FPGA designs and cores

a DSP-compatible abstraction is appropriate.

Increasing design productivity by increasing abstraction is not new. The concept

of raising abstraction to increase productivity was also used when HDLs were originally

created [32]. Before HDL, schematic capture was used and designers often had to work at

a very low level, sometimes having to design with individual transistors. With HDL came

the ability to synthesize logic from a higher-level description without having to manually

construct the logic. The concept of raising abstraction to increase productivity can be

applied to existing HDL IP with proper meta-data wrappers.

The meta-data that is included in basic IP-XACT is fundamentally structural in its

encapsulation approach and does not significantly increase abstraction over a standard HDL

description. The structural description provided by IP-XACT can be supplemented and

expanded by using IP-XACT as a base description and adding high-level datatypes and

temporal behavior information as extensions to the schema. These additional description

elements are similar to those that were originally represented in CHREC XML and provide

a method of raising the abstraction level through encapsulation and are easily applied to

common FPGA IP used for data-flow computation.

3.3.5 Extensions for High-Level Datatypes

Many data-flow FPGA IP communicate numerical data. A difficulty with the IP-

XACT representation of ports is that it does not reflect this higher-level data typing. If

datatypes are nor represented, data corruption can occur between cores when only bit-widths

are required to match on connected ports. Figure 3.4 shows an example of this problem.

Here two 16-bit ports are connected to each other and the most and least significant bits are

properly aligned. However, by naively connecting these ports by bitwidth only, there has

been a data corruption; the 5.9124 that was transmitted has been interpreted as a 4.4781.

This problem becomes more pronounced when floating point or other complex types are

used. In order to ensure correctness of data transfer between cores with arbitrary interfaces

29

and to avoid the problem caused by naive bitwidth-only connections, higher-level datatypes

should be associated with port bit-vectors.

Figure 3.4: The two fixed-point numbers shown have the same bitwidth; however, if only thebitwidths are matched the data transferred between these types will be incorrectly interpreted.

This work extends the IP-XACT standard to include several numerical and other

high-level types that can be associated with signals. This research proposes meta-data

descriptions for bit vector, integer, fixed point, floating point, and custom datatypes. These

types are briefly discussed here and described in detail in Appendix A.

Bit Vector: Bit Vector types have no associated numerical data and are simply

represented as a vector of bits.

Integer: This datatype is basic for standard integer representations of any bitwidth.

It can describe unsigned, 1’s compliment, 2’s compliment, and signed magnitude integer

types.

Fixed Point: This type defines either a number of integer bits or a number of

fractional bits to be included. The total distribution of bits between integer and fractional

bits can be determined from either of these along with the entire bitwidth of the signal. All

of the cores used in the radios built in this study utilize the fixed point representation.

Floating Point: This datatype is highly parameterizable to represent possible divi-

sions of bits in floating point number representations. The floating point type is similar to

the IEEE standard for floating point representations. It has three fields, {1 sign bit}{k bits

for exponent}{n bits for fraction of significand} which can be arbitrarily mapped to bits in

the underlying signal.

Custom Types: Custom types contain a list of fields which associate a name and a

sub-vector of bits from the underlying bit representation.

30

These datatypes are used in the architectural synthesis tool presented in chapter 5 to

ensure that data transfer between cores is correct.

3.3.6 Extensions for Temporal Interface Behavior

Because IP-XACT was originally intended to describe IP that is used in SoC systems,

it does not have a mechanism for describing the temporal behavior of IP interfaces. There

are many ways of representing these interfaces and several methods have been developed

for representing IP interfaces mathematically. Finite automata, both deterministic (DFA)

and nondeterministic (NFA), have been used to describe the protocol and timing behavior of

cores with handshaking protocols which interface with various bus protocols. Several of these

include those discussed in [33], [34], [35], [36], [37], [38], and [9]. While these specifications

are important to many types of IP, they do not meet the requirements of data-flow DSP

and FPGA IP which tend to be data-driven pipelined computational cores and often do not

have handshaking type protocols. An attempt at creating an automata-based description for

DSP IP is given in Appendix B; however, there has not yet been an attempt to implement

this description or to describe it in meta-data.

This work attempts to match the temporal interface behavior of data-flow IP for

FPGAs to the homogeneous synchronous dataflow (H-SDF) model of computation. This is

done by defining three extensions to IP-XACT that allow IP to be described as actors in an

H-SDF graph. These parameters are latency, data introduction interval, and sample delay.

These parameters are important in creating a synthesis system that is able to apply archi-

tectural synthesis algorithms to systems composed of coarse-grain IP. A complete discussion

of these parameters and their use in architectural synthesis is given in chapter 5.

The meta-data formats described in this section, both CHREC XML and IP-XACT

with extensions, propose a standard way of representing meta-data to describe data-flow

FPGA IP. Because meta-data is important to reuse, it is helpful to have a standard way of

representing that meta-data. A standard mechanism enables tools to be built that can work

with the standard and thereby expand the number of IP that are reusable in a tool to all

IP that are described in this standard way. The following chapters will address such tools.

Chapter 4 will present a structural design tool and a parameterization manipulation interface

31

based on CHREC XML that demonstrate the use of standard meta-data. Chapter 5 will

present a different tool called Ogre that utilized IP-XACT and the high-level extensions to

enable architectural synthesis.

32

Chapter 4

Meta-Data Enabled Design Environment

This chapter presents a structural design tool that demonstrates the ability of the

meta-data developed in this work to represent the structural interface of FPGA IP in a

language and source independent manner. This tool enables IP cores from any language to

be instanced and connected independently of their underlying representation.

In addition to the ability to structurally interconnect cores, this tool demonstrates

the ability of meta-data to represent parameterization and the interdependency of param-

eters in IP in a standard way. The parameterization manipulation interface presented in

section 4.2 leverages meta-data descriptions to automatically create a custom parameteriza-

tion interface for individual IP. This GUI demonstrates the usage of parameter relationships

via mathematical expressions by automatically adjusting parameter values and the graphical

representation of the IP when a user makes adjustment to parameter values. This structural

design tool is based primarily on concepts developed in CHREC XML. However, the meta-

data enabled techniques demonstrated in this chapter can also be accomplished by leveraging

IP-XACT and the extensions contributed by this work.

4.1 A Structural Design GUI

Meta-data that defines a standard IP naming scheme and that represents the basic

structural interface of IP can be used as the basis for a language and IP source independent

design composition tool. To enable IP reuse, meta-data can define standard naming methods

that enable a designer to rapidly find desired IP. All hardware IP have common elements

in their structural interface. When these elements are represented in standard meta-data, a

tool can use these elements to represent IP to a designer in a language independent manner.

33

Meta-data can also enable design composition by defining the structural nature of IP input

and output ports.

In addition to enabling language and source independent representation of libraries

of IP, CHREC XML also enabled the building of a generic structural design tool. This

tool allowed a designer to structurally interconnect IP from the library and automatically

generate bitstreams for download to an FPGA. The structural interconnection of IP and the

use of tools to create completed, downloadable designs were enabled by meta-data.

The general flow for this structural design tool is shown in Figure 4.1. IP in any

language could be imported into the library. For VHDL cores, this research developed a

parser that automatically created much of the CHREC XML meta-data that was required

for representation in the library. Once this basic XML was created by the parser, the user

was prompted to add extra information not contained in HDL but required for a complete

CHREC XML description.

Figure 4.1: The CHREC XML schema supported a library structure, allowed for basic com-position of IP, and allowed appropriate vendor tools to be automatically run as generators onIP. The XML also enabled automatic generation of wrappers for the created core in multiplecommon languages.

34

Once IP was imported into the library, the CHREC XML meta-data allowed this

IP to be dragged and dropped onto a design canvas where their ports were connected as

shown in Figure 4.2. The graphical representation for the IP on the design canvas was

automatically generated by the tool based on the meta-data descriptions. The XML was

queried to determine the names and widths of the input and output ports and the graphical

representation was created based on this data. Because the GUI’s representation of cores

depended only on the meta-data in XML, any IP represented in XML could be used in this

structural composition GUI.

Figure 4.2: The GUI tool demonstrates the ability of CHREC XML to standardize descrip-tions for cores from multiple environments and enable them to communicate. The two matchedfilters in this design are from Xilinx CoreGen and the PLL circuit from JHDL.

35

Figure 4.2 shows the structural design of part of a QPSK demodulator in the composi-

tion GUI. This QPSK fragment used two filter circuits generated by the Xilinx CoreGen tool

and a PLL circuit created from JHDL. Because of the different representation languages and

sources of these IP, connecting them in a design would normally require significant manual

manipulation. However, because of the meta-data wrappers defined in CHREC XML, the

composition of these cores could be achieved in a straight forward manner. Once cores were

instanced in the GUI, each core icon showed the ports and the tool allowed the designer to

parameterize the cores (if parameters exist) and to connect ports graphically.

Once the designer had connected the cores in the GUI as desired, the entire design

could be synthesized and a downloadable bitstream created automatically. This was done

based on the file sets and the external tools that were defined as generators in CHREC

XML as shown in Figure 4.1. For the IP in the QPSK segment shown in Figure 4.2, the

Xilinx CoreGen tools were automatically run to create an EDIF version of the filter circuits.

The JHDL compilation tools were run to create a structural VHDL representation of the

PLL. These two cores were automatically instanced and connected in a top-level VHDL

file and this VHDL was then passed by the tool to the Xilinx tool chain. The tool issued

the commands to Xilinx to synthesize, place and route the design and generate a complete

bitstream.

The language and source independent design environment was enabled by meta-data

in CHREC XML. The meta-data enabled a standard representation of libraries of IP and

allowed that library to be easily searched. Structural composition of IP was also enabled by

the meta-data that allowed the design environment to represent IP graphically regardless of

its implementation language or source environment. While these demonstrations are simple,

they show the ability of meta-data to enable tools to organize IP from different sources into a

new design. Other tools could also be created that leverage the meta-data in CHREC XML.

One such tool that performs architectural synthesis based on IP described in meta-data will

be presented in Chapter 5.

36

4.2 Parameter Representation and Manipulation

In addition to providing the ability to structurally interconnect IP in a graphical envi-

ronment, the structural design environment also enabled core parameters to be manipulated

in a generic GUI. Because reusable IP tends to be highly parameterized, it is important to

be able to correctly set parameter values [19]. Two types of parameters were represented

in CHREC XML and in IP-XACT with extensions. Traditional low-level parameters such

as those traditionally included in HDL were listed in XML. Higher-level, domain specific

parameters that did no exist on the original HDL were also listed. Mathematical expres-

sions enabled the tool to set low-level parameters based on higher-level parameter values.

This section discusses the concepts of low-level parameterization, high-level parameteriza-

tion, the translation between levels enabled by mathematical expressions, and the parameter

manipulation GUI that utilized these types of parameterizations.

4.2.1 Traditional Low-Level Parameterization

Hardware cores have traditionally been parameterized with low-level parameters such

as bit-widths and operating modes which are typically represented in HDL. These param-

eters describe relatively low-level changes that can be applied to the core. This low-level

parameterization increases the reusability of a core by allowing it to be used in designs that

require different bit-widths. Low-level parameters typically defined by a name-value pair.

Their values typically have little or no direct dependency or affect on other parameters. Low-

level parameterization is quite common and is fairly simple to implement and meta-data can

represent this type of parameterization quite simply.

Traditional parameterization can significantly increase IP reusability for experienced

hardware designers; however, this low-level, HDL parameterization can be difficult to under-

stand and use for a non-hardware expert. Even experienced hardware designers still have to

understand the low-level implementation of the core in order to integrate it properly into a

system even when the IP has extensive low-level parameterization on a core. The designer

must understand how each of the parameters affects the other parameters and the core’s

behavior. Extensive low-level parameterization presents a greater challenge to a domain ex-

pert, the domain expert may be more confused by a highly parameterized core that has only

37

low-level parameterization. For example, a core with several parameterizable bit-widths that

the designer must manually select without a knowledge of how these will affect the operation

of the IP may be less attractive than a core with no parameterization at all [19].

4.2.2 High-Level Parameterization

Encapsulating low-level parameters in higher-level, more domain specific parameters

can further increase the reusability of cores without causing user confusion. Meta-data

can be used to create high-level parameters that did not exist in the original HDL but

which are more applicable and understandable to a particular domain. For example, for

IP for digital communication systems, high-level parameters that are readily understood by

communication systems experts could be defined. These high-level parameters allow the

designer to interact with the core at a higher level of abstraction and therefore increase the

reusability of the core. This reusability can also be realized both for the experienced hardware

designer and for the inexperienced domain expert. The need for experienced designers to

manipulate the low level details is removed and the ability of the domain expert to understand

the operation of the core is increased because the parameters are more familiar.

Examples of high-level parameters are shown in the Table 4.1 for a typical loop filter

core from the communications IP library developed in this work [39]. This is a simple

first-order loop filter consisting of a multiplier and an accumulator. This core has low-level

parameters for signal bit-widths and constant multiplication coefficients; however, high-level

parameters specific to communication receivers are presented in the meta-data wrapper. The

parameters shown in Table 4.1 are used to perform a non-trivial calculation which determines

both bit-widths and coefficients necessary for a given signal processing function.

In addition, this core contains a parameter named ‘‘samplesPerSymbol’’, which

allows the core to be quickly used in different radio personalities that each operate on a

different number of samples for each output symbol computed. Changing this parameter

fundamentally changes the core’s internal behavior and structure. This high level of param-

eterization significantly improves the ease of reuse for this IP by allowing users to quickly

adapt it to a number of similar but significantly different designs.

38

Table 4.1: High-level parameterization for loop filter core.

Parameter DescriptionloopBandwidth BnT used in calculating constant multiplicand valuesloopDampingFactor ζ used in calculating constant multiplicand valuesphaseDetectorGain Kp used in calculating constant multiplicand valuesaccumulationWidth Number of bits right of radix point for internal accumulatorkPrecision Number of fractional bits used for constant multiplicand valuesddsGain K0 used in calculating constant multiplicand valuessamplesPerSymbol Norder Loop order: first (no accumulator) or second (with accumulation)

4.2.3 Parameter Dependencies and Translation

Because not all IP is designed with high-level parameters, reusability can be improved

by providing a mechanism for enabling IP with robust low-level parameterization to be

parameterized at a high level in a meta-data wrapper. Once high-level parameters have

been set in meta-data they can be translated to more traditional, low-level parameters as

shown in Figure 4.3. High-level parameters can exist in meta-data alone and the meta-

data description itself can describe the relationship between derived high-level parameters

and actual low-level parameters on the IP. This type of dependency is supported by both

CHREC XML and IP-XACT which both provide mathematical dependency relationships

between parameters values.

Meta-data can be used to compute lower level parameters based on the higher-level

parameters defined exclusively in meta-data. For example, if low-level parameters for the

bitwidth of a core are available in HDL, meta-data wrapping that IP could present the user

with a parameter that asked for the minimum and maximum values expected by the IP. The

meta data could then define the mathematical relationship between this given parameter

range and the proper bitwidth parameter that should be set. The ability to parameterized

exclusively in meta-data allows higher-level parameters to be created that did not originally

exist for a core.

The encapsulation of complex, low-level parameters in higher level parameters and

accompanying mathematical relationships reduces the number of unique parameters that

39

Figure 4.3: The high-level parameters represented only in meta-data can be translated toexisting low-level, HDL parameters using mathematical and dependency relationships betweenparameters.

must be set by the user, while still allowing for powerful, deep parameterization. It should

be noted here that not all of the dependencies between high- and low-level parameters must

be expressed in meta-data—VHDL functions (in corresponding core module generators) may

also be leveraged for the computation of some low-level parameters.

Because IP can be extensively parameterized it is important for meta-data descrip-

tions to robustly support this parameterization. The meta-data developed in this work, both

CHREC XML and extended IP-XACT, supports parameterization. Both low- and high-level

parameters can be described in meta-data. The meta-data also describes the relationship

between these parameters methematically and allows higher-level parameters to be defined

exclusively in meta-data and be translated into low-level parameters.

4.2.4 A Parameter Manipulation GUI

A parameter manipulation GUI was created to demonstrate the ability of the CHREC

XML meta-data to represent parameters. The parameterization of IP used in this GUI was

often complicated with some IP having many interrelating parameters. Because of the meta-

data, the parameter manipulation tool was able to automatically set and correct parameter

40

values based on mathematical expressions was demonstrated by the parameter manipulation

GUI.

Figure 4.4: Each core instance can be individually opened and its parameters modified to fitit to a particular use. The parameterization manipulation window is automatically generatedon the fly from the meta-data descriptions.

The parameter manipulation GUI was generated on the fly from meta-data describing

IP that had been instanced in the structural design tool. After an instance had been created

for a core as shown in the GUI in Figure 4.2, the designer could “open” an individual instan-

41

tiated core and edit that core’s parameters as shown in Figure 4.4. The parameterization

interface shown in Figure 4.4 is the FIR filter that was used in the QPSK segment shown in

Figure 4.2.

Meta-data was leveraged to generate the left panel of the GUI shown in Figure 4.4.

This panel displayed the different parameters that could be changed by the user. The pa-

rameter names and their default values were extracted from the meta-data and appropriately

represented on the parameter panel. The GUI presented only the high-level parameters that

should be set by the user; all others were automatically calculated and set as defined in

XML.

The meta-data also enabled the tools to correctly represent the parameter input

method. Some parameter values could be typed in a field, while others required selecting

a value from a drop-down menu. This reflected the definition of valid parameter values as

defined in meta-data. In CHREC XML some parameters were allowed to fall in a given range

of numerical values. Other parameter values were to be selected from a set of choices. These

value types were reflected in the manipulation GUI with ranged numerical values being input

via a field and choices via a combo-box.

The mathematical expressions defined in meta-data were used by the GUI to ensure

proper parameterization of the IP. When users manipulated parameter values, the GUI

responded to these manipulations by altering other parameter values to ensure a valid core

parameterization. For example, when setting the parameters for the FIR filter shown in

Figure 4.4, if the value of the parameter CSETPassbandMin changed, then the minimum

valid value for the parameter passband max also changed. If the user had already set a value

for this parameter that is now outside of the valid range, the GUI corrected that value to

be within the range and notified the user. Other parameters that were dependent on user-

set parameters were also modified as the user changed the parameter values. Parameters

in some IP, especially IP from Xilinx CoreGen [17], affected which ports would exist on a

particular IP when it was generated. When these parameters were changed in the GUI, the

representation in the right panel of the GUI changed to reflect these changes. This right

pane also reflected changes in bitwidths of signals as parameter values changed.

42

The ability of the parameter manipulation GUI to represent parameters was based

solely on meta-data from CHREC XML. None of the manipulation GUI was specific to any

particular IP. The parameterization of IP from any hardware description language or IP

generated by a tool could be represented in this GUI because it depended on meta-data.

The GUI was able to update parameter values and change the graphical representation of

the IP because of the mathematical parameter relationships in CHREC XML. This type of

HDL-independent parameter manipulation is important to describing large libraries of IP

from different sources because it provides a common method for setting parameters based

on mathematical relationships described in meta-data.

4.3 Language-Specific Wrapper Generation

In addition to manipulation of parameters, the CHREC XML meta-data enabled the

tool to create custom wrappers for a single piece of IP and composed designs in a variety

of languages. The structural design tool allowed the designer to export this particular IP

with its parameterization in a VHDL, Verilog, or EDIF wrapper. The generation of wrap-

pers in multiple languages demonstrated the ability of the meta-data to represent sufficient

information to duplicate the interface of an IP core in any language.

Wrapper generation was performed by by querying the XML for port data and using

this data to create a proper wrapper in different languages. If the IP described in XML

had parameters, the tool was able to use this meta-data to properly set the parameters in

the appropriate wrapper languages. The tool also allowed the designer to export a CHREC

XML file that contained the current parameterization for a particular core and allowed the

designer to change the naming of the IP to reflect any customization that may have been

made. The generation of wrappers and the ability to export the core in several formats

all depended on the meta-data in CHREC XML. This meta-data allowed tools to generate

wrappers and run tools regardless of the original implementation language because all needed

data was encapsulated in the XML.

Meta-data enabled design composition and parameter manipulation in a language

independent manner. The tool presented in this chapter leveraged the CHREC XML de-

scriptions of IP to enable structural composition of IP. The graphical representation of cores

43

in the GUI was generated based on the XML descriptions. CHREC XML meta-data also

enabled the automatic generation of top level design VHDL and synthesis of complete de-

signs to bitstreams by automatically running vendor tools specific to different pieces of IP

in the design. Manipulation of parameters was also enabled by meta-data. The parameter

manipulation interface was generated based on meta-data descriptions and the mathemat-

ical dependencies in CHREC XML enabled the GUI to enforce validity of parameter sets.

Meta-data was the key factor in enabling these language- and source-independent design

methods.

44

Chapter 5

Meta-Data Enabled H-SDF Synthesis Using IP

As demonstrated in Chapter 4, it is relatively easy to instance, specialize (i.e., set

parameters), and connect arbitrary IP that is described using XML-based meta-data. This

type of structural design was simple because all of the data required to perform these tasks

was readily available in XML. This chapter introduces another tool that can compose FPGA

designs based on XML IP. This tool, however, operates at a higher level of abstraction and

uses meta-data to reason about correctness of data transfer between connected IP and to

automatically synthesize control circuitry for dataflow designs in FPGAs.

Traditionally control synthesis systems have used fine-grain IP such as multipliers and

adders as its primitive operators. When more coarse-grain IP have been used for synthesis,

the set of possible IP was often limited to a small set of IP that is native to the synthesis

tool. This work, however, allows any coarse-grain IP that is described in meta-data to be

used in synthesis thus allowing the set of operations for synthesis to include any arbitrary

IP from any source.

The addition of two primary types of information to a meta-data description for

FPGA IP were required for the construction of this synthesis tool: high-level numeri-

cal datatypes and temporal behavior specifications. Meta-data for high-level numerical

datatypes describes the datatypes that are represented on input and output ports for IP. This

information enables tools to assist a designer in ensuring that datatypes are correctly ma-

nipulated as data flows through a design. Meta-data specifying the temporal behavior of IP

allows tools to automatically synthesize control circuitry that enforces the proper sequences

of IP operation and ensures that no data is lost in communication.

This chapter will introduce a design tool known as Ogre that uses datatype and

temporal behavior specifications in meta-data to enable the synthesis of dataflow systems.

45

Figure 5.1: An overview of the Ogre System. There are four primary components: libraryrepresentation, translation of schematic information to H-SDF graphs, scheduling the H-SDFgraph, and synthesizing control and interface circuitry to create a complete downloadablebitstream.

The general flow of the Ogre system is shown in Figure 5.1. Ogre utilizes the Simulink

GUI and model file to represent models of systems composed of reusable IP as shown in

Figure 5.2. These models are understood by the underlying synthesis system which can then

reason about high-level datatypes and synthesize control circuitry. This chapter will discuss

the use of high-level datatypes to help a user properly match datatypes between IP in Ogre.

It will also present the method used by Ogre to leverage the H-SDF model of computation to

schedule IP operation and synthesize control and interface circuitry by leveraging meta-data

descriptions.

46

Figure 5.2: Simulink is used as a front end for design entry by the Ogre tool. IP blocksdescribed in IP-XACT XML are automatically included in a Simulink library and can bedropped onto the simulink design pallet to create complete designs.

5.1 Numerical Datatypes

The Ogre tool used high-level numerical datatypes to check for valid data transfer

between IP that have been connected in a design. Much of the IP that is used in data-

flow designs for FPGA operates on numerical data. Because of this, signals in data-flow

computations are also often meant to be interpreted as some type of number such as an

integer or a fractional number represented as fixed or floating point. When composing data-

flow designs and attempting to reuse IP, it is vital to know the mapping of bits in a signal

to the numerical data being represented by this signal. If this mapping data is not available,

blindly tying cores together will almost certainly result in incorrect data transmission. This

is especially important when working with fractional numbers and their fixed and floating

point representations. Ogre utilized the meta-data descriptions developed as extensions to

47

IP-XACT which define a standard way of mapping high-level datatypes to their underlying

bit-vector implementations.

5.1.1 Representing Datatypes

The extension to IP-XACT that allows for the representation of datatypes defines

mappings between high-level datatypes and the bits that implement those types on a partic-

ular signal. There are two components to this representation: the definition of the underlying

bit-vector and the mapping of these bits to a high-level type.

The bit-vector representation is contained in the meta-data description of each port

in XML. The port is defined by the XML ‘‘vector’’ element with the width of the port

being defined as the left side of the vector minus the right side of the vector (left− right).

XML 4 This code snippet shows an example of a high-level datatype extension. Thisexample shows a signed fixed-point type where two bits are used to represent the integerpart.<spirit:component>

. . .

<spirit:vendorExtensions>

<chrec:highLevelDataTypes>

<chrec:portDataType>

<chrec:name>SFix_2_a</chrec:name>

<chrec:fixedPoint

chrec:sign="2sComplement">

<chrec:intBits chrec:resolve="static">

2

</chrec:intBits>

</chrec:fixedPoint>

</chrec:portDataType>

</chrec:highLevelDataTypes>

. . .

</spirit:vendorExtensions>

. . .

</spirit:component>

The high-level type is defined separately from the description of the port. Each port

points to the high-level type that should be used to represent it allowing multiple ports to

be defined by the same type without the need to duplicate the description of the type. An

48

example of a high-level type definition is shown in XML 4. This particular definition is for

a fixed-point datatype. It defines that the two most significant bits should be interpreted as

integer bits and the rest of the bits of a signal should be interpreted as fractional bits. For

fixed-point datatypes it is also possible to specify the number of fractional bits that should

exist on a signal and assume that the rest are integer bits. The extensions to IP-XACT for

datatypes and the details of their implementation are discussed at length in Appendix A

and in [39].

5.1.2 Utilizing Numerical Types

The IP-XACT extensions developed in this research that describe high-level types

were used in the Ogre design synthesis system to assist designers in ensuring that datatypes

matched between IP. Ogre ensures first that bitwidths between IP match and then checks the

datatypes of these connections. If there is a mismatch, Ogre alerts the user to the problem.

Before Ogre checks data-types, Ogre first ensures that bitwidths match between IP.

Bitwidth matching is done by performing a traversal of the diagram starting at the inputs

and propagating the input bitwidths through the design. Mathematical relationships between

parameters and port widths enable the tool to properly set parameters to make bitwidths

match between IP. Once all bitwidth matching has been done, the tool iterates over all nets

in the design and checks that the high-level datatypes are compatible between the ports on

that net. If one of the ports does not match the others, an error is reported to the user,

advising the user of which net had the offending port.

Although the functionality of Ogre leveraged high-level types only for checking of

proper data connections, these meta-data defined types provide the ability for a tool to per-

form more sophisticated datatype synthesis. For example, a tool could leverage the datatypes

in meta-data to automatically synthesize datatype conversions between IP when it detects

that there is a datatype mismatch. When a tool detects a mismatch, a parameterized block

of IP could be inserted between the incompatible ports, making their datatypes compatible

as shown in Figure 5.3.

The high-level datatypes developed in this work are essential for any tool that will

automatically compose cores for data-flow designs on FPGAs. If the high-level numerical

49

Figure 5.3: Datatype-aware tools can use high-level datatype information to synthesize con-version logic between incompatible datatypes and thereby ensure correct data transmission.

datatypes are not defined, there will most likely be corruption of data as it moves between IP

in a design. The meta-data high-level types included in CHREC XML and in extensions to

IP-XACT provide the necessary mapping between the bits of an IP port and the high-level

type which that port’s data belongs to.

5.2 Representing Coarse-Grained IP as H-SDF Actors

In order to automatically compose arbitrary IP in a dataflow system, a description

of the timing behavior of the IP’s interface is required. If temporal core behavior for IP can

be matched to a particular model of computation, tools will be able to reason with these

cores and automatically generate control circuitry for designs. The meta-data proposed in

this work to describe timing behavior is based on the homogeneous synchronous dataflow

(H-SDF) model of computation [40]. This section will briefly describe the H-SDF model and

describe how meta-data implemented as extensions to IP-XACT enabled cores to be mapped

as H-SDF actors.

5.2.1 The H-SDF Model of Computation

The H-SDF model of computation defines the execution semantics for a system based

on the dataflow relationships between portions of the system. H-SDF is represented by a

50

directed, vertex weighted, graph G = {V,E}. Each vertex v ∈ V is called an H-SDF actor

and each edge (x, y) ∈ E represents the operation precedence between two actors.

The edges in E are used to enforce execution semantics on the H-SDF graph. For

example, the presence of edge (a, b) in G means that all computation must be done in vertex

a before vertex b can start its computation. Computation in H-SDF is done by the actors.

When an an actor performs a computation, it is said that the actor “fires.” The weight of

the vertex v represents the number of steps required for that particular actor to fire.

In addition to simply defining edges between vertices, H-SDF also uses the notion of

tokens to enforce semantics. Each edge in G can contain multiple tokens at any given time.

In order for any actor in H-SDF to “fire,” or perform computations, it must have an input

token on each of its inputs. If there are no input edges to an actor, it may fire at any time.

When an actor “fires” it produces tokens on all of its output edges.

(a) Actors A and B fire and pro-duce tokens on outgoing edges.

(b) Actor C fires consuming allinput tokens and producing anoutput token on outgoing edges.

(c) Actor D fires and consumesall inputs. Computation is nowfinished.

Figure 5.4: The homogeneous synchronous dataflow model of computation allows each nodeto “fire” when one token is available on each of its inputs. Each firing produces one token onthe node’s output.

Homogeneous synchronous dataflow is a subset of standard synchronous dataflow

(SDF) because when H-SDF actors “fire” they consume only one token from their inputs

and produce one token on their outputs. In general SDF, actors are allowed to consume and

produce multiple tokens when they fire(i.e., multi-rate dataflow). In this work H-SDF was

51

chosen as the model of computation because many single-rate systems can be represented

as actors that consume and produce single tokens when they perform computations. H-SDF

was also chosen because it is easier to use than general SDF.

Figure 5.4 shows an example of an H-SDF model and a valid sequence of actors firing.

Because actors A and B have no inputs they can fire at any time. When they fire, they each

produce tokens on their output edges. Actor C is allowed to fire once tokens produced by A

and B are both present on its inputs. When C fires, it also produces a single output token

which is consumed by actor D when it fires. Actor D’s firing completes a valid computation

from this H-SDF model.

(a) Invalid H-SDF initialconditions

(b) Valid H-SDF initial con-dition with one initial tokenin the loop

(c) Valid H-SDF initial con-dition with two tokens in theloop

Figure 5.5: A cyclic H-SDF graph must have proper initial conditions. Each cycle in the graphmust start with at least one token already on an edge in the cycle. The graph in figure 5.5(a) isinvalid because it has no such initial condition. Figure 5.5(b) shows the simple case of a validinitial condition with one token initially in the loop. Multiple initial tokens are valid as shownin Figure 5.5(c).

The H-SDF model of computation also supports cyclic data dependency graphs. How-

ever, when an H-SDF graph is cyclic, care must be taken to correctly satisfy the initial con-

ditions for the computation. For each cycle in an H-SDF graph there must be at least one

token on an edge in that cycle. If there is no token in the cycle, the computation will not

be able to start because no actor will have the needed inputs. Multiple tokens may exist in

the cycle or even on a single edge, but at least one token must be in the cycle. An example

of proper and improper initialization of H-SDF graphs is shown in Figure 5.5.

52

The execution semantics of H-SDF allow a static schedule to be computed for the

graph. This schedule will be a repeating schedule that defines the relative start times for

each of the actors. When using H-SDF to represent hardware systems, the schedule can be

mapped on to clock cycles for pipelined IP.

Because H-SDF enforces execution semantics on a dataflow graph, it is useful in

describing the execution of single-rate dataflow systems for FPGAs. If each IP core in a

system can be interpreted as an actor using H-SDF semantics, then the execution semantics

of H-SDF can be used to determine how the hardware system should execute by creating

a static schedule for the operation of IP in the system. This research defines three meta-

data elements that allow coarse-grain IP to be described in a way that allows them to be

interpreted as actors onto the H-SDF graph. This meta-data defines the latency, the data

introduction interval, and the sample delay for IP.

5.2.2 Latency

The latency of an IP core is the number of clock cycles that elapse from the time that

data is consumed on the inputs of the core to the time that the corresponding results are

produced on the outputs. This does not mean that the core is pipelined in the traditional

sense or that data can be accepted by the core on every cycle. For example, cores that accept

data only every 8 cycles and take 9 cycles to compute a result would be given a latency value

of 9.

When mapping a IP core onto an H-SDF actor the latency of IP is represented in

H-SDF graph by the weight of an actor. Because this weight defines the amount of time that

elapses while an actor is performing a computation, this weight can interpreted as the number

of latency clock cycles. This information can be used by H-SDF scheduling algorithms to

to determine the time that data will appear on the output of a core. The latency can also

allow synthesis algorithms to appropriately control IP downstream to wait until valid data

has been produced by the IP.

53

5.2.3 Data Introduction Interval

The data introduction interval for a core describes how many clock cycles must elapse

between the introduction of data for each new sample. Cores with a data introduction interval

of one can accept new samples each clock cycle. The data introduction interval of a core is

independent of its latency. For example a core that has a data introduction interval of 3 can

consume data on clock cycle 0 but then will not consume data again until clock cycle 3 and

then again on cycle 6. This same core may take 9 cycles to compute a result from a set of

inputs.

The data introduction interval imposes an additional constraint on the scheduling

algorithms that generate control for H-SDF execution. If tools are aware that a core can

only accept new data every n clock cycles, then any synthesized control circuitry must ensure

that data is given to a core only when it is able to receive it.

5.2.4 Sample Delay

Sample delay is perhaps the most complected parameter used to describe IP as H-

SDF actors. The sample delay is the number of cycle iterations separating an actor from the

downstream actors. In other words, the sample delay defines how many cycle iterations later

the data produced by an IP will be needed for computation. Sample delay is important when

IP are going to be used in a cyclic manner. For example, in the design shown in Figure 5.2

there is a cycle in the design. The sample delay defines the break between iterations of the

cycle.

Sample delay can also be thought of as the number of initial tokens in a cycle in an

H-SDF graph. If we consider a design to be represented as a H-SDF graph, we know that

there must be at least one initial token on an edge in the cycle in order to enable this loop to

execute properly according to H-SDF semantics. It is this initial condition that the sample

delay represents.The sample delay parameter indicates the number of H-SDF initial tokens

existing on the outputs of a particular IP.

Another way to conceptualize sample delay is that it represents the state generated

by the previous iteration of the loop. For example in Figure 5.5(b) the token that exists on

54

the arc ~ba represents the result of the computation done by the previous execution sequence

{a, c, b}.

This research chose to represent sample delay as a property of a piece of IP. While the

proper way of representing sample delay in cyclic models is an open research question, there

are several advantages to representing it as a property of a particular IP block. Representing

sample delay as a property of a block of IP is especially useful when IP cores are used

in situations that are closely related to their original design. When the sample delay is a

property of particular communications IP, for example, these blocks need only be inserted in a

cycle and the sample delay of that cycle is automatically satisfied. This type of representation

is also logical when thinking of sample delay simply as the state from the previous iteration

of the cycle. If the IP with the sample delay also has internal registers to maintain state,

these registers contain the result of all upstream computation in the cycle. This type of

representation, however, is now without its weaknesses. It breaks down if a core is used in a

situation that is not similar to its original use. This may cause the sample delay on the IP

to be in an incorrect location.

The demonstration avenue for these techniques was communication systems. IP that

are defined to have sample delay in these communication systems are rarely if ever used in

a situation different from their initial usage. There may be models, however, that require a

computation cycle but do not have any IP with an implicit sample delay. For this purpose, a

sample-delay marker that could be used in Simulink models was also created in this research.

5.2.5 IP-XACT Extensions for H-SDF

The meta-data description elements needed to represent coarse-grain IP as actors in

H-SDF was implemented as a set of XML elements called the ‘‘behavioral layer’’. This

set of elements was added to IP-XACT as a vendor extension. XML 5 shows the definition

of a temporal H-SDF interface as it appears as an IP-XACT extension. This particular

interface has a data introduction interval of 7, a pipeline depth of 8, and a sample delay of

0. This representation method allows sample delay to be represented as part of the IP core

and does not require the user to understand the complex concept of sample delay.

55

XML 5 Definition of temporal interface for H-SDF compliant cores.<chrec:behavioralLayer>

<chrec:dataIntroductionInterval>7</chrec:dataIntroductionInterval>

<chrec:pipelineDepth>8</chrec:pipelineDepth>

<chrec:sampleDelay>1</chrec:sampleDelay>

</chrec:behavioralLayer>

The IP-XACT extensions representing H-SDF interfaces enabled scheduling and syn-

thesis algorithms to be applied to IP that had this type of interface. These types of algorithms

allowed hardware to be automatically synthesized to control the flow of data between the

H-SDF cores.

5.3 Applying H-SDF Synthesis Techniques to Coarse-Grain IP

The description of coarse grain IP as actors in the homogeneous synchronous dataflow

model of computation allows traditional architectural synthesis algorithms to be used to

synthesize control logic for systems. Although the algorithms used for this synthesis have

been used before, the meta-data presented in this work enables coarse-grain IP to be used

as primitives in these algorithms.

There are several assumptions made in Ogre about the structural interfaces of the IP

that will be used to create designs. All IP must have a fixed latency and all inputs must

be consumed on the same clock cycle. The latency may be parameterized, however, once

a particular instance of the IP exists the latency must be the same for every computation

done by that core. Ogre also assumes that each IP has two control signals: clock-enable

and data-valid. These signals are used by synthesized control circuitry to properly start

and stop IP operation.

This section will describe the method used in the Ogre tool to leverage meta-data to

perform architectural synthesis. The Ogre tool leverages the Mathworks’ Simulink tool as

an input method for data-flow designs as shown in Figure 5.2. Once IP have been connected

in the Simulink GUI, the Ogre tool can parse the .mdl file and use the meta-data describing

the IP to perform synthesis of complete designs. An overview of this synthesis flow is shown

in Figure 5.1. Details of the synthesis flow will be described in this section. The method of

56

constructing an H-SDF dataflow dependency graph will be presented as well as an overview

of the iterative modulo scheduling algorithm that was used as a first step toward creating

control circuitry. The method of converting schedules to finite state machines will also be

presented.

5.3.1 Translating Schematics to H-SDF Graphs

Before architectural synthesis algorithms could be applied to systems composed of IP

described in meta-data, the interconnection of the IP were represented as an H-SDF graph.

This translation used the structural interconnection between IP described in the Simulink

GUI and the meta-data describing each of the blocks to create the H-SDF graph.

An intermediate netlist data structure was used as part of the translation that repre-

sented the connectivity of the complete design. This netlist structure, shown in Figure 5.1

as the Ogre Netlist, represented all of the data that was contained in the extended IP-XACT

meta-data. The netlist structure was connected to a library of IP meta-data that it queried

to determine the structural interface of a core, its parameters, its datatypes, and its temporal

behavior. Each of these description elements was encapsulated in an “instance” of each core

in the design. Each of these instances contained ports that could be connected in the netlist

structure to represent a full or partial design.

The first step in translating a Simulink model file to an H-SDF graph was to populate

the Ogre netlist structure with instances of the IP that were in the design and to connect the

data ports as represented in the model. Many of these IP were parameterized, and the pa-

rameter values set in Simulink were translated into the IP instance in the Ogre netlist. Once

parameter values were set, Ogre verified the correctness of the provided parameter set by

using the mathematical expressions provided in the meta-data. Once these parameters were

validated, mathematical expressions were used to properly set all of the low-level parameters

on each of the IP instances.

Datatype checking was a two-step process. First the bitwidths were set to be com-

patible across the design. The bitwidths set by the user on the input ports in Simulink were

used as a starting point to propagate the bitwidths throughout the design. Many of the

IP used had parameterizable bitwidths. Because of this parameterization, making bitwidths

57

compatible was often a simple matter of setting the correct parameter to match bitwidths.

When parameters could not be set to correctly resolve bitwidths, Ogre would report this

to the user who would have to resolve the conflict. While resolving bitwidth values in the

design, Ogre also checked for conflicting high-level datatypes. Mismatches identified using

the datatypes defined in meta-data were also reported to the user.

(a) The initial translation of design to H-SDFrepresents initial conditions (sample delay) asa distance on the edge after the IP with thesample delay. Node weights reflect the latencyof IP.

(b) After scheduling, nodes are annotated withthe start time determined by the iterative moduloscheduling algorithm.

Figure 5.6: The 2 H-SDF graphs shown here represent the graph that is created to representthe design shown in Figure 5.2. Before scheduling, only weights and sample delay are presenton nodes. Scheduling applies a start time to each node.

Once the Ogre netlist was completely populated from the Simulink description, an

H-SDF graph was produced that represented the temporal behavior of the computation

system defined in Simulink. For each of the instances of IP in the netlist an H-SDF actor

was created. The weight of this actor was the latency of that particular IP. For each wire

in the netlist the corresponding edge was created in the H-SDF graph. These edges were

58

weighted according to the sample delay description of their source actor. Because sample

delay occurs infrequently in blocks, the weight of most edges was 0. Input and output ports

were also represented as actors but their weight was always 0. They were include only as a

means for determining consistent starting position for the scheduling algorithm discussed in

subsection 5.3.2.

An example of the result of this translation is shown in Figure 5.6. This particular

example shows the H-SDF graph that results when the design shown in Figure 5.2 was

translated to H-SDF. Note the translation of the pipeline depth to the latency or weight of

each of the nodes. Also note that because the “nco” has a sample delay value of 1 there is

a weight of 1 applied to the edge from the “nco” to “CMult1.”

The translation from dataflow block diagram to H-SDF graph was enabled by the

Ogre netlist structure that was based on meta-data contained in the extended IP-XACT

specification developed in this work. This meta-data allowed a simple H-SDF graph to be

created that represented coarse-grain IP from a library to be represented as actors in H-SDF

and allowed a correct representation of the connections between them in the data path of a

design.

5.3.2 Applying Iterative Modulo Scheduling

The H-SDF model of computation defines its execution semantics, but the implemen-

tation of these semantics must be properly represented in hardware in order to produce a

working design. As a first step in translating the semantics of H-SDF to hardware, Ogre

applied a scheduling technique to determine the relative start times of each of the IP in

a design based on a global clock signal. Ogre used an iterative modulo scheduling (IMS)

approach to this schedule as described in [16].

The IMS algorithm described in [16] was intended for general scheduling of multi-cycle

actors onto available processors. Ogre simply needed to determine the clock cycle that data

would be ready for each IP to use to do computation. The power of IMS for this use was that

IMS computed a minimum initiation interval (II) for cyclic H-SDF graphs. The initiation

interval was the number of clock cycles that must elapse between times that the design was

able to consume new data. Minimizing the initiation interval was important because lower

59

initiation intervals corresponded to higher throughput for cyclic data-flow designs. Because

many of the designs developed for this work were cyclic in nature, this was an appropriate

algorithm choice.

(a) Most common scheduling algorithms require that a completed compu-tation iteration be finished before beginning another. The II produced bythis type of scheduling generally does not produce the minimum II, in thiscase the II=8

(b) The IMS schedule allows for iterations of a loop to overlap each other.Each color represents the progression of a complete computation throughthe H-SDF Graph. This produces a schedule with a II=4 which is muchbetter than the minimum possible for the H-SDF graph shown in 5.6(a)

(c) The kernel of theIMS schedule repre-sents the repeatedstart times for IP ina cycle.

Figure 5.7: Scheduling possibilities for the design shown in Figure 5.2 and the H-SDF graphshown in Figures 5.6(a). Scheduling algorithms determine the start times for H-SDF actors.The iterative modulo scheduling algorithm defines the start times for IP in a kernel that allowsiterations of a cycle to overlap and computes the minimum initial interval for an H-SDF graph.

Many scheduling algorithms, when applied to cyclic H-SFD graphs, did not allow for

the minimum initiation interval. For example, many algorithms required that a complete

computation through the graph be complete before beginning a new computation as shown

in Figure 5.7(a). IMS allowed a schedule to be created that overlaps different computational

iterations as shown in Figure 5.7(b). To produced this type of a schedule the sample delay

characteristic of IP was very important. Because sample-delay in H-SDF represented initial

60

values available to an actor, IP that are downstream from a sample delay could be scheduled

before nodes that came before them in strict dataflow. The schedule in Figure 5.7(b) is

the generated schedule for the H-SDF graph shown in Figure 5.6(a). Notice that in the

schedule in Figure 5.7(b) “CMult1” started before the “nco” even though the dataflow edges

in Figure 5.6(a) seem to require that the “nco” run first.

The IMS algorithm computed a schedule “kernel” that described the repetitive sched-

ule that should be used to continually operate the H-SDF graph properly. An example of

this kernel is shown in Figure 5.7(c). The ability of sample delay to allow IMS to fold long

schedules into shorter schedules allowed Ogre to compute the minimum II for a H-SDF graph.

This minimum II allowed for maximum throughput on data-flow hardware designs. Once

Ogre had completed the scheduling process through IMS, the nodes of the H-SDF graph

were labeled with their start times as shown in Figure 5.6(b). The schedule kernel produced

by IMS allowed control circuitry to be created to control the passage of data through the

hardware.

5.3.3 Control Synthesis

Once a schedule had been generated for the design, this schedule could be used to

generate control circuitry for the system. The Ogre synthesis system used the schedule

generated by the IMS algorithm to create a finite state machine (FSM) that controlled when

each of the IP in the design was active. By ensuring that IP are active only during their

scheduled times, this FSM was able to ensure that data moved between IP during the correct

clock cycle.

The FSM generated by the Ogre system assumes that clock-enable and data-valid

signals exist on the IP. Which hardware ports on the IP correspond to these types of signals

was described in meta-data. The FSM controlled the flow by properly manipulating the

values on the clock enable and data-valid signals. When the schedule indicated that an

IP should start, the FSM would raise the data-valid signal for a single clock, signaling to

the IP that it should begin computation because there was real data on its inputs. This

data-valid signal often was connected to an enable signal on the first bank of pipeline

registers in the IP block. In addition to starting the computation with the data-valid

61

signal, the FSM raised the clock-enable signal on the IP for each of the clock cycles that

the IP should be running as determined by the length of the schedule time.

Ogre synthesized the FSM and other interface circuitry in VHDL. When synthesizing

the FSM, a VHDL file was produced to implement the proper behavior. The FSM was also

added to the Ogre netlist structure as an instance of a component. The FSM was connected

to the proper signals in the netlist based on the port names determined from the meta-data.

Once the FSM had been connected to the IP in the system, global clock and reset signals

were also added and connected to IP as needed. An example of the generated VHDL for a

state machine is shown in Appendix D.2.

At this point, the Ogre netlist structure represented a complete and correct hardware

design. Synthesizable VHDL was automatically created from the netlist structure. The

data path between IP was created and the control from the FSM was connected in VHDL.

This generated, top-level VHDL file was then passed to a traditional synthesis flow to cre-

ate a downloadable bitstream. An example of the generated top-level VHDL is shown in

Appendix D.1.

Creation of the synthesis algorithms used in Ogre was possible because of the meta-

data in IP-XACT with the extensions describing datatypes and temporal behavior. Meta-

data enabled data-flow designs captured in Simulink to be translated into a structural netlist

in Ogre. This netlist and the meta-data was then used to create an H-SDF graph that

enabled the IMS algorithm to produce a schedule that minimized the II for the design. The

IMS schedule was used to synthesize a finite state machine that ensured that data moved

through the design correctly. This FSM was included in a top-level VHDL file that could be

synthesized to a bitstream and downloaded to an FPGA.

Ogre demonstrates the ability of meta-data to enable tools to increase design produc-

tivity by performing tasks that are traditionally required of human designers when reusing

IP. Using Ogre, a designer no longer has to manually create control circuitry to ensure correct

flow of data. The designer does not have to worry about bitwidth and datatype correctness.

While Ogre may not be suitable for all types of designs, the ability of Ogre to synthesize

fully functional data-flow designs shows that meta-data can enable tools that can increase

design productivity by performing complex architectural synthesis.

62

Several radio receivers were developed using the Ogre system. This development

leveraged a library of IP cores that were described in IP-XACT and that were able to be

used as H-SDF actors. Ogre was used to develop several different radio personalities. The

development of radios in Ogre and the design productivity improvements observed in this

development will be presented in the next chapter.

63

64

Chapter 6

Meta-Data Enabled Rapid Radio Development

To demonstrate the usefulness of the Ogre design environment and show the potential

design productivity gains, several radio designs were developed. These designs were based on

a library of IP and the designs were created both by hand in VHDL and by using the Ogre

synthesis system. The results of this radio construction demonstrate that the meta-data,

in particular IP-XACT extensions, and the accompanying Ogre design flow reduced design

time for the selected radios from a few days to less than an hour per radio.

To further test the flexibility of the meta-data and the Ogre synthesis system, seven

different QPSK designs, each of which use a different set of IP and occupy a different location

in the area/time trade-off space were created. This variety of designs demonstrated the

ability of Ogre to support rapid design space exploration and find a variety of solutions to a

problem instance by automatically handling many of the timing details for the designer.

6.1 A Highly Parameterized IP Library

The design of digital radio receivers was chosen as the demonstration vehicle for

this work because of the close correlation of digital radio designs to the H-SDF model of

computation. To that end, a library of building blocks suitable for the creation of a variety

of radio personalities was developed. The blocks were first created as parameterized VHDL

modules. The development of these modules and the decisions about how to parameterize

and partition the IP took approximately 3 months.

Meta-data descriptions of the IP cores were created in the IP-XACT with extensions

discussed in Chapter 5. The temporal characteristics of the cores were specified to facilitate

their use within the H-SDF model of computation. High-level datatypes were also used to

describe the input and output data for the IP.

65

Table 6.1: A listing of different versions of blocks that were created and their timing/areacharacteristics. Latency is measured in clock cycles and is therefore omitted in

combinational versions which have no input clock. Block Delay is the totaltime from when the input is presented to when the corresponding output

appears. (These results are based on a Virtex 4-SX35 FPGA.)

Block Type Latency Block Delay Max Freq. Area

(cycles) (ns) (MHz) Slices DSP 48s

Cubic Interpolators 16 43.8 365 119 1

9 54.6 164 156 4

8 43.1 185 53 12

0 34.5 N/A 22 12

Decision (QPSK) 0 0.9 N/A 0 0

Timing Error Detectors 0 9.6 N/A 53 2

1 12.5 159 53 2

2 10.5 284 55 2

Loop Filters 0 11.1 N/A 66 5

2 18 167 74 5

3 18 223 74 5

NCO 0 3.1 319 53 0

Calculate Mu 0 1.7 567 55 0

Phase Error Detectors 0 5.5 182 15 2

1 5.9 338 17 2

Clockwise Rotations 0 5.4 183 12 4

1 5.3 371 13 4

DDS 1 8.5 235 58 0

66

The radio receiver personalities targeted in this research include QPSK, Offset QPSK,

PCM/FM, 16QAM, 8PSK, and 16APSK, although other desired constellations may also be

possible with slight adjustments to the developed block set. The creation of the block

set took advantage of the fact that there are many recurring blocks in these different radio

types [41]. These recurring blocks include interpolators, timing error detectors (TEDs), phase

error detectors (PEDs), loop filters, direct digital synthesis (DDS) blocks, and numerically

controlled oscillators (NCOs). A list of some of the created blocks and their functions is as

follows:

Clockwise Rotation: Rotates a complex signal by a certain angle, determined by

sine and cosine inputs.

Interpolator: FIR filter which outputs an approximation of the desired sample based

on available sample values.

Decision Block: Finds and outputs the constellation point for a given modulation

scheme that is closest to the processed input value.

Timing Error Detector: Computes the sample timing error. The rest of the blocks

in a typical timing loop attempt to drive this error to zero.

Loop Filter: A proportional-plus-integrator filter. This is commonly used to smooth

the output error signals coming from the TED and PED cores.

Numerically Controlled Oscillator: Part of a typical timing loop control; generates

control signals for TED and PED.

Calculate Mu: Generates fractional interval, µ, typically for use by an interpolator.

Phase Error Detector: Computes a sample phase error. The rest of the blocks in a

typical phase loop attempt to drive this error to zero.

Direct Digital Synthesizer: Generates sine and cosine outputs based on an input

phase value.

67

One of the goals of this work was to support the exploration of cost/performance

points in the overall solution space for each radio personality selected. Thus, multiple ver-

sions of each block were designed which differ in their temporal behavior as well as in their

timing and area characteristics. For each block there are combinational versions as well

as heavily pipelined versions to facilitate different radio implementation requirements. In

addition, the various blocks exhibit different data consumption rates based on their internal

design. Table 6.1 lists the blocks in the library and their variations. For example, four cubic

interpolator blocks are available to support a range of latencies, clock rates, and resource

requirements.

6.2 Manually Constructing Radios

The meta-data enabled library of cores was used to manually construct two different

radios in VHDL. This was done by manually selecting IP from the library, manually deter-

mining the proper datatype conversions between the IP, and manually creating a finite state

machine to control the flow of data through the design.

The first manually build VHDL design was a basic combinational QPSK demodulator

which consumed one data sample per clock cycle. Construction of the combinational QPSK

radio was fairly straightforward. Connecting the cores in VHDL, it took about a day to

produce a working radio that could run on hardware with a zero bit error rate. This radio

test was fairly uninteresting, but it proved that the VHDL cores were functionally correct.

The second VHDL design was more difficult to create. This design consisted of

pipelined versions of many of the cores and was thus able to run at a much higher clock

rate. However, the pipelined cores increased the complexity of the radio design because of

feedback in the design and the difficulty of aligning data dependencies in the loop. After

determining the desired timing and sequencing required, a finite state machine controller was

created manually to control and sequence the blocks in the new design. Finally, a number

of manual design iterations were required to find a solution in the design space which was

able to meet both sample and cycle-level timing. The final design required 15 clock cycles

per loop iteration (input sample) and the design time was approximately three days.

68

Figure

6.1:

Asi

mp

leQ

PS

Kra

dio

blo

ckd

iagr

amin

Sim

uli

nk

that

can

be

use

din

Ogr

e.T

he

colo

ron

the

wir

essh

ows

the

loca

tion

of

the

sam

ple

del

ayb

lock

s.N

ote

that

only

dat

ap

ath

sign

als

are

con

nec

ted

inth

ed

iagr

am.

Con

trol

sign

als

nee

dn

otb

eco

nn

ecte

d.

Th

eBYUInterfaceSynthesis

blo

ckp

rovid

esac

cess

toth

eO

gre

syst

em.

69

Figure 6.2: Bit error rate tests were performed on the generated and hand built radios toverify correctness.

6.3 Automatic Radio Generation

The same radio designs that were created by hand were also implemented in Ogre

along with several additional radio personalities. The first design created using the Ogre

tool flow was the combinational QPSK receiver. The design time, which was a day for the

hand-connected design, was reduced to less than an hour when using the tool. The blocks

were simply interconnected in Simulink, and the Ogre tool completed the design. This

implementation also had a zero bit-error rate.

The pipelined version of the QPSK receiver discussed above was also implemented

using the Ogre design environment (see Figure 6.1). Ogre enabled the production of a

functional radio in less than an hour, a significant improvement over the previous three-day

design time. Not only was design productivity improved, but the loop schedule or latency,

which was 15 clock cycles in the hand-built design, was shortened to 13 cycles without a

decrease in reachable clock frequency. This decrease in loop latency was due to the IMS

scheduling used in Ogre [16].

70

Table 6.2: Design time comparisons between radios created by hand and generated radios.

Design Time

Radio Types By Hand Generated

QPSK (comb) 1 day < 1 hour

QPSK (pipelined) 3 days < 1 hour

BPSK Did not build < 1 hour

8PSK Did not build < 1 hour

16QAM Did not build < 1 hour

Design space exploration was also facilitated by this rapid design generation. Instead

of taking a few days to get one design working, it was now possible to get many designs

working in a single day. This drastically changed the design process. The question changed

from “How can I get this combination of cores to function correctly?” to “Which core

combination is best for my application?”

The Ogre system was also leveraged to rapidly create an entire suite of radios with

different characteristics while further demonstrating short design times and high productiv-

ity. Using the entire reuse system, this research was able to produce seven different QPSK

implementations, a BPSK design, and 8PSK and 16QAM designs in a single day as shown

in Table 6.2. Each of these designs was implemented and downloaded to the XTremeDSP

board and demonstrated to correctly produce a constellation. Bit error plots were generated

for several QPSK designs as shown in Figure 6.2. These plots show that the generated QPSK

design performed comparably to the hand-built design and no performance decrease was ob-

served. This demonstrated design time improvement can contribute not only to an increase

in design productivity but also to the feasibility and ease of use for rapidly reconfigurable

radio and other data-driven designs. For example, radio systems implemented in FPGAs

could be rapidly designed and configured on the fly to meet current needs in the field.

The Ogre tool and the productivity improvements demonstrate the ability of meta-

data to enable tools to perform tasks that have normally been done by the designer. The

meta-data extensions to IP-XACT that describe parameterization, high-level datatypes, and

71

temporal behavior enabled the Ogre tool to perform control and interface synthesis, thus

removing the need for designers to do the work manually. Removing these lower-level tasks

from the designer allows the designer to worry less about how to get a particular application

working and more about what is the best design for a particular application.

72

Chapter 7

Conclusion: Productivity Gains from Meta-Data-Assisted Reuse

This work has presented productivity improvements by using tools that leverage meta-

data descriptions of IP cores. Meta-data wrappers were key in enabling the productivity

increases because the meta-data described both the low and high-level details of a core. The

meta-data allowed tools to perform tasks such as setting parameters, evaluating datatype

compatibility, and synthesizing interface and control circuitry. Removing these low-level

design tasks from the designer was the key contributor to increased design productivity.

7.1 Productivity Increases Demonstrated

This work has made five primary contributions that help to improve the design pro-

ductivity for FPGA by simplifying the reuse of coarse-grain IP. These contributions have

been demonstrated by specific meta-data descriptions implemented in CHREC XML and in

IP-XACT with extensions and by the tools that accompany these descriptions.

• This work demonstrated the benefits of representing the interface components of IP in

a standard way. This meta-data enabled the construction of a design composition tool

to structurally interconnect IP in a language and source independent manner. This tool

was based on meta-data descriptions defined in CHREC XML and was demonstrated

in Chapter 4.

• This thesis demonstrated the ability of meta-data, both in CHREC XML and in IP-

XACT with extensions, to describe parameters and leverage mathematical expressions

to translate high-level parameters to lower-level parameters. This contribution was

discussed in Chapter 4.

73

• A technique for describing high-level numerical datatypes in meta-data was also pre-

sented. These high-level types were used in the Ogre system to determine compatibility

of signals on IP before attempting to compose a complete design. The use of these

meta-data-defined datatypes was discussed in Chapter 5.

• This thesis also contributes a method for describing coarse-grain IP in meta data

that allows these IP to be modeled as actors in the H-SDF model of computation.

This model for IP enabled architectural synthesis algorithms to synthesize controllers

and interface circuitry for designs composed of this IP. This description method was

demonstrated in the Ogre tool described in Chapter 5.

• Productivity gains were demonstrated by construction of digital communication radio

receivers. Construction of these receivers was done in the Ogre system and leveraged

the meta-data to dramatically decrease design time from 3 days to less than an hour

for a single receiver.

In demonstrating these contributions two XML schemas were built. CHREC XML

was an initial attempt at meta-data descriptions for FPGA and many of the lessons learned

from CHREC XML translated to the extensions implemented in IP-XACT.

The CHREC XML schema enabled a demonstration of the ability to represent a large

library of cores from different sources in a common library environment. It also demonstrated

the ability to manipulate parameter values for wrapped cores as well as the ability to generate

HDL and other wrappers for these cores. In addition this tool supported the basic automation

of interconnection between cores. These three demonstrated abilities together provide the

basic framework for an IP reuse system and increase the reusability of cores that are wrapped

in the CHREC XML meta-data by removing the need for the designer to understand all of

the low level details of the core.

The IP-XACT standard and accompanying extensions enabled the reuse of hardware

cores in an end-to-end design environment called Ogre. The Ogre environment demonstrated

significant design productivity improvements when used to create digital radio receivers. The

IP-XACT standard was leveraged and extended to create a meta-data description for each

library core which encapsulated all of the details of the cores’ operation. Parameterization

74

native to IP-XACT was extensively used and extensions were added to fully specify the

temporal behavior of the core within the H-SDF model.

This research extended the productivity improvements, seen previously in SoC design,

to data-driven design by developing a library of standard cores for digital communication

systems, describing these cores in meta-data, and leveraging the library and its core de-

scriptions in the Ogre design environment. The library of cores developed in this research

consisted primarily of cores for use in digital communication systems. These cores were

parameterized at both a high and low level to provide flexibility and to allow the designer

to reason with the cores at a higher level of abstraction. These cores also differed in their

latency, data introduction interval and sample delay characteristics, and each functioned as

an actor in an H-SDF graph.

The combination of reusable cores, meta-data describing these cores, and an end-to-

end synthesis flow enabled significant improvements in design productivity. Designs that

took days to build manually were built in a matter of hours using the library, descriptions,

and tools. These productivity benefits were observed and demonstrated on several different

radio designs.

7.2 The Role of Meta-Data in Reuse

Many of the barriers to reuse can be overcome by using meta-data to describe details

of IP cores that must otherwise be understood by the system designer. The encapsulation

of core interface and behavior details in meta-data allows tools to automatically perform

much of the work that has traditionally been required of system designers. There are several

basic items that should be included in meta-data descriptions of FPGA IP, including the

following:

Component Naming: The naming scheme should enable a library to be easily rep-

resented and searched. It should also allow for naming in a language and platform

independent manner.

75

Port Information: Basic information about the low-level hardware implementation

of input and output ports should include bit-widths and bit-vector directions. These

values should be parameterizable.

File Sets: A pointer to the actual implementation files that are wrapped by the meta-

data should be included to enable tools to automatically generate implementation files

from RTL or other languages.

Component Generators: Meta-data for a core should define the tools that should

be run on files listed in the the file sets to produce standard implementation files such

as EDIF netlists, bitstreams for FPGA, or even hard macros [42].

Low-Level Parameterization: This is most closely related to conventional VHDL-

level parameterization. That is, it is used to declare bit-widths on inputs and outputs,

rounding modes, pipelining directives, etc.

Domain-Specific Parameterization: This is used to provide a level of parameteri-

zation usable by a domain expert who is not necessarily a hardware designer. It allows

a domain expert to deal with cores at the levels of abstraction he or she typically deals

with when designing application-specific models.

Dependent Parameterization: This describes the link between domain-specific and

low-level parameterization. It allows low-level parameters to be computed based on

domain-specific parameter values set by an application expert.

Datatypes: The datatypes of the core should be described in the meta-data in such

a way that the integrity of numerical or other data transmitted or received by a port

is not compromised.

Temporal Behavior: This refers to the descriptions of the temporal behavior of

a core with respect to its consumption and production of data and the latency of

computations.

XML [23] provides an ideal method for representing meta-data for reuse because of

its extensibility and the ability to define meta-data elements and their relationships with

76

standard XML Schema [24]. The IP-XACT standard IEEE 1685 [27] provides some of these

basic elements in XML and can be directly used for descriptions of FPGA IP. However, the

description elements specific to FPGA require extensions to IP-XACT which were imple-

mented separately in this work. The combination of meta-data and tools supporting that

meta-data provides significant increases in design productivity.

7.3 Future Work

Much work still remains to be done to enable the reuse of arbitrary IP through meta-

data encapsulation. The end goal of meta-data encapsulation should be to simplify reuse of

arbitrary IP for both experienced digital hardware designers and for domain experts with

no previous hardware experience. To achieve this end, several advances need to be made

in addition to those presented in this work. Two of these advances include the ability to

describe and reason with truly arbitrary interfaces and the expansion and standardization

of high-level datatypes.

Description methods for arbitrary interfaces do not yet exist; yet this description is

a primary element in enabling reuse. This problem is constrained slightly when the design

space is limited to DSP designs. This constraint is appropriate because of the large size

of the DSP design space and its fundamental difference from the SoC model. While the

interface descriptions presented in this work to describe H-SDF type systems can describe a

significant subset of common interface behaviors for DSP designs, they do not describe the

temporal behavior of all DSP IP.

One particularly interesting type of IP that cannot be described with the presented

methods is multi-rate IP. These are IP that expect multiple tokens on their inputs before

firing or that produce multiple tokens on their outputs when they do fire. These cores

directly match the synchronous data flow (SDF) model of computation. Down-sampling

and up-sampling DSP filters are good examples of this SDF type behavior. The description

of these IP can be quite complicated as it needs to contain not only the number of tokens

consumed and produced by the core but also some notion of how they are produced and

consumed. For example, if an output produces two tokens when it fires does that mean that

there are two data values produced serially on the port or that the port somehow represents

77

both of those datum in parallel? Should a synthesis system understand these rate changes

as changes in clock rate, or should it simply be a change in the control structure? Multi-rate

and other interface behavior description requirements present a challenge to both meta-data

representations and to the tools that support reuse.

In addition to expanding the description of temporal interfaces, the implementation of

high-level datatypes in meta-data needs expansion and standardization. This work assumes

that high-level datatypes on ports will be strictly numeric; however, this may not always

be the case. For example, if the port is an output of an Ethernet core, a more appropriate

datatype to use would be a description of the packet that is produced by that port. There

may be other types of cores whose interfaces are more appropriately described by structural

datatypes rather than simple numerical types as described in [31]. While this work has not

addressed all possible description needs for reusable IP, it has shown that using meta-data

to encapsulate needed descriptions is a reasonable way to use descriptions to increase design

productivity.

Verification both of individual IP cores and of complete designs is critical to the

success of any reuse scheme. One of the underlying assumptions of the reuse model is that the

IP being reused is verified and functional. Because much reusable IP is highly parameterized,

the verification problem is complicated. It may be impossible to completely test all possible

combinations of parameters on a core; however, perhaps meta-data can be leveraged to

simplify the problem. Most hardware IP can be modeled with software. If meta-data can

define the relationship between the software model and the hardware implementation then

perhaps this model can be used to verify correctness of design and IP at the same time.

Once a design has been completed, the function of the combined software models can be

compared with the complete hardware design. The IP-XACT standard already implements

this type of an idea with its transactional level modeling meta-data; however, this approach

likely should be extended to dataflow designs for FPGAs. Further research in this area may

show the ability of meta-data to facilitate this type of approach.

78

7.4 The Need for Increased Design Productivity

The electronics industry has seen an increase in the design productivity gap in recent

years due to the slow progression of design productivity relative to the progression of Moore’s

Law. If the gap is not closed significantly, then despite the improvements in technology,

performance of designs produced by the industry will not scale at the same rate as the

technology upon which they are implemented.

The design productivity gap is especially apparent for FPGAs which are often used to

implement DSP or digital communication type systems. In the past, reconfigurable FPGA

architectures have been small enough that a simple DSP system would easily consume all

available resources thereby using all available computing power. However, as the density of

resources on FPGAs has increased, the ability of designers to utilize all available resources

has decreased. If this disparity between design productivity and device capability continues

to increase, it is foreseeable that designers simply will not be able to take advantage of the

computing power available to them on the FPGA fabrics of the future.

Reusing previously verified and tested soft and hard intellectual property (IP) is one

way of narrowing the design productivity gap [8]. There is an enormous amount of previously

verified and tested hard and soft IP in the electronic design industry. Providing easy access to

this IP and enabling designers to quickly and easily integrate it into designs would drastically

narrow the design productivity gap. Reuse of hard IP is becoming more prevalent in modern

FPGAs as the trend is toward providing more high-performance hard cores in the FPGA

fabric. Reuse of soft IP, however, is still difficult.

There are several barriers to reusing soft IP. Soft IP is developed in many languages

and integrating from these many sources can be difficult. IP for FPGAs and other data-

flow based platforms often have non-standard interconnection protocols that require designer

understanding and effort when including them in a design. The datatypes used for commu-

nication on FPGA IP are often numerical in nature, but this is not captured in the bit-level

descriptions that are provided by most HDL formats. The existence of these barriers makes

IP reuse difficult especially when, in order for the reuse process to be feasible, it must not

require more than 30% of the effort to create the same IP from scratch [9].

79

While significant work still remains to be done to enable reuse of arbitrary IP by uti-

lizing meta-data wrappers, this work has demonstrated that significant productivity gains

are possible with this approach. As Moore’s Law continues to progress, it is increasingly im-

portant that these types of productivity gains continue to be demonstrated and implemented.

As the IP-XACT standard is implemented and extended for DSP and other FPGA applica-

tions as outlined in this work, the design productivity gap can be narrowed and designers

and domain experts will more easily be able to take advantage of the rapidly increasing

computational power of FPGA-based systems.

80

Bibliography

[1] International Technology Roadmap for Semiconductors 2009 Edition: Design, Interna-tional Semiconductor Industry Association, 2009. 1, 2, 4

[2] A. DeHon and J. Wawrzynek, “Reconfigurable computing: what, why, andimplications for design automation,” in Proceedings of the 36th annual ACM/IEEEDesign Automation Conference, ser. DAC ’99. New York, NY, USA: ACM, 1999, pp.610–615. [Online]. Available: http://doi.acm.org/10.1145/309847.310009 2

[3] K. Compton and S. Hauck, “Reconfigurable computing: a survey of systems andsoftware,” ACM Comput. Surv., vol. 34, pp. 171–210, June 2002. [Online]. Available:http://doi.acm.org/10.1145/508352.508353 2

[4] A. Sangiovanni-Vincentelli, L. Carloni, F. De Bernardinis, and M. Sgroi, “Benefits andchallenges for platform-based design,” in DAC ’04: Proceedings of the 41st annual De-sign Automation Conference. New York, NY, USA: ACM, 2004, pp. 409–414. 4

[5] M. McFarland, A. Parker, and R. Camposano, “The high-level synthesis of digital sys-tems,” Proceedings of the IEEE, vol. 78, no. 2, pp. 301 –318, Feb. 1990. 5

[6] J. Zhu, “Introduction to c-based high level synthesis,” in ASIC, 2009. ASICON ’09.IEEE 8th International Conference on, October 2009, p. 15. 5

[7] A. Shatnawi, J. Ghanim, and M. O. Ahmad, “High level synthesis of integrated het-erogeneous pipelined processing elements for DSP applications,” Comput. Electr. Eng.,vol. 30, no. 8, pp. 543–562, 2004. [Online]. Available: http://portal.acm.org/citation.cfm?id=1651877&dl=&coll=GUIDE&CFID=80171792&CFTOKEN=69326439 5

[8] E. Girczyc and S. Carlson, “Increasing Design Quality and Engineering ProductivityThrough Design Reuse,” in ACM IEEE Design Automation Conference (DAC), 1993.5, 79

[9] R. Passerone and J. A. Rowson, “Automatic Synthesis of Interfaces Between Incompat-ible Protocols,” in Proceedings of the 35th Design Automation Conference (DAC 1998),June 1998, pp. 8–13. 6, 31, 79, 93

[10] B. Boehm, “Managing Software Productivity and Reuse,” in IEEE Computer, vol. 32,no. 9, September 1999, pp. 111–113. 6

[11] C. W. Krueger, “Software Reuse,” ACM Comput. Surv., vol. 24, pp. 131–183, June1992. [Online]. Available: http://doi.acm.org/10.1145/130844.130856 6

81

[12] R. Bergamaschi, S. Bhattacharya, R. Wagner, C. Fellenz, M. Muhlada, F. White, J.-M.Daveau, and W. Lee, “Automating the Design of SOCs Using Cores,” Design & Test ofComputers, IEEE, vol. 18, no. 5, pp. 32–45, Sep-Oct 2001. 6, 23

[13] EDK Concepts, Tools, and Techniques, Xilinx Inc, 2009. 6, 14

[14] System Generator for DSP User Guide, Xilinx, Inc., 9 2010. 6, 14

[15] LabVIEW 8.6 FPGA Module Help, National Instruments, June 2008,http://zone.ni.com/reference/en-XX/help/371599D-01/. 6, 15, 28, 87, 116

[16] B. R. Rau, “Iterative Modulo Scheduling,” The International Journal of Parallel Pro-cessing, vol. 24, no. 1, February 1996. 9, 59, 70, 92

[17] CORE Generator Guide, Xilinx, Inc., 2009. 11, 13, 15, 42

[18] IP-XACT Draft/D5: A specification for XML meta-data and tool interfaces, SPIRITconsortium, 1370 Trancas Street #184, Napa, CA, 94558, May 2009. 12, 23

[19] D. D. Gajski, A. C. H. Wu, V. Chaiyakul, S. Mori, T. Nukiyama, and P. Bricaud,“Essential Issues for IP Reuse,” Asia and South Pacific Design Automation Conference,pp. 37+, 2000. [Online]. Available: http://dx.doi.org/10.1109/ASPDAC.2000.83506712, 37, 38

[20] J. Falcon and M. Trimborn, “Graphical Programming for Field Programmable GateArrays: Applications in Control and Mechatronics,” in American Control Conference,2006, 2006, p. 7. 15

[21] J. Zhu, “MetaRTL: raising the abstraction level of RTL design,” in DATE ’01:Proceedings of the conference on Design, automation and test in Europe. Piscataway,NJ, USA: IEEE Press, 2001, p. 7176. [Online]. Available: http://portal.acm.org/citation.cfm?id=367072.367096 18

[22] C. Hsu, F. Keceli, M. Ko, S. Shahparnia, and S. S. Bhattacharyya, “DIF:An Interchange Format for Dataflow-Based Design Tools,” in Computer Systems:Architectures, Modeling, and Simulation. Springer Berlin / Heidelberg, 2004, pp.3–32. [Online]. Available: http://www.springerlink.com/content/cu1jkcfg5v0f4t3e 18

[23] World Wide Web Consortium (W3C), “Extensible Markup Language (XML),” http://www.w3.org/XML/, January 2011. 18, 76

[24] ——, “XML Schema,” http://www.w3.org/XML/Schema, January 2011. 18, 77

[25] N. Rollins, A. Arnesen, and M. Wirthlin, “An XML Schema for Representing ReuableIP Cores for Reconfigurable Computing,” in Proceedings of the National Aerospace andElectronics Conference (NAECON 2008), July 2008. 18, 20

[26] IP-XACT v1.4: A Specification for XML Meta-Data and Tool Interfaces, SPIRIT con-sortium, 2008. 23, 85

82

[27] “IEEE Standard for IP-XACT, Standard Structure for Packaging, Integrating, andReusing IP within Tools Flows,” 2010. [Online]. Available: http://ieeexplore.ieee.org/servlet/opac?punumber=5417307 23, 77

[28] L. Benini and G. De Micheli, “Networks on chips: a new SoC paradigm,” Computer,vol. 35, no. 1, pp. 70–78, Jan 2002. 23

[29] World Wide Web Consortium (W3C), “XML Path Language (XPath) 2.0,” http://www.w3.org/TR/xpath20/, January 2007. 24, 25, 86

[30] A. Arnesen, N. Rollins, and M. Wirthlin, “A Multi-Layered XML Schema and DesignTool for Reusing and Integrating FPGA IP,” in 19th International Conference on FieldProgrammable Logic and Applications (FPL 2009), August 2009. 28

[31] T. P. Perry, K. Benkrid, and R. Walke, “An Extensible Code Generation Frameworkfor Heterogeneous Architectures Based on IP-XACT,” in Proc. of VII Southern Pro-grammable Logic Conference (SPL 2011), April 2011. 29, 78

[32] C. Spackman, “Esl anyone?” EE Times & Open-Silicon, Tech. Rep., February 2011. 29

[33] L. de Alfaro and T. A. Henzinger, “Interface Automata,” in ESEC/FSE-9: Proceedings of the 8th European software engineering conference held jointly with9th ACM SIGSOFT international symposium on Foundations of software engineering.New York, NY, USA: ACM Press, 2001, pp. 109–120. [Online]. Available:http://dx.doi.org/10.1145/503209.503226 31, 93, 94

[34] D. Drusinsky and D. Harel, “Using Statecharts for Hardware Descriptionand Synthesis,” Computer-Aided Design of Integrated Circuits and Systems, IEEETransactions on, vol. 8, no. 7, pp. 798–807, 1989. [Online]. Available: http://dx.doi.org/10.1109/43.31537 31, 93

[35] A. Seawright and F. Brewer, “Clairvoyant: a Synthesis System for Production-BasedSpecification,” Very Large Scale Integration (VLSI) Systems, IEEE Transactions on,vol. 2, no. 2, pp. 172–185, 1994. [Online]. Available: http://dx.doi.org/10.1109/92.285744 31, 93

[36] P. Bhaduri and S. Ramesh, “Interface Synthesis and Protocol Conversion,” FormalAspects of Computing, vol. 20, no. 2, pp. 205–224, 2008. [Online]. Available:http://dx.doi.org/10.1007/s00165-007-0045-4 31, 93

[37] L. de Alfaro and T. Henzinger, “Interface Theories for Component-Based Design,” inEmbedded Software. Springer Berlin / Heidelberg, 2001, pp. 148–165. 31, 93

[38] V. D’Silva, A. Sowmya, and S. Ramesh, “Automated Interface Synthesis,” Universityof New South Wales. School of Computer Science and Engineering, Tech. Rep.,September 2003. [Online]. Available: http://www.worldcat.org/oclc/224267365 31, 93

83

[39] A. Arnesen, K. Ellsworth, D. Gibelyou, T. Haroldsen, J. Havican, M. Padilla, B. Nelson,M. Rice, and M. Wirthlin, “Increasing Design Productivity Through Core Reuse, Meta-Data Encapsulation, and Synthesis,” in Proc. of 20th International Conference on Field-Programmable Logic and Applications (FPL 2010), September 2010, pp. 538–543. 38,49

[40] E. Lee and D. Messerschmitt, “Synchronous data flow,” Proceedings of the IEEE, vol. 75,no. 9, pp. 1235–1245, 1987. 50

[41] M. Padilla, “FM Demodulators in Software-Defined Radio using FPGAs with RapidPrototyping,” Master’s thesis, Brigham Young University, 2011. 67

[42] C. Lavin, M. Padilla, S. Ghosh, B. Nelson, B. Hutchings, and M. Wirthlin, “Using HardMacros to Reduce FPGA Compilation Time,” in Proc. of 20th International Conferenceon Field-Programmable Logic and Applications (FPL 2010), September 2010, pp. 438–441. 76

[43] A. Arnesen, “Dataflow Interface Automata: Interface Specification for DSP Cores,”November 2009, NSF Center for High-Performance Reconfigurable Computing(CHREC). 90

[44] M. Sipser, Introduction to the Theory of Computation. PWS Publishing Company,1997. 93

84

Appendix A

CHREC XML Extensions to IP-XACT

A.1 Extending IP-XACT

Vendor extensions are allowed natively by IP-XACT to support extra informationnot included in the basic schema [26]. The documentation for IP-XACT v1.4 states that“the vendorExtensions element is a place in the description in which any vendor specificinformation can be stored. The ‘‘vendorExtensions’’ element allows any well-formeddescription”[26]. Vendors may need to add extensions to the schema to support specialoperations of their tools or to add extra description for a type of core not natively supportedin IP-XACT.

In order for custom elements to be used in vendor extensions elements, these exten-sions must be well formed, meaning that they must have correct XML syntax. While thiscan be accomplished simply by typing syntactically correct XML, this research has chosen toenforce correctness by defining extension elements in another XML schema file. Rather thanre-create an entire schema set simply for the extensions, hooks are provided into the originalCHREC XML schema to provide access to needed elements from CHREC XML. These ex-tension elements are defined in the file chrecExtension.xsd. These extension hooks simplyallow access to the needed elements from CHREC XML and allow them to be syntacticallyverified within the IP-XACT framework.

Because the extension elements remain in the chrec namespace, in order to allowthese elements to be included in the IP-XACT file and still maintain syntactical correctness,additional header information must be added to the file. This header information is shownin XML Code 6 and defines the namespaces that are valid for the file as well as the locationof the schemas that define elements from those namespaces. This information is included inthe first element as attributes on the <spirit:component> element. Each namespace thathas elements in the file must have an xmlns attribute which defines the prefix for elementsfrom that namespace. XML Code 6 shows three namespaces: the spirit namespace, thechrec namespace, and the xsi namespace which is the basic XML namespace. Each names-pace, excluding the xsi namespace, must specify a location for the schema containing thedefinitions of elements from that namespace. This is done in a single xsi:schemaLocation

attribute. Each namespace except for the xsi namespace is listed indexed by its url andthen associated with a relative path to the schema file from the implementing XML file.

IP-XACT defines many places in its schema where vendor extensions are allowedto be inserted. Because of this flexibility, some of the rigor of the schema is lost becauseany element from the extending schema can be inserted in any available vendor extensionelement. For example, extension elements meant to extend the description of a port could

85

XML 6 This code snippet shows the xmlns and xsk:schemaLocation additions that mustbe added to the spirit:component element of IP-XACT XML to support extensions from theCHREC namespace.<spirit:component

xmlns:spirit="http://www.spiritconsortium.org

/XMLSchema/SPIRIT/1.4"

xmlns:chrec="http://ccl.ee.byu.edu"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation= "http://www.spiritconsortium.org/XMLSchema/SPIRIT/1.4

../../Schema/IP-XACT/index.xsd

http://ccl.ee.byu.edu

../../Schema/CHREC/chrecExtension.xsd">

. . .

</spirit:component>

be placed inside a vendor extension element that is associated with a parameter and still besyntactically correct. Because of this arbitrary placement of extending elements, it can bedifficult to parse IP-XACT files that implement extensions. This problem must be addressedby extensive documentation. The following sections provide that documentation for theCHREC XML extensions.

A.2 Parameter Extensions

While IP-XACT does provide robust parameterization support, there are some ele-ments of CHREC XML that are not present in IP-XACT as well as some that are neededfor synthesis of HDL designs. In cores described by IP-XACT, all port information as wellas all parameterization information is provided inside of the <spirit:model> element. The<spirit:modelParameter> element, a child of <spirit:model>, can contain a vendorEx-tensions element. If this element is present, it is expected that only CHREC XML elementscontained inside of the <chrec:parameterExtension> element are inserted at this point.These elements are shown in XML Code 7.

The <chrec:dependendentMinimum> and <chrec:dependentMaximum> elementsshown in XML Code 7 extend the parameterization flexibility. IP-XACT natively allows forparameter values to be constrained by a minimum and maximum value; however, these valuesmust be hard coded. There are instances where the maximum value of a parameter maydepend on the value of another parameter. These extension elements allow that flexibility.The proper syntax for these parameters is the same as the syntax for other dependencyattributes in IP-XACT. The value in these elements should be an XPath [29] expressionwhich references other parameter values by ID and uses valid XPath operators and functionsto manipulate the values.

The <chrec:isHDLParameter/> tag allows parameters to be flagged as ones that ac-tually exist in HDL and therefore need to be set or overridden when HDL cores are instancedin a top-level design. For complex cores it can be valuable to have complex parameter res-olution done in the design tools rather than by implementing complex parameter resolution

86

XML 7 This code snippet shows the syntax of a parameter extension inserted inside ofa model parameter element. This example includes dependent minimum and maximumexpressions as well as the isHDLParameter tag.<spirit:modelParameter spirit:dataType="positive">

<spirit:name>accumulationWidth</spirit:name>

. . .

<spirit:vendorExtensions>

<chrec:parameterExtension>

<chrec:isHDLParameter />

<chrec:dependentMinimum>id(’accumulationWidth’) div 10</chrec:dependentMinimum>

<chrec:dependentMaximum>id(’accumulationWidth’)</chrec:dependentMaximum>

</chrec:parameterExtension>

</spirit:vendorExtensions>

</spirit:modelParameter>

in HDL. This allows parameters in HDL, which can be confusing and not intuitive, to beproperly set by evaluating high level parameters listed in meta-data. Allowing this func-tionality, however, requires that the design tool know which parameters listed in XML areactually parameters in the HDL core. This element allows for that differentiation. If the<chrec:isHDLParameter/> tag is present on a parameter, it is included in HDL instancesof the core; if it is absent it is treated as only an intermediate parameter.

A.3 Port Description Extensions

The descriptions of ports in IP-XACT are also fairly robust and currently require only3 extensions to be compatible with CHREC XML. In IP-XACT, <spirit:port> is a childof the <spirit:model> element. The <spirit:port> element allows a vendor extension.Only extensions that are contained within the <chrec:portExtension> element should beinserted at this point. Elements available in this element are shown in XML Code 8.

The <chrec:highLevelType> element provides a reference to the high level type thatshould be applied to this port. High level types are essential when doing interface synthesisand core stitching. If only bitwidths and low-level types are available, data between cores canpotentially become corrupted if ports whose bitwidths and low-level types match are simplywired together. Defining high level types for a port allows tools to correctly manipulate theinterface between cores to ensure proper transmission of data values. A particular high leveldatatype is often applied to several ports on a core and therefore the actual definition forthe type is listed elsewhere and each port contains just a reference to the high level typethat it implements. More on high-level types is discussed in Section A.4.

In addition to the high level type, port descriptions are also extended by assigning theport to a classification. The motivation for this extension comes from LabVIEW FPGA’sCLIP node XML [15]. CHREC XML allows ports to be classified as one of the following:clock, reset, control, data, address, or unknown. This extension is shown in XML Code 8where the port shown is classified as a data port.

87

XML 8 This code snippet shows the syntax of a port extension including a high level typereference and a classification.<spirit:port>

<spirit:name>y</spirit:name>

<spirit:wire>

. . .

</spirit:wire>

<spirit:vendorExtensions>

<chrec:portExtension>

<chrec:highLevelType>

SFix_2_a

</chrec:highLevelType>

<chrec:portCategory>

data

</chrec:portCategory>

</chrec:portExtension>

</spirit:vendorExtensions>

</spirit:port>

In addition to the extensions shown in XML Code 8, CHREC extensions to IP-XACTalso include a reset value element that can be applied to the port. This element allows thecore designer to specify what particular value should be present at this port when the systemis booted or receives a global reset.

A.4 High Level Datatypes Extension

High level datatype descriptions are one of the major elements missing in IP-XACT.Because IP-XACT compliant cores are expected to be used in an SoC environment andbecause they are compliant with standard bus interfaces, there is little need for this type ofdetail. However, when reasoning about dataflow driven designs and the cores used in them,it is vital to know the mapping of bits in a signal to the actual data being represented by thissignal. If this data is not available, blindly tying cores together will almost certainly resultin incorrect data transmission. This is especially important when working with fractionalnumbers and their fixed and floating point representations. The descriptions for high leveltypes must be robust and able to describe any possible way of dividing bits into differentportions of a data representation.

The CHREC XML vendor extension for IP-XACT is shown in part in XML Code 9.All elements that are included in this extension are children of the<chrec:highLevelDataTypes> element. This should be inserted in IP-XACT XML in thevendor extension element that is a child of the <spirit:component> element.

The high level datatypes extension defines several types that are each customizable.The <chrec:highLevelDataTypes> element contains a list of <chrec:portDataType> ele-ments each of which defines a different type. Each <chrec:portDataType> includes a nameand a single type definition element. The type definition elements that can be included andcustomized include the following:

88

A.4.1 Bit Vector

This datatype is declared by including the <chrec:bitVector> element in the ex-tension. Bit Vector types are types that have no significant data associated with them thatcannot be represented simply as a vector of bits.

A.4.2 Integer

This datatype is the basic type for all standard integer representations. This datatypeis used by including the <chrec:int> element. This element has a required sign attributewhich defines the signed representation for this particular integer type. It can describeunsigned, 1’s compliment, 2’s compliment, and signed magnitude integer types.

A.4.3 Floating Point

This datatype is highly parameterizable to represent possible divisions of bits in float-ing point number representations. To use this type the <chrec:floatingPoint> element isincluded. The floating point type is similar to the IEEE standard for floating point represen-tations. It has three fields, [1 sign bit][k bits for exponent][n bits for fraction of significand].We assume 1 sign bit at the beginning of the vector and either the exponent or fraction bitscan be specified in the type. With these pieces of information in addition to the bitwidthof ports implementing these types, all information about the type mapping can be inferred.This type also includes elements that specify that the type uses a guard bit, a round bit, ora sticky bit. The rounding scheme can also be specified as one of the following: round tonearest even, round toward zero, round toward ∞, or round toward −∞. While this typeexists in the schema and has been implemented on a few of the cores in the library, it hasnot yet been tested or used in synthesis tools.

A.4.4 Fixed Point

To use this datatype the <chrec:fixedPoint> element is included. This elementallows the definition to include either a number of integer bits or a number of fractional bitsto be included in the type. The total distribution of bits between integer and fractional bitscan be determined from either of these elements along with the entire bitwidth of the signal.This element also includes the same sign attribute that exists on the integer type.

A.4.5 Custom Type

This allows fully custom types to be defined. This type contains a list of fields whicheach contain a name as well as a vector of bits that are associated with that name. Thenaming can be related to parameters from the IP-XACT XML or from the original sourceHDL. While this type exists at this point, it has not been tested or used in practice.

XML Code 9 shows an example of the fixed-point type being defined in XML. Notethat there is a sign attribute that states that this type should be interpreted as a signed-fixedpoint value with 2’s compliment encoding. Also note that there should always be 2 integerbits in this type regardless of the length of the bit vector implementing the type.

89

XML 9 This code snippet shows an example of a high level datatype extension. Thisexample shows a signed fixed point type where two bits are used to represent the integerpart.<spirit:component>

. . .

<spirit:vendorExtensions>

<chrec:highLevelDataTypes>

<chrec:portDataType>

<chrec:name>SFix_2_a</chrec:name>

<chrec:fixedPoint

chrec:sign="2sComplement">

<chrec:intBits chrec:resolve="static">

2

</chrec:intBits>

</chrec:fixedPoint>

</chrec:portDataType>

</chrec:highLevelDataTypes>

. . .

</spirit:vendorExtensions>

. . .

</spirit:component>

A.5 Behavioral Layer Extension

The behavioral layer provides the meta-data needed to support the interface synthesisapproach developed in this work. It should be noted that this extension set is not fully matureand that further work is required to allow these extensions to fully describe interfaces andsupport robust interface synthesis. The primary motivation behind the creation of theseextensions was the need to automatically connect cores in a design without using a standardbus architecture. While there was more extensive research conducted regarding interfacerepresentations as shown in Appendix B and [43], these representations are outside of theprimary scope of this work and therefore were not ultimately represented in XML extensionsto IP-XACT.

All of the elements needed to describe interfaces are included in the<chrec:behavioralLayer> element. This element, similar to the<chrec:highLevelDataTypes> element, should be included in the XML in the vendor ex-tension element that is a child of the <spirit:component> element. There are four primarydatum in the behavioral extension: pipeline depth, data introduction interval, sample delay,and signal associations. Each of these extensions is shown in XML Code 10 and is discussedin the following sections.

A.5.1 Pipeline Depth

The pipeline depth of a core is an integer value describing the latency of the core.This number represents the number of clock cycles that elapse from the time that data isconsumed by the inputs of the core to the time that the associated results are produced

90

XML 10 This code snippet is an example of the extension used to define the temporalinterface behavior of the core.<spirit:component>

. . .

<spirit:vendorExtensions>

. . .

<chrec:behavioralLayer>

<chrec:dataIntroductionInterval>

7

</chrec:dataIntroductionInterval>

<chrec:pipelineDepth>

8

</chrec:pipelineDepth>

<chrec:dataValid>

<chrec:signal>validIn</chrec:signal>

</chrec:dataValid>

<chrec:clockEnable>

<chrec:signal>ce</chrec:signal>

</chrec:clockEnable>

<chrec:sampleDelay>0</chrec:sampleDelay>

</chrec:behavioralLayer>

</spirit:vendorExtensions>

. . .

</spirit:component>

on the outputs. The fact that this element exists in XML does not mean that the core ispipelined in the traditional sense or that data can be accepted by the core on every cycle.Cores that accept data only every 8 cycles and take 9 to compute a result should also be givena pipeline depth value of 9. A core that is purely combinational should have a pipeline depthvalue of 0. One with a single register breaking the critical path should have a pipeline depthof 1 and so on. It is important when setting the pipeline depth to carefully consider whichregisters in a particular core actually contribute to the latency and which simply performstate functions.

A.5.2 Data Introduction Interval

The data introduction interval for a core is an integer value describing how many clockcycles must elapse between times that the core is able to accept input data. For examplea core that has a data introduction interval of 3 can consume data on clock cycle 0 butthen will not consume data again until clock cycle 3 and then again on cycle 6. This datais important when automatically interfacing cores because the interface system has to makesure that data is not introduced too quickly to the core.

A.5.3 Sample Delay

In any hardware systems involving feedback, this feedback allows samples later in adata stream to be compared to results of computations on earlier samples in the same stream.

91

A sample delay is listed on a core whose outputs will be used in calculations involving sampleslater in the data stream. For example, the outputs of a core with a sample delay of 1 wouldbe used in computations with the sample immediately following the one that produced thatparticular output. Similarly, a core with a sample delay of 2 would have its outputs used incomputations involving samples which were two later than the sample which produced thoseoutputs.

Figure 6.1 shows an example of sample delay in a QPSK radio design. In this designthere are essentially two loops, one through the NCO and another through the DDS. Thecolors on each of the cores show which sample in the stream the outputs of that core areassociated with. The outputs of the NCO and the DDS are one sample delayed from theirinputs as are the outputs on the calculateMu block. Each of these cores has a sample delayof 1 listed in their XML. It is notable that cores with sample delay can be chained andmultiple sample delays can exist in a feedback loop.

Any feedback loop in a circuit must be broken by at least one core with a sample delay.This is most obvious when considering a design that uses purely combinational cores. If thereis a feedback path and all cores are strictly combinational, an unstable system will result. Inorder to correct this problem, a register must be inserted in that loop to allow the feedbackto be properly used in a synchronous system. When creating high performance designs withpipelined cores, each of the registers inserted in the combinational design become a core witha sample delay.

The need for this behavior is also demonstrated by the system shown in figure 6.1.The large numbers next to blocks in the diagram represent clock cycles in which the registersin that particular block are clocked. These times are computed using a modification of theiterative modulo scheduling algorithm from [16]. This algorithm takes into account thesample delay and uses it to fold computations in the hardware loop into a short time. Notethat the core calculateMu block has a sample delay attribute of 1. This attribute allows it tobe scheduled in time slot 1 which is the same time slot that the y interpolator core begins.

A.5.4 Signal Associations

The final meta-data required to fully define the behavior of a core are several signalassociations. The interface synthesis system developed in this work requires that data validand clock enable signals exist on cores. The data valid signal indicates that the data on theinputs of the core is valid and that the core can consume them. The clock enable signalessentially is tied to the clock enable signal on all registers in the design. This allows coresin the design to be turned on and off at will by centralized control circuitry. These two dataallow the interface synthesis system to ensure that data flows correctly in the design. Theexample in XML Code 10 shows that for this particular core the clock enable signal is called“ce” and that the data valid signal is called “validIn.” The XML extension also allows formultiple clock enable signals and multiple data valid signals. If there are multiples of eithertype of signal, these signals must be associated in XML with the particular data or clocksignals that they control.

92

Appendix B

Dataflow Interface Automata

B.1 Introduction

Finite automata, both deterministic (DFA) and nondeterministic (NFA), have beenused to describe the protocol and timing behavior of cores with handshaking protocols whichinterface with various bus protocols. Several of these include those discussed in [33], [34], [35],[36], [37], [38], and [9]. A good discussion of automata theory for beginners is found in [44].This report introduces Dataflow Interface Automata (DIA). Dataflow Interface Automatadiffer from the automata described in the above cited works in that they are specificallyuseful in describing cores typically used for digital signal processing. Their strength is inmodeling feed forward cores with varying data introduction intervals and varying latenciesor pipeline depths.

B.2 Definition and Examples

A dataflow interface automaton can be modeled as two deterministic finite automata(DFA) which are connected by a transition function from a single state in one to a single statein the other. The first automata, called D, essentially models the input data introductionpattern while the second automata, called P , models the pipeline or latency from data inputto data output.

The overall automata is non-deterministic because the connection from d ∈ D top ∈ P should be the same as one of the transitions from the state d ∈ D to another statedn ∈ D. Despite the fact that this nondeterminism exists, dataflow interface automata donot experience the state explosion associated with traditional fully nondeterministic DFA’s.The definition of this automata as well as some mathematical examples are included below.

Definition 1: A dataflow interface automata (DIA) is the quadruple

A = 〈D,P,Σcontrol, δ〉

where

1. D = 〈Q,ΣinCtrld ,ΣinData, δd, η, q0〉 is a data introduction interval automata where

(a) Q is a finite set of states

(b) ΣinCtrld ∈ Σcontrol is a finite set of input control signals

(c) ΣinData is a finite set of input data signals

93

(d) δd : Q× Σcontrold → Q is the transition function

(e) η : Q× Σcontrold → ΣinData is a mapping of transitions to data inputs

(f) q0 ∈ Q is the start state

2. P = 〈Q,ΣinCtrlp ,ΣoutCtrlp ,ΣoutData, δp, ζ, F 〉 is a pipeline automata where

(a) Q is a finite set of states

(b) ΣinCtrlp ∈ Σcontrol is a finite set of input control signals

(c) ΣoutCtrlp ∈ Σcontrol is a finite set of output control signals

(d) ΣoutData is a finite set of output data signals

(e) δp : Q× Σcontrolp → Q is the transition function

(f) F ⊆ Q is the set of data output states and

(g) ζ : F → ΣoutData

3. Σcontrol is a finite set of control signals

4. δ : d ∈ D × Σcontrol → p ∈ P × ΣinData is the single transition from D to P

Example 1: Pure Functional Figure B.1 shows a diagram of a DIA (D1) that is notparameterized. This particular DIA represents a pipelined multiplier that accepts dataevery 2 clock cycles and has a pipeline depth of 3. In the diagram, input data signals thatare being sampled are followed by a ‘?’ (ex. xin?), and output signals that are asserted ina state are followed by a ‘!’ (ex. zout!). This syntax is similar to that used in [33]. Othersignals are control and are simply listed by name.

Figure B.1: A DIA (D1) showing a data introduction interval of 2 and a pipeline depth of 2.

The formal definition of D1 is 〈D,P,Σcontrol, δ〉 :

1. D = 〈Q,ΣinCtrld ,ΣinData, δd, η, q0〉 :

(a) Q = {d0, d1}

94

(b) ΣinCtrld = {clk}(c) ΣinData = {xin, yin}(d) δd is given as

clk

d0 {d1}

d1 {d0}

(e) η is given as

clk

d0 {xin, yin}

d1 ∅

(f) q0 = d0

2. P = 〈Q,ΣinCtrlp ,ΣoutCtrlp ,ΣoutData, δp, ζ, F 〉 :

(a) Q = {p0, p1, p2}(b) ΣinCtrlp = {clk}(c) ΣoutCtrlp = {∅}(d) ΣoutData = {zout}(e) δp is given as

clk

p0 p1

p1 p2

p2 ∅

(f) F = {p2}(g) ζ is given as p2 → {zout}

3. Σcontrol = {clk}

4. δ : d0 ∪ clk → p0 ∪ {xin, yin}

Example 2: Deterministic With Control Figure B.2 shows the diagram of DIA (D2)with an extra input control signal in addition to the clock signal. Similar to Figure B.1 itis an example for a pipelined multiplier that can accept input only every 2 clock cycles butalso requires that the dataV alid signal be asserted before data is read.

The formal definition of D2 is D2 = 〈D,P,Σcontrol, δ〉 :

1. D = 〈Q,ΣinCtrld ,ΣinData, δd, η, q0〉 :

95

Figure B.2: A DIA (D2) showing a data introduction interval controlled by the signaldataV alid with a pipeline depth of 2.

(a) Q = {d0, d1}(b) ΣinCtrld = {clk, dataV alid}(c) ΣinData = {xin, yin}(d) δd is given as

clk ∪ dataV alid clk ∪ dataV alid

d0 {d1} {d0}

d1 {d0} {d0}(e) η is given as

clk ∪ dataV alid clk ∪ dataV alid

d0 {xin, yin} {∅}

d1 {∅} {∅}(f) q0 = d0

2. P = 〈Q,ΣinCtrlp ,ΣoutCtrlp ,ΣoutData, δp, ζ, F 〉 :

(a) Q = {p0, p1, p2}(b) ΣinCtrlp = {clk}(c) ΣoutCtrlp = {∅}(d) ΣoutData = {zout}(e) δp is given as

clk

p0 p1

p1 p2

p2 ∅

96

(f) F = {p2}(g) ζ is given as p2 → {zout}

3. Σcontrol = {clk}

4. δ : d0 ∪ clk → p0 ∪ {xin, yin}

Example 3: Non-deterministic Figure B.3 shows a DIA that models the behavior of acore that non deterministically processes input data and indicates that it is done processingand that data is ready with the dataRdy signal. The difficulty with this type of core is thatit cannot be statically scheduled.

Figure B.3: A DIA D3 showing the representation for a non-deterministic core that signalsits data is valid with a dataRdy signal.

The formal definition of D3 is D3 = 〈D,P,Σcontrol, δ〉 :

1. D = 〈Q,ΣinCtrld ,ΣinData, δd, η, q0〉 :

(a) Q = {d0, d1}(b) ΣinCtrld = {clk}(c) ΣinData = {xin, yin}(d) δd is given as

clk

d0 {d1}

d1 {d0}

(e) η is given as

97

clk

d0 {xin, yin}

d1 {∅}(f) q0 = d0

2. P = 〈Q,ΣinCtrlp ,ΣoutCtrlp ,ΣoutData, δp, ζ, F 〉 :

(a) Q = {p0, p1, p2}(b) ΣinCtrlp = {clk}(c) ΣoutCtrlp = {dataReady}(d) ΣoutData = {zout}(e) δp is given as

clk clk ∪ dataReady clk ∪ dataReady

p0 p1 − −

p1 − p1 p2

p2 {∅} − −(f) F = {p2}(g) ζ is given as p2 → {zout}

3. Σcontrol = {clk}

4. δ : d0 ∪ clk → p0 ∪ {xin, yin}

Example 4: Non-deterministic with required clear This is the DIA model for a corethat has a non-deteministic latency and requires that the user clear the core before introduc-ing new data to the core. This core also requires that this clear come at least one clock cycleafter the previous data is consumed. Essentially this core has a data introduction intervalof 2 with a required clear and a non-deterministic latency.

The formal definition of D4 is D4 = 〈D,P,Σcontrol, δ〉 :

1. D = 〈Q,ΣinCtrld ,ΣinData, δd, η, q0〉 :

(a) Q = {d0, d1, d3}(b) ΣinCtrld = {clk, clr}(c) ΣinData = {xin, yin}(d) δd is given as

clr clk ∪ clr clk ∪ clr

d0 − d1 d0

d1 d0 d3 −

d2 d0 d2 −

98

Figure B.4: A DIA D4 which models a core with a data introduction interval of 2 with arequired clear before data can be consumed. It also has a non-deterministic latency.

(e) η is given as

clk ∪ clr

d0 {xin, yin}

d1 {∅}

d2 {∅}

(f) q0 = d0

2. P = 〈Q,ΣinCtrlp ,ΣoutCtrlp ,ΣoutData, δp, ζ, F 〉 :

(a) Q = {p0, p1, p2}(b) ΣinCtrlp = {clk, clr}(c) ΣoutCtrlp = {dataRdy}(d) ΣoutData = {zout}(e) δp is given as

clk clr clk ∪ dataReady clk ∪ dataReady

p0 p1 {∅} − −

p1 − {∅} p1 p2

p2 {∅} {∅} {∅} {∅}

(f) F = {p2}(g) ζ is given as p2 → {zout}

3. Σcontrol = {clk}

4. δ : d0 ∪ clk → p0 ∪ {xin, yin}

99

Example 5: Multi-rate Systems (Upsample) This is the DIA model for a multi-ratesystem that does an upsample. Functionally, upsampling means that a core consumes dataat a slower rate than it produces corresponding output data. This is a common occurrencefor DSP cores.

Figure B.5: A DIA D5 which models a core which consumes data every other clock cycle butoutputs data every clock cycle. This is typical behavior for an upsampling core.

The formal definition for D5 is D5 = 〈D,P,Σcontrol, δ〉:

1. D = 〈Q,ΣinCtrld ,ΣinData, δd, η, q0〉 :

(a) Q = {d0, d1}(b) ΣinCtrld = {clk}(c) ΣinData = {data}(d) δd is given as

clk

d0 d1

d1 d0

(e) η is given as

clk

d0 {data}

d1 {∅}

(f) q0 = d0

100

2. P = 〈Q,ΣinCtrlp ,ΣoutCtrlp ,ΣoutData, δp, ζ, F 〉 :

(a) Q = {p0, p1}(b) ΣinCtrlp = {clk}(c) ΣoutCtrlp = {∅}(d) ΣoutData = {zout}(e) δp is given as

clk

p0 p1

p1 {∅}

(f) F = {p0, p1}(g) ζ is given as p0 → {zout} and p1 → {zout}

3. Σcontrol = {clk}

4. δ : d0 → p0 ∪ {data}

Example 6: Multi-rate Systems (Downsample) This is the DIA model for a multi ratesystem that does a downsample. Functionally, downsampling means that a core consumesdata at a faster rate than it produces corresponding output data. In this example(d6), thecore consumes data every clock cycle but only produces output data every other clock cycle.This is a common occurrence for DSP cores.

Figure B.6: A DIA D6 which models a core which consumes data every clock cycle andoutputs data every other clock. This is typical behavior for a downsampler.

The formal definition for D6 is D6 = 〈D,P,Σcontrol, δ〉:

101

1. D = 〈Q,ΣinCtrld ,ΣinData, δd, η, q0〉 :

(a) Q = {d0, d1}(b) ΣinCtrld = {clk}(c) ΣinData = {data}(d) δd is given as

clk

d0 d1

d1 d0

(e) η is given as

clk

d0 {data}

d1 {data}

(f) q0 = d0

2. P = 〈Q,ΣinCtrlp ,ΣoutCtrlp ,ΣoutData, δp, ζ, F 〉 :

(a) Q = {p0}(b) ΣinCtrlp = {∅}(c) ΣoutCtrlp = {∅}(d) ΣoutData = {zout}(e) δp is given as δp = {∅}(f) F = {p0}(g) ζ is given as p0 → {zout}

3. Σcontrol = {clk}

4. δ : d0 → p0 ∪ {data}

B.3 Visualizing DIA’s

It can be difficult to understand how these automata work by simply looking at math-ematics and diagrams. This section contains a series of figures which shows the operation ofthe DIA as different signals occur on the core. The DIA is functionally equivalent to D1.

102

d1d0

p1p0 p2

rst

clk/

xin?yin?

clk

clk/

xin?yin? clk clk

zout!

d1d0

p1p0 p2

rst

clk/

xin?yin?

clk

clk/

xin?yin? clk clk

zout!

d1d0

p1p0 p2

rst

clk/

xin?yin?

clk

clk/

xin?yin? clk clk

zout!

p2

d1d0

p1p0

rst

clk/

xin?yin?

clk

clk/

xin?yin? clk clk

zout!

Signals

rst

clk

clk

clk

Signals

rst

clk

clk

clk

Signals

rst

clk

clk

clk

Signals

rst

clk

clk

clk

Figure B.7: This series of DIA’s shows the progression through the machine D1 as signalsoccur on the core. The red states are active and the red arrows are the transitions that wereused to activate that state. The progression of signals is shown on the right of each segmentwith the arrow pointing to the signal last used.

103

104

Appendix C

The IP-XACT Extensions Schema

This appendix contains the verbatim code from the schema that defines extensions toIP-XACT for higher levels of abstraction. The code is well documented and is included asan example of how these extensions can be implemented. The implementation of the schemaconsists of several schema (.xsd) files and each is listed here.

C.1 CHREC Extensions

The chrecExtensions.xsd file is the file that should be referenced in XML thatrequires extensions defined in this schema. It defines the set of extension elements andallows user access to them.

CHRECExt/chrecExtension.xsd

1 <?xml version=” 1 .0 ” encoding=”UTF−8” ?>< !−−// Des c r i p t i on : chrecExtens ions . xsd// Author: Brigham Young Univers i t y , CHREC B1 , Adam Arnesen// Vers ion: 2 .0

6 // Date: 2010/12/20//// Copyright ( c ) 2010 , Brigham Young Un i v e r s i t y Con f i gurab l e Computing Lab

, A l l r i g h t s r e s e rved .// h t t p : // c c l . ee . byu . edu//

11 // This source f i l e i s prov ided on an AS IS ba s i s . Brigham YoungUn i ve r s i t y d i s c l a ims

// ANYWARRANTY EXPRESS OR IMPLIED INCLUDING ANYWARRANTY OF// MERCHANTABILITY AND FITNESS FOR USE FOR A PARTICULAR PURPOSE.// The user o f the source f i l e s h a l l indemnify and ho ld Brigham Young

Un i ve r s i t y harmless// from any damages or l i a b i l i t y a r i s i n g out o f the use t h e r e o f or the

performance or16 // implementat ion or p a r t i a l implementat ion o f the schema .−−>

<xs:schema targetNamespace=” h t t p : // c c l . ee . byu . edu”elementFormDefault=” q u a l i f i e d ” attr ibuteFormDefaul t=” q u a l i f i e d ”xmlns :xs=” h t t p : //www. w3 . org /2001/XMLSchema” xmlns :chrec=” h t t p : // c c l . ee .

byu . edu”>21 <x s : i n c l u d e schemaLocation=” h s d f I n t e r f a c e . xsd” />

<x s : i n c l u d e schemaLocation=” highLevelDataTypes . xsd” /><x s : i n c l u d e schemaLocation=” parameter . xsd” /><x s : i n c l u d e schemaLocation=” por t s . xsd” />

105

26 <xs : e l ement name=” highLevelDataTypes ” type=” chrec:portsDataTypeType ”><xs : annota t i on>

<xs :documentat ion>This d e f i n e s the high l e v e l data types . One o fthe se should be a s s o c i a t e d with each port on an IP core .

31 </ xs :documentat ion></ xs : annota t i on>

</ xs : e l ement>

<xs : e l ement name=” behav iora lLayer ” type=”chrec :hsd fBehav iora lExtens ionType ”>

36 <xs : annota t i on><xs :documentat ion>

This d e f i n e s the i n t e r f a c e parameters f o r H−SDFCores .

</ xs :documentat ion>41 </ xs : annota t i on>

</ xs : e l ement>

<xs : e l ement name=” portExtens ion ” type=” chrec :portExtens ionType ”>46 <xs : annota t i on>

<xs :documentat ion>This ex t ens i on prov ide s a high l e v e l typer e f e r e n c e , a r e s e t value , and a c a t e g o r i z a t i o n o f a port .

</ xs :documentat ion>51 </ xs : annota t i on>

</ xs : e l ement>

<xs : e l ement name=” parameterExtension ” type=” chrec :parameterExtens ionType”>

56 <xs : annota t i on><xs :documentat ion>

The parameter ex tens i on adds three e lements toparameter va lue s . I t i n d i c a t e s i f a parameter i s an ac tua l

parameter( i . e . g e n e r i c ) inc luded in HDL sources , and a l l ows f o r parameters

to61 have dependent minimum and maximum va lues .

</ xs :documentat ion></ xs : annota t i on>

</ xs : e l ement></ xs:schema>

C.2 Parameters

This file provides extensions for resolving minimum and maximum values on param-eters. IP-XACT 1.4 allows parameters only to have static minimum and maximum values.This extensions allows min and max values to depend on other elements’ values or on math-ematical expressions as defined by an XPath Expression. It also allows parameters to be

106

tagged as HDL parameters. This means that the parameter is an actual parameter thatmust be set in generated HDL. In VHDL this means that the parameter is a generic in theVHDL and must be properly overwritten in generated code.

CHRECExt/parameter.xsd

<?xml version=” 1 .0 ” encoding=”UTF−8”?>< !−−// Des c r i p t i on : parameter . xsd// Author: Brigham Young Univers i t y , CHREC B1 , Adam Arnesen

5 // Vers ion: 2 .0// Date: 2010/12/20//// Copyright ( c ) 2010 , Brigham Young Un i v e r s i t y Con f i gurab l e Computing Lab

, A l l r i g h t s r e s e rved .// h t t p : // c c l . ee . byu . edu

10 //// This source f i l e i s prov ided on an AS IS ba s i s . Brigham Young

Un i ve r s i t y d i s c l a ims// ANYWARRANTY EXPRESS OR IMPLIED INCLUDING ANYWARRANTY OF// MERCHANTABILITY AND FITNESS FOR USE FOR A PARTICULAR PURPOSE.// The user o f the source f i l e s h a l l indemnify and ho ld Brigham Young

Un i ve r s i t y harmless15 // from any damages or l i a b i l i t y a r i s i n g out o f the use t h e r e o f or the

performance or// implementat ion or p a r t i a l implementat ion o f the schema .−−>

<xs:schema targetNamespace=” h t t p : // c c l . ee . byu . edu”elementFormDefault=” q u a l i f i e d ” attr ibuteFormDefaul t=” q u a l i f i e d ”

20 xmlns :xs=” h t t p : //www. w3 . org /2001/XMLSchema” xmlns :chrec=” h t tp : // c c l . ee .byu . edu”>

<xs:complexType name=” parameterExtensionType ”><xs : annota t i on>

<xs :documentat ion>25 This type prov ide s CHREC XML ext en s i on s to IP−XACT

f o r r e s o l v i n g minimum and maximum va lues on parameters . IP−XACT1.4

only a l l ows parameters to have s t a t i c minimum and maximum va lues .This ex t en s i on s a l l ows min and max va lues to depend on othere lements va lue s or on mathematical e x p r e s s i o n s as de f ined by an

30 XPath Express ion . I t a l s o a l l ows parameters to be tagged as HDLparameters . This means that the parameter i s an ac tua l parameterthat must be s e t in generated HDL. In VHDL t h i s means that theparameter i s a g e n e r i c in the VHDL and must be proper ly

ove rwr i t t en .</ xs :documentat ion>

35 </ xs : annota t i on><xs : s equence>

<xs : e l ement name=”isHDLParameter” maxOccurs=”1” minOccurs=”0”><xs : annota t i on>

<xs :documentat ion>40 This i s a tag that has no content . I f the tag i s

107

present in the XML f o r a p a r t i c u l a r parameter i t i si n t e r p r e t e d

that that parameter i s an HDL parameter and should beove rwr i t t en

in generated code .</ xs :documentat ion>

45 </ xs : annota t i on></ xs : e l ement><xs : e l ement name=”dependentMinimum” type=” x s : s t r i n g ”

maxOccurs=”1” minOccurs=”0”><xs : annota t i on>

50 <xs :documentat ion>This i s an XPath expr e s s i on supply ing ther e s u l t a n t va lue f o r the conta in ing element in terms o f otherp r o p e r t i e s in the conta in ing f i l e .

</ xs :documentat ion>55 </ xs : annota t i on>

</ xs : e l ement><xs : e l ement name=”dependentMaximum” type=” x s : s t r i n g ”

maxOccurs=”1” minOccurs=”0”><xs : annota t i on>

60 <xs :documentat ion>This i s an XPath expr e s s i on supply ing ther e s u l t a n t va lue f o r the conta in ing element in terms o f otherp r o p e r t i e s in the conta in ing f i l e .

</ xs :documentat ion>65 </ xs : annota t i on>

</ xs : e l ement></ xs : s equence>

</ xs:complexType></ xs:schema>

C.3 High-Level Datatypes

This file the high-level datatypes. It shows types for bit vector, strings, integers,floating point, fixed point, character, Boolean and user custom types.

CHRECExt/highLevelDataTypes.xsd

1 <?xml version=” 1 .0 ” encoding=”UTF−8”?>< !−−// Des c r i p t i on : highLevelDataTypes . xsd// Author: Brigham Young Univers i t y , CHREC B1 , Adam Arnesen// Vers ion: 2 .0

6 // Date: 2010/12/20//// Copyright ( c ) 2010 , Brigham Young Un i v e r s i t y Con f i gurab l e Computing Lab

, A l l r i g h t s r e s e rved .// h t t p : // c c l . ee . byu . edu//

11 // This source f i l e i s prov ided on an AS IS ba s i s . Brigham YoungUn i ve r s i t y d i s c l a ims

// ANYWARRANTY EXPRESS OR IMPLIED INCLUDING ANYWARRANTY OF// MERCHANTABILITY AND FITNESS FOR USE FOR A PARTICULAR PURPOSE.

108

// The user o f the source f i l e s h a l l indemnify and ho ld Brigham YoungUn i ve r s i t y harmless

// from any damages or l i a b i l i t y a r i s i n g out o f the use t h e r e o f or theperformance or

16 // implementat ion or p a r t i a l implementat ion o f the schema .−−>

<xs:schema targetNamespace=” h t t p : // c c l . ee . byu . edu”elementFormDefault=” q u a l i f i e d ” attr ibuteFormDefaul t=” q u a l i f i e d ”xmlns :xs=” h t t p : //www. w3 . org /2001/XMLSchema” xmlns :chrec=” h t t p : // c c l . ee .

byu . edu”>21 <x s : i n c l u d e schemaLocation=” c o n f i g u r a b l e . xsd”></ x s : i n c l u d e>

<x s : i n c l u d e schemaLocation=”commonElements . xsd”></ x s : i n c l u d e>< !−− ============================= −−>< !−− complexType: portsDataTypeType −−>< !−− ============================= −−>

26 <xs:complexType name=”portsDataTypeType”><xs : annota t i on>

<xs :documentat ion>This type conta in s a s e t o f high−l e v e l port datatypes .</ xs :documentat ion>

</ xs : annota t i on>31 <xs : s equence>

<xs : e l ement name=”portDataType” type=” chrec:portDataTypeType ”maxOccurs=”unbounded” />

</ xs : s equence></ xs:complexType>

36< !−− ============================= −−>< !−− complexType: portDataTypeType −−>< !−− ============================= −−><xs:complexType name=”portDataTypeType”>

41 <xs : annota t i on><xs :documentat ion>

This type d e s c r i b e s a core data type . For a datatype there are 2 mandatory e l ement s :1) name −> a name f o r the data type used to r e f e r e n c e the type

with in the XML ( Ex: s ing l eB i tWire ) .46 Data types can be de s c r ibed with more d e t a i l .

The f o l l o w i n g can a l s o d e s c r i b e the data type :1) types −> the port can be a s s o c i a t e d with one o f the f o l l o w i n g

pre−de f ined data t y p e s :a ) s t r i n gb) i n t −> has a ’ s i gn ’ a s s o c i a t e d

51 c ) f l o a t i n g po int −> assumes 1 b i t f o r s ign , c o n f i g u r a b l e numbero f f r a c t i o n / exponent b i t s

d) f i x e d po int −> has a ’ s i gn ’ and c o n f i g u r a b l e number o ff r a c t i o n b i t s

e ) charac t e r (8 b i t ASCI)f ) booleang ) a custom type −> any number o f custom bit−maping f i e l d s can

be c rea ted .56 </ xs :documentat ion>

</ xs : annota t i on><xs : s equence>

<xs :group r e f=”chrec:nameOnlyGroup” />

109

<x s : c h o i c e minOccurs=”1”>61 <xs : e l ement name=” bi tVector ” n i l l a b l e=” true ” />

<xs : e l ement name=” s t r i n g ” type=” chre c : s t r i ngType ” /><xs : e l ement name=” i n t ” type=” chrec : in tType ” /><xs : e l ement name=” f l o a t i n g P o i n t ” type=” chr e c : f l o a t i ngPo in tType ” /><xs : e l ement name=” f i x edPo in t ” type=” chrec : f i xedPo intType ” />

66 <xs : e l ement name=” charac t e r ” type=” chrec : characte rType ” /><xs : e l ement name=” boolean ” type=” chrec :booleanType ” /><xs : e l ement name=”custom” type=” chrec:customType ” />

</ x s : c h o i c e></ xs : s equence>

71 </ xs:complexType>

< !−− ============================= −−>< !−− complexType: corePortDataTypes −−>< !−− ============================= −−>

76 <xs:complexType name=” str ingType ”><xs : annota t i on>

<xs :documentat ion>I f t h i s element i s pre sent the port i s o f types t r i n g as per VHDL s t r i n g typing .

81 </ xs :documentat ion></ xs : annota t i on>

</ xs:complexType>

< !−− ============================= −−>86 < !−− complexType: corePortDataTypes −−>

< !−− ============================= −−><xs:complexType name=” intType ”>

<xs : annota t i on><xs :documentat ion>

91 This type d e s c r i b e s the i n t data type . A ’ s i gn ’a t t r i b u t e i s r equ i r ed . I f the s i gn i s dependent on a parameter ( asi s the case with many COREGen co r e s ) , @dependent and @dependencya t t r i b u t e s should be used .

</ xs :documentat ion>96 </ xs : annota t i on>

<xs :a t t r ibuteGroup r e f=” c h r e c : c o n f i g u r a b l e ” /><x s : a t t r i b u t e name=” s i gn ” type=” chrec : in tS ignType ” use=” requ i r ed ” />

</ xs:complexType>

101 < !−− ============================= −−>< !−− complexType: corePortDataTypes −−>< !−− ============================= −−><xs:complexType name=” f loat ingPo intType ”>

<xs : annota t i on>106 <xs :documentat ion>

The f l o a t i n g po int type i s s i m i l a r to the IEEE standard f o rf l o a t i n g po int

r e p r e s e n t a t i o n s . I t has three f i e l d s , [ 1 s i gn b i t ] [ k b i t s f o rexponent ] [ n b i t s f o r f r a c t i o n o f s i g n i f i c a n d ] . The only s p e c i f i e r

weneed i s the k b i t s f o r the exponent ( s i n c e we assume only 1 s i gn

bit ,

110

111 and the t o t a l b i twidth i s s p e c i f i e d by the ’ b i tVector ’ )</ xs :documentat ion>

</ xs : annota t i on><xs : s equence>

<x s : c h o i c e>116 <xs : e l ement name=”numExponentBits” type=” chre c : con f i gu rab l eType ”

default=”8” /><xs : e l ement name=” numFractionBits ” type=” chrec : con f i gu rab l eType ”

default=”23” /></ x s : c h o i c e>

121 <xs : e l ement name=” guardBit ” minOccurs=”0” /><xs : e l ement name=” roundBit ” minOccurs=”0” /><xs : e l ement name=” s t i c k y B i t ” minOccurs=”0” /><xs : e l ement name=”roundingScheme” type=” chrec :roundingType ”

minOccurs=”0” />126 </ xs : s equence>

</ xs:complexType>

< !−− ============================= −−>< !−− complexType: corePortDataTypes −−>

131 < !−− ============================= −−><xs:complexType name=” f ixedPointType ”>

<xs : annota t i on><xs :documentat ion>

The f i x e d po int has three important a t t r i b u t e s : b i t s be f o r edecimal

136 ( i n t B i t s ) , b i t s a f t e r decimal ( f r a c B i t s ) , and t o t a l b i t s ( Ex:11010.11110100010) S ince the t o t a l number i f b i t s i s known (

s p e c i f i e dby the ’ b i tVector ’ ) , only ’ i n t B i t s ’ or ’ f r a c B i t s ’ i s r equ i r ed . Thevalue o f both ’ i n t B i t s ’ and ’ f r a c B i t s ’ can be determined by a

parameter( ’ i n tB i t s Re f ’ and ’ f r a c B i t s R e f ’ ) or by a math expr e s s i on

141 ( ’ i n tB i t sEx pr e s s i on ’ and ’ f r a c B i t s E x p r e s s i o n ’ ) . A ’ s i gn ’ a t t r i b u t ei s

r equ i r ed . I f the s i gn i s dependent on a parameter ( as i s the casewith

many COREGen co r e s ) , the ’ s i gn ’ i s s e t to ’ dependent ’ and the’ dependentSigns ’ element i s used .

</ xs :documentat ion>146 </ xs : annota t i on>

<xs : s equence><x s : c h o i c e>

<xs : e l ement name=” i n t B i t s ” type=” chrec : con f i gu rab l eType ” /><xs : e l ement name=” f r a c B i t s ” type=” chrec : con f i gu rab l eType ” />

151 </ x s : c h o i c e><xs : e l ement name=” s ignRef ” type=” chrec : con f i gu rab l eType ”

minOccurs=”0” maxOccurs=”1”/><xs : e l ement name=”roundingScheme” type=” chrec :roundingType ”

minOccurs=”0” maxOccurs=”1”/>156 </ xs : s equence>

<x s : a t t r i b u t e name=” s i gn ” type=” chrec : in tS ignType ” use=” requ i r ed ” /></ xs:complexType>

111

< !−− ============================= −−>161 < !−− complexType: corePortDataTypes −−>

< !−− ============================= −−><xs:complexType name=” characterType ”>

<xs : annota t i on><xs :documentat ion>

166 I f t h i s element i s pre sent the port i s o f typecharac t e r as per VHDL charac t e r typing .

</ xs :documentat ion></ xs : annota t i on>

</ xs:complexType>171

< !−− ============================= −−>< !−− complexType: corePortDataTypes −−>< !−− ============================= −−><xs:complexType name=”booleanType”>

176 <xs : annota t i on><xs :documentat ion>

I f t h i s element i s pre sent the port i s o f typeboolean as per VHDL s t r i n g typing .

</ xs :documentat ion>181 </ xs : annota t i on>

</ xs:complexType>

< !−− ============================= −−>< !−− complexType: corePortDataTypes −−>

186 < !−− ============================= −−><xs:complexType name=”customType”>

<xs : annota t i on><xs :documentat ion>

This type i s to be used f o r types that are not191 commonly found or are types that are s p e c i f i c to a

c e r t a i n HDL f i l e .This type i s b u i l t o f a s e t o f ’ f i e l d s ’ . A f i e l d i s s imply a s e t

o fb i t s with a name .A f i e l d a l s o has a s p e c i f i e d b i t range which

196 i n d i c a t e s the l o c a t i o n o f the f i e l d with in the o v e r a l lword .

</ xs :documentat ion></ xs : annota t i on><xs : s equence>

201 <xs : e l ement name=” f i e l d s ” type=” c h r e c : f i e l d s T y p e ” /></ xs : s equence>

</ xs:complexType>

< !−− ============================= −−>206 < !−− s impleType: intSignType −−>

< !−− ============================= −−><xs :s impleType name=” intSignType ”>

<xs : annota t i on><xs :documentat ion>This type l i s t s a l l b inary i n t e g e r unsigned / s igned

211 types .</ xs :documentat ion></ xs : annota t i on>

112

<x s : r e s t r i c t i o n base=” xs : token ”><xs :enumerat ion value=” unsigned ” /><xs :enumerat ion value=”1sComplement” />

216 <xs :enumerat ion value=”2sComplement” /><xs :enumerat ion value=” signMagnitude ” /><xs :enumerat ion value=” dependent ” />

</ x s : r e s t r i c t i o n></ xs :s impleType>

221< !−− ============================= −−>< !−− s impleType: roundingType −−>< !−− ============================= −−><xs :s impleType name=”roundingType”>

226 <xs : annota t i on><xs :documentat ion>This type l i s t s a l l p o s s i b l e rounding types .</ xs :documentat ion>

</ xs : annota t i on><x s : r e s t r i c t i o n base=” xs : token ”>

231 <xs :enumerat ion value=”RoundToNearestEven” /><xs :enumerat ion value=”RoundToward0” /><xs :enumerat ion value=”RoundToward+I n f i n i t y ” /><xs :enumerat ion value=”RoundToward−I n f i n i t y ” />

</ x s : r e s t r i c t i o n>236 </ xs :s impleType>

< !−− ============================= −−>< !−− complexType: f i e l d sType −−>< !−− ============================= −−>

241 <xs:complexType name=” f i e l d sType ”><xs : annota t i on>

<xs :documentat ion>This type i n c l u d e s a s e t o f custom data typef i e l d s .</ xs :documentat ion>

</ xs : annota t i on>246 <xs : s equence>

<xs : e l ement name=” f i e l d ” type=” c h r e c : f i e l d T y p e ” maxOccurs=”unbounded” />

</ xs : s equence></ xs:complexType>

251 < !−− ============================= −−>< !−− complexType: corePortDataTypes −−>< !−− ============================= −−><xs:complexType name=” f i e ldType ”>

<xs : annota t i on>256 <xs :documentat ion>

This type d e s c r i b e s a custom data type f i e l d . Thef i e l d has a name and one or more i d e n t i f i e d abso lu t e b i t ranges .

Inother words a s i n g l e f i e l d can be i n t e r s p e r s e d among other f i e l d s( Ex: a s i n g l e f i e l d can be a l l even b i t s − which would r e q u i r e a

261 number o f ’ f i e ldRange ’ e lements ) . Note that a ’ f i e ldRange ’r e q u i r e s

a ’ l e f t ’ and a ’ r i g h t ’ and i s not merely a b i twidth . The ’ l e f t ’and

113

’ r i g h t ’ va lue s are abso lu t e in terms o f the f u l l port b i twidth .</ xs :documentat ion>

</ xs : annota t i on>266 <xs : s equence>

<xs :group r e f=” chrec:nameGroupOptional ” /><xs : e l ement name=” f i e ldRange ” type=” chrec :vectorType ”

maxOccurs=”1” minOccurs=”1”/></ xs : s equence>

271 </ xs:complexType></ xs:schema>

C.4 H-SDF Interface Definitions

This file defines the description of the H-SDF model of the core. It includes thelatency, data introduction interval and sample delay on a core.

CHRECExt/hsdfInterface.xsd

<?xml version=” 1 .0 ” encoding=”UTF−8”?>< !−−

3 // Des c r i p t i on : h s d f I n t e r f a c e . xsd// Author: Brigham Young Univers i t y , CHREC B1 , Adam Arnesen// Vers ion: 2 .0// Date: 2010/12/20//

8 // Copyright ( c ) 2010 , Brigham Young Un i v e r s i t y Con f i gurab l e Computing Lab, A l l r i g h t s r e s e rved .

// h t t p : // c c l . ee . byu . edu//// This source f i l e i s prov ided on an AS IS ba s i s . Brigham Young

Un i ve r s i t y d i s c l a ims// ANYWARRANTY EXPRESS OR IMPLIED INCLUDING ANYWARRANTY OF

13 // MERCHANTABILITY AND FITNESS FOR USE FOR A PARTICULAR PURPOSE.// The user o f the source f i l e s h a l l indemnify and ho ld Brigham Young

Un i ve r s i t y harmless// from any damages or l i a b i l i t y a r i s i n g out o f the use t h e r e o f or the

performance or// implementat ion or p a r t i a l implementat ion o f the schema .−−>

18 <xs:schema targetNamespace=” h t t p : // c c l . ee . byu . edu”elementFormDefault=” q u a l i f i e d ” attr ibuteFormDefaul t=” q u a l i f i e d ”xmlns :xs=” h t t p : //www. w3 . org /2001/XMLSchema” xmlns :chrec=” h t t p : // c c l . ee .

byu . edu”>

<xs:complexType name=” hsdfBehaviora lExtens ionType ”>23 <xs : annota t i on>

<xs :documentat ion>This type should be used f o r H−SDF with a f i x e dla t ency and data i n t r o d u c t i o n i n t e r v a l .

</ xs :documentat ion>28 </ xs : annota t i on>

<xs : s equence><xs : e l ement name=” d a t a I n t r o d u c t i o n I n t e r v a l ” type=” x s : i n t ”

maxOccurs=”1” minOccurs=”1”>

114

<xs : annota t i on>33 <xs :documentat ion>

This i s the number o f c y c l e s that e l a p s e betweent imes that data i s expected on the inputs to the core .

</ xs :documentat ion></ xs : annota t i on>

38 </ xs : e l ement><xs : e l ement name=” la t ency ” type=” x s : i n t ” maxOccurs=”1”

minOccurs=”1”><xs : annota t i on>

<xs :documentat ion>43 This i s the number o f c l o ck c y c l e s that e l a p s e

from the time that data i s consumed on inputs u n t i lcor re spond ing

data i s produced on output por t s .</ xs :documentat ion>

</ xs : annota t i on>48 </ xs : e l ement>

<xs : e l ement name=” sampleDelay ” type=” x s : i n t ” maxOccurs=”1”minOccurs=”0”><xs : annota t i on>

< !−− TODO: This shou ld be removed when we t r a n s i t i o n to samplede lay

53 b l o c k s . −−><xs :documentat ion>

DEPRECATED: This w i l l be r ep laced with the samplede lay b locks . In cur rent work t h i s i s the element that says i f

theoutputs should be delayed a sample c y c l e from i t s inputs .

58 </ xs :documentat ion></ xs : annota t i on>

</ xs : e l ement><xs : e l ement name=” dataVal id ” type=” c h r e c : s i g n a l A s s o c i a t i o n T y p e ”

maxOccurs=”unbounded” minOccurs=”0”>63 <xs : annota t i on>

<xs :documentat ion>This a s s o c i a t e s the data v a l i d s i g n a l f o r thecore . This i s not a r equ i r ed element , however , i f i t i s notpre sent and a data v a l i d s i g n a l does e x i s t on the core ,

68 f u n c t i o n a l i t y i s not guaranteed .</ xs :documentat ion>

</ xs : annota t i on></ xs : e l ement><xs : e l ement name=” clockEnable ” type=” c h r e c : s i g n a l A s s o c i a t i o n T y p e ”

73 maxOccurs=”1” minOccurs=”0”><xs : annota t i on>

<xs :documentat ion>This a s s o c i a t e s the c l o ck enable s i g n a l f o r thecore . This i s not a r equ i r ed element , however , i f i t i s not

78 pre sent and a c l o ck enable s i g n a l does e x i s t on the core ,f u n c t i o n a l i t y i s not guaranteed f o r the core or f o r the des ign

.</ xs :documentat ion>

</ xs : annota t i on>

115

</ xs : e l ement>83 </ xs : s equence>

</ xs:complexType>

<xs:complexType name=” s igna lAssoc ia t i onType ”><xs : annota t i on>

88 <xs :documentat ion>Used to a s s o c i a t e s i g n a l s .</ xs :documentat ion></ xs : annota t i on><xs : s equence>

<xs : e l ement name=” s i g n a l ” type=” x s : s t r i n g ” maxOccurs=”1”minOccurs=”1” />

93 <xs : e l ement name=” s i g n a l A s s o c i a t i o n ” type=” x s : s t r i n g ”maxOccurs=”unbounded” minOccurs=”0” />

</ xs : s equence></ xs:complexType>

</ xs:schema>

C.5 Port Extensions

The extensions described in this file are included on a port in IP-XACT to categorizeit as a clock, reset, control, data, address, or unknown category. These categories are usedto interface with the LabVIEW FPGA CLIP node [15].

CHRECExt/ports.xsd

<?xml version=” 1 .0 ” encoding=”UTF−8”?>2 < !−−

// Des c r i p t i on : po r t s . xsd// Author: Brigham Young Univers i t y , CHREC B1 , Adam Arnesen// Vers ion: 2 .0// Date: 2010/12/20

7 //// Copyright ( c ) 2010 , Brigham Young Un i v e r s i t y Con f i gurab l e Computing Lab

, A l l r i g h t s r e s e rved .// h t t p : // c c l . ee . byu . edu//// This source f i l e i s prov ided on an AS IS ba s i s . Brigham Young

Un i ve r s i t y d i s c l a ims12 // ANYWARRANTY EXPRESS OR IMPLIED INCLUDING ANYWARRANTY OF

// MERCHANTABILITY AND FITNESS FOR USE FOR A PARTICULAR PURPOSE.// The user o f the source f i l e s h a l l indemnify and ho ld Brigham Young

Un i ve r s i t y harmless// from any damages or l i a b i l i t y a r i s i n g out o f the use t h e r e o f or the

performance or// implementat ion or p a r t i a l implementat ion o f the schema .

17 −−><xs:schema targetNamespace=” h t t p : // c c l . ee . byu . edu”

elementFormDefault=” q u a l i f i e d ” attr ibuteFormDefaul t=” q u a l i f i e d ”xmlns :xs=” h t t p : //www. w3 . org /2001/XMLSchema” xmlns :chrec=” h t t p : // c c l . ee .

byu . edu”><x s : i n c l u d e schemaLocation=”commonElements . xsd” />

22<xs:complexType name=” portExtensionType ”>

116

<xs : annota t i on><xs :documentat ion>

This prov ide s three primary ex t en s i on s f o r port27 d e s c r i p t i o n . A high−l e v e l type , r e s e t va lue s f o r ports , and

ac a t e g o r i z a t i o n o f por t s .

</ xs :documentat ion></ xs : annota t i on>

32 <xs : s equence><xs : e l ement name=” highLevelType ” type=” chrec :ba s i cS t r ingType ”

minOccurs=”0” /><xs : e l ement name=” rese tVa lue ” type=” chrec : con f i gu rab l eType ”

minOccurs=”0” />37 <xs : e l ement r e f=” chrec :por tCategory ” />

</ xs : s equence></ xs:complexType>

<xs : e l ement name=” portCategory ”>42 <xs : annota t i on>

<xs :documentat ion>This element a l l ows port to be c a t e g o r i z e daccord ing to t h e i r usage type . These c a t e g o r i z a t i o n s aroseo r i g i n a l l y from the need to match LabVIEW FPGA CLIP node XML but

are47 more g e n e r a l l y a p p l i c a b l e f o r c a t e g o r i z a t i o n o f pro t s . .

</ xs :documentat ion></ xs : annota t i on><xs :s impleType>

<x s : r e s t r i c t i o n base=” xs : token ”>52 <xs :enumerat ion value=” c l o ck ” />

<xs :enumerat ion value=” r e s e t ” /><xs :enumerat ion value=” c o n t r o l ” /><xs :enumerat ion value=” data ” /><xs :enumerat ion value=” address ” />

57 <xs :enumerat ion value=”unknown” /></ x s : r e s t r i c t i o n>

</ xs :s impleType></ xs : e l ement>

</ xs:schema>

C.6 Supporting Code

These two files provide support to the others. They are used in files that import themand provide basic elements that are common to each of the other schema files. They alsoallow the extension to use the parameterization and dependency support that is provided byIP-XACT.

CHRECExt/configurable.xsd

<?xml version=” 1 .0 ” encoding=”UTF−8”?>< !−−// Des c r i p t i on : c on f i g u r a b l e . xsd

4 // Author: Brigham Young Univers i t y , CHREC B1 , Adam Arnesen

117

// Vers ion: 2 .0// Date: 2010/12/20//// Copyright ( c ) 2010 , Brigham Young Un i v e r s i t y Con f i gurab l e Computing Lab

, A l l r i g h t s r e s e rved .9 // h t t p : // c c l . ee . byu . edu

//// This source f i l e i s prov ided on an AS IS ba s i s . Brigham Young

Un i ve r s i t y d i s c l a ims// ANYWARRANTY EXPRESS OR IMPLIED INCLUDING ANYWARRANTY OF// MERCHANTABILITY AND FITNESS FOR USE FOR A PARTICULAR PURPOSE.

14 // The user o f the source f i l e s h a l l indemnify and ho ld Brigham YoungUn i ve r s i t y harmless

// from any damages or l i a b i l i t y a r i s i n g out o f the use t h e r e o f or theperformance or

// implementat ion or p a r t i a l implementat ion o f the schema .−−>

<xs:schema targetNamespace=” h t t p : // c c l . ee . byu . edu”19 elementFormDefault=” q u a l i f i e d ” attr ibuteFormDefau l t=” q u a l i f i e d ”

xmlns :xs=” h t t p : //www. w3 . org /2001/XMLSchema” xmlns :chrec=” h t t p : // c c l . ee .byu . edu”>

<x s : i n c l u d e schemaLocation=”commonElements . xsd” />

<x s : a t t r i b u t e name=” r e s o l v e ” type=” chrec : r e so l v eType ”24 default=” s t a t i c ”>

<xs : annota t i on><xs :documentat ion>Determines how a property value i s r e s o l v e d .</ xs :documentat ion>

</ xs : annota t i on>29 </ x s : a t t r i b u t e>

<x s : a t t r i b u t e name=” id ” type=” xs : ID ”><xs : annota t i on>

<xs :documentat ion>34 ID a t t r i b u t e f o r unique ly i d e n t i f y i n g an element

with in i t s document .</ xs :documentat ion>

</ xs : annota t i on></ x s : a t t r i b u t e>

39<x s : a t t r i b u t e name=”dependency” type=” x s : s t r i n g ”>

<xs : annota t i on><xs :documentat ion>Required on p r o p e r t i e s with a r e s o l v e = ” dependent

”a t t r i b u t e . This i s an XPath expr e s s i on supply ing the r e s u l t a n t

value44 f o r the conta in ing element in terms o f other p r o p e r t i e s in the

conta in ing f i l e . </ xs :documentat ion></ xs : annota t i on>

</ x s : a t t r i b u t e>

49 <xs :a t t r ibuteGroup name=” c o n f i g u r a b l e ”><xs : annota t i on>

<xs :documentat ion>

118

Base s e t o f a t t r i b u t e s f o r an element to bec o n f i g u r a b l e . This i s from IP−XACT

54 </ xs :documentat ion></ xs : annota t i on><x s : a t t r i b u t e r e f=” c h r e c : r e s o l v e ” /><x s : a t t r i b u t e r e f=” c h r e c : i d ” /><x s : a t t r i b u t e r e f=” chrec :dependency ” />

59 </ xs :a t t r ibuteGroup></ xs:schema>

CHRECExt/commonElements.xsd

<?xml version=” 1 .0 ” encoding=”UTF−8”?>< !−−// Des c r i p t i on : commonElements . xsd// Author: Brigham Young Univers i t y , CHREC B1 , Adam Arnesen

5 // Vers ion: 2 .0// Date: 2010/12/20//// Copyright ( c ) 2010 , Brigham Young Un i v e r s i t y Con f i gurab l e Computing Lab

, A l l r i g h t s r e s e rved .// h t t p : // c c l . ee . byu . edu

10 //// This source f i l e i s prov ided on an AS IS ba s i s . Brigham Young

Un i ve r s i t y d i s c l a ims// ANYWARRANTY EXPRESS OR IMPLIED INCLUDING ANYWARRANTY OF// MERCHANTABILITY AND FITNESS FOR USE FOR A PARTICULAR PURPOSE.// The user o f the source f i l e s h a l l indemnify and ho ld Brigham Young

Un i ve r s i t y harmless15 // from any damages or l i a b i l i t y a r i s i n g out o f the use t h e r e o f or the

performance or// implementat ion or p a r t i a l implementat ion o f the schema .−−>

<xs:schema targetNamespace=” h t t p : // c c l . ee . byu . edu”elementFormDefault=” q u a l i f i e d ” attr ibuteFormDefaul t=” q u a l i f i e d ”

20 xmlns :xs=” h t t p : //www. w3 . org /2001/XMLSchema” xmlns :chrec=” h t tp : // c c l . ee .byu . edu”>

<x s : i n c l u d e schemaLocation=” c o n f i g u r a b l e . xsd”></ x s : i n c l u d e>

< !−− ============================= −−>< !−− complexType: con f i gurab l eType −−>

25 < !−− ============================= −−><xs:complexType name=” conf igurab leType ”>

<xs : annota t i on><xs :documentat ion>

This type prov ide s a c o n f i g u r a b l e type f o r any30 non−s t a t i c va lue . This type i s s t r o n g l y based on the IP−XACT

c o n f i g u r a b l e type .</ xs :documentat ion>

</ xs : annota t i on><xs : s impleContent>

35 <x s : e x t e n s i o n base=” chre c :ba s i cS t r ingType ”><xs :a t t r ibuteGroup r e f=” c h r e c : c o n f i g u r a b l e ” />

</ x s : e x t e n s i o n>

119

</ xs : s impleContent></ xs:complexType>

40< !−− ============================= −−>< !−− s impleType: bas i cS t r ingType −−>< !−− ============================= −−><xs :s impleType name=” bas icStr ingType ”>

45 <xs : annota t i on><xs :documentat ion>

This i s s imply a wrapper f o r the normal XML s t r i n gtype except that i t r e q u i r e s that the re i s no white space .

</ xs :documentat ion>50 </ xs : annota t i on>

<x s : r e s t r i c t i o n base=” x s : s t r i n g ”><xs :whi teSpace value=” c o l l a p s e ” />

</ x s : r e s t r i c t i o n></ xs :s impleType>

55< !−− ============================= −−>< !−− group: nameOnlyGroup −−>< !−− ============================= −−><xs :group name=”nameOnlyGroup”>

60 <xs : annota t i on><xs :documentat ion>

This group simply prov ide s a name and d e s c r i p t i o nf o r any element .

</ xs :documentat ion>65 </ xs : annota t i on>

<xs : s equence><xs : e l ement name=”name” type=” chrec :ba s i cS t r ingType ” /><xs : e l ement name=” d e s c r i p t i o n ” type=” chrec :ba s i cS t r ingType ”

minOccurs=”0” />70 </ xs : s equence>

</ xs :group>

< !−− ============================= −−>< !−− s impleType: reso lveType −−>

75 < !−− ============================= −−><xs :s impleType name=” reso lveType ”>

<xs : annota t i on><xs :documentat ion>

Determines how a property i s r e s o l v e d .80 1) s t a t i c −

Property value i s inc luded in the XML f i l e . I t cannot becon f i gu r ed .2) user − Property content can be modi f i ed throughc o n f i g u r a t i o n .

85 Mod i f i c a t i on s w i l l be saved with core i n s t a n t i a t i o n s with in ades ign

or can be used a f t e r being dynamical ly s e t by the user ingene ra t ing

a s i n g l e core .3) dependent − The value i s supp l i ed by anotherparameter .

120

90 4) genera tor − Generators may modify t h i s property .Mod i f i c a t i on s aresaved in i n s t a n t i a t i o n s o f the core with in ades ign .

</ xs :documentat ion>95 </ xs : annota t i on>

<x s : r e s t r i c t i o n base=” xs : token ”><xs :enumerat ion value=” s t a t i c ” /><xs :enumerat ion value=” user ” /><xs :enumerat ion value=” dependent ” />

100 <xs :enumerat ion value=” generato r ” /></ x s : r e s t r i c t i o n>

</ xs :s impleType>

< !−− ============================= −−>105 < !−− group: nameGroupOptional −−>

< !−− ============================= −−><xs :group name=”nameGroupOptional”>

<xs : annota t i on><xs :documentat ion>

110 This group a l l ows a source name to be attached to aname group .1) name −> a unique name2) sourceName −> Thiselement i s

115 o p t i o na l .E i ther the use o f t h i s element doesn ’ t makesense (EX: af i l e ) , or i ti s used f o r d i s p l a y purposes . When used

120 f o r d i s p l a ypurposes ,t y p i c a l l y i t i n c l u d e s a few words prov id ing amore d e t a i l e dand/ or

125 user−f r i e n d l y name than the ’name ’ .3) d e s c r i p t i o n −> Ful ld e s c r i p t i o n s t r i ng , t y p i c a l l y f o r documentation .

</xs:documentation></xs :annotat ion>

130 <xs : sequence><xs : e l ement name=”name” type=”chrec :ba s i cS t r ingType ” /><xs : e l ement name=”sourceName” type=”chrec :ba s i cS t r ingType ”

minOccurs=”0” /><xs : e l ement name=”d e s c r i p t i o n ” type=”chrec :ba s i cS t r ingType ”

135 minOccurs=”0” /></xs : sequence>

</xs :group>

<!−− ============================= −−>140 <!−− complexType: vectorType −−>

<!−− ============================= −−><xs:complexType name=”vectorType”>

<xs :annotat ion>

121

<xs:documentation>145 This type d e s c r i b e s the i n d i c e s f o r a vectored port

( such as VHDL port s ) . The va lues are c o n f i g u r a b l e . The vec tor i sused in s t ead o f j u s t a s i n g l e b i twidth value because o f t enbit−s l i c e s o f a s i g n a l i s r equ i r ed when s i g n a l s are being

connected .</xs:documentation>

150 </xs :annotat ion><xs : sequence>

<xs : e l ement name=” l e f t ” type=”chrec : con f i gu rab l eType ” /><xs : e l ement name=”r i g h t ” type=”chrec : con f i gu rab l eType ” />

</xs : sequence>155 </xs:complexType>

</xs:schema>

122

Appendix D

Generated VHDL from Ogre

This appendix contains the top-level VHDL and the FSM for a radio design that weregenerated by the Ogre system discussed in Chapter 5. Pains were taken in the Ogre systemto create human-readable VHDL as demonstrate by the files below.

D.1 Top-Level VHDL

vhdl/chrec qpsk S15 mod.vhd

l ibrary i e e e ;use i e e e . s t d l o g i c 1 1 6 4 . a l l ;use i e e e . numer ic std . a l l ;

4entity chrec qpsk S15 mod i s

port (c l k : in s t d l o g i c ;r e a l i n : in s t d l o g i c v e c t o r (11 downto 0) ;

9 r s t : in s t d l o g i c ;v a l i d I n : in s t d l o g i c ;imag in : in s t d l o g i c v e c t o r (11 downto 0) ;y1 : out s t d l o g i c v e c t o r (11 downto 0) ;s t robe : out s t d l o g i c ;

14 x1 : out s t d l o g i c v e c t o r (11 downto 0) ;dec y : out s t d l o g i c v e c t o r (1 downto 0) ;dec x : out s t d l o g i c v e c t o r (1 downto 0)) ;

end chrec qpsk S15 mod ;19

architecture Generated of chrec qpsk S15 mod i s

24 component s i g t o s l v i sgeneric (

WIDTH : i n t e g e r := 8) ;

port (29 s i g I n : in s igned (WIDTH − 1 downto 0) ;

slvOut : out s t d l o g i c v e c t o r (WIDTH − 1 downto 0)) ;

end component ;

34

123

component decis ionParam i sgeneric (

RADIO TYPE : i n t e g e r := 2) ;

39 port (y : in s igned ;x : in s igned ;d e c i s i o n y : out s igned ;d e c i s i o n x : out s igned

44 ) ;end component ;

component nco v2 0 i s49 generic (

SAMPLES PER SYMBOL : i n t e g e r := 2) ;

port (r s t : in s t d l o g i c ;

54 x : in s igned ;c l k : in s t d l o g i c ;v a l i d I n : in s t d l o g i c ;ce : in s t d l o g i c ;mu : out unsigned ;

59 s t robe : out s t d l o g i c) ;

end component ;

64 component regEnSigned i sgeneric (

width : i n t e g e r := 8) ;

port (69 c l k : in s t d l o g i c ;

en : in s t d l o g i c ;d : in s igned ( width − 1 downto 0) ;r s t : in s t d l o g i c ;q : out s igned ( width − 1 downto 0)

74 ) ;end component ;

component s l v t o s i g i s79 generic (

WIDTH : i n t e g e r := 8) ;

port (s l v I n : in s t d l o g i c v e c t o r (WIDTH − 1 downto 0) ;

84 sigOut : out s igned (WIDTH − 1 downto 0)) ;

end component ;

124

89 component l o o p f i l t e r l a t 2 v 2 0 i sgeneric (

kPrec i s i on : i n t e g e r := 44 ;phaseDetectorGain : r e a l := 6 . 0 ;samplesPerSymbol : i n t e g e r := 2 ;

94 accumulationWidth : i n t e g e r := 32 ;order : i n t e g e r := 2 ;loopBandwidth : r e a l := 0 . 0 1 ;loopDampingFactor : r e a l := 1 . 0 ;DDSGain : r e a l := −1.0

99 ) ;port (

e r r o r I n : in s igned ;c l k : in s t d l o g i c ;ce : in s t d l o g i c ;

104 v a l i d I n : in s t d l o g i c ;r s t : in s t d l o g i c ;e s t imate : out s igned ( accumulationWidth downto 0)) ;

end component ;109

component calculateMu i sgeneric (

samplesPerSymbol : i n t e g e r := 2114 ) ;

port (v a l i d I n : in s t d l o g i c ;c l k : in s t d l o g i c ;r s t : in s t d l o g i c ;

119 ce : in s t d l o g i c ;s t robe : in s t d l o g i c ;preMu : in unsigned ;mu : out unsigned) ;

124 end component ;

component DDS AdjustableFrequency i sgeneric (

129 phaseOf f s e t : r e a l := 0 . 0 ;romAddrWidth : i n t e g e r := 12 ;ga in : r e a l := 1 .0) ;

port (134 ce : in s t d l o g i c ;

r s t : in s t d l o g i c ;c l k : in s t d l o g i c ;v a l i d I n : in s t d l o g i c ;data : in s igned ;

139 cos : out s igned (17 downto 0) ;s i n : out s igned (17 downto 0)) ;

end component ;

125

144component i n t e r p o l a t o r c u b i c 1 2 d s p 4 8 s p i p e d i s

port (ce : in s t d l o g i c ;x : in s igned ;

149 r s t : in s t d l o g i c ;mu : in unsigned ;c l k : in s t d l o g i c ;v a l i d I n : in s t d l o g i c ;y : out s igned

154 ) ;end component ;

component s i g n e d f i x e d p o i n t r e s i z e i s159 generic (

output l ength : i n t e g e r := 12 ;o u t p u t i n t e g r a l b i t s : i n t e g e r := 2 ;i n p u t i n t e g r a l b i t s : i n t e g e r := 2 ;i nput l eng th : i n t e g e r := 12

164 ) ;port (

x : in s igned ( input l eng th − 1 downto 0) ;y : out s igned ( output l ength − 1 downto 0)) ;

169 end component ;

component ped i sport (

174 d e c i s i o n y : in s igned ;x : in s igned ;y : in s igned ;s t robe : in s t d l o g i c ;d e c i s i o n x : in s igned ;

179 phaseError : out s igned) ;

end component ;

184 component regEnStdLogic i sport (

en : in s t d l o g i c ;c l k : in s t d l o g i c ;d : in s t d l o g i c ;

189 r s t : in s t d l o g i c ;q : out s t d l o g i c) ;

end component ;

194component TED zero c ro s s ing l a t1 v2 0 i s

generic (

126

samplesPerSymbol : i n t e g e r := 2 ;numOfInputs : i n t e g e r := 2

199 ) ;port (

d e c i s i o n y : in s igned ;c l k : in s t d l o g i c ;d e c i s i o n x : in s igned ;

204 ce : in s t d l o g i c ;x : in s igned ;y : in s igned ;r s t : in s t d l o g i c ;s t robe : in s t d l o g i c ;

209 v a l i d I n : in s t d l o g i c ;t imingError : out s igned) ;

end component ;

214component chrec qpsk S15 mod FSM i s

port (v a l i d I n : in s t d l o g i c ;r s t : in s t d l o g i c ;

219 c l k : in s t d l o g i c ;reg1EN : out s t d l o g i c ;phase f i l terVALIDIN : out s t d l o g i c ;dec x regEN : out s t d l o g i c ;t i m i n g f i l t e r C E : out s t d l o g i c ;

224 x interpolatorVALIDIN : out s t d l o g i c ;ncoVALIDIN : out s t d l o g i c ;x inte rpo la torCE : out s t d l o g i c ;y1RegEN : out s t d l o g i c ;dec y regEN : out s t d l o g i c ;

229 reg2EN : out s t d l o g i c ;reg4EN : out s t d l o g i c ;calculateMuVALIDIN : out s t d l o g i c ;TEDVALIDIN : out s t d l o g i c ;DDSCE : out s t d l o g i c ;

234 reg3EN : out s t d l o g i c ;strobe regEN : out s t d l o g i c ;y interpolatorVALIDIN : out s t d l o g i c ;reg6EN : out s t d l o g i c ;t iming f i l terVALIDIN : out s t d l o g i c ;

239 TEDCE : out s t d l o g i c ;ncoCE : out s t d l o g i c ;y inte rpo la torCE : out s t d l o g i c ;p h a s e f i l t e r C E : out s t d l o g i c ;reg5EN : out s t d l o g i c ;

244 x1RegEN : out s t d l o g i c ;calculateMuCE : out s t d l o g i c ;DDSVALIDIN : out s t d l o g i c) ;

end component ;249

127

component cwRotation i sport (

x : in s igned ;254 y : in s igned ;

s i n : in s igned ;cos : in s igned ;y out : out s igned ;x out : out s igned

259 ) ;end component ;

signal y1Reg q y1 inReg : s igned (11 downto 0) ;signal r e g 4 q r e s i z e 2 x : s igned (12 downto 0) ;

264 signal r e a l i n o u t R e g r e a l i n c o n v e r t e r s l v I n : s t d l o g i c v e c t o r (11downto 0) ;

signal imag in outReg cwRotat ion y : s igned (11 downto 0) ;signal r s t o u t R e g n c o r s t : s t d l o g i c ;signal FSM x inte rpo l a to rCE x in t e rpo l a to r c e : s t d l o g i c ;signal FSM reg5EN reg5 en : s t d l o g i c ;

269 signal FSM DDSVALIDIN DDS validIn : s t d l o g i c ;signal reg5 q DDS data : s igned (18 downto 0) ;signal ca lcu lateMu mu y interpo lator mu : unsigned (16 downto 0) ;signal r eg6 q nco x : s igned (17 downto 0) ;signal nco mu calculateMu preMu : unsigned (17 downto 0) ;

274 signal de c y r eg q dec y inR eg : s igned (1 downto 0) ;signal d e c i s i o n d e c i s i o n x r e s i z e 3 x : s igned (11 downto 0) ;signal s t r o b e r e g q s t r o b e i n R e g : s t d l o g i c ;signal FSM reg1EN reg1 en : s t d l o g i c ;signal FSM t im ing f i l t e rVALIDIN t im ing f i l t e r va l i d In : s t d l o g i c ;

279 signal FSM TEDCE TED ce : s t d l o g i c ;signal val idIn outReg FSM val idIn : s t d l o g i c ;signal FSM reg2EN reg2 en : s t d l o g i c ;signal r e s i z e 3 y d e c x r e g d : s igned (1 downto 0) ;signal ped phaseError reg4 d : s igned (12 downto 0) ;

284 signal FSM calculateMuCE calculateMu ce : s t d l o g i c ;signal FSM dec x regEN dec x reg en : s t d l o g i c ;signal dec yconve r t e r s l vOut dec y inReg : s t d l o g i c v e c t o r (1 downto 0)

;signal FSM y1RegEN y1Reg en : s t d l o g i c ;signal de c x r eg q dec x inR eg : s igned (1 downto 0) ;

289 signal FSM reg4EN reg4 en : s t d l o g i c ;signal t i m i n g f i l t e r e s t i m a t e r e s i z e 1 x : s igned (18 downto 0) ;signal dec xconve r t e r s l vOut dec x inReg : s t d l o g i c v e c t o r (1 downto 0)

;signal y1conver te r s lvOut y1 inReg : s t d l o g i c v e c t o r (11 downto 0) ;signal DDS sin cwRotat ion s in : s i gned (17 downto 0) ;

294 signal F S M p h a s e f i l t e r C E p h a s e f i l t e r c e : s t d l o g i c ;signal FSM reg3EN reg3 en : s t d l o g i c ;signal p h a s e f i l t e r e s t i m a t e r e g 5 d : s igned (18 downto 0) ;signal imag in ou tReg imag inconve r t e r s l v In : s t d l o g i c v e c t o r (11

downto 0) ;signal FSM y interpo latorVALIDIN y interpo lator va l id In : s t d l o g i c ;

299 signal FSM calculateMuVALIDIN calculateMu validIn : s t d l o g i c ;signal FSM phase f i l t e rVALIDIN phase f i l t e r va l i d In : s t d l o g i c ;

128

signal FSM ncoVALIDIN nco validIn : s t d l o g i c ;signal n c o s t r o b e c a l cu l a t eM u s t r o b e : s t d l o g i c ;signal FSM DDSCE DDS ce : s t d l o g i c ;

304 signal DDS cos cwRotation cos : s i gned (17 downto 0) ;signal cwRotat ion y out reg2 d : s igned (11 downto 0) ;signal cwRotat ion x out reg1 d : s igned (11 downto 0) ;signal c l k ou tReg nco c l k : s t d l o g i c ;signal x i n t e r p o l a t o r y d e c i s i o n x : s igned (11 downto 0) ;

309 signal FSM x interpo latorVALIDIN x interpo lator va l id In : s t d l o g i c ;signal F S M t i m i n g f i l t e r C E t i m i n g f i l t e r c e : s t d l o g i c ;signal FSM ncoCE nco ce : s t d l o g i c ;signal r e g 1 q x i n t e r p o l a t o r x : s igned (11 downto 0) ;signal r e g 2 q y i n t e r p o l a t o r x : s igned (11 downto 0) ;

314 signal r e s i z e 4 y d e c y r e g d : s igned (1 downto 0) ;signal x1conver te r s lvOut x1 inReg : s t d l o g i c v e c t o r (11 downto 0) ;signal d e c i s i o n d e c i s i o n y r e s i z e 4 x : s igned (11 downto 0) ;signal r e s i z e 1 y r e g 6 d : s igned (17 downto 0) ;signal TED timingError reg3 d : s igned (11 downto 0) ;

319 signal FSM y inte rpo l a to rCE y in t e rpo l a to r c e : s t d l o g i c ;signal FSM TEDVALIDIN TED validIn : s t d l o g i c ;signal FSM x1RegEN x1Reg en : s t d l o g i c ;signal FSM strobe regEN strobe reg en : s t d l o g i c ;signal FSM dec y regEN dec y reg en : s t d l o g i c ;

324 signal r e g 3 q t i m i n g f i l t e r e r r o r I n : s i gned (11 downto 0) ;signal r ea l in outReg cwRotat i on x : s igned (11 downto 0) ;signal FSM reg6EN reg6 en : s t d l o g i c ;signal r e s i z e 2 y p h a s e f i l t e r e r r o r I n : s igned (14 downto 0) ;signal y i n t e r po l a t o r y y 1R e g d : s igned (11 downto 0) ;

329 signal x1Reg q x1 inReg : s igned (11 downto 0) ;begin

dec yconve r t e r : s i g t o s l vgeneric map(

334 WIDTH => 2)port map(

s i g I n => dec y reg q dec y inReg ,slvOut => dec yconve r t e r s l vOut dec y inReg

339 ) ;

d e c i s i o n : decis ionParamgeneric map(

RADIO TYPE => 4344 )

port map(d e c i s i o n x => d e c i s i o n d e c i s i o n x r e s i z e 3 x ,x => x i n t e r p o l a t o r y d e c i s i o n x ,d e c i s i o n y => d e c i s i o n d e c i s i o n y r e s i z e 4 x ,

349 y => y i n t e r po l a t o r y y 1R e g d) ;

nco : nco v2 0generic map(

354 SAMPLES PER SYMBOL => 2

129

)port map(

r s t => r s t ou tReg nco r s t ,x => reg6 q nco x ,

359 mu => nco mu calculateMu preMu ,v a l i d I n => FSM ncoVALIDIN nco validIn ,s t robe => nco s t robe ca l cu l a t eMu s t robe ,c l k => c lk outReg nco c lk ,ce => FSM ncoCE nco ce

364 ) ;

y1Reg : regEnSignedgeneric map(

width => 12369 )

port map(q => y1Reg q y1 inReg ,r s t => r s t ou tReg nco r s t ,en => FSM y1RegEN y1Reg en ,

374 c l k => c lk outReg nco c lk ,d => y i n t e r po l a t o r y y 1R e g d

) ;

r e a l i n c o n v e r t e r : s l v t o s i g379 generic map(

WIDTH => 12)port map(

s l v I n => r e a l i n o u t R e g r e a l i n c o n v e r t e r s l v I n ,384 sigOut => r ea l in outReg cwRotat i on x

) ;

p h a s e f i l t e r : l o o p f i l t e r l a t 2 v 2 0generic map(

389 phaseDetectorGain => 2 . 0 ,kPre c i s i on => 35 ,samplesPerSymbol => 2 ,accumulationWidth => 18 ,order => 2 ,

394 loopBandwidth => 0 . 03 ,loopDampingFactor => 1 . 0 ,DDSGain => 1 .0

)port map(

399 r s t => r s t ou tReg nco r s t ,ce => F S M p h a s e f i l t e r C E p h a s e f i l t e r c e ,e s t imate => p h a s e f i l t e r e s t i m a t e r e g 5 d ,v a l i d I n => FSM phase f i l t e rVALIDIN phase f i l t e r va l id In ,c l k => c lk outReg nco c lk ,

404 e r r o r I n => r e s i z e 2 y p h a s e f i l t e r e r r o r I n) ;

calculateMu1 : calculateMugeneric map(

130

409 samplesPerSymbol => 2)port map(

r s t => r s t ou tReg nco r s t ,mu => ca lcu lateMu mu y interpo lator mu ,

414 preMu => nco mu calculateMu preMu ,ce => FSM calculateMuCE calculateMu ce ,v a l i d I n => FSM calculateMuVALIDIN calculateMu validIn ,s t robe => nco s t robe ca l cu l a t eMu s t robe ,c l k => c l k ou tReg nco c l k

419 ) ;

x1conver ter : s i g t o s l vgeneric map(

WIDTH => 12424 )

port map(slvOut => x1converter s lvOut x1 inReg ,s i g I n => x1Reg q x1 inReg

) ;429

t i m i n g f i l t e r : l o o p f i l t e r l a t 2 v 2 0generic map(

phaseDetectorGain => 6 . 0 ,kPre c i s i on => 35 ,

434 samplesPerSymbol => 2 ,accumulationWidth => 18 ,order => 2 ,loopBandwidth => 0 . 01 ,loopDampingFactor => 1 . 0 ,

439 DDSGain => −1.0)port map(

r s t => r s t ou tReg nco r s t ,v a l i d I n => FSM t iming f i l t e rVALIDIN t im ing f i l t e r va l i d In ,

444 es t imate => t i m i n g f i l t e r e s t i m a t e r e s i z e 1 x ,c l k => c lk outReg nco c lk ,ce => F S M t i m i n g f i l t e r C E t i m i n g f i l t e r c e ,e r r o r I n => r e g 3 q t i m i n g f i l t e r e r r o r I n

) ;449

DDS : DDS AdjustableFrequencygeneric map(

phaseOf f s e t => 0 . 0 ,ga in => 1 . 0 ,

454 romAddrWidth => 12)port map(

r s t => r s t ou tReg nco r s t ,v a l i d I n => FSM DDSVALIDIN DDS validIn ,

459 data => reg5 q DDS data ,s i n => DDS sin cwRotation sin ,ce => FSM DDSCE DDS ce ,cos => DDS cos cwRotation cos ,

131

c l k => c l k ou tReg nco c l k464 ) ;

d e c y r eg : regEnSignedgeneric map(

width => 2469 )

port map(r s t => r s t ou tReg nco r s t ,q => dec y reg q dec y inReg ,c l k => c lk outReg nco c lk ,

474 d => r e s i z e 4 y d e c y r e g d ,en => FSM dec y regEN dec y reg en

) ;

x i n t e r p o l a t o r : i n t e r p o l a t o r c u b i c 1 2 d s p 4 8 s p i p e d479 port map(

r s t => r s t ou tReg nco r s t ,ce => FSM x inte rpo la to rCE x inte rpo la to r ce ,mu => ca lcu lateMu mu y interpo lator mu ,c l k => c lk outReg nco c lk ,

484 y => x i n t e r p o l a t o r y d e c i s i o n x ,v a l i d I n => FSM x interpo latorVALIDIN x interpo lator va l id In ,x => r e g 1 q x i n t e r p o l a t o r x

) ;

489 reg6 : regEnSignedgeneric map(

width => 18)port map(

494 r s t => r s t ou tReg nco r s t ,q => reg6 q nco x ,c l k => c lk outReg nco c lk ,d => r e s i z e 1 y r e g 6 d ,en => FSM reg6EN reg6 en

499 ) ;

x1Reg : regEnSignedgeneric map(

width => 12504 )

port map(r s t => r s t ou tReg nco r s t ,c l k => c lk outReg nco c lk ,d => x i n t e r p o l a t o r y d e c i s i o n x ,

509 en => FSM x1RegEN x1Reg en ,q => x1Reg q x1 inReg

) ;

y i n t e r p o l a t o r : i n t e r p o l a t o r c u b i c 1 2 d s p 4 8 s p i p e d514 port map(

r s t => r s t ou tReg nco r s t ,mu => ca lcu lateMu mu y interpo lator mu ,

132

v a l i d I n => FSM y interpo latorVALIDIN y interpo lator va l id In ,c l k => c lk outReg nco c lk ,

519 x => r e g 2 q y i n t e r p o l a t o r x ,ce => FSM y inte rpo la to rCE y inte rpo la to r ce ,y => y i n t e r po l a t o r y y 1R e g d

) ;

524 r e s i z e 4 : s i g n e d f i x e d p o i n t r e s i z egeneric map(

output l ength => 2 ,i nput l eng th => 12 ,i n p u t i n t e g r a l b i t s => 2 ,

529 o u t p u t i n t e g r a l b i t s => 2)port map(

y => r e s i z e 4 y d e c y r e g d ,x => d e c i s i o n d e c i s i o n y r e s i z e 4 x

534 ) ;

ped1 : pedport map(

d e c i s i o n x => r e s i z e 3 y d e c x r e g d ,539 phaseError => ped phaseError reg4 d ,

s t robe => nco s t robe ca l cu l a t eMu s t robe ,x => x i n t e r p o l a t o r y d e c i s i o n x ,d e c i s i o n y => r e s i z e 4 y d e c y r e g d ,y => y i n t e r po l a t o r y y 1R e g d

544 ) ;

r e s i z e 2 : s i g n e d f i x e d p o i n t r e s i z egeneric map(

output l ength => 15 ,549 input l eng th => 13 ,

i n p u t i n t e g r a l b i t s => 1 ,o u t p u t i n t e g r a l b i t s => 3

)port map(

554 x => r e g 4 q r e s i z e 2 x ,y => r e s i z e 2 y p h a s e f i l t e r e r r o r I n

) ;

r e s i z e 3 : s i g n e d f i x e d p o i n t r e s i z e559 generic map(

output l ength => 2 ,i nput l eng th => 12 ,i n p u t i n t e g r a l b i t s => 2 ,o u t p u t i n t e g r a l b i t s => 2

564 )port map(

x => d e c i s i o n d e c i s i o n x r e s i z e 3 x ,y => r e s i z e 3 y d e c x r e g d

) ;569

dec xconve r t e r : s i g t o s l v

133

generic map(WIDTH => 2

)574 port map(

s i g I n => dec x reg q dec x inReg ,slvOut => dec xconve r t e r s l vOut dec x inReg

) ;

579 r e s i z e 1 : s i g n e d f i x e d p o i n t r e s i z egeneric map(

output l ength => 18 ,i nput l eng th => 19 ,i n p u t i n t e g r a l b i t s => 1 ,

584 o u t p u t i n t e g r a l b i t s => 0)port map(

x => t i m i n g f i l t e r e s t i m a t e r e s i z e 1 x ,y => r e s i z e 1 y r e g 6 d

589 ) ;

reg2 : regEnSignedgeneric map(

width => 12594 )

port map(r s t => r s t ou tReg nco r s t ,en => FSM reg2EN reg2 en ,d => cwRotat ion y out reg2 d ,

599 c l k => c lk outReg nco c lk ,q => r e g 2 q y i n t e r p o l a t o r x

) ;

reg3 : regEnSigned604 generic map(

width => 12)port map(

r s t => r s t ou tReg nco r s t ,609 en => FSM reg3EN reg3 en ,

c l k => c lk outReg nco c lk ,d => TED timingError reg3 d ,q => r e g 3 q t i m i n g f i l t e r e r r o r I n

) ;614

s t r o b e r e g : regEnStdLogicport map(

r s t => r s t ou tReg nco r s t ,q => s t r o b e r e g q s t r o b e i n R e g ,

619 d => nco s t robe ca l cu l a t eMu s t robe ,c l k => c lk outReg nco c lk ,en => FSM strobe regEN strobe reg en

) ;

624 reg4 : regEnSigned

134

generic map(width => 13

)port map(

629 q => r e g 4 q r e s i z e 2 x ,r s t => r s t ou tReg nco r s t ,d => ped phaseError reg4 d ,en => FSM reg4EN reg4 en ,c l k => c l k ou tReg nco c l k

634 ) ;

reg5 : regEnSignedgeneric map(

width => 19639 )

port map(r s t => r s t ou tReg nco r s t ,en => FSM reg5EN reg5 en ,q => reg5 q DDS data ,

644 d => p h a s e f i l t e r e s t i m a t e r e g 5 d ,c l k => c l k ou tReg nco c l k

) ;

y1conver ter : s i g t o s l v649 generic map(

WIDTH => 12)port map(

s i g I n => y1Reg q y1 inReg ,654 slvOut => y1conver te r s lvOut y1 inReg

) ;

TED : TED ze ro c ro s s ing l a t1 v2 0generic map(

659 numOfInputs => 2 ,samplesPerSymbol => 2

)port map(

r s t => r s t ou tReg nco r s t ,664 ce => FSM TEDCE TED ce ,

d e c i s i o n x => r e s i z e 3 y d e c x r e g d ,s t robe => nco s t robe ca l cu l a t eMu s t robe ,c l k => c lk outReg nco c lk ,x => x i n t e r p o l a t o r y d e c i s i o n x ,

669 d e c i s i o n y => r e s i z e 4 y d e c y r e g d ,t imingError => TED timingError reg3 d ,v a l i d I n => FSM TEDVALIDIN TED validIn ,y => y i n t e r po l a t o r y y 1R e g d

) ;674

reg1 : regEnSignedgeneric map(

width => 12)

135

679 port map(r s t => r s t ou tReg nco r s t ,en => FSM reg1EN reg1 en ,d => cwRotat ion x out reg1 d ,c l k => c lk outReg nco c lk ,

684 q => r e g 1 q x i n t e r p o l a t o r x) ;

FSM : chrec qpsk S15 mod FSMport map(

689 r s t => r s t ou tReg nco r s t ,x inte rpo la torCE => FSM x inte rpo la to rCE x inte rpo la to r ce ,reg5EN => FSM reg5EN reg5 en ,DDSVALIDIN => FSM DDSVALIDIN DDS validIn ,reg1EN => FSM reg1EN reg1 en ,

694 t iming f i l terVALIDIN =>FSM t iming f i l t e rVALIDIN t im ing f i l t e r va l i d In ,

TEDCE => FSM TEDCE TED ce ,v a l i d I n => val idIn outReg FSM val idIn ,reg2EN => FSM reg2EN reg2 en ,calculateMuCE => FSM calculateMuCE calculateMu ce ,

699 dec x regEN => FSM dec x regEN dec x reg en ,y1RegEN => FSM y1RegEN y1Reg en ,reg4EN => FSM reg4EN reg4 en ,p h a s e f i l t e r C E => F S M p h a s e f i l t e r C E p h a s e f i l t e r c e ,reg3EN => FSM reg3EN reg3 en ,

704 y interpolatorVALIDIN =>FSM y interpo latorVALIDIN y interpo lator va l id In ,

calculateMuVALIDIN => FSM calculateMuVALIDIN calculateMu validIn ,phase f i l terVALIDIN => FSM phase f i l t e rVALIDIN phase f i l t e r va l id In ,ncoVALIDIN => FSM ncoVALIDIN nco validIn ,DDSCE => FSM DDSCE DDS ce ,

709 c l k => c lk outReg nco c lk ,x interpolatorVALIDIN =>

FSM x interpo latorVALIDIN x interpo lator va l id In ,t i m i n g f i l t e r C E => F S M t i m i n g f i l t e r C E t i m i n g f i l t e r c e ,ncoCE => FSM ncoCE nco ce ,y inte rpo la torCE => FSM y inte rpo la to rCE y inte rpo la to r ce ,

714 TEDVALIDIN => FSM TEDVALIDIN TED validIn ,x1RegEN => FSM x1RegEN x1Reg en ,strobe regEN => FSM strobe regEN strobe reg en ,dec y regEN => FSM dec y regEN dec y reg en ,reg6EN => FSM reg6EN reg6 en

719 ) ;

d e c x r eg : regEnSignedgeneric map(

width => 2724 )

port map(r s t => r s t ou tReg nco r s t ,d => r e s i z e 3 y d e c x r e g d ,en => FSM dec x regEN dec x reg en ,

729 q => dec x reg q dec x inReg ,

136

c l k => c l k ou tReg nco c l k) ;

imag inconver t e r : s l v t o s i g734 generic map(

WIDTH => 12)port map(

s igOut => imag in outReg cwRotat ion y ,739 s l v I n => imag in ou tReg imag inconve r t e r s l v In

) ;

cwRotation1 : cwRotationport map(

744 y => imag in outReg cwRotat ion y ,s i n => DDS sin cwRotation sin ,cos => DDS cos cwRotation cos ,y out => cwRotat ion y out reg2 d ,x out => cwRotat ion x out reg1 d ,

749 x => r ea l in outReg cwRotat i on x) ;

r e a l i n o u t R e g r e a l i n c o n v e r t e r s l v I n <= r e a l i n ;r s t o u t R e g n c o r s t <= r s t ;

754 s t robe <= s t r o b e r e g q s t r o b e i n R e g ;va l idIn outReg FSM val idIn <= v a l i d I n ;dec y <= dec yconve r t e r s l vOut dec y inReg ;dec x <= dec xconve r t e r s l vOut dec x inReg ;y1 <= y1conver te r s lvOut y1 inReg ;

759 imag in ou tReg imag inconve r t e r s l v In <= imag in ;c l k ou tReg nco c l k <= c lk ;x1 <= x1conver te r s lvOut x1 inReg ;

end Generated ;

D.2 Finite State Machine

vhdl/chrec qpsk S15 mod FSM.vhd

1 l ibrary i e e e ;use i e e e . s t d l o g i c 1 1 6 4 . a l l ;

entity chrec qpsk S15 mod FSM i sport (

6 c l k : in s t d l o g i c ;r s t : in s t d l o g i c ;v a l i d I n : in s t d l o g i c ;y inte rpo la torCE : out s t d l o g i c ;TEDVALIDIN : out s t d l o g i c ;

11 reg6EN : out s t d l o g i c ;y1RegEN : out s t d l o g i c ;TEDCE : out s t d l o g i c ;DDSVALIDIN : out s t d l o g i c ;

137

reg1EN : out s t d l o g i c ;16 y interpolatorVALIDIN : out s t d l o g i c ;

ncoCE : out s t d l o g i c ;p h a s e f i l t e r C E : out s t d l o g i c ;x inte rpo la torCE : out s t d l o g i c ;calculateMuVALIDIN : out s t d l o g i c ;

21 phase f i l terVALIDIN : out s t d l o g i c ;dec y regEN : out s t d l o g i c ;t i m i n g f i l t e r C E : out s t d l o g i c ;dec x regEN : out s t d l o g i c ;reg5EN : out s t d l o g i c ;

26 DDSCE : out s t d l o g i c ;calculateMuCE : out s t d l o g i c ;strobe regEN : out s t d l o g i c ;ncoVALIDIN : out s t d l o g i c ;reg3EN : out s t d l o g i c ;

31 reg2EN : out s t d l o g i c ;t iming f i l terVALIDIN : out s t d l o g i c ;x1RegEN : out s t d l o g i c ;x interpolatorVALIDIN : out s t d l o g i c ;reg4EN : out s t d l o g i c

36 ) ;end chrec qpsk S15 mod FSM ;

architecture behav io ra l of chrec qpsk S15 mod FSM i s41

type s t a t e t y p e i s ( s t a t e 0 , s t a t e 1 , s t a t e 2 , s t a t e 3 , s t a t e 4 , s t a t e 5, s t a t e 6 , s t a t e 7 , s t a t e 8 , s t a t e 9 , s ta t e 10 , s ta t e 11 , s ta t e 12 ,s ta t e 13 , s ta t e 14 , s t a t e 1 5 ) ;

signal cs : s t a t e t y p e ;signal ns : s t a t e t y p e ;

begin46

process ( c lk , ns , r s t ) i sbegin

i f r s t = ’1 ’ thencs <= s t a t e 1 5 ;

51 e l s i f r i s i n g e d g e ( c l k ) thencs <= ns ;

end i f ;end process ;

56 process ( cs , v a l i d I n ) i sbegin

ns <= s t a t e 1 5 ;y inte rpo la torCE <= ’ 0 ’ ;TEDVALIDIN <= ’ 0 ’ ;

61 reg6EN <= ’ 0 ’ ;y1RegEN <= ’ 0 ’ ;TEDCE <= ’ 0 ’ ;DDSVALIDIN <= ’ 0 ’ ;reg1EN <= ’ 0 ’ ;

66 y interpolatorVALIDIN <= ’ 0 ’ ;

138

ncoCE <= ’ 0 ’ ;p h a s e f i l t e r C E <= ’ 0 ’ ;x inte rpo la torCE <= ’ 0 ’ ;calculateMuVALIDIN <= ’ 0 ’ ;

71 phase f i l terVALIDIN <= ’ 0 ’ ;dec y regEN <= ’ 0 ’ ;t i m i n g f i l t e r C E <= ’ 0 ’ ;dec x regEN <= ’ 0 ’ ;reg5EN <= ’ 0 ’ ;

76 DDSCE <= ’ 0 ’ ;calculateMuCE <= ’ 0 ’ ;strobe regEN <= ’ 0 ’ ;ncoVALIDIN <= ’ 0 ’ ;reg3EN <= ’ 0 ’ ;

81 reg2EN <= ’ 0 ’ ;t iming f i l terVALIDIN <= ’ 0 ’ ;x1RegEN <= ’ 0 ’ ;x interpolatorVALIDIN <= ’ 0 ’ ;reg4EN <= ’ 0 ’ ;

86 case cs i swhen s t a t e 0 =>

y inte rpo la torCE <= ’ 0 ’ ;TEDVALIDIN <= ’ 0 ’ ;reg6EN <= ’ 0 ’ ;

91 y1RegEN <= ’ 0 ’ ;TEDCE <= ’ 0 ’ ;DDSVALIDIN <= ’ 0 ’ ;reg1EN <= ’ 1 ’ ;y interpolatorVALIDIN <= ’ 0 ’ ;

96 ncoCE <= ’ 0 ’ ;p h a s e f i l t e r C E <= ’ 0 ’ ;x inte rpo la torCE <= ’ 0 ’ ;calculateMuVALIDIN <= ’ 1 ’ ;phase f i l terVALIDIN <= ’ 0 ’ ;

101 dec y regEN <= ’ 0 ’ ;t i m i n g f i l t e r C E <= ’ 0 ’ ;dec x regEN <= ’ 0 ’ ;reg5EN <= ’ 0 ’ ;DDSCE <= ’ 0 ’ ;

106 calculateMuCE <= ’ 1 ’ ;strobe regEN <= ’ 1 ’ ;ncoVALIDIN <= ’ 0 ’ ;reg3EN <= ’ 0 ’ ;reg2EN <= ’ 1 ’ ;

111 t iming f i l terVALIDIN <= ’ 0 ’ ;x1RegEN <= ’ 0 ’ ;x interpolatorVALIDIN <= ’ 0 ’ ;reg4EN <= ’ 0 ’ ;ns <= s t a t e 1 ;

116 when s t a t e 1 =>y inte rpo la torCE <= ’ 1 ’ ;TEDVALIDIN <= ’ 0 ’ ;reg6EN <= ’ 0 ’ ;y1RegEN <= ’ 0 ’ ;

139

121 TEDCE <= ’ 0 ’ ;DDSVALIDIN <= ’ 0 ’ ;reg1EN <= ’ 0 ’ ;y interpolatorVALIDIN <= ’ 1 ’ ;ncoCE <= ’ 0 ’ ;

126 p h a s e f i l t e r C E <= ’ 0 ’ ;x inte rpo la torCE <= ’ 1 ’ ;calculateMuVALIDIN <= ’ 0 ’ ;phase f i l terVALIDIN <= ’ 0 ’ ;dec y regEN <= ’ 0 ’ ;

131 t i m i n g f i l t e r C E <= ’ 0 ’ ;dec x regEN <= ’ 0 ’ ;reg5EN <= ’ 0 ’ ;DDSCE <= ’ 0 ’ ;calculateMuCE <= ’ 0 ’ ;

136 strobe regEN <= ’ 0 ’ ;ncoVALIDIN <= ’ 0 ’ ;reg3EN <= ’ 0 ’ ;reg2EN <= ’ 0 ’ ;t iming f i l terVALIDIN <= ’ 0 ’ ;

141 x1RegEN <= ’ 0 ’ ;x interpolatorVALIDIN <= ’ 1 ’ ;reg4EN <= ’ 0 ’ ;ns <= s t a t e 2 ;

when s t a t e 2 =>146 y inte rpo la torCE <= ’ 1 ’ ;

TEDVALIDIN <= ’ 0 ’ ;reg6EN <= ’ 0 ’ ;y1RegEN <= ’ 0 ’ ;TEDCE <= ’ 0 ’ ;

151 DDSVALIDIN <= ’ 0 ’ ;reg1EN <= ’ 0 ’ ;y interpolatorVALIDIN <= ’ 0 ’ ;ncoCE <= ’ 0 ’ ;p h a s e f i l t e r C E <= ’ 0 ’ ;

156 x inte rpo la torCE <= ’ 1 ’ ;calculateMuVALIDIN <= ’ 0 ’ ;phase f i l terVALIDIN <= ’ 0 ’ ;dec y regEN <= ’ 0 ’ ;t i m i n g f i l t e r C E <= ’ 0 ’ ;

161 dec x regEN <= ’ 0 ’ ;reg5EN <= ’ 0 ’ ;DDSCE <= ’ 0 ’ ;calculateMuCE <= ’ 0 ’ ;strobe regEN <= ’ 0 ’ ;

166 ncoVALIDIN <= ’ 0 ’ ;reg3EN <= ’ 0 ’ ;reg2EN <= ’ 0 ’ ;t iming f i l terVALIDIN <= ’ 0 ’ ;x1RegEN <= ’ 0 ’ ;

171 x interpolatorVALIDIN <= ’ 0 ’ ;reg4EN <= ’ 0 ’ ;ns <= s t a t e 3 ;

when s t a t e 3 =>

140

y inte rpo la torCE <= ’ 1 ’ ;176 TEDVALIDIN <= ’ 0 ’ ;

reg6EN <= ’ 0 ’ ;y1RegEN <= ’ 0 ’ ;TEDCE <= ’ 0 ’ ;DDSVALIDIN <= ’ 0 ’ ;

181 reg1EN <= ’ 0 ’ ;y interpolatorVALIDIN <= ’ 0 ’ ;ncoCE <= ’ 0 ’ ;p h a s e f i l t e r C E <= ’ 0 ’ ;x inte rpo la torCE <= ’ 1 ’ ;

186 calculateMuVALIDIN <= ’ 0 ’ ;phase f i l terVALIDIN <= ’ 0 ’ ;dec y regEN <= ’ 0 ’ ;t i m i n g f i l t e r C E <= ’ 0 ’ ;dec x regEN <= ’ 0 ’ ;

191 reg5EN <= ’ 0 ’ ;DDSCE <= ’ 0 ’ ;calculateMuCE <= ’ 0 ’ ;strobe regEN <= ’ 0 ’ ;ncoVALIDIN <= ’ 0 ’ ;

196 reg3EN <= ’ 0 ’ ;reg2EN <= ’ 0 ’ ;t iming f i l terVALIDIN <= ’ 0 ’ ;x1RegEN <= ’ 0 ’ ;x interpolatorVALIDIN <= ’ 0 ’ ;

201 reg4EN <= ’ 0 ’ ;ns <= s t a t e 4 ;

when s t a t e 4 =>y inte rpo la torCE <= ’ 1 ’ ;TEDVALIDIN <= ’ 0 ’ ;

206 reg6EN <= ’ 0 ’ ;y1RegEN <= ’ 0 ’ ;TEDCE <= ’ 0 ’ ;DDSVALIDIN <= ’ 0 ’ ;reg1EN <= ’ 0 ’ ;

211 y interpolatorVALIDIN <= ’ 0 ’ ;ncoCE <= ’ 0 ’ ;p h a s e f i l t e r C E <= ’ 0 ’ ;x inte rpo la torCE <= ’ 1 ’ ;calculateMuVALIDIN <= ’ 0 ’ ;

216 phase f i l terVALIDIN <= ’ 0 ’ ;dec y regEN <= ’ 0 ’ ;t i m i n g f i l t e r C E <= ’ 0 ’ ;dec x regEN <= ’ 0 ’ ;reg5EN <= ’ 0 ’ ;

221 DDSCE <= ’ 0 ’ ;calculateMuCE <= ’ 0 ’ ;strobe regEN <= ’ 0 ’ ;ncoVALIDIN <= ’ 0 ’ ;reg3EN <= ’ 0 ’ ;

226 reg2EN <= ’ 0 ’ ;t iming f i l terVALIDIN <= ’ 0 ’ ;x1RegEN <= ’ 0 ’ ;

141

x interpolatorVALIDIN <= ’ 0 ’ ;reg4EN <= ’ 0 ’ ;

231 ns <= s t a t e 5 ;when s t a t e 5 =>

y inte rpo la torCE <= ’ 1 ’ ;TEDVALIDIN <= ’ 0 ’ ;reg6EN <= ’ 0 ’ ;

236 y1RegEN <= ’ 0 ’ ;TEDCE <= ’ 0 ’ ;DDSVALIDIN <= ’ 0 ’ ;reg1EN <= ’ 0 ’ ;y interpolatorVALIDIN <= ’ 0 ’ ;

241 ncoCE <= ’ 0 ’ ;p h a s e f i l t e r C E <= ’ 0 ’ ;x inte rpo la torCE <= ’ 1 ’ ;calculateMuVALIDIN <= ’ 0 ’ ;phase f i l terVALIDIN <= ’ 0 ’ ;

246 dec y regEN <= ’ 0 ’ ;t i m i n g f i l t e r C E <= ’ 0 ’ ;dec x regEN <= ’ 0 ’ ;reg5EN <= ’ 0 ’ ;DDSCE <= ’ 0 ’ ;

251 calculateMuCE <= ’ 0 ’ ;strobe regEN <= ’ 0 ’ ;ncoVALIDIN <= ’ 0 ’ ;reg3EN <= ’ 0 ’ ;reg2EN <= ’ 0 ’ ;

256 t iming f i l terVALIDIN <= ’ 0 ’ ;x1RegEN <= ’ 0 ’ ;x interpolatorVALIDIN <= ’ 0 ’ ;reg4EN <= ’ 0 ’ ;ns <= s t a t e 6 ;

261 when s t a t e 6 =>y inte rpo la torCE <= ’ 1 ’ ;TEDVALIDIN <= ’ 0 ’ ;reg6EN <= ’ 0 ’ ;y1RegEN <= ’ 0 ’ ;

266 TEDCE <= ’ 0 ’ ;DDSVALIDIN <= ’ 0 ’ ;reg1EN <= ’ 0 ’ ;y interpolatorVALIDIN <= ’ 0 ’ ;ncoCE <= ’ 0 ’ ;

271 p h a s e f i l t e r C E <= ’ 0 ’ ;x inte rpo la torCE <= ’ 1 ’ ;calculateMuVALIDIN <= ’ 0 ’ ;phase f i l terVALIDIN <= ’ 0 ’ ;dec y regEN <= ’ 0 ’ ;

276 t i m i n g f i l t e r C E <= ’ 0 ’ ;dec x regEN <= ’ 0 ’ ;reg5EN <= ’ 0 ’ ;DDSCE <= ’ 0 ’ ;calculateMuCE <= ’ 0 ’ ;

281 strobe regEN <= ’ 0 ’ ;ncoVALIDIN <= ’ 0 ’ ;

142

reg3EN <= ’ 0 ’ ;reg2EN <= ’ 0 ’ ;t iming f i l terVALIDIN <= ’ 0 ’ ;

286 x1RegEN <= ’ 0 ’ ;x interpolatorVALIDIN <= ’ 0 ’ ;reg4EN <= ’ 0 ’ ;ns <= s t a t e 7 ;

when s t a t e 7 =>291 y inte rpo la torCE <= ’ 1 ’ ;

TEDVALIDIN <= ’ 0 ’ ;reg6EN <= ’ 0 ’ ;y1RegEN <= ’ 0 ’ ;TEDCE <= ’ 0 ’ ;

296 DDSVALIDIN <= ’ 0 ’ ;reg1EN <= ’ 0 ’ ;y interpolatorVALIDIN <= ’ 0 ’ ;ncoCE <= ’ 0 ’ ;p h a s e f i l t e r C E <= ’ 0 ’ ;

301 x inte rpo la torCE <= ’ 1 ’ ;calculateMuVALIDIN <= ’ 0 ’ ;phase f i l terVALIDIN <= ’ 0 ’ ;dec y regEN <= ’ 0 ’ ;t i m i n g f i l t e r C E <= ’ 0 ’ ;

306 dec x regEN <= ’ 0 ’ ;reg5EN <= ’ 0 ’ ;DDSCE <= ’ 0 ’ ;calculateMuCE <= ’ 0 ’ ;strobe regEN <= ’ 0 ’ ;

311 ncoVALIDIN <= ’ 0 ’ ;reg3EN <= ’ 0 ’ ;reg2EN <= ’ 0 ’ ;t iming f i l terVALIDIN <= ’ 0 ’ ;x1RegEN <= ’ 0 ’ ;

316 x interpolatorVALIDIN <= ’ 0 ’ ;reg4EN <= ’ 0 ’ ;ns <= s t a t e 8 ;

when s t a t e 8 =>y inte rpo la torCE <= ’ 1 ’ ;

321 TEDVALIDIN <= ’ 0 ’ ;reg6EN <= ’ 0 ’ ;y1RegEN <= ’ 0 ’ ;TEDCE <= ’ 0 ’ ;DDSVALIDIN <= ’ 0 ’ ;

326 reg1EN <= ’ 0 ’ ;y interpolatorVALIDIN <= ’ 0 ’ ;ncoCE <= ’ 0 ’ ;p h a s e f i l t e r C E <= ’ 0 ’ ;x inte rpo la torCE <= ’ 1 ’ ;

331 calculateMuVALIDIN <= ’ 0 ’ ;phase f i l terVALIDIN <= ’ 0 ’ ;dec y regEN <= ’ 0 ’ ;t i m i n g f i l t e r C E <= ’ 0 ’ ;dec x regEN <= ’ 0 ’ ;

336 reg5EN <= ’ 0 ’ ;

143

DDSCE <= ’ 0 ’ ;calculateMuCE <= ’ 0 ’ ;strobe regEN <= ’ 0 ’ ;ncoVALIDIN <= ’ 0 ’ ;

341 reg3EN <= ’ 0 ’ ;reg2EN <= ’ 0 ’ ;t iming f i l terVALIDIN <= ’ 0 ’ ;x1RegEN <= ’ 0 ’ ;x interpolatorVALIDIN <= ’ 0 ’ ;

346 reg4EN <= ’ 0 ’ ;ns <= s t a t e 9 ;

when s t a t e 9 =>y inte rpo la torCE <= ’ 0 ’ ;TEDVALIDIN <= ’ 1 ’ ;

351 reg6EN <= ’ 0 ’ ;y1RegEN <= ’ 1 ’ ;TEDCE <= ’ 1 ’ ;DDSVALIDIN <= ’ 0 ’ ;reg1EN <= ’ 0 ’ ;

356 y interpolatorVALIDIN <= ’ 0 ’ ;ncoCE <= ’ 0 ’ ;p h a s e f i l t e r C E <= ’ 0 ’ ;x inte rpo la torCE <= ’ 0 ’ ;calculateMuVALIDIN <= ’ 0 ’ ;

361 phase f i l terVALIDIN <= ’ 0 ’ ;dec y regEN <= ’ 1 ’ ;t i m i n g f i l t e r C E <= ’ 0 ’ ;dec x regEN <= ’ 1 ’ ;reg5EN <= ’ 0 ’ ;

366 DDSCE <= ’ 0 ’ ;calculateMuCE <= ’ 0 ’ ;strobe regEN <= ’ 0 ’ ;ncoVALIDIN <= ’ 0 ’ ;reg3EN <= ’ 0 ’ ;

371 reg2EN <= ’ 0 ’ ;t iming f i l terVALIDIN <= ’ 0 ’ ;x1RegEN <= ’ 1 ’ ;x interpolatorVALIDIN <= ’ 0 ’ ;reg4EN <= ’ 1 ’ ;

376 ns <= s t a t e 1 0 ;when s t a t e 1 0 =>

y inte rpo la torCE <= ’ 0 ’ ;TEDVALIDIN <= ’ 0 ’ ;reg6EN <= ’ 0 ’ ;

381 y1RegEN <= ’ 0 ’ ;TEDCE <= ’ 0 ’ ;DDSVALIDIN <= ’ 0 ’ ;reg1EN <= ’ 0 ’ ;y interpolatorVALIDIN <= ’ 0 ’ ;

386 ncoCE <= ’ 0 ’ ;p h a s e f i l t e r C E <= ’ 1 ’ ;x inte rpo la torCE <= ’ 0 ’ ;calculateMuVALIDIN <= ’ 0 ’ ;phase f i l terVALIDIN <= ’ 1 ’ ;

144

391 dec y regEN <= ’ 0 ’ ;t i m i n g f i l t e r C E <= ’ 0 ’ ;dec x regEN <= ’ 0 ’ ;reg5EN <= ’ 0 ’ ;DDSCE <= ’ 0 ’ ;

396 calculateMuCE <= ’ 0 ’ ;strobe regEN <= ’ 0 ’ ;ncoVALIDIN <= ’ 0 ’ ;reg3EN <= ’ 1 ’ ;reg2EN <= ’ 0 ’ ;

401 t iming f i l terVALIDIN <= ’ 0 ’ ;x1RegEN <= ’ 0 ’ ;x interpolatorVALIDIN <= ’ 0 ’ ;reg4EN <= ’ 0 ’ ;ns <= s t a t e 1 1 ;

406 when s t a t e 1 1 =>y inte rpo la torCE <= ’ 0 ’ ;TEDVALIDIN <= ’ 0 ’ ;reg6EN <= ’ 0 ’ ;y1RegEN <= ’ 0 ’ ;

411 TEDCE <= ’ 0 ’ ;DDSVALIDIN <= ’ 0 ’ ;reg1EN <= ’ 0 ’ ;y interpolatorVALIDIN <= ’ 0 ’ ;ncoCE <= ’ 0 ’ ;

416 p h a s e f i l t e r C E <= ’ 1 ’ ;x inte rpo la torCE <= ’ 0 ’ ;calculateMuVALIDIN <= ’ 0 ’ ;phase f i l terVALIDIN <= ’ 0 ’ ;dec y regEN <= ’ 0 ’ ;

421 t i m i n g f i l t e r C E <= ’ 1 ’ ;dec x regEN <= ’ 0 ’ ;reg5EN <= ’ 0 ’ ;DDSCE <= ’ 0 ’ ;calculateMuCE <= ’ 0 ’ ;

426 strobe regEN <= ’ 0 ’ ;ncoVALIDIN <= ’ 0 ’ ;reg3EN <= ’ 0 ’ ;reg2EN <= ’ 0 ’ ;t iming f i l terVALIDIN <= ’ 1 ’ ;

431 x1RegEN <= ’ 0 ’ ;x interpolatorVALIDIN <= ’ 0 ’ ;reg4EN <= ’ 0 ’ ;ns <= s t a t e 1 2 ;

when s t a t e 1 2 =>436 y inte rpo la torCE <= ’ 0 ’ ;

TEDVALIDIN <= ’ 0 ’ ;reg6EN <= ’ 0 ’ ;y1RegEN <= ’ 0 ’ ;TEDCE <= ’ 0 ’ ;

441 DDSVALIDIN <= ’ 0 ’ ;reg1EN <= ’ 0 ’ ;y interpolatorVALIDIN <= ’ 0 ’ ;ncoCE <= ’ 0 ’ ;

145

p h a s e f i l t e r C E <= ’ 0 ’ ;446 x inte rpo la torCE <= ’ 0 ’ ;

calculateMuVALIDIN <= ’ 0 ’ ;phase f i l terVALIDIN <= ’ 0 ’ ;dec y regEN <= ’ 0 ’ ;t i m i n g f i l t e r C E <= ’ 1 ’ ;

451 dec x regEN <= ’ 0 ’ ;reg5EN <= ’ 1 ’ ;DDSCE <= ’ 0 ’ ;calculateMuCE <= ’ 0 ’ ;strobe regEN <= ’ 0 ’ ;

456 ncoVALIDIN <= ’ 0 ’ ;reg3EN <= ’ 0 ’ ;reg2EN <= ’ 0 ’ ;t iming f i l terVALIDIN <= ’ 0 ’ ;x1RegEN <= ’ 0 ’ ;

461 x interpolatorVALIDIN <= ’ 0 ’ ;reg4EN <= ’ 0 ’ ;ns <= s t a t e 1 3 ;

when s t a t e 1 3 =>y inte rpo la torCE <= ’ 0 ’ ;

466 TEDVALIDIN <= ’ 0 ’ ;reg6EN <= ’ 1 ’ ;y1RegEN <= ’ 0 ’ ;TEDCE <= ’ 0 ’ ;DDSVALIDIN <= ’ 1 ’ ;

471 reg1EN <= ’ 0 ’ ;y interpolatorVALIDIN <= ’ 0 ’ ;ncoCE <= ’ 0 ’ ;p h a s e f i l t e r C E <= ’ 0 ’ ;x inte rpo la torCE <= ’ 0 ’ ;

476 calculateMuVALIDIN <= ’ 0 ’ ;phase f i l terVALIDIN <= ’ 0 ’ ;dec y regEN <= ’ 0 ’ ;t i m i n g f i l t e r C E <= ’ 0 ’ ;dec x regEN <= ’ 0 ’ ;

481 reg5EN <= ’ 0 ’ ;DDSCE <= ’ 1 ’ ;calculateMuCE <= ’ 0 ’ ;strobe regEN <= ’ 0 ’ ;ncoVALIDIN <= ’ 0 ’ ;

486 reg3EN <= ’ 0 ’ ;reg2EN <= ’ 0 ’ ;t iming f i l terVALIDIN <= ’ 0 ’ ;x1RegEN <= ’ 0 ’ ;x interpolatorVALIDIN <= ’ 0 ’ ;

491 reg4EN <= ’ 0 ’ ;ns <= s t a t e 1 4 ;

when s t a t e 1 4 =>y inte rpo la torCE <= ’ 0 ’ ;TEDVALIDIN <= ’ 0 ’ ;

496 reg6EN <= ’ 0 ’ ;y1RegEN <= ’ 0 ’ ;TEDCE <= ’ 0 ’ ;

146

DDSVALIDIN <= ’ 0 ’ ;reg1EN <= ’ 0 ’ ;

501 y interpolatorVALIDIN <= ’ 0 ’ ;ncoCE <= ’ 1 ’ ;p h a s e f i l t e r C E <= ’ 0 ’ ;x inte rpo la torCE <= ’ 0 ’ ;calculateMuVALIDIN <= ’ 0 ’ ;

506 phase f i l terVALIDIN <= ’ 0 ’ ;dec y regEN <= ’ 0 ’ ;t i m i n g f i l t e r C E <= ’ 0 ’ ;dec x regEN <= ’ 0 ’ ;reg5EN <= ’ 0 ’ ;

511 DDSCE <= ’ 0 ’ ;calculateMuCE <= ’ 0 ’ ;strobe regEN <= ’ 0 ’ ;ncoVALIDIN <= ’ 1 ’ ;reg3EN <= ’ 0 ’ ;

516 reg2EN <= ’ 0 ’ ;t iming f i l terVALIDIN <= ’ 0 ’ ;x1RegEN <= ’ 0 ’ ;x interpolatorVALIDIN <= ’ 0 ’ ;reg4EN <= ’ 0 ’ ;

521 i f v a l i d I n = ’1 ’ thenns <= s t a t e 0 ;

elsens <= s t a t e 1 5 ;

end i f ;526 when s t a t e 1 5 =>

y inte rpo la torCE <= ’ 0 ’ ;TEDVALIDIN <= ’ 0 ’ ;reg6EN <= ’ 0 ’ ;y1RegEN <= ’ 0 ’ ;

531 TEDCE <= ’ 0 ’ ;DDSVALIDIN <= ’ 0 ’ ;reg1EN <= ’ 0 ’ ;y interpolatorVALIDIN <= ’ 0 ’ ;ncoCE <= ’ 0 ’ ;

536 p h a s e f i l t e r C E <= ’ 0 ’ ;x inte rpo la torCE <= ’ 0 ’ ;calculateMuVALIDIN <= ’ 0 ’ ;phase f i l terVALIDIN <= ’ 0 ’ ;dec y regEN <= ’ 0 ’ ;

541 t i m i n g f i l t e r C E <= ’ 0 ’ ;dec x regEN <= ’ 0 ’ ;reg5EN <= ’ 0 ’ ;DDSCE <= ’ 0 ’ ;calculateMuCE <= ’ 0 ’ ;

546 strobe regEN <= ’ 0 ’ ;ncoVALIDIN <= ’ 0 ’ ;reg3EN <= ’ 0 ’ ;reg2EN <= ’ 0 ’ ;t iming f i l terVALIDIN <= ’ 0 ’ ;

551 x1RegEN <= ’ 0 ’ ;x interpolatorVALIDIN <= ’ 0 ’ ;

147

reg4EN <= ’ 0 ’ ;i f v a l i d I n = ’1 ’ then

ns <= s t a t e 0 ;556 else

ns <= s t a t e 1 5 ;end i f ;

when others =>end case ;

561 end process ;

end behav io ra l ;

148