WO2002008887A2

WO2002008887A2 - System, method and article of manufacture for utilizing a code library to implement drivers in a reconfigurable logic device

Info

Publication number: WO2002008887A2
Application number: PCT/GB2001/003244
Authority: WO
Inventors: John Gordon Lee Alexander; Sanjay Ibrahim Maniku
Original assignee: Celoxica Limited
Priority date: 2000-07-20
Filing date: 2001-07-19
Publication date: 2002-01-31
Also published as: AU2002224572A1; WO2002008887A3

Abstract

A system, method and article of manufacture are provided for implementing drivers in a reconfigurable logic device. A request for access to one or more hardware devices is received. Such hardware can include, for example, a mouse, keyboard, display device, etc. A reconfigurable logic device is put in communication with a code library. Preferably, the reconfigurable logic device is capable of being configured to communicate with multiple hardware devices. Such a code library includes one or more drivers for interfacing the hardware device with an application. A driver associated with the hardware device is retrieved from the code library. The driver is utilized to configure the reconfigurable logic device to communicate with the hardware device(s). In one aspect of the present invention, the reconfigurable logic device interfaces with a hardware register, buffer management, a microprocessor, an interrupt handler, and/or a memory transfer application or device. Preferably, the reconfigurable logic device includes at least one field programmable gate array (FPGA).

Description

Title: SYSTEM, METHOD AND ARTICLE OF MANUFACTURE FOR UΗLIZING A CODE LIBRARY TO IMPLEMENT

DRIVERS IN A RECONFIGURABLE LOGIC DEVICE

FIELD OF THE INVENTION

The present invention relates to implementing drivers in hardware and more particularly to selectively implementing drivers in a reconfigurable logic device.

BACKGROUND OF THE INVENTION

It is well known that software-controlled machines provide great flexibility in that they can be adapted to many different desired purposes by the use of suitable software. As well as being used in the familiar general purpose computers, software-controlled processors are now used in many products such as cars, telephones and other domestic products, where they are known as embedded systems.

However, for a given a function, a software-controlled processor is usually slower than hardware dedicated to that function.. A way of overcoming this problem is to use a special software-controlled processor such as a RISC processor which can be made to function more quickly for limited purposes by having its parameters (for instance size, instruction set etc.) tailored to the desired functionality.

Where hardware is used, though, although it increases the speed of operation, it lacks flexibility and, for instance, although it may be suitable for the task for which it was designed it may not be suitable for a modified version of that task which is desired later. It is now possible to form the hardware on reconfigurable logic circuits, such as Field Progr_-tnmable Gate Arrays (FPGA's) which are logic circuits which can be repeatedly reconfigured in different ways. Thus they provide the speed advantages of dedicated hardware, with some degree of flexibility for later updating or multiple functionality.

In general, though, it can be seen that designers face a problem in finding the right balance between speed and generality. They can build versatile chips which will be software controlled and thus perform many different functions relatively slowly, or they can devise application-specific chips that do only a limited set of tasks but do them much more quickly.

A compromise solution to these problems can be found in systems which combine both dedicated hardware and also software. The hardware is dedicated to particular functions, e.g. those requiring speed, and the software can perform the remaining functions. The design of such systems is known as hardware-software codesign.

It would be desirable to implement drivers in reconfigurable hardware to provide the speed advantages of dedicated hardware, with some degree of flexibility for later updating or multiple functionality.

SUMMARY OF THE INVENTION

A system, method and article of manufacture are provided for implementing drivers in a reconfigurable logic device. A request for access to one or more hardware devices is received. Such hardware can include, for example, a mouse, keyboard, display device, pointing device, etc. A reconfigurable logic device is put in communication with a code library. Preferably, the reconfigurable logic device is capable of being configured to communicate with multiple hardware devices. Such a code library includes one or more drivers for interfacing the hardware device with an application. A driver associated with the hardware device is retrieved from the code library. The driver is utilized to configure the reconfigurable logic device to communicate with the hardware device(s).

In one aspect of the present invention, the reconfigurable logic device interfaces with a hardware register, buffer management, a microprocessor, an interrupt handler, and/or a memory transfer application or device. Preferably, the reconfigurable logic device includes at least one field programmable gate array (FPGA).

In accordance with the invention, a code library is a representation of functions packaged in a binary file with source files for interfacing with the code library. A driver is logic that interfaces devices with a client application. The packaging of drivers in a code library for specific utilization in reconfigurable logic which reduces complexity and facilitates full utilization of the underlying hardware. This is accomplished by providing an abstracted, intuitive interface to the hardware registers, buffer management, microprocessors, interrupt handling and memory transfers.

For example, to implement an asynchronous read and write operation in support of an RS232C communication driver, the read operation, that is normally implemented as a software READ statement, is transformed into a reconfigurable logic device that performs the READ operation. Because the READ operation is implemented in hardware it is much more efficient without sacrificing an intuitive interface for utilizing the device.

The invention extends to a computer program comprising program code means for executing the method.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be better understood when consideration is given to the following detailed description of embodiments thereof. Such description makes reference to the annexed drawings wherein:

Figure 1 is a schematic diagram of a hardware implementation. of one embodiment of the present invention;

Figure 2 is a flow diagram of a process for implementing drivers in a reconfigurable logic device;

Figure 3 shows a resistor network of an FPGA graphics processor according to an embodiment of the present invention;

Figure 4 is a code fragment for a display process according to an embodiment of the present invention;

Figure 5 is a code fragment for a frame-rate update process according to one embodiment of the present invention;

Figure 6 is a diagram of a PS/2 system according to an embodiment of the present invention;

Figure 7 illustrates PS/2 serial data transfer protocol waveforms;

Figure 8 illustrates a coordinate system for a mouse; and Figure 9 depicts pin numbering of a high-density 15-way D-type socket board connector.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

A preferred embodiment of a system in accordance with the present invention is preferably practiced in the context of a personal computer such as an IBM compatible personal computer, Apple Macintosh computer or UNIX based workstation. A representative hardware environment is depicted in Figure 1, which illustrates a typical hardware configuration of a workstation in accordance with a preferred embodiment having a central processing unit 110, such as a microprocessor, and a number of other units interconnected via a system bus 112. The workstation shown in Figure 1 includes a Random Access Memory (RAM) 114, Read Only Memory (ROM) 116, an I/O adapter 118 for connecting peripheral devices such as disk storage units 120 to the bus 112, a user interface adapter 122 for connecting a keyboard 124, a mouse 126, a speaker 128, a microphone 132, and/or other user interface devices such as a touch screen (not shown) to the bus 112, communication adapter 134 for connecting the workstation to a communication network (e.g., a data processing network) and a display adapter 136 for connecting the bus 112 to a display device 138. The workstation typically has resident thereon an operating system such as the Microsoft Windows NT or Windows/95 Operating System (OS), the IBM OS/2 operating system, the MAC OS, or UNIX operating system. Those skilled in the art will appreciate that the present invention may also be implemented on platforms and operating systems other than those mentioned.

A preferred embodiment is written using JAVA, C, and the C++ language and utilizes object oriented programming methodology. Object oriented programming (OOP) has become increasin ¹ ised to develop complex applications. As OOP moves toward the mainstream of software design and development, various software solutions require adaptation to make use of the benefits of OOP. A need exists for these principles of OOP to be applied to a messaging interface of an electronic messaging system such that a set of OOP classes and objects for the messaging interface can be provided. OOP is a process of developing computer software using objects, including the steps of analyzing the problem, designing the system, and constructing the program. An object is a software package that contains both data and a collection of related structures and procedures. Since it contains both data and a collection of structures and procedures, it can be visualized as a self-sufficient component that does not require other additional structures, procedures or data to perform its specific task. OOP, therefore, views a computer program as a collection of largely autonomous components, called objects, each of which is responsible for a specific task. This concept of packaging data, structures, and procedures together in one component or module is called encapsulation.

In general, OOP components are reusable software modules which present an interface that conforms to an object model and which are accessed at run-time through a component integration architecture. A component integration architecture is a set of architecture mechanisms which allow software modules in different process spaces to utilize each others capabilities or functions. This is generally done by assuming a common component object model on which to build the architecture. It is worthwhile to differentiate between an object and a class of objects at this point. An object is a single instance of the class of objects, which is often just called a class. A class of objects can be viewed as a blueprint, from which many objects can be formed.

OOP allows the programmer to create an object that is a part of another object. For example, the object representing a piston engine is said to have a composition- relationship with the object representing a piston. In reality, a piston engine comprises a piston, valves and many other components; the fact that a piston is an element of a piston engine can be logically and semantically represented in OOP by two objects.

OOP also allows creation of an object that "depends from" another object. If there are two objects, one representing a piston engine and the other representing a piston engine wherein the piston is made of ceramic, then the relationship between the two objects is not that of composition. A ceramic piston engine does not make up a piston engine. Rather it is merely one kind of piston engine that has one more limitation than the piston engine; its piston is made of ceramic. In this case, the object representing the ceramic piston engine is called a derived object, and it inherits all of the aspects of the object representing the piston engine and adds further limitation or detail to it. The object representing the ceramic piston engine "depends from" the object representing the piston engine. The relationship between these objects is called inheritance.

When the object or class representing the ceramic piston engine inherits all of the aspects of the objects representing the piston engine, it inherits the thermal characteristics of a standard piston defined in the piston engine class. However, the ceramic piston engine object overrides these ceramic specific thermal characteristics, which are typically different from those associated with a metal piston. It skips over the original and uses new functions related to ceramic pistons. Different kinds of piston engines have different characteristics, but may have the same underlying functions associated with it (e.g., how many pistons in the engine, ignition sequences, lubrication, etc.). To access each of these functions in any piston engine object, a programmer would call the same functions with the same names, but each type of piston engine may have different/overriding implementations of functions behind the same name. This ability to hide different implementations of a function behind the same name is called polymorphism and it greatly simplifies communication among objects.

With the concepts of composition-relationship, encapsulation, inheritance and polymorphism, ar ^~L:ect can represent just about anytliing in the real world. In fact, one's logical perception of the reality is the only limit on determining the kinds of things that can become objects in object-oriented software. Some typical categories are as follows: Objects can represent physical objects, such as automobiles in a traffic-flow simulation, electrical components in a circuit-design program, countries in an economics model, or aircraft in an air-traffic-control system.

Objects can represent elements of the computer-user environment such as windows, menus or graphics objects.

An object can represent an inventory, such as a personnel file or a table of the latitudes and longitudes of cities.

An object can represent user-defined data types such as time, angles, and complex numbers, or points on the plane.

With this enormous capability of an object to represent just about any logically separable matters, OOP allows the software developer to design and implement a computer program that is a model of some aspects of reality, whether that reality is a physical entity, a process, a system, or a composition of matter. Since the object can represent anything, the software developer can create an object which can be used as a component in a larger software project in the future.

If 90% of a new OOP software program consists of proven, existing components made from preexisting reusable objects, then only the remaining 10% of the new software project has to be written and tested from scratch. Since 90% already came from an inventory of extensively tested reusable objects, the potential domain from which an error could originate is 10% of the program. As a result, OOP enables software developers to build objects out of other, previously built objects.

This process close¹ .sembles complex machinery being built out of assemblies and sub-assemblies. OOP technology, therefore, makes software engineering more like hardware engineering in that software is built from existing components, which are available to the developer as objects. All this adds up to an improved quality of the software as well as an increased speed of its development. Programming languages are beginning to fully support the OOP principles, such as encapsulation, inheritance, polymorphism, and composition-relationship. With the advent of the C++ language, many commercial software developers have embraced OOP. C++ is an OOP language that offers a fast, machine-executable code. Furthermore, C++ is suitable for both commercial-application and systems- programming projects. For now, C++ appears to be the most popular choice among many OOP programmers, but there is a host of other OOP languages, such as Smalltalk, Common Lisp Object System (CLOS), and Eiffel. Additionally, OOP capabilities are being added to more traditional popular computer programming languages such as Pascal.

The benefits of object classes can be summarized, as follows:

• Objects and their corresponding classes break down complex programming problems into many smaller, simpler problems.

• Encapsulation enforces data abstraction through the organization of data into small, independent objects that can communicate with each other. Encapsulation protects the data in an object from accidental damage, but allows other objects to interact with that data by calling the object's member functions and structures.

• Subclassing and inheritance make it possible to extend and modify objects through deriving new kinds of objects from the standard classes available in the system. Thus, new capabilities are created without having to start from scratch.

• Polymorphism and multiple inheritance make it possible for different progrεrmm ' o mix and match characteristics of many different classes and create specialized objects that can still work with related objects in predictable ways.

• Class hierarchies and containment hierarchies provide a flexible mechanism for modeling real-world objects and the relationships among them. • Libraries of reusable classes are useful in niany situations, but they also have some limitations. For example:

• Complexity. In a complex system, the class hierarchies for related classes can become extremely confusing, with many dozens or even hundreds of classes. • Flow of control. A program written with the aid of class libraries is still responsible for the flow of control (i.e., it must control the interactions among all the objects created from a particular library). The programmer has to decide which functions to call at what times for which kinds of objects.

• Duplication of effort. Although class libraries allow programmers to use and reuse many small pieces of code, each programmer puts those pieces together in a different way. Two different programmers can use the same set of class libraries to write two programs that do exactly the same thing but whose internal structure (i.e., design) may be quite different, depending on hundreds of small decisions each programmer makes along the way. Inevitably, similar pieces of code end up doing similar things in slightly different ways and do not work as well together as they should.

Class libraries are very flexible. As programs grow more complex, more prograrrrmers are forced to reinvent basic solutions to basic problems over and over again. A relatively new extension of the class library concept is to have a framework of class libraries. This framework is more complex and consists of significant collections of collaborating classes that capture both the small scale patterns and major mechanisms that implement the common requirements and design in a specific application domain. They were first developed to free application programmers from the chores involved in displaying menus, ^* tdows, dialog boxes, and other standard user interface elements for personal computers.

Frameworks also represent a change in the way programmers think about the interaction between the code they write and code written by others. In the early days of procedural programming, the programmer called libraries provided by the operating system to perform certain tasks, but basically the program executed down the page from start to finish, and the programmer was solely responsible for the flow of control. This was appropriate for printing out paychecks, calculating a mathematical table, or solving other problems with a program that executed in just one way.

The development of graphical user interfaces began to turn this procedural programming arrangement inside out. These interfaces allow the user, rather than program logic, to drive the program and decide when certain actions should be performed. Today, most personal computer software accomplishes this by means of an event loop which monitors the mouse, keyboard, and other sources of external events and calls the appropriate parts of the programmer's code according to actions that the user performs. The programmer no longer determines the order in which events occur. Instead, a program is divided into separate pieces that are called at unpredictable times and in an unpredictable order. By relinquishing control in this way to users, the developer creates a program that is much easier to use. Nevertheless, individual pieces of the program written by the developer still call libraries provided by the operating system to accomplish certain tasks, and the programmer must still determine the flow of control within each piece after it's called by the event loop. Application code still "sits on top of the system.

Even event loop programs require programmers to write a lot of code that should not need to be written separately for every application. The concept of an application framework carries the event loop concept further. Instead of dealing with all the nuts and bolts of constructing basic menus, windows, and dialog boxes and then making these things all work together, programmers using application frameworks start with working application code and basic user interface elements in place. Subsequently, they build from there by replacing some of the generic capabilities of the framework with the specific capabilities of the intended application. Application frameworks reduce the total amount of code that a programmer has to write from scratch. However, because the framework is really a generic application that displays windows, supports copy and paste, and so on, the programmer can also relinquish control to a greater degree than event loop programs permit. The framework code takes care of almost all event handling and flow of control, and the programmer's code is called only when the framework needs it (e.g., to create or manipulate a proprietary data structure).

A programmer writing a framework program not only relinquishes control to the user (as is also true for event loop programs), but also relinquishes the detailed flow of control within the program to the framework. This approach allows the creation of more complex systems that work together in interesting ways, as opposed to isolated programs, having custom code, being created over and over again for similar problems.

Thus, as is explained above, a framework basically is a collection of cooperating classes that make up a reusable design solution for a given problem domain. It typically includes objects that provide default behavior (e.g., for menus and windows), and programmers use it by inheriting some of that default behavior and overriding other behavior so that the framework calls application code at the appropriate times.

There are three main differences between frameworks and class libraries:

• Behavior versus protocol. Class libraries are essentially collections of behaviors that you can call when you want those individual behaviors in your program. A framework, on the other hand, provides not only behavior but also the protocol or set of rules that govern the ways in which behaviors can be combined, including rules for what a programmer is supposed to provide versus what the framework provides. • Call versus override. With a class library, the code the programmer instantiates objects and calls their member functions. It's possible to instantiate and call objects in the same way with a framework (i.e., to treat the framework as a class library), but to take full advantage of a framework's reusable design, a programmer typically writes code that overrides and is called by the framework.

The framework manages the flow of control among its objects. Writing a program involves dividing responsibilities among the various pieces of software that are called by the framework rather than specifying how the different pieces should work together. • Implementation versus design. With class libraries, programmers reuse only implementations, whereas with frameworks, they reuse design. A framework embodies the way a family of related programs or pieces of software work. It represents a generic design solution that can be adapted to a variety of specific problems in a given domain. For example, a single framework can embody the way a user interface works, even though two different user interfaces created with the same framework might solve quite different interface problems.

Thus, through the development of frameworks for solutions to various problems and programming tasks, significant reductions in the design and development effort for software can be achieved. A preferred embodiment of the invention utilizes HyperText Markup Language (HTML) to implement documents on the Internet together with a general-purpose secure communication protocol for a transport medium between the client and the Newco. HTTP or other protocols could be readily substituted for HTML without undue experimentation. Information on these products is available in T. Berners-Lee, D. C<™"oly, "RFC 1866: Hypertext Markup Language - 2.0" (Nov. 1995); and R. Fielding, H, Frystyk, T. Bemers-Lee, J. Gettys and J.C. Mogul, "Hypertext Transfer Protocol ~ HTTP/1.1 : HTTP Working Group Internet Draft" (May 2, 1996). HTML is a simple data format used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains. HTML has been in use by the World-Wide Web global information initiative since 1990. HTML is an application of ISO Standard 8879; 1986 Information Processing Text and Office Systems; Standard Generalized Markup Language (SGML).

To date, Web development tools have been limited in their ability to create dynamic Web applications which span from client to server and interoperate with existing computing resources. Until recently, HTML has been the dominant technology used in development of Web-based solutions. However, HTML has proven to be inadequate in the following areas:

Poor performance;

Restricted user interface capabilities;

Can only produce static Web pages; • Lack of interoperability with existing applications and data; and

Inability to scale.

Sun Microsystem's Java language solves many of the client-side problems by:

• Improving performance on the client side; • Enabling the creation of dynamic, real-time Web applications; and

• Providing the ability to create a wide variety of user interface components.

With Java, developers can create robust User Interface (UI) components. Custom "widgets" (e.g., real-time stock tickers, animated icons, etc.) can be created, and client- side performance rproved. Unlike HTML, Java supports the notion of client-side validation, offloading appropriate processing onto the client for improved performance. Dynamic, real-time Web pages can be created. Using the above-mentioned custom UI components, dynamic Web pages can also be created. Sun's Java language has emerged as an industry-recognized language for "progr_-iιmmg the Internet." Sun defines Java as: "a simple, object-oriented, distributed, interpreted, robust, secure, εffcMtecture-neutral, portable, high-performance, multithreaded, dynamic, buzzword-compliant, general-purpose programming language. Java supports programming for the Internet in the form of platform-independent Java applets." Java applets are small, specialized applications that comply with Sun's Java Application Programming Interface (API) allowing developers to add "interactive content" to Web documents (e.g., simple animations, page adornments, basic games, etc.). Applets execute within a Java-compatible browser (e.g., Netscape Navigator) by copying code from the server to client. From a language standpoint, Java's core feature set is based on C++. Sun's Java literature states that Java is basically, "C++ with extensions from Objective C for more dynamic method resolution."

Another technology that provides similar function to JAVA is provided by Microsoft and ActiveX Technologies, to give developers and Web designers wherewithal to build dynamic content for the Internet and personal computers. ActiveX includes tools for developing animation, 3-D virtual reality, video and other multimedia content. The tools use Internet standards, work on multiple platforms, and are being supported by over 100 companies. The group's building blocks are called ActiveX Controls, small, fast components that enable developers to embed parts of software in hypertext markup language (HTML) pages. ActiveX Controls work with a variety of programming languages including Microsoft Visual C++, Borland Delphi, Microsoft Visual Basic programming system and, in the future, Microsoft's development tool for Java, code named "Jakarta." ActiveX Technologies also includes ActiveX Server Framework, allowing developer to create server applications. One of ordinary skill in the art readily recognizes that ActiveX could be substituted for JAVA without undue experimentation to practice the invention. Handel-C is a programming language. It enables a software or hardware engineer to target directly FPGAs (Field Programmable Gate Array) in a similar fashion to classical microprocessor cross-compiler development tools, without recourse to a Hardware Description Language. Thereby allowing the designer to directly realise the raw real- time computing capability of the FPGA.

Handel-C is a programming language designed to enable the compilation of programs into synchronous hardware; it is aimed at compiling high level algorithms directly into gate level hardware.

The Handel-C syntax is based on that of conventional C so programmers familiar with conventional C will recognize almost all the constructs in the Handel-C language.

Sequential programs can be written in Handel-C just as in conventional C but to gain the most benefit in performance from the target hardware its inherent parallelism must be exploited.

Handel-C includes parallel constructs that provide the means for the programmer to exploit this benefit in his applications. The compiler compiles and optimizes Handel-C source code into a file suitable for simulation or a netlist which can be placed and routed on a real FPGA.

The simulator allows you to test your program without using real hardware. It can display the state of every variable (register) in your program at every clock cycle if required, the simulation steps and the number of cycles simulated being under program control. Optionally the source code that was executed at each clock cycle as well as the program state may be displayed in order to assist in the debugging of the source code. Further debugging options are provided in the toolset, notably the 'Logic Estimator'. This tool displays the source code in a color highlighted form which relates to the logic depth and usage. So providing feedback to the designer for further optimizations.

Code Library to Implement Drivers in a Reconfigurable Logic Device

Figure 2 depicts a process 200 for implementing drivers in a reconfigurable logic device. In operation 202, a request for access to one or more hardware devices is received. Such hardware can include, for example, a mouse, keyboard, display device, etc. In operation 204, a reconfigurable logic device is put in communication with a code library. Such a code library includes one or more drivers for interfacing the hardware device with an application. Preferably, the reconfigurable logic device is capable of being configured to communicate with multiple hardware devices. A driver associated with the hardware device is retrieved from the code library in operation 206. In operation 208, the driver is utilized to configure the reconfigurable logic device to communicate with the hardware device(s).

In one aspect of the present invention, the reconfigurable logic device interfaces with a hardware register, buffer management, a microprocessor, an interrupt handler, and/or a memory transfer application or device. Preferably, the reconfigurable logic device includes at least one field programmable gate array (FPGA). For example, to implement an asynchronous read and write operation in support of an RS232C communication driver, the read operation, that is normally implemented as a software READ statement, is transformed into a reconfigurable logic device that performs the READ operation. Because the READ operation is implemented in hardware it is much more efficient without sacrificing an intuitive interface for utilizing the device.

Field Programmable Gate Array (FPGA) Graphics Generator

According to an illustrative embodiment of the present invention, a graphics generator is created on an FPGA.

When a design engineer plans the design of a graphics system, they usually envisage a system that includes:

• microprocessor and memory

• graphics processor

• video memory

• video controller including DAC • software program in the microprocessor to control the system.

This section shows how the complete system can be implemented on a single FPGA using the Handel-C language.

The great advanta — f doing this is the short development time that leads to rapid prototyping of products. A Handel-C program can be developed and implemented in a matter of hours or days compared to weeks or months for hardware on a printed circuit board. Modifications can be done similarly rapidly. Other advantages are that a single chip solution is easier to maintain and upgrade; it is designed with a single tool; parallelism in the hardware of the FPGA can give performance improvements; and the overall cost of the system can be lower.

The basic principles of generating video in an FPGA are explained first, and then a simple example of a video game is used as an illustration.

Video Signals

The signals depend on the type of display that is being driven. The simplest is a TTL monitor for which the signals can be driven directly by the pins of the FPGA, so no external components are necessary at all.

However, for the present discussion, it is assumed that a VGA monitor is being used and so the video signals are:

• red

• green

• blue

• horizontal sync • vertical sync

These signals must have the correct electrical and timing characteristics.

Electrical Characteristics

The horizontal sync and vertical sync are TTL, and so can be driven directly by the pins of the FPGA. However the red, green and blue are analogue 0.7V peak-to-peak positive into a 75 ohm load so a DAC is required. A simple DAC can be implemented in a resistor network. Figure 3 shows such a network 300 for 4 bits per color. Three of these are required, one each for red, green and blue. For the highest accuracy the resistors should be chosen so that they double in value for each bit from bit 3 302 to bit 0 304. With 3.5V (TTL high output level) on all the bits, the voltage at the 75 ohm load is 0.78V.

The resistor networks and connector can be placed on the prototype area of boards such as the Xilinx design demonstration boards. The pinout of the VGA connector is discussed in Appendix C.

Timing Characteristics

The SyncGen process that generates the horizontal and vertical sync signals is set forth in the full Handel-C program listing in Appendix D. The program listing of Appendix D includes the deimition of a number of expressions representing various combinations of the current x and y pixel position variables. These definitions would normally be part of a library, which is why they are parameterized on the name of the x and y pixel counter variables. A definition of raster scan constants can be found in Appendix E.

The clock for the whole Handel-C program has been specified to be an external clock on pin 13 of the FPGA (see hardware specific definitions in the full listing of Appendix D) The displayed pixel moves on each clock so this is also the pixel frequency. The frequency is 20MHz, and the screen refresh rate is 60 frames per second.

The HBlank and blank expressions calculate the horizontal and vertical bleuiking periods, i.e. the non-visible periods. They are generated by logical expressions involving the current pixel position. The sync signals for the monitor are generated similarly. The SyncGen process outputs the horizontal and vertical sync signals on pins 9 and 6 of the FPGA. It also increments x and y or resets them to zero according to the current pixel position. The 'par' statement runs the two assignments within the curly brackets in parallel.

Every assignment takes exactly one clock cycle, and the whole program is clocked by the same clock. So these parallel assignments both complete in every clock cycle, literally in parallel. Note that the evaluations of the expressions in 'if and 'while' statements take zero clock cycles. So one execution of the while (1) loop takes exactly one clock cycle.

It is very important to remember the key feature in Handel-C of parallelism. Parallel processes or statements use completely separate logic within the FPGA so they run in complete lockstep: the first statements of each process run in the same clock period, then the second statements run in the next clock period, and so on. The time taken for a par construct to complete is the time of the longest process within the par. Shorter processes in effect have to wait for the longest process to finish.

Program Structure

The program to be described might be the core of a video 'bat-and-ball' game. The screen consists of a background color, surrounded by a border and a moving square (the 'ball') which moves in straight lines and bounces off the border. At the top-level the program consists of parallel composition of three processes as shown below:

* The main program * ******************* void main (void) par

{

SyncGen () ;

Display ( ) ;

PerFrameϋpdate () ; }

}

This fragment highlights the major difference already mentioned between Handel-C and conventional sequential languages like C, that of parallelism. This program calls for three separately executing processes to run concurrently. The first one is the SyncGen process and has already been described in detail. See also Appendix D. It is responsible for producing (approximately) standard VGA video sync signals and for updating the ScanX and ScanY variables which track the current pixel position both during display and during the hidden parts of the video signal, namely the horizontal and vertical blank intervals. The other two processes synchronize themselves to this one by inspecting the values of these two variables. The Display process is responsible for producing the video output signal and the PerFrameUpdate process changes the variables used by the display process to advance the state of the 'game'.

Another difference with C is that variables can be typed with an arbitrary bit width. In the global variable definitions in the full listing, ScanX and ScanY are defined to have just enough bits to represent the total number of columns and lines in the display, as reproduced below

unsigned (log2ceil (TotalCols) ) ScanX; unsigned (log2ceil (TotalLines) ) Scan Y; Width inferencing and typing systems ensure that the programmer needs to declare widths only where necessary.

The compiler will usually be able to work out the widths of objects that the programmer has not explicitly specified.

Display Process

The fragment 400 in Figure 4 is the declaration of the video output register, and the process that creates the video signal. The interface structure declaration defines the mapping of the video register onto the FPGA pins. The FPGA is a Xilinx 4003. There are 3 colours of 4 bits each and the external resistor network DAC already described is used for each colour.

The display process runs continuously in a 'while' loop. If the current pixel position (ScanX, ScanY) is visible then the nested 'if statement branches one of three ways depending on whether the current pixel is within a border region, or within the ball, or is simply part of the background. A different pixel color is assigned to the video output register for each of these situations and the video signal is additionally forced to black outside the visible region.

The Handel-C language defines that an assignment takes exactly one clock cycle. It can be seen that the most that happens in one invocation of the body of the while loop is a single assignment. There is no sequential composition anywhere in the body. Thus this inner loop will run in exactly one clock cycle and the video register will be updated at the full 20MHz video clock speed.

Frame-Rate Update Process The PerFrameUpdate process 500 in Figure 5 runs continuously and waits for the first non-visible pixel. At this point it calculates the new ball direction and updates the ball position. There are thousands of clock cycles in the blanking period for this process to execute so there is no particular advantage to having it run in parallel. However there is no particular advantage to having it run sequentially either. The saving in hardware from any attempt to share the adders sequentially is likely to be more than outweighed by the addition of multiplexors to achieve this sharing. Hence it runs in parallel.

Note the 'delay' statement at the end. This is effectively a no-op and takes one cycle. It is inserted to ensure that the 'while' loop takes at least one clock cycle. Without it a combinatorial loop would be generated in the hardware.

PS/2 Interface and Mouse Driver

This section discusses the PS/2 serial data transfer protocol and presents a Handel-C module for interfacing with an external device through a PS/2 port and a mouse driver for a standard 2 button PS/2 mouse, according to an illustrative embodiment of the present invention.

Features

• PS/2 protocol specification

• PS/2 serial data transfer interface

• Mouse driver for 2 button PS2 mouse

Operation The PS/2 serial interface was introduced by IBM with its PS/2 microcomputer. Although the protocol is no longer officially supported by the company it has become a standard for most modern mice and keyboards.

Figure 6 depicts a PS/2 system 600. The interface requires 4 wires connecting a host 602 and a device 604, set up as shown in Figure 6. The CLK and DATA line each have a 10k pull-resistor, allowing the communicating parties to float the lines to indicate a logic 1 and pull them low for a logic zero, without actually having to drive any of the lines.

PS/2 Serial data transfer protocol

The PS/2 protocol allows synchronous, bi-directional bit-serial cornmimication between the host and an external device such as a mouse or keyboard. Either side may transmit commands or data at any time, although only one side can transmit at any one time.

Each byte transmitted between the host and the attached device consists of a start bit (logic 0), eight data bits (transmitted LSB first), a parity bit (odd parity), and a stop bit (logic 1). During transmission the device controls the clock and the host or device (depending on which is doing the transmitting) pull the DATA wire low to signal a logic 0 or float high to signal a logic 1.

Between transmissions, the bus can be in one of three states:

• Idle - If CLF ^α" DATA are both high, there is no activity on the bus.

• Inhibit - If the host is holding CLK low, the device is inhibited from transmitting data.

• Request to send - If the host is holding DATA low and allowing CLK to float high, the host is ready to transmit a byte to the device. Host Receiving Data

The device can transmit on the bus whenever the bus is idle, but not if the bus is inhibited or in the request to send state. The device transmits a byte by pulsing CLK low then high 11 times and placing the start bit, 8 data bits, parity bit and stop bits on the DATA wire respectively. The host samples the DATA line when CLK is how; the device will change the state of the DATA line during the period when. CLK is high. CLK will remain low for 30 - 50 μs and high for 30 - 50 μs. DATA should be valid be valid at least 5μs before the falling edge CLK and for at least 5μs after the rising edge of CLK. The host is able to inhibit any further transmission while the last one is processed by pulling CLK low after the stop bit is received. The host can also abort a transmission by pulling CLK low before the rising edge of the tenth clock.

The waveforms 700 associated with sending and receiving data are shown in Figure 7. Device actions are shown in bold lines and host actions in light lines.

Host Sending Data

To send data to the device, the host signals its intent by holding CLK low for at least 100 μs, then pulling DATA low and releasing CLK, thus putting the bus into the ready- to-send state. The device will check for this state and upon detecting it will pulse CLK eleven times. CLK will remain low for 30 - 50 μs and high for 30 - 50 μs. The host must change the value on DATA while CLK is low; the device samples it when CLK is high. Again, the h ^{' '}s able to abort a transmission by holding CLK low for at least 100 μs at any time before the eleventh CLK pulse.

After the tenth clock the device should check for a valid stop bit and respond by clocking one more time and pulling DATA low (line control bit). Should the device find DATA low during the stop bit it should continue to clock until DATA goes high and then send a Resend command to the host.

PS/2 Port Interface

The PS/2 is implemented in the file ps2_port.h. It has the interface:

ps2_port (ps2_data_in, ps2_data_out)

where ps2_data_in snάps2_data_ out are 8 bit wide channels. Any data received by the port can be read fxomps2_data_in and any data to be sent out over the port should be written to ps2_data_o t. Framing error and parity eπor checking occurs internally and only valid data bytes are output through the channel. The parity bits and framing bits for the bytes to be sent are also generated internally, and this need not concern the user.

The ps2_port() process should be run in parallel to any process wishing to communicate over the PS/2 port, such as a mouse driver or keyboard controller.

PS/2 Mouse Driver

Usage

The PS/2 mouse driver is contained in the file ps2_mouse.h. Although the standard PS/2 mouse only has 2 buttons the driver follows same API as the existing mouse drivers, to make the task of porting applications between different platforms as easy as possible.

mouse_screen (px, py, bl, bm, br, VisibleCols, VisibleLines) where px and py are of type unsigned 10 and indicate the current position of the mouse cursor on the screen, and bl, bm and bx (unsigned 1) indicate the state of the mouse buttons, (bm will always have the value logic 0 as the standard PS/2 mouse protocol only supports 2 buttons).

The process should be run in parallel to the syncgenQ process in the main loop. The ps2_port() process which is required by this driver is called internally in parallel with the main loop of the driver.

The driver supports 'hot plugging', the unplugging and re-plugging of devices during the running of the application.

PS/2 mouse data packet

The data packet consists of 3 bytes and these are made up as described below in Table 1. A packet is sent to the computer every time the mouse changes state (i.e. the mouse is moved or the buttons are released/pressed).

Table 1

D7 D6 D5 D4 D3 D2 Dl DO

Bytel XV YV XS YS 1 0 RB LB

Byte 2 X7 X6 X5 X4 X3 X2 XI xo

Byte 3 Y7 Y6 Y5 Y4 Y3 Y2 Yl Y0

LB and RB are the states of the left and right mouse buttons respectively (1 if the button is pressed) X0-7 indicates the movement of the mouse in the X direction since last packet (+ve means right)

Y0-7 indicates the movement of the mouse in the Y direction since last packet (+ve means up)

XS and YS indicate the sign of the X and Y bytes - bytes 2 and 3 are themselves signed so this appear to be a remnant from previous mouse protocols in which they were not. (This could also be used for eπor checking)

XV and YV indicate whether there was an overflow error during the mouse movement.

The decoding of these data packets happens internally and the user is only presented with the current position of the cursor (calculated from the previous coordinates of the cursor and the relative movement since those coordinates calculated) on the screen and the states of the mouse buttons.

Some manufacturers extend this protocol to six bytes to allow for devices with more features. The make up of these six byte packets is device dependent however, and as such this driver is not able to support it. Please refer to the manufacture's documentation for more device specific information.

Mouse Commands

On being plugged in nr powered up, a PS/2 mouse will perform self test and calibration procedures and then transmit the command sequence $AA $00 to indicate that it is ready for communication. Should the self test fail the device may send the error code $FC followed by $00. Once the device is ready, the sequence $AA $00 has been received, the host ma send a number of initialization commands to the device. Each of these, except the Resend ($FE) command, will be acknowledged by the mouse with an ACK ($FA) byte which may be followed by more information bytes depending on the requirements of the host . Finally, once the initialization procedure is complete, the host should send the Enable ($F4) command to start the mouse transmitting positional information. ,

Different device manufactures have extended the protocol to support more features (i.e. more than two buttons, mouse wheels, touchpads etc. ) and each will have their own set of commands associated with it. Some of the commands are however standard and any PS/2 pointing device should support these.

These commands are outlined below:

$FF Reset. Performs a software reset and recalibration. The response is ACK ($F A) followed by $AA $00

$FE Resend. The device will resend the last data packet. (The size of this packet will depend on the last command issued to the device)

$F6 Set Defaults. This resets the device to the initial power-up state. (The device will need to be re-enabled after this command)

$F5 Disable. Disables stream mode reporting of motion packets.

$F4 Enable. Enables stream mode reporting of motion packets.

$F2 Read Device Type. The response to this is ACK($FA) followed by a $00

$F0 Set Remote Mode. Switches the device to remote mode (as opposed to fhe default stream mode). In this mode the device will only send motion packet information when queried with the Read Data ($EB)command.

$EB Read Data. The device replies with ACK ($FA) and a motion data packet.

$EA Set Stream Mode. Switches the device back to stream mode.

Information on the PS/2 protocol and mouse protocols in general can be found in The Indispensable PC Hardware Book, Hans Peter Messmer, Addison- Wesley; the PC Mouse Information website, http://www. hut.fi/~then/mytexts/mouse. html; and Synaptics TouchPad Interfacing Guide is available on the Engineering Web/Misc. Technical Information or from Synaptics direct.

Microsoft Mouse Driver

According to another illustrative embodiment of the present invention, a Microsoft Mouse header provides macros for reading data from a Microsoft Mouse Protocol compatible, 2 or 3-button serial mouse connected to the serial port of the Hammond board. The header provides macro supporting Microsoft compatible 2 and 3-button mice and provides an additional macro that maintains the position of the mouse pointer within given screen dimensions..

This section describes the operation of the driver in some detail. The first subsection explains the communication with a Microsoft compatible mouse via the serial port in some detail. The second subsection describes the basic sequence of operations of the driver to handle this communication. Appendix F contains a code segment for a driver for a mouse driver for master/slave FPGAs. Coordinate System

As shown in Figure 8, the coordinate system for the mouse has the origin at the top left of the screen 802, with the x-axis positive to the right and the y-axis positive downwards.

The Microsoft Compatible Mouse

The Data Pocket

A Microsoft compatible mouse sends data packets to the serial port whenever the mouse changes state (i.e. the mouse is moved or the buttons are released/pressed). The data packet consists of three bytes, as shown in Table 2.

Table 2

Key for Table 2:

LB: state of the left button (1 meaning the button is pressed)

RB: state of the ic+tt button (1 meaning the button is pressed)

X0-7: movement of the mouse in the X-axis since the last packet (right is positive)

Y0-7: movement of the mouse in the Y-axis since the last packet (down is positive) The byte marked with ' 1 ' is sent first and then the others. The bit D6 in the first byte is used for synchronizing the driver to the mouse packets if they become out of sync. In three-button mode, when the middle button is pressed, held down, or released, a fourth byte is sent with the value 32 if the button is pressed, zero if it is not. Bit D6 is not set, so the synchronization is maintained.

Mouse Identification

A Microsoft compatible Mouse uses the RTS pin as its power source. Whenever RTS is set to O' and reset to T, the mouse performs an internal reset and sends the ASCII character 'M' to signal its presence. It is therefore possible to discern a mouse's mode when it is first given power.

Three-button-mice send 'M3' if you drop and raise RTS in Microsoft mode. Holding down the left mouse button on some mice when the power is dropped and raised will cause them to switch to "Mouse Systems" mode, which uses an entirely different packet to communicate with the host. There is no support for Mouse Systems mice in the macros provided by "MicrosoftMouse.h". See- Appendix F.

It has been noticed, however, that some 3-button mice (that purport to be Microsoft mouse protocol compatible mice) do not correctly identify themselves as such when power is dropped and raised. To get around this problem, all mice are assumed to be three-button mice, which does not cause any problems, as the three-button protocol is simply an extension of the two-button one.

In addition, some mice do not send the correct code in the fourth byte to indicate a middle-button press. This is handled by simply checking a fourth byte for a non-zero value to indicate a middle-button press. The "mouse" Macro

Parallel Processes

The mouse macro has three parallel processes: a process for the serial port driver; a process that continually sends data on the RTS to the mouse in order to provide power and a process that reads and interprets data from the serial port.

The serial port driver is found in "serial.h". The "serial_port" macro provides two channels to the RS232 serial port: one input and one output. The process providing power continually sends 0x1111111 to the mouse. Appendix A contains an illustrative code segment for a serial port driver.

The Input Reading Process

The third process, which reads data from the mouse, first goes through a brief initialization. It reads in two bytes from the input channel and checks for an ASCII "M" to identify the mouse as a Microsoft compatible mouse. If this character is not detected, rather than fail, the process will continue to treat the mouse as a Microsoft compatible mouse, but its behavior cannot be guaranteed. If an "M" is detected, the second byte is then tested for ASCII character "3", which, if found, sets the process to operate in three- button mode. The default mode of operation is to treat the mouse as using the basic Microsoft two-button protocol, sending a fourth byte with either a zero value to indicate the middle-button being released or a non-zero value to indicate the middle-button being pressed. This may cause problems if the mouse is using a different, unspecified, protocol but, in general, satisfactory operation should result.

After the initialization, the process enters a continuous loop for reading data packets. The first step of the loop is to ensure that the process is reading the first byte of a packet by testing the synchronization bit (bit number 6), reading in a new byte if necessary. It then reads in the second and third bytes of the standard data packet and updates the left and right buttons and the x and y coordinates of the mouse pointer (according to the data packet shown above).

The final stage of the loop is to test for a middle button event. This involves first reading in a fourth data byte from the input channel and testing the synchronization bit. If the byte is identified as the first byte in a data packet (bit 6 is 1), then the loop returns to the beginning using this byte as the first of the next packet. Otherwise, this byte is tested for the status of the middle button: in normal Microsoft three-button mode, a zero value indicates released and 32 indicates pressed; in two-button mode with non- Microsoft three-button extensions, a zero value indicates released, non-zero indicates released.

The mouse screen Macro

This macro is identical to the "mouse" macro except that it takes two extra arguments, the height and width of the screen (in pixels) and uses these to maintain the position of the mouse pointer within these dimensions.

Usage

Include the header file "MicrosoftMouse.h" in your program. Use the "mouse" or "mouse_screen" macro in parallel with your main body of execution. The arguments required are the coordinates of the mouse pointer that you wish to update (unsigned integers px and py), the left, right and center button states (unsigned integers of width 1) which you wish to update and, in the case of the "mouse_screen" macro, the number of visible columns and lines on the display (unsigned integers VisibleCols and VisibleLines, which must be the same width as px and py). mouse(px, py, bl, bm, br); mouse_screen(px, py, bl, bm, br, VisibleCols, VisibleLines);

While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation.. Thus, the breadth and scope of a preferred embodiment should not be limited by any of the above described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

1. A method for implementing drivers in a reconfigurable logic device, comprising the steps of:

(a) receiving a request for access to a hardware device; (b) connecting a reconfigurable logic device to a code library, wherein the code library includes at least one driver for interfacing the hardware device with an application; (c) retrieving a driver associated with the hardware device from the code library; and (d) utilizing the driver for configuring the reconfigurable logic device to communicate with the hardware device.

2. A method as recited in claim 1, wherein the reconfigurable logic device interfaces with at least one of a hardware register, buffer management, a microprocessor, an interrupt handler, and a memory transfer.

3. A method as recited in claim 1 or 2, wherein the hardware device is an input device.

4. A method as recited in claim 1, 2 or 3, wherein the reconfigurable logic device is capable of being configured to communicate with multiple hardware devices.

5. A method as recited in claim 4, wherein the request is for access of multiple hardware devices, and wherein the reconfigurable logic device is configured to communicate with the multiple hardware devices.

6. A method as recited in claim 1, 2, 3, 4 or 5, wherein the reconfigurable logic device includes at least one field programmable gate array.

7. A computer program embodied on a computer readable medium for implementing drivers in a reconfigurable logic device, comprising: (a) a code segment that receives a request for access to a hardware device;

(b) a code segment that connects a reconfigurable logic device to a code library, wherem the code library includes at least one driver for interfacing the hardware device with an application;

(c) ^' a code segment that retrieves a driver associated with the hardware device from the code library; and

(d) a code segment that utilizes the driver for configuring the reconfigurable logic device to communicate with the hardware device.

8. A computer program as recited in claim 7, wherein the reconfigurable logic device interfaces with at least one of a hardware register, buffer management, a microprocessor, an interrupt handler, and a memory transfer.

9. A computer program as recited in claim 7 or 8, wherein the hardware device is an input device.

10. A computer program as recited in claim 7, 8 or 9, wherem the reconfigurable logic device is capable of being configured to communicate with multiple hardware devices.

11. A method as recited in claim 10, wherein the request is for access of multiple hardware devices, and wherein the reconfigurable logic device is configured to communicate with the multiple hardware devices.

12. A computer program as recited in claim 7, 8, 9, 10 or 11 , wherein the reconfigurable logic device includes at least one field programmable gate array.

13. A system for implementing drivers in a reconfigurable logic device, comprising: (a) logic that receives a request for access to a hardware device; (b) logic that connects a reconfigurable logic device to a code library, wherein the code library includes at least one driver for interfacing the hardware device with an application; (c) logic that retrieves a driver associated with the hardware device from the code library; and (d) logic that utilizes the driver for configuring the reconfigurable logic device to communicate with the hardware device.

14. A system as recited in claim 13, wherein the reconfigurable logic device interfaces with at least one of a hardware register, buffer management, a microprocessor, an interrupt handler, and a memory transfer.

15. A system as recited in claim 13 or 14, wherein the hardware device is an input device.

16. A system as recited in claim 13, 14 or 15, wherein the reconfigurable logic device is capable of being configured to communicate with multiple hardware devices.

17. A system as recited in claim 16, wherein the request is for access of multiple hardware devices, and wherein the reconfigurable logic device is configured to communicate with the multiple hardware devices.

8. A system as recited in claim 13, 14, 15, 16 or 17, wherein the reconfigurable logic device includes at least one field programmable gate array.