Method and system for managing a plurality of I/O interfaces with an array of multicore processor resources in a semiconductor chip

The present invention relates to a method and system for managing I/O interfaces with an array of multicore processor resources in a semiconductor chip. The I/O interfaces are connected to the processor resources through an I/O shim. An I/O interface sends a dataframe to the I/O shim. The I/O interface packetizes data to form the dataframe, based on an I/O protocol. The dataframe includes a header and the data. The I/O shim identifies a command corresponding to the dataframe by using one or more of the processor resources. The command includes a set of tasks. Subsequently, the set of tasks is executed on the data.

BACKGROUND OF THE INVENTION

The present invention relates, in general, to interfacing Input/Output (I/O) interfaces with an array of multicore processor resources that are connected in a tiled architecture. In particular, the present invention relates to providing a dynamic software-controlled hardware interface between the I/O interfaces and the array of multicore processor resources.

I/O interfaces are hardware circuits that are designed to process, initialize and move data in a semiconductor chip. Examples of I/O interfaces include a 10 Gbe, a PCIe, Gbe I/Os, and the like. The hardware circuitry of an I/O interface depends on its usage model and application. For example, some applications require transfer of the data prior to processing it, while other applications require processing of the data prior to its transfer. The I/O interfaces are connected to the processor resources. The processor resources processes the data received from the I/O interfaces. The I/O interfaces are generally connected to the processor resources by hardwired connections that are designed based on a predefined addressing scheme. Examples of predefined addressing schemes include a memory-mapped addressing scheme and an I/O-mapped addressing scheme. The I/O interface connections do not facilitate the flexibility of dynamically connecting the I/O interfaces with the processor resources.

The hardware circuitry is designed by using common buses, such that a particular I/O interface can only communicate with its corresponding processor resource. This adds to the complexity of the circuit, particularly if the number of I/O interfaces and/or processor resources is large. Consequently, the circuitry requires additional chip area, and each processor resource is rigidly pre-assigned to an I/O resource. Moreover, the combination of a particular processor resource and its corresponding I/O interface is also fixed.

Alternatively, tri-state bus architecture can be used in the hardware circuitry. The tri-state bus architecture allows a limited number of processor resources to be dynamically linked to the I/O interfaces. The limit of the number of processor resources linked to I/O interfaces is based on the electrical characteristics, such as current requirements, acceptable transfer delays, and the like. Additionally, the tri-state bus architecture has to ensure no contention on tri-state buses during every scan shift operation in Automatic Test Pattern Generating Concerns (ATAG). ATAG is used to distinguish between the correct circuit behavior and the faulty circuit behaviors caused by any fault in the design or performance of the circuit.

In light of the foregoing discussion, there is a need for a method and system for dynamically managing I/O interfaces with an array of multicore processor resources. Such a method and system should provide a dynamically controlled hardware circuit to connect I/O interfaces to the array of multicore processor resources that use the chip area efficiently. This would eliminate any predetermined binding of a particular processor resource with a corresponding I/O interface. Further, such a system should be scalable, so that one or more of the processor resources can be connected to an I/O interface, depending on its characteristics. Furthermore, such a system should facilitate the assignment of processor resources to the I/O interfaces in any desired combination.

SUMMARY OF THE INVENTION

An object of the present invention is to provide a method and system for managing Input/Output (I/O) interfaces with an array of multicore processor resources in a semiconductor chip.

Another object of the present invention is to provide a dynamic interface I/O shim between the array of multicore processor resources and the I/O interfaces, with a chip area-efficient hardware controlled by software. This provides flexibility to the process of dynamically assigning one or more of the processor resources to each of the I/O interfaces to process data.

Yet another object of the present invention is to eliminate the pre-determined assignment of the processor resources to any of the I/O interfaces. This provides flexibility in using the processor resources.

Yet another object of the present invention is to dynamically identify the number of processor resources needed for an I/O interface, depending on the characteristics of the I/O interface.

Yet another object of the present invention is to provide an I/O shim's software control that strings together the processor resources and the I/O interfaces in any desired combination.

Various embodiments of the present invention provide a method and system for managing I/O interfaces with an array of multicore processor resources in a semiconductor chip. Such a system for managing I/O interfaces with an array of multicore processor resources is hereinafter referred as an I/O shim. An I/O interface sends a dataframe to the I/O shim. This dataframe is formed by packetizing data based on an I/O protocol. The dataframe includes the data and a header. The I/O shim identifies a command corresponding to the dataframe by using one or more of the processor resources. The command includes a set of tasks, which is executed on the data by the I/O shim.

DETAILED DESCRIPTION OF THE INVENTION

Various embodiments of the present invention provide a method, system and computer program product for managing Input/Output (I/O) interfaces with an array of multicore processor resources in a semiconductor chip. Such a system for managing I/O interfaces with an array of multicore processor resources is hereinafter referred to as an I/O shim. Examples of the I/O interfaces include a 10 Gbe, a PCIe, Gbe I/Os, and the like. The I/O interfaces use different I/O protocols to communicate with the array of multicore processor resources to process data. Examples of such I/O protocols include, but are not limited to, a Local Interconnect Network (LIN) protocol, a Controller Area Network (CAN) protocol, a Media Oriented System Transport (MOST) protocol, and a Transmission Control Protocol/Internet Protocol (TCP/IP).

These I/O interfaces communicate with the array of multicore processor resources through I/O Dynamic Network (IODN) lines. However, the I/O interfaces communicate with the memory used for storing data through Memory Dynamic Network (MDN) lines. The I/O interfaces transmit the data that is packetized in dataframes to a desired location, depending on the task to be executed on the data. These dataframes are formed by the I/O interfaces based on the set of rules defined by an I/O protocol. Different I/O interfaces use different I/O protocols to form the dataframes by packetizing the data. Further, the location of the header and the data included in each dataframe is defined on the basis of the I/O protocol used to form the dataframe.

The header in the dataframe includes a command which is detected by a processor resource. This processor resource is selected from the array of multicore processor resources on the basis of its availability and capability. The capability of a processor resource is defined as the set of tasks that can be executed by the processor resource. Each processor resource in the array of multicore processor resources is programmed to execute a certain set of tasks on the data. This set of tasks is included in a command. Further, the identification of the command corresponding to the header in the dataframe is executed by a processor resource that is chosen randomly from a set of available and capable processor resources. These processor resources are a part of the array of multicore processor resources. Subsequently, the set of tasks present in the command is executed on the data.

FIG. 1is a block diagram illustrating a semiconductor chip100, wherein various embodiments of the present invention can be practiced. Semiconductor chip100includes I/O interfaces102a-d, an off-chip memory104, I/O shims106a-d, and an array of multicore processor resources108. I/O interfaces102a-dform the hardware circuitry that provides compatibility for communication between processing units interconnected through these I/O interfaces. I/O interfaces102a-duse different I/O protocols to packetize data and are designed differently for different I/O protocols. In accordance with an embodiment of the present invention, I/O interfaces102a-dmay use similar protocols for packetizing the data. Based on the I/O protocol, each of I/O interfaces102a-dpacketizes data to form a dataframe and uses the dataframe to transfer the data to a desired location.

Off-chip memory104is connected to semiconductor chip100to store the data. I/O shims106a-dare interfaces between I/O interfaces102a-dand an array of multicore processor resources108. I/O shims106a-dare designed logic with a hardware component and a software component. I/O shims106a-dprocess the data and manage the processed data in order to move the data to a desired location. Thus, I/O shims106a-ddynamically interface each of I/O interfaces102a-dto the array of multicore processor resources108.

In addition, I/O shims106a-dprovide compatibility between I/O interfaces102a-dand the array of multicore processor resources108. This compatibility includes understanding I/O protocols and the usage models of I/O interfaces102, and the like, by the array of multicore processor resources108. The usage model of I/O interfaces102a-dcan be any of transferring data application, processing data to format dataframes, and the like.

The array of multicore processor resources108includes processor resources arranged in a tiled manner in semiconductor chip100. Each processor resource in the array of multicore processor resources108executes a specified set of tasks and can be dynamically programmed to execute the required set of tasks. This is achieved by programming the array of multicore processor resources108to execute a defined set of tasks in semiconductor chip100at any point of time. Since processor resources present in the array of multicore processor resources108are reprogrammed dynamically, depending on the requirement and availability of processor resources, the defined set of tasks keeps changing for particular processor resources. Further, each processor resource in the array of multicore processor resources108can program I/O shims106a-d, to execute a set of tasks on the data. In accordance with another embodiment of the present invention, I/O shims106a-dcan be programmed by an off-chip controller218that is connected to semiconductor chip100.

FIG. 2is a block diagram illustrating a system200for managing Input/Output (I/O) interfaces102a-dwith the array of multicore processor resources108present in semiconductor chip100, in accordance with an embodiment of the present invention. System200includes I/O interface102a, I/O shim106d, along with its elements, processor resources108aand108b, a memory shim212, and an off-chip controller218. I/O interface102acommunicates with the array of multicore processor resources108through I/O shim106d, using IODN lines216. However, for the purpose of illustration, only two multicore processor resources,108aand108b, are shown inFIG. 2. I/O interface102acan communicate with one or more processor resources in the array of multicore processor resources108, depending on the characteristics and requirement of I/O interface102a. I/O interface102apacketizes data to form a dataframe, based on a corresponding I/O protocol. The dataframe includes a header and a data bit portion. I/O interface102asends the dataframe to I/O shim106d.

I/O shim106ddynamically interfaces I/O interface102aand the array of multicore processor resources108, using a designed combination of hardware and software components. The software components of I/O shim106dare stored in configuration registers of I/O shim106d. I/O shim106dcan be dynamically programmed at any instant by writing a program code in the configuration registers. I/O shim106dcan be programmed by one of the processor resources in the array of multicore processor resources108or by off-chip controller218connected to I/O shim106a-din semiconductor chip100. Since I/O shim106dis a hardware component that is controlled by a software component, it can handle multiple I/O usage models. For example, I/O shim106dcan handle the tasks of sending the received data directly to memory shim212or to processor resource108aor108b, depending on the requirement, as well as sending the received data directly from I/O interface102ato I/O interface102bvia one of I/O shim106a-dand one of the array of multicore processor recourses108.

I/O shim106dincludes a media-access control layer202, a transfer-rate controlling module204, a generic-command identifying module206, an executing module208, and an arbitrator multiplexer220. Each of I/O interfaces102has a corresponding compatible media-access control layer. For example, I/O interface102ahas a specifically designed corresponding control layer compatible with media-access control layer202. The dataframe received from I/O interface102ais routed to its corresponding media-access control layer202, which includes an identifying module210. Identifying module210identifies the I/O protocol used in the dataframe received from I/O interface102a. Further, media-access control layer202identifies the header and the data present in the dataframe by using the identified I/O protocol. Additionally, media-access control layer202may be configured in a pass-all-packet mode in order to make media-access control layer202compatible with custom packets. These custom packets are generated by non-standard I/O interfaces. For custom packets, media-access control layer202, configured in pass-all-packet mode, bypasses traditional MAC (Media Access Control) features such as CRC (Cyclical Redundancy Code) checking, preamble processing, framing, and L2 header checking. These bypassed features are performed by processor resources108. Further, processing of the custom packet information is also performed by processor resources108.

Transfer-rate controlling module204regulates the rate at which the dataframe is received. Transfer-rate controlling module204connects media-access control layer202with generic-command identifying module206. Transfer-rate controlling module204also dynamically connects the complex pieces of design in generic-command identifying module206with media-access control layer202. This results in the complex pieces of designs in generic-command identifying module206being dynamically used for different media-access control layers. The complex pieces of design in generic-command identifying module206includes the designs of a Direct Media Access (DMA) engine, a configuration interface, a network interface, a First-In-First-Out (FIFO), and interrupt generation.

Generic-command identifying module206provides flexibility to handle any protocol-specific data from I/O interfaces102. In addition, generic-command identifying module206dynamically manipulates the header present in the dataframe, e.g., pre-pending data or post-pending data, based on the computational requirement. Thereby, generic-command identifying module206provides capabilities of load balancing, protocol sorting, simple quality of service (QoS), and header forwarding to I/O shim106.

Generic-command identifying module206, with the help of processor resources, identifies the command present in the header of the dataframe and takes dynamic decisions, based on the identified command. This includes pre-pending and post-pending the data. In addition, generic-command identifying module206is defined to provide a message-based protocol to I/O interface102afor communication. This eliminates the need for I/O protocol-specific hardware in semiconductor chip100, since a message-based protocol provides the ability to emulate. This emulation is performed based on the data information, which is in the form of bits in the message. The active bits have emulating signals. Further, the message-based protocol virtualizes a required set of tasks such that each of the set of tasks can be represented by a message. After receiving the message, the set of tasks is performed so the message virtually represents the set of tasks. This includes virtualizing tasks such as interrupt generation, interrupt handling, as well as register and processor commands.

Furthermore, the message-based protocol can also be coupled with the array of multicore processor resources108that are arranged in a tiled fashion. Moreover, the message-based protocol provides flexibility in the assignment of either a processor resource108aor a processor resource108bto I/O interface102a. For example, if processor resource108awants to shift control of I/O interface102ato processor resource108b, processor resource108asends a message-based protocol message to processor resource108bto indicate the shift of control. This provides I/O management of I/O interfaces102present in the array of multicore processor resources108. In addition, this provides dynamic assignment of processor resource108aor108bto I/O interfaces102. As a result, pre-determined binding of processor resource108ato service I/O interfaces102is eliminated. Examples of such services include, but are not limited to, controlling ingress and egress traffic, headerframe processing, power management, initialization, interrupts, and Basic Input/Output System (BIOS)-level interactions.

Executing module208stores the data in memory shim212through MDN lines214. Subsequently, executing module208executes the set of tasks corresponding to the command identified on the dataframe, using one or more processor resources from the array of multicore processor resources108. Each processor resource in the array of multicore processor resources108is a processing unit that is programmed to execute a set of tasks on the received data. Each of the processor resources in the array of multicore processor resources108is connected to I/O shim106dthrough IODN lines216. I/O shim106dtransfers the data to one of the array of multicore processor resources108on IODN lines216. Further, each processor resource in the array of multicore processor resources108can program I/O shim106dto execute a set of tasks on the data.

FIG. 3is a block diagram illustrating generic-command identifying module206, along with its elements, in accordance with an embodiment of the present invention. Generic-command identifying module206includes a header-processing module302, a header storage306, a packet storage308, and a command log310. Header-processing module302extracts the header and the data from the dataframe received from I/O interfaces102. The header in the dataframe may include a Quality of Service (QoS) indicator. The header includes information pertaining to the data structure and the location of the header. The data structure of header storage306and packet storage308can be one of Last In First Out (LIFO), First In First Out (FIFO), or a tree structure.

Header-processing module302packetizes the header to form a headerframe. The headerframe includes the address of a processor resource that is selected from the array of multicore processor resources108. This processor resource is dynamically selected from the array of multicore processor resources108and is capable of and available for executing a required set of tasks. Header-processing module302includes a sending module304, which sends the headerframe to the selected processor resource. The headerframe is routed to the selected processor by arbitrator multiplexer220. This selected processor resource checks for framing errors in the headerframe and sends back the acknowledge command. The checking of framing errors includes checking parity of the header frame, cyclic redundancy code (CRC) of the header frame and the like, in order to check and remove errors in the received headerframe. Subsequently, the selected processor resource identifies the command corresponding to the headerframe. The processor resource, based on the identified command, issues a directive command to command log310. Command log310includes a set of tasks corresponding to each of the received directive commands. Subsequently, the set of tasks corresponding to the received directive command is executed on the data by one of the processor resources or I/O shim106based on the set of tasks to be performed. The directive command also includes information about packetizing the header to form the headerframe in order to execute the set of tasks.

FIG. 4is a block diagram illustrating executing module208, along with its elements, in accordance with an embodiment of the present invention. Executing module208includes a Direct memory access (DMA) engine402and a data handler404. DMA engine402is a programmable unit, which can be programmed by one of the array of multicore processor resources108, based on the command identified in the headerframe. In accordance with another embodiment, DMA engine402can be programmed based on a set of tasks that DMA engine402is required to perform on the data. DMA engine402transfers the data to a desired location, based on the requirement identified in the command, from I/O shim106to memory shim212through MDN lines214. Alternatively, DMA engine402transfers the data from I/O shim106to one of the array of multicore processor resources108through IODN lines216. Data handler404performs protocol-specific processing to manipulate data, based on the identified command. Data handler404includes a data manipulator406, which performs specific data manipulation, based on the identified command. For example, data manipulator performs the functions of pre-pending or post-pending the data, and the like.

FIG. 5is a flow diagram illustrating a method for managing I/O interfaces102with the array of multicore processor resources108in semiconductor chip100, in accordance with an embodiment of the present invention. I/O interface102apacketizes data, based on an I/O protocol, to form a dataframe. The dataframe includes a header and a data portion. At step502, the dataframe is received from I/O interface102aat I/O shim106d. At step504, the I/O protocol corresponding to the dataframe is identified by identifying module210present in I/O shim106d. The header is identified by I/O shim106din the dataframe by using the identified I/O protocol information. This I/O protocol information provides I/O shim106dwith information regarding the header and data portion of the dataframe. Further, a command, corresponding to the identified header, is detected by processor resource108a. Processor resource108ais selected from the array of multicore processor resources108, based on the capabilities and availability of multicore processor resources. The detected command includes a set of tasks that are to be executed on the data. At step506, the set of tasks is executed on the data present in the dataframe by one of the processor resources or I/O shim106dbased on the set of tasks to be performed.

FIGS. 6A and 6Billustrate a flow diagram of a method for managing I/O interfaces102with the array of multicore processor resources108in semiconductor chip100, in accordance with another embodiment of the present invention. I/O interface102apacketizes data, based on an I/O protocol, to form a dataframe. The dataframe includes a header and the data. At step602, the dataframe is received by I/O shim106dfrom I/O interface102a. As mentioned earlier, the transfer rate of receiving the dataframe is controlled by transfer-rate controlling module204when the dataframes are received. At step604, an I/O protocol, corresponding to the received dataframe, is identified by identifying module210. The identified I/O protocol includes the information pertaining to the header and data parts of the dataframe. At step606, the header and the data present in the dataframe are identified, based on the identified I/O protocol information. At step608, the header is packetized to form a headerframe by header-processing module302. The headerframe includes information relating to the address of processor resource108athat is selected from the array of multicore processor resources108. As mentioned earlier, the array of multicore processor resources108are processor resources that are programmed to execute a required set of tasks and are available for service.

Subsequently, the headerframe is sent by sending module304to processor resource108aat step610, to process the headerframe, and to identify a command corresponding to the headerframe. An arbitrator multiplexer220, present in IO shim106droutes the headerframe to processor resource108a. Processor resource108achecks for the framing errors and sends an acknowledgement bit for receipt of the headerframe. Arbitrator multiplexer220receives the acknowledgment bit and thereby confirms receipt of the headerframe from processor resource108a. At step612, processor resource108aidentifies a command corresponding to the headerframe in command log310, which includes a log of commands corresponding to different headerframes. Subsequently, a directive command, issued by processor resource108a, selects the set of tasks corresponding to the identified command present in command log310. At step614, DMA engine402is programmed by processor resource108ato execute the selected set of tasks corresponding to the identified command. As mentioned earlier, DMA engine402uses data handler404to perform certain data manipulations such as pre-pending the data, post-pending the data, and the like. At step616, DMA engine402directs the data in the packet storage to off-chip memory104through MDN lines214, if the set of tasks in the command corresponds to transferring the data to off-chip memory104. Alternatively, DMA engine402directs the data in the packet storage to one or more processor resources in the array of multicore processor resources108on the semiconductor chip100through IODN lines216at step618, if the set of tasks does not correspond to transferring the data to off-chip memory104. A selection of the one or more of processor resources is performed based on the set of tasks identified by processor resource108ain the command. The number of processor resources needed for performing the set of tasks also depends on the identified command. In addition, processor resource108bcan process the data present in the packet storage if required by the set of tasks identified in the command.

FIG. 7illustrates a flow diagram of a method for managing I/O interfaces102with an array of multicore processor resources108in the semiconductor chip100, in accordance with yet another embodiment of the present invention. At step702, a processor resource from the array of multicore processor resources108initializes other processor resources in the array of multicore processor resources108. This includes programming each of the array of multicore processor resources108to execute a certain set of tasks. In accordance with another embodiment of the present invention, an off-chip processor218, connected to semiconductor chip100, initializes the array of multicore processor resources108. The initialization process is performed based on a multi-level boot sequence. The initialization process starts by asserting the reset pin of semiconductor chip100. The on-chip state machines manage the phase lock loop (PLL) initialization and provide internal logic reset. In level-0 of the multi-level boot sequence, an instruction stream built into each processor resource wakes up and waits for command from its static network ports. The strapping pins indicate to semiconductor chip100the port address from which the data is transferred into semiconductor chip100. This data is transferred to one of I/O shims106a-d. Subsequently, the one of the I/O shims106a-dsends a dataframe, formed from the data to one of processor resources108through the static network. This processor resource, including a level-0 boot code, is programmed by one of the I/O shims106a-dto interpret the information in the dataframe. The information includes an address where the data is to be stored. Subsequently, the processor resource, with a level-0 boot code, programs the rest of processor resource108in serial fashion. I/O shims106a-dinformation is fed to a controlling processor that initiates the configuration of each I/O interface102by writing memory registers in I/O shims106a-d. The writing of the memory registers is performed by transferring digital information related to each I/O interface102to the memory registers. I/O interface102apacketizes the data to form a dataframe. The dataframe includes a header and the data. At step704, a dataframe is received by I/O shim106dfrom I/O interface102a. At step706, the I/O protocol corresponding to the received dataframe is identified by I/O shim106d. Subsequently, the header and the data present in the dataframe are identified by I/O shim106d, using the identified I/O protocol. The command corresponding to the header in the dataframe is detected by processor resource108a, which is capable of executing the required set of tasks. Such a processor resource is selected from the array of multicore processor resources108based on the capability and availability of the processor resource. These processor resources are also searched for their availability to execute the required set of tasks on the data corresponding to the command. At step708, the set of tasks is executed on the data present in the dataframe by I/O shim106dif the set of tasks does not require involvement of the array of multicore processor resource108.

FIG. 8illustrates a flow diagram of a method for managing I/O interfaces102with an array of multicore processor resources108in the semiconductor chip100, in accordance with yet another embodiment of the present invention. I/O interface102apacketizes data, based on an I/O protocol, to form a dataframe. The dataframe includes a header and the data. At step802, the dataframe is received by I/O shim106dfrom I/O interface102a. At step804, a command is received by I/O shim106dfrom processor resource108a. The command includes a set of tasks that is to be executed on the data present in the dataframe. At step806, the set of tasks is executed on the data present in the dataframe by DMA engine402, which is programmed by processor resource108ato execute the set of tasks corresponding to the command.

Various embodiments of the present invention provide a dynamic interface, an I/O shim between I/O interfaces, and an array of multicore processor resources. An I/O shim is a chip area-efficient hardware that is controlled by software. It handles I/O interfaces by using different usage models, which include steps such as sending the data directly to the memory shim through MDN lines, and sending the data directly to one of the array of multicore processor resources108through IODN lines or from one I/O interface to another I/O interface.

Additionally, the I/O shim is dynamically assigned to one or more of the processor resources and to a particular I/O interface, based on the capabilities and availabilities of the array of multicore processor resources. This eliminates pre-determined binding of the assigned processor resource to the I/O interface and provides flexibility to the I/O shim.

Further, the I/O shim dynamically decides the number of I/O processor resources needed for an I/O interface, depending on the set of tasks to be performed on the data. Further, the software component of the I/O shim strings together the processor resources and the I/O interfaces in any desired combination.

The system, as described in the present invention or any of its components, may be embodied in the form of a computer system. Typical examples of a computer system include a general-purpose computer, a programmed microprocessor, a micro-controller, a peripheral integrated circuit element, and other devices or arrangements of devices that are capable of implementing the steps constituting the method of the present invention.

The computer system typically comprises a computer, an input device, a display unit and the Internet. The computer typically comprises a microprocessor, which is connected to a communication bus. The computer also includes a memory, which may include Random Access Memory (RAM) and Read Only Memory (ROM). Further, the computer system comprises a storage device, which can be a hard disk drive or a removable storage drive such as a floppy disk drive, an optical disk drive, and the like. The storage device can also be other similar means for loading computer programs or other instructions on the computer system.

The computer system executes a set of instructions that are stored in one or more storage elements to process input data. The storage elements may also hold data or other information, as desired, and may be an information source or physical memory element present in the processing machine.

The set of instructions may include various commands that instruct the processing machine to execute specific tasks such as the steps constituting the method of the present invention. The set of instructions may be in the form of a software program. The software may be in various forms such as system software or application software. Further, the software might be in the form of a collection of separate programs, a program module with a larger program, or a portion of a program module. The software might also include modular programming in the form of object-oriented programming. Processing of input data by the processing machine may be in response to user commands, to the results of previous processing, or to a request made by another processing machine.

While the embodiments of the invention have been discussed and described, the invention is not limited to these embodiments only. A number of changes and modifications can be thought of without moving away from the scope of the invention, as discussed in the claims.