Jyothis( Dynamically Reconfigurable Computing)

8/7/2019 Jyothis( Dynamically Reconfigurable Computing)

http://slidepdf.com/reader/full/jyothis-dynamically-reconfigurable-computing 1/28

Seminar Report 2004 Dynamically Reconfigurable Computing

DYNAMICALLY RECONFIGURABLECOMPUTING – WHAT IT MEANS

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”.

DYNAMICALLY RECONFIGURABLECOMPUTING – WHAT IT IMPLIES

Almost all the DRC systems today consist of FPGAs. System

1 Govt Engineering College, Thrissur




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, therole 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 NEEDThere are two primary methods in conventional 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 anellipse 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 INCENTIVESReconfigurable computing has several advantages that makes it

very desirable:

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 differenthardware 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 isn't any new

response or comment left.





DYNAMICAL RECONFIGURABILITY 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

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 differentthen.). 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.





RECONFIGURABILE SYSTEMS

DRH can do many things well or even better, but when itcomes 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-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. This

is to make inter-object routing easier. It is especially important in DRC systemssince 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.

This clear picture illustrates hardware objects in an intuitive way.


HARDWARE OBJECT FRAMEWORK

HARDWAREOBJECT




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

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





Another clear picture to show that abstraction has always layers.


APPLICATION SOFTWARE

HARDWARE

VH MANAGER

DEVICE DRIVER

CONFIGURATION MANAGER




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 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 duty.

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.





DESIGN CONCERNS

Hardware

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.

Software

When generating binary files to be executed on systems that include

traditional microprocessor and dynamically reconfigurable hardware, it must be

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.





RUN-TIME RECONFIGURATION

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.





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 allthese 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 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

future.

APPLICATIONS – TESTED

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





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.

DSP Applications

High performance low power DSP hardware is possible using

Dynamically Reconfigurable Logic.

Other

String pattern matching, data compression etc.

APPLICATIONS – TO BE TESTED

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 application.

DISC 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.

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 caseof 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

already ?

WHAT YOU HAVE BEEN READING

What you have been reading till now can be summarized as

follows:

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

APPENDIX

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.

WHAT I HAVE BEEN READING

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

www.opencores.org

2. An Introduction To Reconfigurable Computing BY Katherine

Compton & Scott Hauck


http://www.opencores.org/

http://www.opencores.org/




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

NASA

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

Bently

GNU Free Documentation License

Version 1.1, March 2000

Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA02111-1307 USA

Everyone is permitted to copy and distribute verbatim copies of this license document, but


http://www.f-cpu.org/

http://www.f-cpu.org/




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 getcredit 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 designedfor free software.

We have designed this License in order to use it for manuals for free software, because free software needsfree 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 isinstruction or reference.

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 dealsexclusively 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 theDocument is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) Therelationship 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 whosespecification is available to the general public, whose contents can be viewed and edited directly andstraightforwardly 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 automatictranslation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent fileformat whose markup has been designed to thwart or discourage subsequent modification by readers is notTransparent. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo inputformat, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simpleHTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can beread and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing toolsare 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 tohold, legibly, the material this License requires to appear in the title page. For works in formats which do not haveany title page as such, "Title Page" means the text near the most prominent appearance of the work's title, precedingthe 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 Documentare reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may notuse 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 copiesyou 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 licensenotice 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 alsoclearly and legibly identify you as the publisher of these copies. The front cover must present the full title with allwords of the title equally prominent and visible. You may add other material on the covers in addition. Copyingwith 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 atthe 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 redistributingany 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 3above, provided that you release the Modified Version under precisely this License, with the Modified Versionfilling 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 thoseof 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 themodifications 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 theDocument'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 asgiven on its Title Page, then add an item describing the Modified Version as stated in the previoussentence.

10. Preserve the network location, if any, given in the Document for public access to a Transparent copy of theDocument, and likewise the network locations given in the Document for previous versions it was basedon. 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 refersto gives permission.

11. In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve inthe section all the substance and tone of each of the contributor acknowledgements and/or dedicationsgiven therein.

12. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Sectionnumbers 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 Version.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 SecondarySections and contain no material copied from the Document, you may at your option designate some or all of thesesections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's licensenotice. 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 byan 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 aBack-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 theDocument already includes a cover text for the same cover, previously added by you or by arrangement made bythe 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 namesfor publicity for or to assert or imply endorsement of any Modified Version.

5. Combining DocumentsYou 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 InvariantSections of all of the original documents, unmodified, and list them all as Invariant Sections of your combinedwork in its license notice.

The combined work need only contain one copy of this License, and multiple identical Invariant Sectionsmay be replaced with a single copy. If there are multiple Invariant Sections with the same name but differentcontents, make the title of each such section unique by adding at the end of it, in parentheses, the name of theoriginal author or publisher of that section if known, or else a unique number. Make the same adjustment to thesection 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 anysections entitled "Dedications". You must delete all sections entitled "Endorsements."







AUTHOR INFO

The author is a Linux fanatic who is also interested in thingslike literature, mathematics, philosophy and French. Thanks to this seminar, he isalso interested in the world at large. He is a proponent of Linux and Open Sourceand hopes to live to the day when the proprietary model is accepted as is withoutno 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 onlyoccasionally.

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 [email protected]

mailto:[email protected]

mailto:[email protected]

Date post:	09-Apr-2018
Category:	Documents
Upload:	yuben-joseph
View:	219 times
Download:	0 times