Jyothis_ dynamically reconfigurable computing_

Document Sample
Jyothis_ dynamically reconfigurable  computing_ Powered By Docstoc
					Seminar Report 2004                                Dynamically Reconfigurable Computing

                      Dynamically Reconfigurable Computing is the computing
that uses Dynamically Reconfigurable Logic. The latter is the logic that can be
altered at run-time. Since both their names are rather long, we will call them
DRC and DRL from now on.
                      Though DRC uses DRL, anything that use DRL is not DRC.
To be called a DRC, many more components must be there, the most important
among them being proper software that can drive the logic. Without the
software, a common man will be left with a non-reconfigurable hardware that is
both larger and somewhat slower than its traditional counterpart (if even that –
most of the time he will be left with just a piece of non-usable hardware which
he regrets).
                      And obviously, application software must be there. A
Dynamically Reconfigurable System without application software is like a PC
without a single piece of software in it – both are wasted resources. Thus the
hardware part and the software part combine to make a DR Computing system.
                      Now we will see why take all the trouble to make and
combine hardware and software that nobody is actually comfortable with. And
then we will see what are the “all the trouble”.


 1                                                     Govt Engineering College, Thrissur
Seminar Report 2004                            Dynamically Reconfigurable Computing

                      Almost all the DRC systems today consist of FPGAs. System
designers have always used FPGAs for prototyping the design of Application
Specific Integrated Circuits (ASICs). When the design is finalized, FPGA is
thrown away and the final product has no FPGA part. When used in this way, the
role of FPGA is just a placeholder. This is not DRC.
                      However, now some system designers choose to leave the
FPGA part in the production system. This has the advantage that the logic within
the system can changed even after the product has been shipped. For example,
hardware upgrades and bug fixes can be administrated as easily as their software
counterparts. In order to support a new version of the network protocol, the
designer just have to redesign the internal logic of the FPGA and send it to the
customers by e-mail. The customer can download the new design to the system
and restart it and la voilà – their system supports the newest protocol, all without
a single “hardware upgrade”. This is Configurable Computing. DRC takes this to
one step further.
                      DRC involves manipulation of logic inside FPGA (DRL) at
run-time. ie, the design of the hardware changes in response to the demands
placed upon the system at run-time. What a CPU do to software, DRC do to
hardware. This means that FPGA acts as an execution engine for a number of
different hardware functions. These hardware functions can execute in a parallel
or serial fashion.
                      Dynamically Reconfigurable Computing allows the system to
execute more hardware functions than it has gates to fit. This is excellent since
many parts of the system will idle most of the time.

                                 THE NEED
                      There are two primary methods in conventional computing –

 2                                                  Govt Engineering College, Thrissur
Seminar Report 2004                             Dynamically Reconfigurable Computing

either use special purpose Application Specific Integrated Circuits (ASICs) or
use general purpose microprocessors.
                      ASICs are hardwired and very much special purpose. ASICs
implement algorithms in hardware. The disadvantage is that ASIC used for one
purpose can never be used for a different purpose. Thus when they are told to do
what they are taught to do, they do it well, but you can't tell them to draw an
ellipse when they were taught to draw a circle – it simply won't work. For
example, consider your mp3 player that costs Rs 5000. Now a new encoding
called ogg vorbis is becoming popular. Obviously you can't make the mp3 player
play the ogg format – there is no way you can convince it that there may be a
better format.
                      The general purpose microprocessor has a set of instructions
such that we can make it understand anything else in terms of those instructions.
The advantage is that it is very much flexible. It can be taught to draw a circle or
an ellipse as you wish, when you wish. The disadvantage is that you have to
teach the microprocessor each time you want it to do something, no matter how
many times you have already taught it the same thing. This causes system
slowdowns and bottlenecks( eg: Von Neumann bottleneck).
                      Thus we can summarize these two methods : the ASIC learns
thoroughly but unfortunately never forgets a thing; the Microprocessor always
forgets but never learns by heart. If we can remove the 'but' parts in the above
sentence, that would obviously be a desirable method. Here comes the DRC.
                      The Dynamically Reconfigurable Hardware is intended to
combine the good effects of both ASICs and the microprocessors, to be a
hardware that is flexible as software.

                            THE INCENTIVES
                      Reconfigurable computing has several advantages that makes
it very desirable:

 3                                                  Govt Engineering College, Thrissur
Seminar Report 2004                              Dynamically Reconfigurable Computing

                      First, greater functionality is achieved for a simple hardware
design. The enticing thing is that all the logic need not be present in the FPGA at
all the time and thus the cost of supporting additional features is only the cost of
memory required to store the logical design. As an example, consider a cellular
phone that supports multiple communication and data protocols. The idea is that
the phone should support different protocols as we move from area to area, one
at a time. If such a phone is implemented using DRL, it can download different
hardware designs as it moves to a region that has a different protocol – thus
never requiring to actually support more than one protocol at a time.
                      The second, and for many, the most important, is the lower
system cost. But don't rush to hardware shops now – the initial cost may be
comparable or even greater than traditional hardware. What I meant was that if
you use the system long enough, you will find that the total cost ( initial +
maintenance ) is lower. If you include the cost of an upgrade, you will see that
DRH (DR Hardware) wins the race hands down.
                      The third, fourth, and fifth advantages are the increased
customizability, reduced time to market and the incremental design cycle.
                      DRH is customizable. This means that we can decide exactly
how our hardware should work. If you are daring enough, you can make a
completely new architecture.
                      The time to market is reduced since there are no chip design
and prototype cycles.

                      An incremental design cycle can be used in designing DRH.
In the beginning a product with minimum functionality is shipped. Then the
product is improved from the responses and comments of the customers. The
improvement can be shipped to the customers as a soft copy. Again the product
is improved from the new responses and comments. This cycle repeats till there

 4                                                   Govt Engineering College, Thrissur
Seminar Report 2004                           Dynamically Reconfigurable Computing

isn't any new response or comment left.

                      Now it is time to analyze what exactly “Dynamical
Reconfigurability” means. For this we must understand the difference between
DRH and traditional FPGAs. Traditional FPGAs are configurable, not
dynamically reconfigurable. To reprogram a traditional programmable FPGA, its
present state must be erased first and it can't be captured beforehand. Also, the

 5                                                Govt Engineering College, Thrissur
Seminar Report 2004                               Dynamically Reconfigurable Computing

whole chip must be reprogrammed at once. You can't say that “I only wan't to
change one gate, so I will change only that gate” - you don't have a choice there.
                      To be called dynamically reconfigurable, an FPGA should
have some minimum qualifications. The qualifications are given below.
On-the-fly Reconfigurability
                      We hate to restart our computer whenever we install or
uninstall something. It is because we don't like delays. We like to see the results
of our actions quickly (unless you have committed a crime – it is very different
then.). In the case of DR FPGA, it is not what we like that matters; it is a must
that the FPGA should work without restart. Also, the time for reconfiguration
should be very small to be worthy of the hardware of the next generation.
Partial Reconfigurability
                      Partial reconfigurability is the ability in the part of the FPGA
to reprogram only a part of itself while keeping the other parts intact and fully
functional. This property gives you the choice of reprogramming only one gate if
you need to change that gate only. The Atmel 40K and Xilinx 62xx series have
this qualification.

Externally Visible Internal State
                      This means that the internal state of the FPGA can be
captured anytime, while the system is running. This allows hardware designs to
be swapped into and out of the FPGA as needed.

 6                                                    Govt Engineering College, Thrissur
Seminar Report 2004                           Dynamically Reconfigurable Computing

                      DRH can do many things well or even better, but when it
comes to things like memory access, the microprocessor is unbeatable. So we
can't avoid the microprocessor completely. Another point is that eggs left to
itself won't make an omlette. There has to be a supervisor to guide them to make
one. In the present context, we use the microprocessor as the supervisor who will
guide the DRH through different hardware designs. Thus reconfigurable systems
are usually formed with a combination of DRL and a general purpose
microprocessor. The DRL act as a component of the microprocessor, a co-

 7                                                Govt Engineering College, Thrissur
Seminar Report 2004                             Dynamically Reconfigurable Computing

processor, or a stand-alone processor in a multi-processing system.
                      It is only natural that we look into the implementation of a
dynamically reconfigurable system next.

                      The main parts of a DRC system are :

                      *) Hardware objects
                      **) Run-time environment

                        HARDWARE OBJECTS
                      Hardware objects are functional or logical hardware
component that contains its own configuration or state information. They should
be position independent so that any part of the hardware can be allocated to
hardware objects.
                      To be relocatable, the size and shape of hardware objects
should be constrained. These constraints dictate that the hardware objects should
be rectangular in shape with edge lengths that are multiples of some unit length
called hardware page size. The page size may be a convenient number of gates.
Eg,.in Xilinx 62xx, page sizes of 4 or 16 is used.
                      It is desirable to standardize the hardware object interface.

 8                                                   Govt Engineering College, Thrissur
Seminar Report 2004                              Dynamically Reconfigurable Computing

This is to make inter-object routing easier. It is especially important in DRC
systems since the routing between hardware objects is performed on-the-fly.
This also helps in greater object reuse. We can also maintain libraries of
frequently used objects so that larger designs can be quickly built on that.
                      To be general, hardware objects should communicate with the
outside world through an abstraction. This abstraction is called the hardware
object framework and is physically located at the outer edge of the FPGA.
Though this abstraction shrinks the space available to hardware objects, it is a
small price to pay for the greater reusability and faster design cycles it offers.



 9                                                   Govt Engineering College, Thrissur
Seminar Report 2004                             Dynamically Reconfigurable Computing

       This clear picture illustrates hardware objects in an intuitive way.

                   RUN-TIME ENVIRONMENT
                      As I said earlier, we leave the duty of managing DRH to a
microprocessor or microcontroller that may be coupled to the DRH in varying
degrees. I also said that microprocessors don't remember. The natural conclusion
is that we must have a software wrapper around a DRL equipment.
                      The Run-Time Environment is the software wrapper around
the DR logic to manage the following things:
               ✔   Decides which hardware object to execute and when
               ✔   Performs     routing    between      hardware      objects     and
                   hardware object framework.
               ✔   Swaps hardware objects into and out of DRL
                      In a DRC system, decisions are made at run-time. Imparting

10                                                   Govt Engineering College, Thrissur
Seminar Report 2004                             Dynamically Reconfigurable Computing

these decisions to a piece of software allows us to write software at a very high
degree of abstraction.
                      Now, anything that has anything to do with abstraction of any
kind is sure to be associated with a layered architecture. The run-time
environment is no exception. The layers associated with it are:
       a) A Virtual Hardware Manager
       b) A Configuration Manager
       c) A Device Driver

                      APPLICATION SOFTWARE

                              VH MANAGER


                            DEVICE DRIVER


        Another clear picture to show that abstraction has always layers.

11                                                   Govt Engineering College, Thrissur
Seminar Report 2004                           Dynamically Reconfigurable Computing

                 LAYERS OF ABSTRACTION
The Virtual Hardware Manager
                      The virtual hardware manager provides the Applications
Programming Interface (API). An application programmer needs to deal only
with the VHM. It provides functions to make a circuit, communicate with the
circuit, partially reconfigure the circuit and free its resources. To achieve high
efficiency, the virtual hardware manager maintains a map of the system in terms
of the available hardware objects.
The Configuration Manager
                      The configuration manager is the middle man between the
VHM and the Device Driver. It conveys the request from the VHM to the
device driver in a way that the device driver understands the request. For this,
the configuration manager converts it to a number of functions that the device

12                                                 Govt Engineering College, Thrissur
Seminar Report 2004                              Dynamically Reconfigurable Computing

driver provides.
                      The CM loads the registers of FPGA with the data passed
from the application through the VHM. Passing the state information from the
device driver to the virtual hardware manager is also the configuration manager's
The Device Driver
                      In every abstraction, there is a layer which has no further
abstraction and which has to perform the most unpleasant tasks. The device
driver is such a layer and it has to communicate directly with the DRL. Unlike
the upper two layers, the driver gets no peek at the great job they are
accomplishing. Though it is the device driver that does everything, it is the
application software that gets all the credit.

                      The device driver reads or writes the Static RAM of the
FPGA. It reads or writes the hardware object programming data. When the
application software issues an interrupt, the device driver interrupts the
hardware. When needed, it sets the FPGA clock frequency. As a safety measure,
the driver monitors the current drawn by the FPGA.
                      These three layers of abstraction makes the learning curve
needed to program for dynamically reconfigurable computing systems short and
cost-effective. This is like Unix system where the abstractions are so clearly
defined by tradition that application programmers never need to know about the
kernel internals.

13                                                   Govt Engineering College, Thrissur
Seminar Report 2004                           Dynamically Reconfigurable Computing

                       DESIGN CONCERNS
            Speed of Reconfiguration is of the order of microseconds at
present. For rapid reconfiguration of high speed systems, this is not enough. But
in systems where one configuration will be used a number of times before
reconfiguration take place, this speed is agreeable enough.

            Size and Density:      Now FPGAs of only upto half a million
transistors are available. Density limitations can be overcome by using more
than one FPGA, but it will severely cut performance.
            Size of DRL circuits are more than the corresponding ASICs.

     When generating binary files to be executed on systems that include
traditional microprocessor and dynamically reconfigurable hardware, it must be

14                                                 Govt Engineering College, Thrissur
Seminar Report 2004                            Dynamically Reconfigurable Computing

partitioned into sections to be executed on DRL and sections to be executed on
the microprocessor. This can be done either manually or automatically using a
specially designed compiler. Don't even think of doing it manually – it can be so
difficult and cumbersome. That leaves the option of using the compilers I told
you about. Unfortunately, no such compilers are yet available in the market.

                      Unlike traditional microprocessors, the DRL can execute two
or more completely different processes at the same time. This is achieved by
partitioning the hardware as necessary and allocating one slice to each process.
But it may happen that the number of processes that is to be run on DRH is too
numerous. When this happens, it is desirable that hardware designs are swapped
into and out of the DRH as their turn comes. This swapping during run-time is
known as run-time reconfiguration. Run-time Reconfiguration can be applied
successfully to a single program when the areas of the program that can be
accelerated by DRL is greater than that can be fit in the dynamically
reconfigurable hardware. This situation is illustrated below.

15                                                  Govt Engineering College, Thrissur
Seminar Report 2004                             Dynamically Reconfigurable Computing

                        OPERATING SYSTEM
                      An operating system that wishes to be accepted by DRC
systems must first pass the following tests:
     A)       Is the OS flexible ?
     B)Can its scheduler be customized by the user ?
     C)Does the OS have a wide support ?
     D)       Is it stable and bug-free on non-configurable hardware, let alone on
       dynamically reconfigurable hardware ?
                      It seems that Linux is the only operating system that passes
all these tests. The fact that Linux is an open source software adds strength to
this argument. It is highly customizable and can be made to work on virtually
any type of hardware. Besides, Linux is already supported (in fact, it is the only

16                                                     Govt Engineering College, Thrissur
Seminar Report 2004                                    Dynamically Reconfigurable Computing

major OS that is supported) in projects like F-CPU¶ which aims at designing a
configurable and free microprocessor.
                        Let's just say that Linux will be the operating system of the

                       APPLICATIONS – TESTED
Data Encryption and Decryption
                        These two are the most obvious applications. Both will gain
immediate speed-up if run on DRC systems. Since DRC can offer variable
register size and run-time reconfiguration, the encryption and decryption
algorithms can be executed in the most efficient way possible.

Computer Virus and Worm Detector
                        Viruses and worms can be detected by strings of malicious
code. To isolate them out from the Internet traffic, the traffic content must be
monitored in real time. It will be too slow to be implemented in software and too
rapidly changing to be implemented using ASICs. Hence DRC.

¶For more information on F-CPU project, see Appendix

17                                                         Govt Engineering College, Thrissur
Seminar Report 2004                              Dynamically Reconfigurable Computing

DSP Applications
                      High performance low power DSP hardware is possible using
Dynamically Reconfigurable Logic.

                      String pattern matching, data compression etc.

Smart Cellular Phone
               As I mentioned before, a smart cellular phone which supports
multiple data and communication protocols, but one at a time is one possible

               As you have guessed, DISC stands for Dynamical Instruction Set
Computer. It has variable instructions that can customized for each application
by the algorithm implementors. Instructions can even be dynamically loaded into
hardware as they are needed.

               I hope that soon this section would be obsolete.

18                                                   Govt Engineering College, Thrissur
Seminar Report 2004                           Dynamically Reconfigurable Computing

                           CAUSE & EFFECT
                      One of the many things that lead to DRC is the open
hardware design trend. The idea behind open hardware is to publish all
information about the hardware including its implementation details, how it is
interfaced to other systems and how it can be used. This information is usually
published under the GNU General Public License, making it freely available to
all. The Open Hardware methodology makes the hardware evolution rapid
because when two ideas are combined, they get multiplied, not added. This is
exactly as in the case of Open Source.
                      One of the many things that lead from DRC is evolvable
computing where electronic circuits autonomously adapt to the changing
environment. It is ideal to make spacecrafts using such circuits and NASA is
presently conducting studies on it. Evolvable circuits can also optimize
themselves in non-changing environments. The software part of evolvable
computing is mostly genetic algorithms. All this speeds up the progress of
Artificial Intelligence. You have still enough time to be in a matrix – or are you

19                                                 Govt Engineering College, Thrissur
Seminar Report 2004                              Dynamically Reconfigurable Computing

already ?


                      What you have been reading till now can be summarized as
                      i) The Dynamically Reconfigurable Systems are already here.
There is no element of science-fiction in DRC; it is plain, present and pleasant
truth. I hope that they will make the world a better place to live.
                      ii) Soon your computer will be as flexible as plastic, yielding
to your every wish (unless you wish otherwise).
                      iii) Tomorrow we may be able to download and install the
latest computer architecture as we now install the latest Linux kernel.
                      iv) Nothing Escapes LINUX

20                                                    Govt Engineering College, Thrissur
Seminar Report 2004                            Dynamically Reconfigurable Computing


The F-CPU Project
                      The F-CPU or Free CPU project was begun in mid-1998s as
the FREEDOM PROJECT. The project began when some Linux Kernel
developers got fed up with the antediluvian features of intel x86 architecture.
The rumor that the details of the 64-bit intel architecture (ia64) would be kept
secret under the Non-Disclosure Act poured gas on the fire. The motto behind
the project is “there can be no free software without free hardware” and one of
its goals is to kick Intel out of desktops.

                      This project aims at designing an open source CPU. It
progresses by publishing, testing and debugging and through these, making
various designs. The advances in the field of reconfigurable hardware makes the
project more and more viable.

                      The F-CPU project has a mailing list archive at the yahoo
group f-cpu. Interested readers can go there to get a more complete story.

21                                                 Govt Engineering College, Thrissur
Seminar Report 2004                          Dynamically Reconfigurable Computing

1. “Open      Hardware         Design   Trend”   BY      Jamil        Khatib    in

2. An Introduction To Reconfigurable Computing                   BY    Katherine
     Compton & Scott Hauck

3. An Overview of Advances in Reconfigurable Computing Systems                  BY

     Bozidar Radunovic

4. Augmenting a Microprocessor with Reconfigurable Hardware                     BY

     John Reid Hauser

5. “The F-CPU Project – Freedom for devices : Philosophy, Dogma,
     or Relegion ? ”   BY   Yann Guidon in www.f-cpu.org

6. Toward       a      Dynamically      Reconfigurable      Computing          and
     Communication System for Small Spacecraft        BY   Mulie Kifle et al. of
22                                               Govt Engineering College, Thrissur
Seminar Report 2004                                              Dynamically Reconfigurable Computing

7. On Evolvable Hardware                        BY   Timothy G. W. Gordon & Peter J.

                           GNU Free Documentation License

                                          Version 1.1, March 2000
Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA
                                    02111-1307 USA
 Everyone is permitted to copy and distribute verbatim copies of this license document, but
                                changing it is not allowed.

0. Preamble
          The purpose of this License is to make a manual, textbook, or other written document "free" in the sense
of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it,
either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way
to get credit for their work, while not being considered responsible for modifications made by others.
         This License is a kind of "copyleft", which means that derivative works of the document must
themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft
license designed for free software.
         We have designed this License in order to use it for manuals for free software, because free software
needs free documentation: a free program should come with manuals providing the same freedoms that the
software does. But this License is not limited to software manuals; it can be used for any textual work, regardless
of subject matter or whether it is published as a printed book. We recommend this License principally for works
whose purpose is instruction or reference.

23                                                                     Govt Engineering College, Thrissur
Seminar Report 2004                                                Dynamically Reconfigurable Computing

1. Applicability And Definitions
          This License applies to any manual or other work that contains a notice placed by the copyright holder
saying it can be distributed under the terms of this License. The "Document", below, refers to any such manual or
work. Any member of the public is a licensee, and is addressed as "you".
         A "Modified Version" of the Document means any work containing the Document or a portion of it,
either copied verbatim, or with modifications and/or translated into another language.
          A "Secondary Section" is a named appendix or a front-matter section of the Document that deals
exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject
(or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the
Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The
relationship could be a matter of historical connection with the subject or with related matters, or of legal,
commercial, philosophical, ethical or political position regarding them.
         The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of
Invariant Sections, in the notice that says that the Document is released under this License.
         The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover
Texts, in the notice that says that the Document is released under this License.
          A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose
specification is available to the general public, whose contents can be viewed and edited directly and
straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for
drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic
translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent
file format whose markup has been designed to thwart or discourage subsequent modification by readers is not
Transparent. A copy that is not "Transparent" is called "Opaque".
         Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input
format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple
HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can
be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing
tools are not generally available, and the machine-generated HTML produced by some word processors for
output purposes only.
         The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed
to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not
have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title,
preceding the beginning of the body of the text.

2. Verbatim Copying
          You may copy and distribute the Document in any medium, either commercially or noncommercially,
provided that this License, the copyright notices, and the license notice saying this License applies to the
Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License.
You may not use technical measures to obstruct or control the reading or further copying of the copies you make
or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough
number of copies you must also follow the conditions in section 3.
         You may also lend copies, under the same conditions stated above, and you may publicly display copies.

3. Copying In Quantity
         If you publish printed copies of the Document numbering more than 100, and the Document's license
notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover
Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also
clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all

24                                                                        Govt Engineering College, Thrissur
Seminar Report 2004                                                Dynamically Reconfigurable Computing

words of the title equally prominent and visible. You may add other material on the covers in addition. Copying
with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions,
can be treated as verbatim copying in other respects.
        If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed
(as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
         If you publish or distribute Opaque copies of the Document numbering more than 100, you must either
include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy
a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free
of added material, which the general network-using public has access to download anonymously at no charge
using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps,
when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus
accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly
or through your agents or retailers) of that edition to the public.
         It is requested, but not required, that you contact the authors of the Document well before redistributing
any large number of copies, to give them a chance to provide you with an updated version of the Document.

4. Modifications
        You may copy and distribute a Modified Version of the Document under the conditions of sections 2
and 3 above, provided that you release the Modified Version under precisely this License, with the Modified
Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to
whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

     1. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from
         those of previous versions (which should, if there were any, be listed in the History section of the
         Document). You may use the same title as a previous version if the original publisher of that version
         gives permission.
     2. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the
         modifications in the Modified Version, together with at least five of the principal authors of the
         Document (all of its principal authors, if it has less than five).
     3. State on the Title page the name of the publisher of the Modified Version, as the publisher.
     4. Preserve all the copyright notices of the Document.
     5. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
     6. Include, immediately after the copyright notices, a license notice giving the public permission to use the
         Modified Version under the terms of this License, in the form shown in the Addendum below.
     7. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the
         Document's license notice.
     8. Include an unaltered copy of this License.
     9. Preserve the section entitled "History", and its title, and add to it an item stating at least the title, year,
         new authors, and publisher of the Modified Version as given on the Title Page. If there is no section
         entitled "History" in the Document, create one stating the title, year, authors, and publisher of the
         Document as given on its Title Page, then add an item describing the Modified Version as stated in the
         previous sentence.
     10. Preserve the network location, if any, given in the Document for public access to a Transparent copy of
         the Document, and likewise the network locations given in the Document for previous versions it was
         based on. These may be placed in the "History" section. You may omit a network location for a work
         that was published at least four years before the Document itself, or if the original publisher of the
         version it refers to gives permission.
     11. In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve
         in the section all the substance and tone of each of the contributor acknowledgements and/or dedications
         given therein.
     12. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section
         numbers or the equivalent are not considered part of the section titles.
     13. Delete any section entitled "Endorsements". Such a section may not be included in the Modified

25                                                                       Govt Engineering College, Thrissur
Seminar Report 2004                                               Dynamically Reconfigurable Computing

     14. Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section.
         If the Modified Version includes new front-matter sections or appendices that qualify as Secondary
Sections and contain no material copied from the Document, you may at your option designate some or all of
these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's
license notice. These titles must be distinct from any other section titles.
         You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your
Modified Version by various parties--for example, statements of peer review or that the text has been approved
by an organization as the authoritative definition of a standard.
          You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a
Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover
Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the
Document already includes a cover text for the same cover, previously added by you or by arrangement made by
the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on
explicit permission from the previous publisher that added the old one.
        The author(s) and publisher(s) of the Document do not by this License give permission to use their
names for publicity for or to assert or imply endorsement of any Modified Version.

5. Combining Documents
         You may combine the Document with other documents released under this License, under the terms
defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant
Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined
work in its license notice.
         The combined work need only contain one copy of this License, and multiple identical Invariant
Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but
different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name
of the original author or publisher of that section if known, or else a unique number. Make the same adjustment
to the section titles in the list of Invariant Sections in the license notice of the combined work.
         In the combination, you must combine any sections entitled "History" in the various original documents,
forming one section entitled "History"; likewise combine any sections entitled "Acknowledgements", and any
sections entitled "Dedications". You must delete all sections entitled "Endorsements."

6. Collections Of Documents
         You may make a collection consisting of the Document and other documents released under this
License, and replace the individual copies of this License in the various documents with a single copy that is
included in the collection, provided that you follow the rules of this License for verbatim copying of each of the
documents in all other respects.
         You may extract a single document from such a collection, and distribute it individually under this
License, provided you insert a copy of this License into the extracted document, and follow this License in all
other respects regarding verbatim copying of that document.

7. Aggregation With Independent Works
         A compilation of the Document or its derivatives with other separate and independent documents or
works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of
the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an
"aggregate", and this License does not apply to the other self-contained works thus compiled with the Document,
on account of their being thus compiled, if they are not themselves derivative works of the Document.

26                                                                       Govt Engineering College, Thrissur
Seminar Report 2004                                              Dynamically Reconfigurable Computing

         If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the
Document is less than one quarter of the entire aggregate, the Document's Cover Texts may be placed on covers
that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole

8. Translation
         Translation is considered a kind of modification, so you may distribute translations of the Document
under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their
copyright holders, but you may include translations of some or all Invariant Sections in addition to the original
versions of these Invariant Sections. You may include a translation of this License provided that you also include
the original English version of this License. In case of a disagreement between the translation and the original
English version of this License, the original English version will prevail.

9. Termination
         You may not copy, modify, sublicense, or distribute the Document except as expressly provided for
under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will
automatically terminate your rights under this License. However, parties who have received copies, or rights,
from you under this License will not have their licenses terminated so long as such parties remain in full

10. Future Revisions Of This License
          The Free Software Foundation may publish new, revised versions of the GNU Free Documentation
License from time to time. Such new versions will be similar in spirit to the present version, but may differ in
detail to address new problems or concerns. See http:///www.gnu.org/copyleft/.
         Each version of the License is given a distinguishing version number. If the Document specifies that a
particular numbered version of this License "or any later version" applies to it, you have the option of following
the terms and conditions either of that specified version or of any later version that has been published (not as a
draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you
may choose any version ever published (not as a draft) by the Free Software Foundation.

27                                                                     Govt Engineering College, Thrissur
Seminar Report 2004                             Dynamically Reconfigurable Computing

                             AUTHOR INFO

                     The author is a Linux fanatic who is also interested in things
like literature, mathematics, philosophy and French. Thanks to this seminar, he is
also interested in the world at large. He is a proponent of Linux and Open Source
and hopes to live to the day when the proprietary model is accepted as is without
no warranty – antediluvian.
                   As you can guess from this booklet, the author loves to write
on things he love. But since it steals his precious hours, he engages in writing
only occasionally.
                   If the author is still alive ( I certainly hope so), he would like
to hear from you, provided you share common interests or different opinions. He
can be reached at jyothisv@gmail.com

28                                                  Govt Engineering College, Thrissur
Seminar Report 2004   Dynamically Reconfigurable Computing

29                        Govt Engineering College, Thrissur