System for high speed computer graphics computation

The invention relates to a multiprocessing computer system for graphics, comprising a first unidirectional ring of computational subsystems each having a digital processor,    input-output means for interconnecting the first unidirectional ring to an external computer. A system of this kind has been disclosed in EP-A-0 236,762. The present invention is directed to extremely high-speed computer graphics image calculation with an architecture that is based on two undirectional rings. The reference, however accomplishing improved performance by means of a single ring of processing subsystems, inclusive of flag latches on the ring for interprocessor synchronization. In consequence, amongst other things it is an object of the present invention to further practice the ring architecture in an advantageous manner as set out in claim 1.

Various further advantageous aspects are recited in dependent Claims.

The Background Art

The field of computer graphics is growing rapidly in all segments of modern society, including entertainment, science, industry, and military applications. As the power and availability of digital computing devices increases, the variety of specific applications using computer graphics also increases. The phrase "computer graphics," in its broad sense as used herein, should be understood to include any application in which digital data is generated or manipulated to create a visually perceptible image. For example, computer graphics may involve digitizing an original real image and altering or manipulating the resulting digital data to produce a generated image different in some way from the original real image. In contrast, it may be that the image which is generated and presented to a user never existed previously except as a computer model consisting of data which was modeled, animated, and rendered to produce the final generated images.

In general, and particularly in the case of computer modeled, animated, and rendered images, the number of calculations which must be performed to create even one frame of a high resolution animated sequence far exceeds the capacity of most general purpose computers used, for example, in a business setting. Moreover, in the commercial applications of computer graphics, particularly in the entertainment and mass media industry, the meeting of very tight schedules and close deadlines requires that complex computer graphics sequences be completed very quickly. Meeting such tight schedules and close deadlines is crucial to the success of a commercial endeavor.

In order to produce computer systems capable of producing graphic images within reasonable time periods, suppliers of such systems have manufactured highly specialized hardware just for the purpose of generating computer graphics. Disadvantageously, such specialized hardware is incompatible with other manufacturers' hardware or is unable to emulate other manufacturers' systems or resulting images.

Moreover, the previously available computer systems which were dedicated to performing computer graphics were inflexible and could not be adapted to the particular needs of the user or the task at hand. For example, such dedicated computer graphics hardware may unalterably allocate one quarter of its resources to performing modeling tasks, one half of its resources to animation tasks, and the remaining resources to rendering tasks. Significantly, the needs of the user often do not match such an allocation of system resources. Furthermore, the dedicated hardware used in previously available systems often becomes obsolete soon after its release due to advances in the art.

In view of the drawbacks and disadvantages found in the prior state of the art, it would be an advance in the art to provide a computer system adapted for producing graphic images which is configurable so as to allow the hardware resources to be allocated to different tasks as the need arises. It would be yet another advance in the art to provide a computer graphics image computation system which may be adapted to input and output video information from several different peripheral devices and which can efficiently carry out the tasks of modeling, animating, and rendering of computer graphic images.

It would be a further advance in the art to provide a computer graphics image computation system which allows the images which have been stored or computed to be rapidly distributed to locations within the system or transferred to external video devices. It would also be an advance in the art to provide a computer graphics image computation system which utilizes a standard digital video signal to move image data within the system such as can be readily used by external video devices. It would also be an advance in the art to provide a computer graphics image computation system in which the number of components which can be incorporated therein may be expanded to accommodate the changing needs of the user.

OBJECTS AND BRIEF SUMMARY OF THE INVENTION

In view of the foregoing, it is a primary object of the present invention to provide a system and method for high speed computer graphics image computation.

Another object of the present invention is to provide a system and method for computer graphics image computation which can efficiently carry out modeling, rendering, and animating tasks and allows its hardware resources to be variably allocated among different tasks.

A further object of the present invention is to provide a system and method for computer graphics image computation which incorporates a pathway for transferring digitally encoded video images at high speed.

Still another object of the present invention is to provide a system and method for computer graphics image computation which allows a plurality of video processors to be synchronously linked together.

Yet another object of the present invention is to provide a system and method for computer graphics image computation which produces images that emulate the images generated by other computer graphic systems.

The present invention utilizes both a novel system architecture and arrangement of software to achieve the above-stated objects as will be briefly summarized below.

The computer graphics image computation system of the present invention utilizes hardware structures which are referred to herein as a processor ring (hereinafter P-ring), a video ring (hereinafter V-ring), and a plurality of local buses which directly interconnect at least one of the computational processors or computational subsystems, which make up the processor ring to at least one of the video processors which make up the video ring. Using this architecture, data can rapidly travel on the P-ring, the V-ring, and between the V-ring and the P-ring.

Importantly, the architecture of the processor ring closely couples a plurality of powerful computational subsystems. The P-ring when coupled with the V-ring provides a novel, flexible, and powerful computer graphics image computation system.

The novel architecture of the video ring includes a plurality of video processors which synchronously operate in real time to rapidly move digital video image data around the V-ring. The architecture of the V-ring and its accompanying method, enhances the graphic image computational power of the computational subsystems on the P-ring by providing a structure specifically adapted to move large amounts of data in the form of video images from one location in the system to another. The present invention's combination of digital computing, carried out on the P-ring, with digital video processing, carried out on the V-ring, results in a system better able to carry out computer graphics tasks than any previously available system.

The high performance of the P-ring makes it particularly suitable for carrying out computer graphics image computation tasks. The architecture and software systems of the P-ring allow the computational subsystems of the P-ring to be grouped as one or more logical machines devoted to a particular graphics computation task. For example, all of the computational subsystems, may be devoted to a single task; e.g., modeling, animating, or rendering. Alternatively, the computational subsystems on the P-ring may be divided into a plurality of logical machines, one computer graphics image computation task being assigned to each such logical machine. The ring architecture of the P-ring allows digital information to be distributed among the processors very quickly.

Each of the processors, or computational subsystems, on the P-ring operates asynchronously from the other processors on the ring. Thus, when one processor is finished with a task, it can dispatch the results of its work over the P-ring and may receive further instructions and data without waiting for any other processor to complete its immediate task.

Complete information concerning the P-ring can be found in the European Patent entitled "High Speed Digital Computing System" filed concurrently herewith as European Patent Application EP-A-0 367 182.

In contrast to the P-ring, the V-ring is intended to synchronously move lines and frames of digital video signals among video processors at video rates and in a digital video format. As noted, digital video signals require that massive amounts of data be processed, particularly when multiple frames are being processed to form an animated sequence.

In order to handle such large amounts of data, digital video signals are passed from the first video processor in the V-ring to the last video processor synchronously and in real time which allows digital video images from an external source, such as a video tape recorder or a disk drive, to be distributed downstream to one or more video processors on the V-ring. Since data may only travel in one direction on the V-ring, i.e., "downstream," "upstream" travel of data is accomplished by passing the data through the last downstream processor and storing the data line-by-line in a line store and then reinserting the stored data into the digital video signal train at the first video processor. A ring is thus formed whereon digital video signals may be moved in real time.

When moving data downstream, a digital video signal representing an entire frame is moved through the V-ring in the time required to complete one video frame. When moving data upstream, a digital video signal representing an entire frame is moved through the V-ring in the time required to complete two video frames or two "frame times" Frame time, as used herein, means that if the output of a video processor were monitored it would appear as a normal video image to a viewer, whether the video standard being used is NTSC, PAL, or some other standard.

The additional frame time is required because each line of a video signal is moved into the line store in one "line time" and then the contents of the line store is moved to the next video processor in another line time. Thus, a total of two line time periods and a total of two frame time periods is required to move a line and a frame, respectively, upstream on the video ring.

The video processors may be digital frame buffers which are used to merely store a digital video frame. Alternatively, the video processor may be active processing devices such as devices used for digital filtering, digital video effects, raster manipulations, as well as other "real time" digital video devices. Digital video signals are sent downstream on the V-ring in "digital video signal trains" which include both a command portion and a pixel data portion containing the data for a video image.

A V-ring controller is part of the V-ring and functions as a means for inserting and removing video images on the V-ring. The V-ring controller also functions as a means for generating commands which are sent on the V-ring to the video processors. Both the V-ring controller and the video processors receive commands directly from a computational subsystem on the P-ring by way of its respective local bus.

By combining the P-ring and the V-ring into a computer graphics image computation system, with a plurality of local communication paths between the P-ring and the V-ring, the computational processors and the video processors are allowed to exchange data rapidly and reliably. As stated previously, by providing for rapid exchange of information, the full power of parallel processing architecture of the P-ring can be realized. Furthermore, the described architecture is configurable meaning that the hardware may be assigned any one of several graphic image computation tasks by providing the proper programming.

During operation, a user at one of possibly many work stations directs the operation of the embodiment of the present invention. For example, a user may retrieve models of objects from mass storage and the tasks of altering, animating, and rendering the model may be distributed among the computational subsystems on the P-ring. Since each of the video processors on the V-ring is connected via its local bus to a computational subsystem, any combination of computational subsystems and video processors may be used as a modeling workstation, rendering workstation, or for any other task.

In such an arrangement, one or more computational subsystems may perform the computation intensive tasks with the user monitoring the results by way of the video output of the video processor. In this way, the components on the V-ring function to interface the high speed digital computing components of the P-ring with the video image processing components of the V-ring. The V-ring moves the video images which are created or manipulated under the direction of the user to points within the system or to an external video device such as a video tape recorder. The embodiments of the invention are not tied to a specific algorithm and thus can emulate the graphic images produced by other hardware or software schemes. Furthermore, the embodiments of the invention may be easily interfaced with other systems (both digital computing and video) and may be quickly adapted to changes in software and hardware.

BRIEF DESCRIPTION OF THE DRAWINGS

In the description which follows, and in the accompanying drawings, many of the figures have been divided into two parts in order to increase their clarity. Where a figure has been divided into two parts, the designation "-N" has been added as a suffix to the figure number where "N" is the part into which the figure has been divided. For example, in the high level block diagram provided in Figure 1C, the figure has been divided into two parts designated as "Fig. 1C-1" and "Fig. 1C-2." In the case of figures which have been divided into two parts, the complete figure may be reassembled by placing the first part in the left position and the second part in the right position. Also, the boxed letter designations indicate interconnections between the different parts of the same figure.

In the description which follows, including the glossaries, tables, and drawings, the symbols "!" or "*" associated with the mnemonic name of a signal all indicate the "NOT" condition of the signal.

In order to more fully understand the manner in which the above-recited advantages and objects of the invention are obtained, a more particular description of the invention will be rendered by reference to preferred embodiments thereof, which are illustrated in the appended drawings, in which: <ul id="ul0001" list-style="none"><li>Figure 1A provides a block diagram of the architecture of a preferred embodiment;</li><li>Figures 1B-1 and 1B-2 provide a block diagram of the present invention having <u>the architecture of Figure 1A</u> and configured to carry out particular computer graphics computations;</li><li>Figures 1C-1 and 1C-2 provide a block diagram according to Figure 1B but <u>having a different configuration</u> to carry out other compute graphics image computations;</li><li>Figure 2A provides a block diagram representing the principal functional structures <u>of the V-ring controller</u> of Figure 1A.</li><li>Figure 2B provides a high level block diagram representing the principal functional structures of the video processors (frame buffers) represented in Figure 1A.</li><li>Figures 3-1 and 3-2 provide a high level block diagram representing a computer graphics image computation system including representative peripheral devices.</li><li>Figure 4 provides a diagram representing the organization of a software application system for use in the presently preferred embodiments.</li><li>Figure 5 provides a diagram representing the organization of an application software system suitable for rendering of computer images in the presently preferred embodiments.</li><li>Figure 6 provides a block diagram representing the tile processor blocks illustrated in Figure 5.</li><li>Figures 7-1 and 7-2 provide a block diagram of a representative embodiment of the V-ring controller illustrated in Figure 2A.</li><li>Figures 8A - 8I provide a representation of the organization of the video signals and commands present on the presently preferred embodiment of the video ring.</li><li>Figures 9A - 9D provide high level block diagrams illustrating the paths taken by video signals through the structures of the V-ring controller represented in Figure 7.</li><li>Figures 10A-1 and 10A-2 provide a block diagram illustrating the structure of the command control stack of the V-ring controller represented in Figure 7.</li><li>Figure 10B provides a state diagram for the command control stack state machine represented in Figure 10A.</li><li>Figures 11A-1 and 11A-2 provide a block diagram illustrating the structure of the line store block represented in Figure 7.</li><li>Figure 11B - 11C provides a state diagram for the CPU state machine and the line store state machine, respectively, represented in Figure 11A.</li><li>Figure 12A provides a block diagram illustrating the structure of the V-ring input represented in Figure 7.</li><li>Figure 12B provides a block diagram illustrating the structure of the command processor represented in Figure 12A.</li><li>Figure 13 provides a block diagram illustrating the organization of the ring output represented in Figure 7.</li><li>Figure 14 provides a block diagram illustrating the structure of the matrix module represented in Figure 7.</li><li>Figure 15 provides a block diagram of a representative embodiment of the frame buffer represented in Figure 2B.</li></ul>

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

A. General Overview of the Basic Inventive Concepts Represented in the System and Methods of the Present Invention: Figures 1A, 1B, and 1C.

Hereinafter, like structures are provided with like reference characters. This description only represents possible embodiments of the invention and is not intended to limit the scope of the invention as defined in the Claims.

Provided in Figure 1A is a block diagram representing the architecture of one preferred embodiment of the invention. The representation is greatly simplified so as to allow a clear description.

As can be seen in Figure 1A, the embodiment includes a processor ring 12 (herein referred to as a P-ring) which includes a plurality of computational subsystems 20A - 20B and a P-ring controller 18. Each of the computational subsystems 20A - 20B may comprise only a single microprocessor or a more powerful digital computing system.

Each computational subsystem and the P-ring controller may be provided on an individual circuit board which are installed in a chassis and which are interconnected by way of a backplane connector.

The components of the P-ring communicate with an external computer 10 by way of an Ethernet (NFS) communication network 16. This network 16 is used to transfer relatively small amounts of data. Other methods of providing communication between the external computer 10 and the P-ring 12 can be provided. In this way, the versatility of the embodiments is enhanced.

Shown in Figure 1A are the P-ring controller I/O connections 24, which include a time code input, such as from a SMPTE time code generator, and also a machine control connection allowing control interaction with other machines, such as video recording devices during operation as well. These facilities allow the interchange of data and control with "external" peripheral computing and video devices.

The P-ring comprises a plurality of digital processors contained with the computational subsystems 20A - 20B. The computation subsystems 20A - 20B are closely coupled by the communication paths 22A - 22C provided between each of the computational subsystems. Each communication path between the computational subsystems is a high speed parallel data pathway.

Also represented in Figure 1A are the components which comprise the V-ring designated by bracket 14. The V-ring 14 includes a V-ring controller 26 and a plurality of video processors 28A - 28B and the parallel communication paths 30A - 30C therebetween. It is preferred that the V-ring controller 26 and video processors 28A - 28B are each provided on their individual circuit boards for mounting in a chassis and connection to appropriate backplane connectors.

The V-ring controller 26 can communicate input and output of both component digital video and analog video signals with peripheral devices as represented at 32. The V-ring controller 26 serves for inputting and outputting video signals between various external peripheral video devices and the V-ring 14. It also serves for inserting a video signal onto the V-ring 14.

The V-ring 14 is particularly useful for high-speed transfer of large amounts of data in a digital video signal format which might otherwise overwhelm the P-ring if placed thereon. Thus, the V-ring is used to move large blocks of bulk data to, from, and between the computational subsystems on the P-ring.

The communication paths 30A - 30C between each video processor 28A - 28B on the V-ring 14 and the V-ring controller 26 are parallel communication paths allowing high speed transfer of data from one location on the V-ring 14 to another location on the V-ring 14. In order to achieve high data transfer rates, the operation of the V-ring is synchronous and in real time. That is, video signals are passed through one video processor and on to the adjacent downstream video processor in real time and in step with a clock signal distributed to all locations on the V-ring 14.

Importantly, both the P-ring 12 and the V-ring 14 are expandable. That is, the structure of the P-ring 12 and the V-ring 14 allow a large number of computational subsystems 20A - 20B or video processors 28A - 28B to be added to the P-ring or V-ring, respectively.

Significantly, as shown in Figure 1A, a plurality of local buses 34A - 34C are provided which interconnect the computational subsystems 20A - 20B on the P-ring 12 with the devices on the V-ring 14. These local buses, or local communication pathways, 34A - 34C, similar to the parallel communication pathways forming the V-ring 14 and the P-ring 12 are buses comprising many parallel data or address lines. Thus, by way of the local buses 34A - 34C, digital video signals traveling on the V-ring 14 may be acquired by any computational subsystem 20A - 20B on the P-ring 12 and computer graphic images computed by the computational subsystems 20A - 20B may be transferred to any of the video processors 28A - 28B.

Significantly, as used herein, the term "video processor" is intended to encompass any number of video devices which process video signals in real time. For example, the term "video processor" is intended to include a frame buffer whose principal function is merely to store digital video signals and output the same on command as well as various digital video effects devices which are able to carry out sophisticated manipulation of digital video images in real time.

As mentioned, in order to rapidly move the massive amounts of data involved in digital video signals, the V-ring operates synchronously and in what will be referred to herein as "frame time". In other words, when dealing with an NTSC video signal, the equivalent of one frame of video passes through each video processor 28A - 28B in one-thirtieth of a second. Similarly, when dealing with PAL video signals, the equivalent of one frame of video passes through a frame buffer in one twenty-fifth of a second. Importantly, as will be explained later, the video processors 28A - 28B on the V-ring 14 operate either genlocked to a house timing signal or to a ring timing signal internal to the V-ring 14. The importance of each of these timing signals will be explained in greater detail shortly.

In order to provide embodiments which can be most efficiently used for a plurality of computer graphics computation tasks, the embodiments of the present invention may be configured into one or more logical machines each assigned a particular task. Figures 1B and 1C illustrated different configurations of an embodiment of the present invention.

Figure 1B provides a representation of one embodiment of the present invention including a P-ring controller 18 and seven computational subsystems 20A - 20G each coupled by parallel communication paths 22A - 22H to form the P-ring 12. The embodiment of Figure 1B also includes a V-ring controller 26 and five video processors (frame buffers) 28A - 28E. Each video processor 28A - 28E has a parallel communication path 30A - 30F joining it to an adjacent video processor 28A - 28E to form the V-ring 14.

Associated with each of the video processors 28A - 28E is a work station 38A - 38E having a video monitor 40A - 40E. Each work station 38A - 38E is in communication with a computational subsystem 20A - 20G by way of a serial control line 42A - 42E. Users at each work station 38A - 38E are able to command the components of the P-ring 12 and the V-ring 14 in order to manipulate and move data and observe the results on the video monitors 40A - 40E.

The embodiment illustrated in Figure 1B is configured into four logical machines. Each logical machine carries out a particular computer graphics image computation task. As represented by the box marked 44, a computational subsystem 20A, a video processor 28A, and work station 38A are combined as one logical machine assigned to carry out a graphic image task. Such graphic image tasks may include a "paint" task. In other words, a user positioned at the work station 38A gives commands to paint with color the image being manipulated.

The combination of a computational subsystem 20A, video processor 28A, and work station 38A represented in box 44 may conveniently be referred to as a "user slice." Each user slice includes the components necessary to allow a user to manipulate some aspect of a graphic image and view or store the results. In contrast to a "user slice," a "compute slice" is a computational subsystem only and is used, generally in conjunction with other computational subsystems, for computation-intensive tasks such as rendering and filtering of images, computation of image sections with geometric objects, composing imaging layers, analyzing and transforming data, and so forth.

Another user slice of the embodiment represented in Figure 1B is designated by the box marked 46 and is, for example, a logical machine programmed to carry out the task of modeling images. Furthermore, as represented by the block marked 48, two computational subsystems 20C - 20D, a video processor 28C, and a work station 38C, are configured as a logical machine to carry out a task such as animation. Still further, as represented by the block marked 40, three computational subsystems 20E - 20F, a video processor 28E and a user work station 38E are configured as a logical machine assigned to the task of rendering graphic images.

Thus, the structures on the P-ring 12 and the V-ring 14 are not dedicated to any particular function but may be configured as a variety of logical machines to perform the graphic image computation tasks at hand. Importantly, some tasks, such as rendering complicated images, are more computation intensive than other tasks. Thus, as represented by the box 50 in Figure 1B, the task of rendering a graphic image may be assigned to three computational subsystems 20E - 20G with one video processor 28E and work station 38E being provided to allow the user to direct the rendering process.

The configurability and versatility of the embodiment represented in Figure 1B is further demonstrated by the configuration of the embodiment represented in Figure 1C. In the embodiment represented in Figure 1C, all seven computational subsystems 20A - 20G have been grouped into one logical machine, represented by the box marked 52, and assigned the task of rendering a graphic image. This versatility allows embodiments of the present invention to be most cost effectively used for graphics image computation tasks. For example, if a particular assignment requires complex modelling and rendering but yet the animation will be relatively simple, an embodiment of the present invention may be first configured as one large modelling machine and then one large rendering machine.

The embodiments of the present invention provide cost effective use. For example, a single user may be assigned to carry out complex rendering tasks during night hours. During normal business hours, the embodiment may be divided into various logical machines to carry out less complex tasks with a user directing each of the various tasks from a work station.

The organization of the V-ring will now be more specifically described with the structure of the P-ring being described in the above-referenced European Patent Application.

B. General Description of the Components of the Video Ring: Figures 2A and 2B.

The video ring, or V-ring, allows digital video signals to be passed to both downstream and upstream video processors in real time as well as receive data from, and place data on, the P-ring. Thus, the V-ring complements the P-ring.

To provide the described embodiments with the greatest compatibility and versatility, data on the V-ring is in the form of a standard component digital video signal. In the described embodiments, the component digital video signal is compatible with CCIR Recommendation 601 utilizing a 4:4:4:4 luminance to colour signal ratio and including a key channel. Such format greatly facilitates interfacing the present invention with external video devices.

The principle components of the V-ring are the V-ring controller and the plurality of video processors including frame buffers which are adapted for transferring data between the computational subsystems and the V-ring and converting the same into a digital video signal. The digital video signal can be viewed by a user, moved around the V-ring, or moved out of the V-ring to an external video device. The video ring controller, aside from controlling the operation of the video processors on the V-ring, serves as a means for inserting a video signal onto the V-ring and as a means for outputting a video image which is on the V-ring.

Figure 2A provides a block diagram representing the principle functional blocks of the V-ring controller. It will be appreciated that under the definition herein adopted, the V-ring controller may be considered a specific type of video processor. Likewise, Figure 2B provides a block diagram representing the major functional blocks of the frame buffers utilized in the presently preferred embodiment and the high level functions carried out by the frame buffers.

As shown in Figure 2A, the V-ring controller is in communication with the local bus 140, the V-ring parallel input 130, and the V-ring parallel output 156. The local bus connection 140 provides a direct path for data transfer between the V-ring controller and the P-ring controller as represented in Figure 1A.

The parallel V-ring input 130 and the parallel V-ring output 156 are each thirty-two bit wide buses providing a total of four bytes for pixel data in addition to a command bit line and a horizontal sync pulse line (not explicitly represented in Figures 2A and 2B). The four pixel data bytes of the V-ring are designated A, B, C, D and carry the four components (R, G, B, K) of a CCIR 601 component digital video signal. The component digital video signal may pass through the V-ring controller to the parallel V-ring output 156 unchanged or the digital video signal may be manipulated in some way.

It is preferred that digital video signals placed on the V-ring be in the form of a component digital video signal compatible with the CCIR Recommendation 601 or its United States counterpart, RP-125. It is, however, within the scope of the present invention to utilize composite digital video signals on the V-ring. Even further, it is to be understood that it is within the scope of the present invention to utilize a non-standard or proprietary video signal encoding scheme on the V-ring.

The embodiment illustrated in Figure 2A is provided with two video signal inputs 132 and 136 and one video signal output 154. The analog input 132 is connected to an analog input module 134 which contains those components necessary to generate a component digital video signal and place the component digital video signal on the V-ring in the proper sequence.

The CDV (component digital video) input 136 likewise is connected to a CDV input module 138 which contains the components necessary to properly place a component digital video signal onto the V-ring. It will be appreciated that the analog input module 134 and the CDV input module both function as a means for inserting a video signal onto the V-ring. Other, as well as additional, components, however, may also perform this function. The analog input module may serve the function of a means for generating a component digital video signal which is suitable for placement on the V-ring. However, other structures may perform the same function.

The CDV output 154 receives the video signal from the CDV output module 152. The CDV output module 152 contains those components necessary to extract a component digital video signal from the V-ring and output it to an external video device. The CDV output module 152 is one of the structures which may serve the function of a means for outputting a video signal received at the V-ring input 130. It will be appreciated that the analog input 132, the CDV input 138, and the CDV output 154 connections all can be interfaced with various available video devices.

The matrix module 144 forms part of the V-ring, and converts a component digital video signal having one format into a corresponding component digital video signal having another format, e.g., RGB format to CrYCb format. The pseudo-CDV multiplexer (Pseudo CDV MUX) 148 produces pseudo-component digital video signals and places the same in the proper bytes of the V-ring.

The sync generator 146 represented in Figure 2A provides synchronization signals which are required to properly operate the V-ring and the components associated therewith. The sync generator 146 synchronizes the video processors on the V-ring. While not represented in Figure 2A, various further clock and synchronization signals are distributed to the components on the V-ring.

Data may only travel in one direction around the V-ring. In order to facilitate moving a video signal to an upstream location on the V-ring, the line stored 142 is provided as a means for storing a video signal.

The described embodiments of the V-ring organize and handle video signals into lengths equal to one video scan line. Thus, when one frame buffer desires to pass a video signal to an upstream frame buffer, the video signal is first passed downstream, line by line, to the V-ring controller and the lines are placed in the line store 142. Once placed in the line store 142, the lines of the video signal may wait until it is their turn to be properly inserted onto the V-ring as a video train signal having appropriate commands and control signals provided by V-ring controller. Thus, the line store 142 provides a novel approach for allowing for efficient transfer of video signals to upstream video processors on the V-ring.

Also represented in Figure 2A is the command control stack 150. The command control stack 150 functions as a means for generating commands for the V-ring. The command control stack 150 inserts into the command portion of the video signal train the proper command and address bits so that the downstream frame buffers will carry out the desired operations. In this way, the V-ring controller is able to control the operation of each of the frame buffers or video processors. It will be appreciated that any of the structures herein described which are capable of placing pixel data onto the V-ring may, in combination with the command control stack, function as a means for generating a video signal train which includes both a command portion and a pixel data portion. More information concerning a representation of the embodiment of the V-ring controller will be provided later in this disclosure.

Figure 2B provides a high level block diagram representing the components of each frame buffer which comprise the other major components of the V-ring. As mentioned earlier, the frame buffer is just one type of video processor which may be included on the V-ring. For example, sophisticated real time video digital effects generators may be included on the V-ring in order to accomplish particular effects. Importantly, such digital video processors must operate in real time since operation of the V-ring is synchronous.

Figure 2B shows the frame buffer's connections to the local bus 164, and the parallel V-ring input 160, and the parallel V-ring output 162. Similar to the V-ring controller represented in Figure 2A, the V-ring input 160 and the V-ring output 162 each include 34 parallel conductors (32 bits data and 2 bits control).

The frame buffer represented in Figure 2B is provided with a ring command processor 166 which functions as a means for receiving commands and which interprets and executes the commands placed at the head of the video signal train by the command control stack (150 in Figure 2A). A multiplexing system (MUX System) 168 is used in the frame buffer to direct the digital video signals captured from the V-ring to the video RAM modules 170 for storage or direct the digital video signals to the analog output 172. The multiplexing system 168 also includes the components necessary to place a video signal received by way of the local bus 164 or stored in the video RAM modules 170 onto the V-ring. Thus, the multiplexing system 168 represents just one structure which may be used as a means for inserting a video signal onto the V-ring.

It should be noted that a computational subsystem on the P-ring has access to the digital video signals placed in the video RAM modules 170 by way of the local bus 164. Thus, the computational subsystems can utilize the V-ring to transfer data both internally to the system as well as to the outside world.

In Figure 2B, the analog output 172 produces an RGB analog video signal which may be viewed by a user. The analog output receives an analog signal from a digital to analog (D/A) converter 171 and serves as a means for outputting a video image which has been received at the V-ring input 160 or by way of the local bus 164.

C. Representative Systems and Application Incorporating the Present Invention: Figure 3.

The system in Figure 3 illustrates the organization of an overall computer graphics system incorporating the present invention.

In Figure 3, the P-ring includes a P-ring controller 18 and five computational subsystems 20A - 20E. The V-ring includes a V-ring controller 26 and five frame buffers 28A - 28E. The configuration of the embodiment represented in Figure 3 provides that a maximum of three computational subsystems and three video frame buffers may installed in one chassis. The chassis are represented by the boxes marked 198 and 200 in Figure 3. Thus, the two chassis 198 and 200 are interconnected by way of connectors and expansion cables indicated at bracket 186. DRAM memories 70A - 70E are connected to each local bus 72A - 72F allowing both the MC 68020 processor and the programmable hardware booster (both contained on the computational subsystems) to access to the DRAM memories 70A - 70E.

Also represented in Figure 3 is a work station 10, preferably a Sun Microsystems 3/110 workstation, provided with two additional 140 Mbyte random access memory devices, which together function as a external computer. The workstation 10 is connected to the P-ring controller by way of an Ethernet network 16 as well as a serial bus 180 and a terminal cable 182. It will be appreciated that if the application warrants, additional workstations could be added to the Ethernet network to interface with the embodiment of the present invention or with other work stations.

As is common in video applications, an external sync generator 184 is provided to distribute house sync signals to various pieces of video equipment and particularly for use by the V-ring of the embodiment.

Also represented in Figure 3 is a video disc device 188 which is preferably a video disc device manufactured by Abekas Model A-60. The video disc device 188 is connected so as to input video signals into the V-ring controller 26 and also receive video signals from the V-ring controller 26. As mentioned earlier, the P-ring controller 18 is provided with machine control inputs and outputs. In the embodiment represented in Figure 3, the machine control input and output represented at 202 is connected to the video disc device 188 and thus the operation of the video disc device 188 may be controlled.

Also represented in Figure 3 is a video source 194 representing any of a plurality of video devices which may be used to provide video input to the V-ring. For example, the video source may be a video camera (not shown). The output of the video source, preferably in RGB format, is input to a 601 encoder 190 which outputs a component digital video signal which is compatible with CCIR Recommendation 601. The output of the 601 encoder 190 is passed to the V-ring controller 26. Similarly, a 601 decoder receives output from the V-ring controller 26. The 601 decoder 192 is shown providing an RGB video signal to a high resolution video monitor 196.

Also represented in the embodiment of Figure 3 are four color monitors 204A - 204D connected to four of the frame buffers 28A - 28D, respectively. Each receives an RGB signal output from one of the frame buffers 28A - 28D, respectively. Also provided is a terminal and a data input tablet, represented at 38A - 38D, both of which are connected to the respective computational subsystems by way of serial communication lines 206A - 206D. As explained earlier, this arrangement allows a user to direct and monitor the tasks being carried out by the respective computational subsystem.

The embodiment represented in Figure 3 may, under appropriate software, be configured into one or more logical machines programmed to carry out specific image computation tasks. The ability of the embodiment to transfer information on the V-ring and on the P-ring, as well as between the V-ring and the P-ring, makes maximum use of the computing power of the computation subsystems which make up the P-ring.

D. Representative Software Organization for Use With the Present Invention: Figures 4-6.

Preferably, the system software used with the present invention should view the hardware as a set of computational subsystems which are to be partitioned. The computational subsystems in each partition are joined to form a single logical machine. The system software should view the application software as a task network which is distributed over the computational subsystems in the logical machine.

When an application software system is written, it is organized as a network of processes which can execute concurrently on different computational subsystems. The resulting organization of these tasks into a network of tasks is referred to as a logical task network diagram. A logical task network contains information (supplied by the programmer) of which tasks in the network communicate with each other, the amount of processing relative to other tasks, and so forth.

Given a logical task network diagram and a logical machine, it is possible to derive a preferred physical task layout. The physical task layout describes exactly on which computational subsystems each task will reside. Therefore, as the embodiment is expanded and more computational subsystems become available, the system may adjust the physical task layout to take best advantage of the number of computational subsystems available.

Having provided a general overview of the architecture of the hardware embodying the present invention, the preferred organization and standards of the application software system to be used with the embodiments of the present invention can be generally explained. All application software should be particularly written so as to take full advantage of the hardware architecture of the embodiments.

In general, one of the most demanding applications of the presently preferred embodiments of the present invention is to generate three-dimensional computer animations combined with live action. However, the present invention allows such applications to be handled more efficiently than previously possible.

The organization of the application software is generally represented in Figure 4. The application software consists of a data base 212 which contains information for the computer animation (models, attributes, key frames, etc.), the description of the filtering and compositing necessary, and necessary device control commands.

As in any complex software system, it is necessary to provide some internal standards. The following provides some of the more important preferred standards: <ul id="ul0002" list-style="none" compact="compact"><li>1. Time should be calculated in floating point seconds so that any time per frame can be supported. Furthermore, calculating time in floating point seconds allows motion blur which requires many closely spaced samples in time to produce a single frame.</li><li>2. Pixel files are used for storing images. They consist of eight bit components or sixteen bit components. All four components R, G, B, and K are stored.</li><li>3. Matte files are used for storing mattes. They consist of eight-bit or sixteen-bit components. Only the K component is stored.</li><li>4. Texture maps are used for wrapping textures onto surfaces of objects. All four components, R, G, B, and K are stored. Texture maps are organized in pages of 64 pixels by 64 scanlines.</li></ul>

As shown in Figure 4, the application software system should include appropriate translators, editors, etc., as represented at 210. Those skilled in the art utilizing the disclosure contained herein will be able to provide appropriate additional standards and produce representative software for use with the embodiments of the present invention.

The device control and imaging handling system portion of the application software is responsible for dealing with the outside world. It performs tasks such as frame capture, single framing, constructing texture maps, and so forth. The device control portion consists of drivers (specialized software modules) for each device type such as a video disc device.

There is a baseline command set that each device must be able to support. The baseline commands are "store image" (time, pixel file name) and "load image" (time, pixel file name). Each device driver must be able to convert time from seconds to whatever units are appropriate for the device and vice versa. The device must also convert pixel files to the format the device needs and vice versa. Each device driver should be independent from the other device drivers. This greatly minimizes maintenance costs and simplifies adding new drivers.

The image handling system 214 represented in Figure 4 is responsible for generating matte files, texture matte files, and so forth, from pixel files. It is also used for storing, copying, and deleting the image-type files stored on the system.

The major responsibility of the compositing and image processing system 216 is to composite and filter existing image layers into final frames. These frames are then either saved as pixel files or sent to some external device such as a video tape recorder (VTR).

The compositing and image processing system 216 operates on pixels and matte files. Preferably, the term "file" should not be thought of to imply disk storage and retrieval, but may mean such. The file handling system for these types of files, and for all image type files, should be designed to keep as much of the file in RAM as possible. Therefore the system makes accesses to magnetic disc only when necessary. This gives systems having different amounts of physical RAM similar capability but varying performance.

The filter and compositing operators are organized as a set of small code modules. Each code module is preferably completely independent. The code module takes as input one or more pixel or matte files and produces one or more pixel or matte files as output. Facilities should be provided within the software for importing any other parameters to the operators. The operators initially may be written in a high-level language, and with little effort they may be ported to the programmable hardware booster in the computational subsystem. This facilitates adding new operators or increasing the performance of the system.

Also represented in Figure 4 is the rendering system portion of the application software. The major responsibility of the rendering system 218 is to generate an image file (i.e., a pixel file) which isused by the compositing and image processing system 216 to form the final image. As represented in Figure 5, the rendering system 218 includes three major portions: the director 220, the tile processors 222A - 222C, and the pixel collector 224. Each of these portions of the rendering system 218 will be explained below.

A single copy of the director 220 and pixel collector 224 exists for each logical machine partitioned in the embodiments of the present invention. However, a tile processor 222A - 222C is instantiated on each computational subsystem. This allows the rendering system to easily utilize all of the computational subsystems during the rendering process.

In Figure 5, the lower portion of the figure, designated by bracket 226, shows a possible division of the screen into screen tiles which each include some portion of an abstract image.

The director 220 controls the rendering process. The major task of the director is to determine how to divide the screen into tiles which are processed by the tile processors 222A - 222C. A tile is a rectangular portion of the screen. A tile processor may fail if the complexity of the screen tile exceeds the resources, e.g., memory, available to it. If a tile processor 222A - 222C fails, the director 220 receives notification of the failed tile and replaces the tile with more smaller tiles.

If a tile processor 222A - 222C succeeds, it returns the time it took to compute the tile and the complexity of the tile to the director 220. If the complexity of the tile is simple compared to the resources available to the tile processor, the director 220 coalesces adjacent tiles into a single tile when their total complexity can be handled by a single tile processor.

This dynamic reallocation of tiles on the screen provides an effective method of load balancing and "chasing" the complexity of the image around the screen. In contrast, a static allocation of processors to screen tiles suffers unless the complexity is evenly distributed across the screen. Furthermore, when the tiles are statically allocated, each tile processor 222A - 222C must be able to handle the worst case situation requiring all tile processors 222A - 222C to be ready to handle the most complex tile. The dynamic reallocation of tiles avoids this difficulty by adapting the tiles so that the complexity of the tiles matches the capability of the tile processors. Preferably, when rendering an animated sequence, the last screen tile subdivision is used as a starting point for the next frame.

As represented in Figure 5, a plurality of tile processors 222A - 222C are provided. The tile processor's responsibility is to compute the R, G, B, and K value for each of the pixels in its currently assigned tile. As represented in Figure 6, each tile processor is further broken into five major sections: (1) the object processor 228, (2) the geometry modifier 230; (3) the splitter/shader 232; (4) the scan converter 234; and, (5) the ray/surface intersector 236.

The object processor 228 culls objects from the screen tiles. For the pieces of each object which cannot be discarded, the attributes (geometry attributes and shading attributes) for those pieces are collected. Each piece of the object comprising geometric primitives is then sent to the geometry modifier 230.

The geometry modifier 230 applies the geometric attribute to each piece of geometry as it comes in and produces rendering primitives. The geometric attribute is a code module. It applies some rule, e.g., stochastic subdivision, and produces the corresponding rendering primitives. As with compositing and filtering operators, preferably, all geometric attributes are independent code modules which may be easily modified and new ones may be added.

As represented in Figure 6, the splitter/shader 232 functions to recognize each of the rendering primitives. The splitter/shader 232 shades each vertex of the primitive as an initialization step. After shading each vertex of the primitive, only the new points created during the subdivision process are shaded. The primitives are subdivided until their screen projection is small.

Rays can be created during the shading process. When this occurs, the rays are passed to the ray/surface intersector 236. The ray/surface intersector 236 returns the color from the ray which is used in the shading process. Once the screen projection is small enough, the primitives are converted to droplets (suggesting droplets of paint) which are passed onto the scan converter 234. Preferably, the shading model is a code module as well. This allows for a variety of shading models and techniques to be easily implemented. Techniques such as solid texturing can be used with great effect and efficiency with the software system of the present invention.

It is preferred that shading calculations be performed before hidden surface determination. The major factor contributing to this preference are (1) transparency (along with other attributes such as color and surface normal) are allowed to change as a result of the shading calculation; (2) scan conversion is much simpler as the shading models would not have to be carried with each rendering primitive; and (3) accessing texture maps and other large tables is much more efficient since only the information for a single surface element is needed at a time. Also, preferably, lights in the system are also treated as code modules. This allows virtually any type of light to be easily added.

As represented in Figure 6, the major responsibility of the scan converter 234 of the application software system is to perform hidden surface calculations including correct handling of transparency and to perform the necessary sampling and filtering to produce pixels. The completed pixels are then sent to the pixel collector 224 (Figure 5).

The ray surface intersector 236 of the application software system is given only those objects which are selected to block rays. Rays created during the shading process are sent to the ray/surface intersector. The nearest intersection point relative to the origin of the ray is found and shaded.

It is important to note that shading a surface point may cause generation of other rays which in turn are processed by the ray/surface intersector 236. Shading models that fire rays as part of the shading calculations will be shadowed by and/or show reflections of the objects which were given to the ray/surface intersector. The adoption of this technique is preferred since it provides an incremental approach to ray tracing, i.e., only those objects selected are raytraced, the other objects in the scene are rendered in a more conventional fashion.

As represented in Figure 5, once the previous portions of the application software system have been carried out, the pixel collector 224 receives the pixels from each tile processor 222A - 222C to form the completed image layer, i.e., the pixel file. The pixel collector 224 then reports the status of each of the tiles back to the director 220.

E. The Preferred Embodiment for the V-Ring Controller: Figures 7-14.

The V-ring controller 26 distributes commands to the other video processors on the V-ring, inserts and removes video signals, and allows video processors to send data to upstream video processors by way of the V-ring.

Figure 7 shows the principal functional blocks of the V-ring controller. Many of its blocks are illustrated in greater detail in a later figure.

The width of the V-ring communication path is 34-bits including ring bytes A, B, C, D, a command bit (represented at CBI - command bit in) and a ring reference bit (represented at RRI - ring reference in). The ring reference bit or signal contains both horizontal reference timing bits (such as horizontal start pulse (HSP) to be described later) and vertical reference timing bits. The basic data element passed around the V-ring is referred to as a digital signal train. The first 90 "cars" on the signal train are reserved for ring commands, the last 768 "cars" (in an NTSC compatible signal) are reserved for pixel data. The pixel data carried on a train corresponds to one scanline. The horizontal start pulse of the ring reference signal marks the beginning of each train.

During each scanline of "ring time," a train is dispatched from the V-ring controller onto the V-ring. The flow of trains never stops on the V-ring. The purpose of these trains is to carry scanlines of pixel data from one place to another on the V-ring. In the following description, all of the video processors on the V-ring will be frame buffers of the type described later in this disclosure.

The V-ring has several purposes which include the following: <ul id="ul0003" list-style="none" compact="compact"><li>1. To allow real time frame capture from the V-ring controller any frame buffer on the V-ring;</li><li>2. To allow real time delivery of frames from any frame buffer to the V-ring controller;</li><li>3. To allow real time delivery of picture information from a group of frame buffers to a frame buffer selected for output, i.e., for video output; and</li><li>4. To allow high-speed transfer of general data from one frame buffer to another frame buffer, in particular, bulk data that would tend to clog the P-ring.</li></ul>

The general concept of using the V-ring is as follows. Each frame buffer in the V-ring is normally engaged in some sort of local function, such as paint. In this mode, the frame buffer is genlocked to house timing and the user watching the output from a frame buffer sees a changing picture as the image data is manipulated.

If a user does not want to risk being bothered by possible V-ring activity, he can clear the ring enable bit in the V-ring control port of the frame buffer. This in effect disconnects the V-ring commands from the frame buffer and the signals on the V-ring are passed unchanged through the frame buffer.

If a user wants to be the initiator of some V-ring activity, he must compile a control stack, send it to the V-ring controller, ring-enable his frame buffer, and wait for the V-ring controller to schedule his requested ring process. The communication by which this user sets up a video ring activity occurs on the P-ring.

If a user contains data on his frame buffer which might be of use to other users having other frame buffers, the user has the option of leaving his frame buffer ring-enabled. In this way, other users can access data in a frame buffer by means of the V-ring. Such access might be in the form of extracting an entire image from the frame buffer or the occasional access of a texture map.

When some other user accesses data on a frame buffer, there will be a temporary corruption of the frame buffer's local video readout for a period of time corresponding to the length of the ring access. This might only be for a few scanlines and be unnoticed, or it might be a whole frame and the analog output of the frame buffer may then be noticeably corrupted. Of course, by leaving the frame buffer ring-enabled in a large system, the user is faced with the possibility that some other user might destroy data on his frame buffer via the V-ring.

1. Organization of a Video Signal Train

Provided in Figure 8A is a diagram showing the organization of a video signal which is passed on the V-ring. The video signal is referred to as a video signal train due to its similarity to a train having an engine (the command area) and box cars (the pixel data). Provided below is a explanation of the major characteristics of the video train.

a. Length

For both PAL and NTSC compatible video signals, a 13.5 MHz clock is used which corresponds to 74.074 nanoseconds per pixel. The PAL compatible train is 864 "cars" long for a horizontal time length of 64.0 microseconds. The NTSC compatible train is 858 "cars" long for a horizontal time length of 63.555 microseconds. Thus, the PAL and NTSC compatible trains are of slightly different length.

b. Horizontal Start Pulse (HSP)

This hardware pulse marks car number 0 of each train. Obviously, the difference between PAL and NTSC compatible signals is that the horizontal start pulses are farther apart in a PAL compatible signal. The HSP is contained in the ring reference signal and travels along the V-ring along with the other bits of the signal. It is propagated in the same way as the data bits and the command bit are propagated around the V-ring. It is delayed through frame buffers in exactly the same way.

c. Command Area

The first 90 or so "cars" on the train are called the command area. The ring commands are located in the command area. Each command consists of a command word and a variable number of parameter words. Each command is tagged with a command bit which is found on a separate line in the V-ring. In the example shown in Figure 8A, there are only two commands, and each command is followed by one parameter word. This command arrangement is typical for movement of a scanline of data from one frame buffer to another.

d. Number of Commands Possible

The number of commands that can be placed in a train depends on the length of the commands, the cutoff point beyond which commands cannot exceed (e.g. car = 50), and also the design of the command control stack on the V-ring controller to be explained shortly.

e. Ring Message (RM)

The first car of each train contains ring message (RM) bits that are transmitted to all frame buffers. The most recent ring message is always available in the ring message status port on the frame buffer. Like the commands, the ring messages must, of course, be generated by the V-ring controller command control stack.

f. Ring Bytes

The data portion of the video ring consists of 32 bits arranged in four bytes labeled A, B, C and D. In the RGBK display mode, ring bytes ABCD carry RGBK data, respectively, at 8-bits per component. This signal configuration is compatible with CCIR Recommendation 601.

In the command area of the train, the first 90 cars, ring bytes C and D carry the 16-bit ring command and parameter words. In the command area, bytes A and B are unused. In the pixel boxcar part of the train, which is the last 768 cars, the ring bytes carry the pixel data as just mentioned above.

g. Latch Delays and Local Time

As a video train passes through a frame buffer, it experiences a delay of exactly two "cars". This is because each frame buffer has two latches in series, one at the V-ring input port, and one at the V-ring output port. Thus, as the train progresses through many frame buffers, it gets progressively delayed relative to time at the V-ring controller. However, from the point of view of each individual frame buffer, this delay is of no concern. The horizontal start pulse always marks the precise beginning of a scanline for a video processor since the HSP experiences the same delays as the CMD and data bits. In other words, each frame buffer then has what may be referred to as a "local ring time" which varies by two clocks from adjacent frame buffers. However, this local ring time is not to be confused with local house time.

Figure 8B is a representation of the organization of a command word used on the V-ring. V-ring commands consist of a command word followed by a variable number of parameter words. The command word is always identified by the presence of a command bit (CMD). Regardless of the command, the command word always has the same format, as explained below.

h. Op Code

This 6-bit field is what distinguishes different V-ring commands. Of the 64 possible op codes, five are used up by commands implemented on the frame buffer.

i. Cage

In order for a command to be recognized and executed by a frame buffer on the V-ring, the 6-bit cage field of the command must match the 6-bit cage bits of the cage (or chassis) in which the frame buffer is located.

j. Slot

In order for a ring command to be recognized and executed by a frame buffer in the V-ring, the 4-bit slot field of the command word must match the 4-bit slot number assigned to the frame buffer.

2. The Video Output Setup Ring Command

Figure 8C is a representation of the organization of the video output setup ring command used on the V-ring. Start in Figure 8C represents the count during which the address frame buffer is to deposit its first pixel into the train. Stop in Figure 8C represents the count during which the addressed frame buffer is to deposit its last pixel into the train. Thus, Start and Stop are counts in the horizontal count system. In this system, a scanline ranges from Horizontal Count (HCNT)=0 to HCNT=857 for NTSC, and HCNT=863 for PAL. Pixels are carried in the last 768 "boxcars" of the train in either case.

Figure 8D is a further representation of the organization of the video output setup ring command. In NTSC, for example, if Start=90 and Stop=858, the train will "pick up" all 768 pixels from a frame buffer which has been addressed by the command. Alternatively, if Start=90 and Stop=94, the signal train will pick up only pixels 0, 1, 2, 3 from the addressed frame buffer. Pixels 4 through 767 will pass through the address frame buffer unaltered. In general, using the Start/Stop numbers one can arrange to pick up an arbitrary, but continuous, segment of pixels from a frame buffer.

Since each frame buffer can be set up with its own Start/Stop numbers, one can arrange to assemble a single picture from several horizontally disjointed pieces located on different frame buffers. Since a segment picked up from a downstream frame buffer overwrites that which was picked up from an upstream frame buffer where the segments overlap, one can arrange to have the downstream frame buffer put "windows" over the upstream frame buffer. If one is willing to put a video output setup command on each train, one could arrange to have window of arbitrary shape, e.g., an ellipse.

a. Format

The Format field represented in Figure 8C controls the distribution of the pixel bits onto the V-ring. Figure 8E shows that the video random access memory (VRAM located on the frame buffers as represented in Figure 15) bytes are labeled a, b, c, d, e, f, g h and can connect to the V-ring bytes A, B, C, D in various ways. Each VRAM byte can drive two of the V-ring bytes. One byte is called the primary byte, the other is called the secondary byte. The primary is always the byte that also drives the analog RGBK byte video output of the frame buffer represented in Figure 15. For example, for VRAM byte "g," the primary ring output byte is D and the secondary is B. The Format field directs the VRAM bytes which V-ring bytes to drive. The 16-bit Format field can be thought of as eight 2-bit fields, one 2-bit field for each VRAM byte.

As represented in Figure 8E, the following values for the SP (secondary/primary) bits have the following functions: <dl id="dl0001" compact="compact"><dt>SP =</dt><dd>11 VRAM byte should drive neither V-ring byte 10 VRAM byte should drive only the Primary V-ring byte 01 VRAM byte should drive only the Secondary V-ring byte 00 VRAM byte should drive both Primary and Secondary V-ring bytes</dd></dl>

If the Format field is such that a particular V-ring byte is not being driven by a VRAM byte, that particular V-ring byte simply passes through the addressed frame buffer without alteration. This is true regardless of the values of the Start/Stop parameters. This allows pictures to be mixed in pixel depth from different video processors if desired.

It is the responsibility of the V-ring command programmer to make sure that no V-ring byte is driven by more than one VRAM byte. For example, it would be possible to set the Format field so that VRAM bytes a, d, e, h all drive ring byte A. This would cause bus contention and yield garbage. This contention would only exist during scanlines when the command control stack is extracting pixel data from the addressed frame buffer using the video output ring command.

b. Use of the Output Setup Command

Normally, if it is desired to pick up a picture from a frame buffer and deliver it to the V-ring controller, the video output set up command need only be issued once. Once received, the parameters are all latched into the frame buffer. Then, when video output commands come along, those latched parameters control the manner in which the output occurs. Typically, the Start/Stop parameters are set to their "full scanline pickup" values, the hardware magnification parameters are turned off, pinning is generally turned on, and the format is set as desired. For example, for normal RGBK output onto the video ring, the following format would be used: <tables id="tabl0001" num="0001"><table frame="all"><tgroup cols="9" colsep="1" rowsep="0"><colspec colnum="1" colname="col1" colwidth="17.50mm" /><colspec colnum="2" colname="col2" colwidth="17.50mm" /><colspec colnum="3" colname="col3" colwidth="17.50mm" /><colspec colnum="4" colname="col4" colwidth="17.50mm" /><colspec colnum="5" colname="col5" colwidth="17.50mm" /><colspec colnum="6" colname="col6" colwidth="17.50mm" /><colspec colnum="7" colname="col7" colwidth="17.50mm" /><colspec colnum="8" colname="col8" colwidth="17.50mm" /><colspec colnum="9" colname="col9" colwidth="17.50mm" /><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">Format (RGBK) =</entry><entry namest="col2" nameend="col2" align="right">01</entry><entry namest="col3" nameend="col3" align="right">00</entry><entry namest="col4" nameend="col4" align="right">01</entry><entry namest="col5" nameend="col5" align="right">00</entry><entry namest="col6" nameend="col6" align="right">01</entry><entry namest="col7" nameend="col7" align="right">00</entry><entry namest="col8" nameend="col8" align="right">01</entry><entry namest="col9" nameend="col9" align="right">00</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="right">a</entry><entry namest="col3" nameend="col3" align="right">b</entry><entry namest="col4" nameend="col4" align="right">c</entry><entry namest="col5" nameend="col5" align="right">d</entry><entry namest="col6" nameend="col6" align="right">e</entry><entry namest="col7" nameend="col7" align="right">f</entry><entry namest="col8" nameend="col8" align="right">g</entry><entry namest="col9" nameend="col9" align="right">h</entry></row></tbody></tgroup></table></tables>

Instead of sending the output setup command only once, it is possible to send it once each frame, perhaps during the vertical intervals. This is essential if horizontal scrolling is to be performed on the video ring. To accomplish horizontal scrolling, different numbers for Show and/or Pxstart (Figure 8C) are sent before each frame. By adjusting the Start/Stop numbers used for each frame, some kind of moving window across the image could be obtained.

Importantly, with several frame buffers on the V-ring, an output setup command muSt be targeted to each frame buffer so that each is properly set up for video output. Again, these commands could be sent just once, once per frame, or once per scanline.

In summary, the video output setup command is used to "set up" the frame buffer for subsequent video output commands on the V-ring.

The setup command step is extremely general in that it prepares for many things to happen on the V-ring. For example, pixel data can be horizontally scrolled and magnified. The pixel data can also be vertically scrolled and magnified by the implicit ordering of commands on the command control stack compiled on the V-ring controller. The pixel data can be horizontally mixed between different frame buffers, using the Start/Stop fields, allowing area scan conversation segmentation of the image as well as fancy windowing functions. The pixel data can also be mixed in pixel depth between different frame buffers, using the Format parameters, as might be useful in some sort of still-store type application. Even with a single processor, when it operates in the 16-bit Cy mode, the Format field can be set up so that any of the four stored 16-bit Cy pictures can drive either half of the video ring.

3. The Video Ring Input Setup Command

Figure 8F is a representation of the organization of the video ring input setup command used on the V-ring. The video ring input setup command is used to set up a video processor for subsequent video input commands on the video ring.

The major field in the video input setup ring command is the write protect field. The format of the write protect bit is as follows: <dl id="dl0002" compact="compact"><dt>P = 1</dt><dd>means byte is write-protected</dd><dt>P = 0</dt><dd>means byte is write enabled</dd></dl>

The VRAM bytes (a, b, c, d, e, f, g, h,) whose corresponding bit in the eight bit write protect field is set will not be overwritten by the video ring input command.

4. The Video Ring Output Command

Figure 8G is a representation of the organization of the video ring output command used on the V-ring. This ring command causes the frame buffer to output pixels into the video train in which this command occurs. The manner in which the pixels are output is controlled for the most part by the most recently received video ring output setup command.

a. Picture

This field tells the frame buffer which picture it should output data onto the V-ring.

b. Scanline

Within the picture specified by the Picture field, the Scanline field specifies which scanline should be output into the train. Normally, the visible NTSC picture is contained in scanlines 0 - 484 and the visible PAL picture in scanlines 0 - 584. As the pixel data is loaded into the video train, it may be scrolled and magnified, horizontally segmented by Start/Stop, pinned in various modes, and formatted in various ways. These data formatting attributes are all controlled by the most recently received video output setup ring command.

5. The Video Ring Input Command

Figure 8H is a representation of the organization of the video ring input command used on the V-ring. This command causes the frame buffer to input pixels from the video train in which this command occurs. The bytes of the pixels that will be written are determined by the write-protect field of the video ring input setup command.

a. Picture

This field tells the frame buffer into which picture it should deposit the data that comes in on the video signal train.

b. Scanline

Within the picture specified by the Picture field, the Scanline field specifies into which scan line the data will be written. The Picture and Scanline fields have the same meaning in the video ring input commands as in the video ring output commands. Only the direction of transfer is different. When data is written into a frame buffer using this command, that data also passes through to the video output port of the frame buffer along with the command information. Thus, it is possible to write a scanline into many frame buffers. This can be done by having several video input commands at the start of each signal train, each one addressed for a different frame buffer.

6. The Ring Timing Changeover Command

Figure 8I is a representation of the organization of the ring timing changeover command used on the V-ring controller. The purpose of this command is to switch a frame buffer back and forth between local time and ring time. In this command, H = 1 means switch to local time and H = 0 means switch to ring time. The frame buffer can be genlocked either to local house timing, as would be appropriate for local paint mode and the like, or it can be genlocked to the video ring. These two timing systems can be totally asynchronous and can be based on independent crystal oscillators.

Since the two video setup commands simply load parameters into latches on the frame buffer, these commands can be executed with the frame buffer on either timing basis.

The video input and output commands, however, can only be properly executed if the frame buffer in question is genlocked to ring time. This is necessary because the pixel data that is read out of the VRAM must be phase locked to the V-ring clock.

The command control stack on the V-ring controller is responsible to make sure that it "changes over" the frame buffer to ring time before it tries to input or output data. To do this, it sends the timing changeover ring command.

When the timing changeover command is used, no other ring commands must exist on the same train or on the next one. This is because the timing changeover process takes between one and two horizontal pulse times and during this time the frame buffers ignore all other ring commands.

7. Data Paths Through the V-Ring Controller

Figures 9A - 9D are simplified block diagrams of the V-ring controller represented in Figure 7. Figure 9A represents the data path through the V-ring controller in the component digital video input mode. Component digital video (CDV) input is passed through one of two identical inputs (CDV A and CDV B) and is sent to the CDV INPUT MUX where one of the inputs is selected. From the CDV Input Multiplexor the CDV data goes to the CDV DMUX where one of the following two operations take place:

It is separated into component form (Cr, Y, &amp; Cb) which is placed on bytes A, B and C respectively on the matrix input side of the V-Ring; or

It is separated into Cr &amp; Cb multiplexed onto one byte which is placed on byte A on the matrix input side of the V-ring and also separated into y which goes to byte B. This second configuration of video data is referred to as Pseudo CDV.

If the data is in component form it can either be converted to RGB (in the matrix) or left as component to be sent on the V-ring to a frame buffer.

If the data is in Pseudo CDV form it may be stored in a frame buffer of this configuration. By using the byte swap functions, to be described later, the Pseudo CDV signal can be sent to a frame buffer on bytes A&amp;B or C&amp;D. This allows two pictures to be stored in a frame buffer, one on bytes A &amp; B, the other on bytes C &amp; D.

Figure 9B represents the data path through the V-ring controller in the component digital video output mode. In this mode of operation, RGB data from a frame buffer enters the V-ring controller at the V-ring input on bytes A, B &amp; C. In the matrix, it is converted to component form (Cb Y Cr), then the color components are multiplexed onto byte A by the PCDV MUX. This results in Pseudo CDV video on bytes A &amp; B of the matrix output side of the V-Ring.

Alternately, the data can be stored in a frame buffer in component form and the matrix set to identity. The component data would then pass unchanged through the matrix to be converted into Pseudo CDV form in the PCDV MUX. The data could also be stored in a frame buffer in Pseudo CDV form on bytes A and B. The matrix would then be set to identity and the PCDV MUX would be turned off.

The Pseudo CDV data is routed through the data steering latches to the PC and PL buses and the CDV MUX and OUTPUT sections. Here it is converted to CDV data and output on one of the CDV outputs.

Figure 9C represents the data path through the V-ring controller in the key channel output mode. In the key channel output mode, the K channel from a frame buffer enters the V-ring controller on byte D of the ring. It then goes through the matrix where it is unchanged and applied to the luminance input of one of the CDV MUX. In this case, the chroma input to the CDV MUX is driven to blanking.

The key channel output allows storage of the K channel data on a CDV storage device such as a digital recorder. This K channel output could also operate in parallel with the normal CDV appearing at one CDV output and key channel data appearing at the other CDV output.

Figure 9D represents the data path through the V-ring controller in the key channel input mode. The K channel data is recorded as luminance on a digital storage device which enters the V-ring controller on one of the CDV inputs. It then goes to byte D of the matrix input bus and passes through the matrix where it will generally be unchanged. It then goes onto the byte D of the V-ring and to addressed frame buffer.

8. The Command Control Stack of the V-ring Controller

Figure 10A is a detailed block diagram showing the functional blocks of the command control stack represented in Figure 7. The command control stack is used to send commands down to the frame buffers on the V-ring. The commands, some of which were summarized earlier, are sent on the V-ring during the horizontal blanking period of the video signal. The control words are 16 bits wide and are sent on the C&amp;D bytes of the V-ring as explained earlier.

Following the control words sent during the horizontal blanking period, blanking data is sent. The blanking data can be programmed to match whatever video standard is used on the V-ring. The command control stack can also be programmed to send the proper blanking on the A&amp;B bytes of the V-ring.

One main component of the control stack is a 16K by 20 bit command RAM. The command RAM is used to hold commands for the V-ring. The commands are placed in the command RAM in the order that they are to be sent around the V-ring. Each time a ring command is placed in the RAM the Command bit bit 16) is set. This bit will travel with the command word around the V-ring.

The last word of a group of commands that are all for the same scan line should contain the blanking levels for the C&amp;D bytes of the V-ring. The end of line bit (bit 17) is set with this word. This bit is used by the command control stack as an indication to quit sending commands around the ring and start sending the blanking levels.

The blanking level bit (bit 18) is also used in the command RAM. The data associated with the blanking level sets the blanking level that is sent on the A&amp;B bytes of the V-ring. Once this level is set, it will remain the same until it is changed by new blanking level.

a. Video Start Port

The video start port is a pointer to the command RAM. It is loaded via the local bus and points to the first control word to be sent during the active video part of the frame.

b. Video End Port

The video end port is loaded via the local bus to point at the last pixel data of the last line that is to be sent on the V-ring. When the values in the video counter and the video end port are equal, the video counter is loaded from the video start port.

c. Video Offset Port

By loading the video offset port to point to the top line to be displayed it can be used to make the frame scroll. At the start of a frame the value in the video offset port is loaded into the vertical counter. The counter is then incremented to point at the control words that are being sent on the V-ring.

d. Vertical End Port

The vertical end port is loaded via the local bus to point to the last data of the last line that is to be sent on the V-ring. When the video end port and the vertical end port compare, the vertical counter is reloaded from the vertical start port.

e. Command Stack Control Port

The command stack (CSTACK) control port has two bits that apply to the command control stack. The first is bit 0, which, when active enables the command control stack to run. The second bit is the transfer mode bit. When the transfer mode bit is inactive, the command control stack runs as described. When the transfer mode bit is active, the vertical blanking period is ignored and only the video ports are used. The interlace mode is also ignored and every line is sent.

f. Ring Sync Generator Control Port

The interlace mode bit comes from this port. When active, the command control stack will cause every other line to be sent down the V-ring. Otherwise, the command control stack will send the lines in order.

Provided below in Glossary A is a list of all the mnemonics shown in Figure 10A.

Figure 10B is a state diagram showing the various states of the control stack. Provided below in Glossary B is a list of the further mnemonics represented in Figure 10B. Also provided in Appendices A-C is the CUPL programming code for the PAL devices shown in Figure 10A. <tables id="tabl0002" num="0002"><img file="EP0367183B1_D0001.tif" /></tables><tables id="tabl0003" num="0003"><img file="EP0367183B1_D0002.tif" /></tables><tables id="tabl0004" num="0004"><img file="EP0367183B1_D0003.tif" /></tables><tables id="tabl0005" num="0005"><img file="EP0367183B1_D0004.tif" /></tables>

9. The Line Store of the V-ring Controller

Figure 11A provides a detailed block diagram of the line store represented in Figure 7. The line store includes 4 Kbytes of memory, buffers to interface the memory to the local bus and the V-ring, an address counter, and four PAL devices.

The line store is a 1024 x 32 bit dual port memory capable of storing one line of video data, i.e. up to 1024 pixels. One of the ports of the dual port memory connects to the V-ring at the MI (Matrix Input) BUS. Through this port, data can be either put onto or captured from the ring in real time (13.5 MHz pixel rate). The second port interfaces the line store to the local bus.

The line store performs the following functions: <ul id="ul0004" list-style="none" compact="compact"><li>1. It acts as a temporary buffer when transferring data between frame buffers, necessary when the destination frame buffer is upstream on the V-ring from the source frame buffer;</li><li>2. It is used to insert VIRS into the video train so the destination frame buffer will have VIR reference when in the ring view mode;</li><li>3. It is used to capture information contained in the horizontal blanking interval such as ancillary data on a CDV input or burst reference on an analog input. This data can then be read by the P-ring controller over the local bus or it can be sent to a frame buffer over the V-ring during the active video transfer;</li><li>4. It is used to insert ancillary data into the horizontal blanking interval of the CDV output; and</li><li>5. It is used to put test signals onto the V-ring.</li></ul>

a. Memory

The line store memory preferably consists of eight CY7C149 static RAMs whose data lines connect to the LD bus and whose address lines connect to the LA bus. These are 1K by 4 bit high speed RAMS capable of reading or writing data at the pixel clock rate of 13.5 MHz. The LD bus connects to two sets of bidirectional buffers, one set going to the local bus and the other going to the V-ring. The LA bus comes from the address counter.

b. Local Bus Interface

The line store to local bus interface consists of four 74F244 octal bidirectional buffers, the CPUSM PAL, and parts of the LSWRC PAL, and the address counter. Data from the local bus section (D 31 - 0) interfaces to the LD bus through the four bidirectional buffers. The common output enable pinouts of the buffers are controlled by the CPUSM PAL while the direction lines connect to the SWRITE* signal from the local bus interface section.

The address lines from the local bus section (A 11 - 2) connect to the data inputs of the three address counter devices. During a local bus access, the counters are disabled and the load input to the counter is held low which causes the address on the data inputs to appear at the counter outputs. This load input is controlled by the CPUSM PAL. The write enable and chip select for the memory chips are generated in the CPUSM PAL, then sent to the LSWRC PAL which selects them during a local cycle.

c. CPUSM PAL

The CPUSM PAL (CPU State Machine) generates most of the signals required to complete a local bus to line store read or write cycle. Figure 11B provides the CPU State Machine diagram. Provided in Appendix D is the CUPL programming code for the CPUSM PAL device.

d. Inputs to the Line Store

The LSMQ 3 - 0 and the SSELS* inputs to the line store are used to initiate a local bus cycle. The SSELS* is a decoded signal from a local bus interface section and is used to select the line store while the LSMQ bits hold off the local bus cycle until the line store state machine is finished with its present cycle (i.e., returns to state 0).

The SWRITE* input indicates to the state machine whether the cycle is to be a read cycle or a write cycle.

The DS* input is derived from the local bus interface section and is used to generate the DSACKL* signal. The DSACKL* signal acknowledges to the CPU that the local bus access cycle is complete.

The SBRESET* signal ensures that the CPU state machine starts out in state zero when the system is initialized.

e. Outputs

The signals shown in the CPU state diagram of Figure 11B are the outputs as labeled on the CPUSM PAL shown in Figure 11A.

LADLD* (Line Store Address Load) is the load to the address counter used during a local bus cycle.

LAWE* (Line Store to Local Bus Write Enable) asserts the write enable during a local bus write cycle.

LSAOE* (Line Store to Local Bus Output Enable) enables the bidirectional buffers during a local bus cycle.

LCSEN (Line Store Chip Select Enable) asserts the chip select during a local bus access.

f. Line Store State Machine - LSSTM PAL

Figure 11C provides the line store state machine state diagram for the line store PAL device. The line store state machine is contained in the LSSTM PAL device shown in figure 11A with its inputs coming from the command processor section and the ring sync generator (Figure 10A). Provided in Appendix E is the CUPL programming code for the LSSTM PAL device.

As shown in Figure 11C, the line store state machine has four "active" states and six "wait" states. During the active states, the line store is doing one of four basic functions as summarized below: <ul id="ul0005" list-style="none" compact="compact"><li>1. State 2 (S2)/Write Line State. During State 2, the active video portion, a line (768 pixels) is written from the V-ring input into the line store memory.</li><li>2. State 4 (S4)/Read Line State. During State 4, a line of video data (768 pixels) is read from the line store memory and put onto the V-ring at the MI bus;</li><li>3. State 6 (S6)/Write Horizontal Blanking State. During State 6, the horizontal blanking interval of an incoming video signal (CDV or analog input) is written into the line store memory; or</li><li>4. State 8 (S8)/Read Horizontal State. During State 8, which is active during horizontal blanking, data in the line store memory is put onto the V-ring at the MI bus. This data is then picked up by the CDV output section and output during the blanking interval (ancillary data).</li></ul>

A state machine cycle is initiated by a command from the command processor section which moves the machine into one of the wait states. Here, the machine waits for a timing signal, which has the correct relationship to the video signal, and then moves into one of the active states. These timing signals may be derived from the sync generator or are derived from the V-ring reference at the V-ring input. At the end of an active state, another timing signal, or the termination of the same one, moves the machine back to S0 where it waits for the next command.

g. Line Store Commands

Provided below in Table A is a list of commands for the line store. <tables id="tabl0006" num="0006"><table frame="all"><title>TABLE A</title><tgroup cols="3" colsep="1" rowsep="0"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row><entry namest="col1" nameend="col1" align="center">CDMD* 3-0</entry><entry namest="col2" nameend="col2" align="center">COMMAND</entry><entry namest="col3" nameend="col3" /></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="right">0 0 0 0</entry><entry namest="col2" nameend="col2" align="left">NOOP</entry><entry namest="col3" nameend="col3" align="left">No operation, do nothing.</entry></row><row><entry namest="col1" nameend="col1" align="right">0 0 0 1</entry><entry namest="col2" nameend="col2" align="left">WLCMD</entry><entry namest="col3" nameend="col3" align="left">Write Line Command write a line to the line store.</entry></row><row><entry namest="col1" nameend="col1" align="right">0 0 1 0</entry><entry namest="col2" nameend="col2" align="left">RLCMD</entry><entry namest="col3" nameend="col3" align="left">Read Line Command read a line from the line store.</entry></row><row><entry namest="col1" nameend="col1" align="right">0 0 1 1</entry><entry namest="col2" nameend="col2" align="left">WHCMD</entry><entry namest="col3" nameend="col3" align="left">Write Horizontal Blanking Command write the horizontal blanking interval to the line store.</entry></row><row><entry namest="col1" nameend="col1" align="right">0 1 0 0</entry><entry namest="col2" nameend="col2" align="left">RHCMD</entry><entry namest="col3" nameend="col3" align="left">Read Horizontal Blanking Command read the horizontal blanking interval from the line store.</entry></row><row><entry namest="col1" nameend="col1" align="right">0 1 0 1</entry><entry namest="col2" nameend="col2" align="left">FCCMD</entry><entry namest="col3" nameend="col3" align="left">Frame Capture Command set the FCM latch.</entry></row><row><entry namest="col1" nameend="col1" align="right">0 1 1 0</entry><entry namest="col2" nameend="col2" align="left">ANCMD</entry><entry namest="col3" nameend="col3" align="left">Ancillary Mode Command set the ANCM latch.</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="right">0 1 1 1</entry><entry namest="col2" nameend="col2" align="left">EFCMD</entry><entry namest="col3" nameend="col3" align="left">End Frame Capture Command clear the FCM or ANCM latch.</entry></row></tbody></tgroup></table></tables>

The RIHR* (Ring Input Horizontal Reference) comes from the V-ring input and is used to denote the end of active video on the V-ring input.

The RICS* (Ring Input Commands Start) is derived from the RIHR* signal and is used to denote the start of active video on the V-ring input.

The ACTV1* and ACTV2* (Active Video) signals come from the sync generator and are used to denote the active video area at the V-ring output. The two signals are timed differently, and one is selected depending on whether or not a matrix circuit is present.

The OBLNK1* and OBLNK2* (Output Blanking) signals come from the sync generator and denote the horizontal blanking area at the V-ring output. The two signals are timed differently, and one is selected depending on whether or not a matrix circuit is present.

The EEAVP* (Early End Active Video Pulse) signal takes place some time before the end of active video. This signal is used to terminate the cycle when transferring blanking interval data to a frame buffer.

The RBLNK* (Ring Blanking) denotes the horizontal blanking area when writing ancillary data or burst to the line store.

The SBRESET* and SSELS* inputs both force the state machine into its idle state (S0). They also reset the FCM and ANCM latches.

h. Outputs

The LSMQ 3-0 (Line Store State Machine Q) outputs shown in Figure 11A are used by several circuits on the V-ring controller to arbitrate access to the V-ring between the line store and other circuits. Because some of these circuits are downstream on the V-ring from the line store, the LSMQ signals must be delayed to match the data delays. This is done by the state delay section. In the state delay section, the LSMQ signals are delayed by one clock to become the DLSM signals which are then sent to the matrix on the V-ring controller where they are delayed by the same number of clocks as the data. From the output of the matrix, the signals, now named ILSM, are sent back to the state delay section where they are delayed one more clock period and named SLSM.

The FCM* (Frame Capture Mode) signal is the output of a latch which is set when doing burst captures.

The ANCM* (Ancillary Mode) signal is the output of a latch which is set when doing certain ancillary data captures.

i. Address Counter

As represented in Figure 11A, the line store address counter preferably consists of three 74FR163 synchronous counter devices. The count enable (LCNTE) and the clear (ADCLR*) signals, which control the counter during ring access, are derived from the LSWRC PAL.

During ring access, the address counter is controlled by the LSWRC PAL and LSSTM PAL. During the wait states, which precede the read and write states, the ADCLR* signal is asserted so the counter is held at count 0. During the read or write state, the counter is allowed to run (count up) until the state machine moves into the next state where it is either cleared or held at its last count (during state 0). During certain ancillary data transfers (ANCM asserted), the LCNTE line is toggled so the counter runs at one-half normal rate.

j. The LSWRC PAL (Line Store Write/Read Control)

The LSWRC PAL generates the control signals for the address counter plus the chip select and write enable for the memory chips. Appendix F provides the CUPL programming code for the LSWRC PAL device.

k. The LSRBC PAL (Line Store to V-Ring Buffer Control)

The LSRBC PAL controls the line store to V-Ring buffers. Appendix G provides the CUPL programming code for the LSRBC PAL device.

10. Ring Input Section and Command Processor Section

Figure 12A shows a detailed block diagram of the V-ring input section of the V-ring controller represented in Figure 7. The V-ring input section includes the V-ring input interface, the analog input latches, the CDV input latches, the command latch, and the matrix bypass latch. Also shown in Figure 12A is the input buffer control (INBUF) PAL.

a. V-ring Input Interface

The V-ring input interface buffers data coming onto the V-ring controller from the V-ring. If necessary, the V-ring input interface buffers retime the data to the V-ring controller master clock (labeled C74). The incoming data is preferably buffered in four 74HC244 octal buffers, one for each data byte. The data bytes are labeled A, B, C, and D on the block diagram of Figure 12A and are assigned the following bits: <dl id="dl0003" compact="compact"><dt>Byte A =</dt><dd>24 bits through 31</dd><dt>Byte B =</dt><dd>bits 16 through 23</dd><dt>Byte C =</dt><dd>bits 8 through 15</dd><dt>Byte D =</dt><dd>bits 0 through 7</dd></dl>

b. Timing Latch #1

After being buffered by the V-ring input interface buffers, the data is sent to the first timing latch which consists of four 74F374 octal latches. In the first timing latch the data is latched by a 13.5 MHz clock labeled R74. The R74 clock is derived from a 27 MHz clock (VRCLK) which travels around the ring with the data. 74 octal latches. In the second timing latch the data is latched by another 13.5 MHz clock labeled M74. M74 is a tunable clock in that its timing relationship can be varied relative to R74 and C74 clock signals.

c. Timing Latch #2

From the first timing latch, the data is sent to a second set of timing latches consisting of four 74F374 octal latches. In the second timing latch the data is latched by another 13.5 MHz clock labeled M74. M74 is a tunable clock in that its timing relationship can be varied relative to R74 and C74 clock signals.

d. Ring Data and Command Latches

From the second set of timing latches, the data is sent to the ring data latch and the command latch. Both of these latches are clocked by the master clock (C74). The ring data latch consists of four 74F374 octal latches whose output enables are controlled by the input buffer control PAL.

The command latch consists of two 74F374 octal latches on V-ring data bytes C and D. The data from these latches is sent along with the command bit to the command processor section.

e. Analog Input Latch

The analog input latch consists of eight 74F374 octal latches which receive data from the V-ring controller analog input and drive it onto the V-ring.

f. CDV Data Latch

The CDV data latch shown in Figure 12A consists of three 74F374 octal latches which receive data from the CDV input section and drive it onto the V-ring. As in the ring input buffer and the analog input latches, the output enables of the CDV data latch are controlled by the input buffer control PAL. Data comes from the CDV input section on the three buses labeled YI, CBI, and CRI as represented in Figure 12A. These represent the luminance and color difference signals Y, Cb, and Cr, respectively.

The data from the CDV input section can be in one of two forms, the above-mentioned Y Cb Cr or a form referred to as Pseudo CDV. The Pseudo CDV form has the Y data on the YI bus and the Cr data multiplexed onto the CBI bus. In this form, a picture can be transferred on just two bytes of the V-ring and stored in two memory bytes of the frame buffer.

g. I Key Latch

As represented in Figure 12A, the input key mode latch (IKEY LATCH) takes luminance data from the YI bus and puts it on byte D of the V-Ring. This latch is used to retrieve key data which was previously stored on some CDV device.

h. Matrix Bypass Latch

The matrix bypass latch represented in Figure 12A, consists of two 74F374 octal latches whose inputs connect to the YI and CBI buses and whose outputs connect to V-ring bytes A and B by way of the VO bus. The output enables of the matrix bypass latch are derived from the input buffer control PAL. The matrix bypass latch allows Pseudo CDV data from the CDV input to be put directly on the V-ring after the matrix. This operation is useful for certain still store functions.

i. INBUF PAL

The INBUF PAL represented in Figure 12A selects which input source will be put on the V-ring and ensures there is no contention with the line store section which interfaces to the ring at the same point.

All the inputs to the INBUF PAL come from either the video IO control port or the line store state machine (Figures 11A - 11C). The SIN lines from the video IO control port select which video source is to be input. Provided below in Table B is a list of the SIN line values and the corresponding video input source. <tables id="tabl0007" num="0007"><table frame="all"><title>TABLE B</title><tgroup cols="2" colsep="1" rowsep="0"><colspec colnum="1" colname="col1" colwidth="78.75mm" /><colspec colnum="2" colname="col2" colwidth="78.75mm" /><thead valign="top"><row><entry namest="col1" nameend="col1" align="center"><u>SIN (2-0) Value</u></entry><entry namest="col2" nameend="col2" align="center"><u>Video Input Source</u></entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="center">0</entry><entry namest="col2" nameend="col2" align="left">None</entry></row><row><entry namest="col1" nameend="col1" align="center">1</entry><entry namest="col2" nameend="col2" align="left">V-RING Input</entry></row><row><entry namest="col1" nameend="col1" align="center">2</entry><entry namest="col2" nameend="col2" align="left">CDVA</entry></row><row><entry namest="col1" nameend="col1" align="center">3</entry><entry namest="col2" nameend="col2" align="left">CDVB</entry></row><row><entry namest="col1" nameend="col1" align="center">4</entry><entry namest="col2" nameend="col2" align="left">RED from analog input red</entry></row><row><entry namest="col1" nameend="col1" align="center">5</entry><entry namest="col2" nameend="col2" align="left">GREEN from analog input green</entry></row><row><entry namest="col1" nameend="col1" align="center">6</entry><entry namest="col2" nameend="col2" align="left">Blue from analog input blue</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="center">7</entry><entry namest="col2" nameend="col2" align="left">CCVS from analog input CCVS</entry></row></tbody></tgroup></table></tables>

The NTXON bit from the video IO control port determines whether the data will go through the matrix or around the matrix by way of the matrix bypass latch.

The IKEY bit turns on the IKEY latch and enables the luminance data from the CDV input onto byte C of the V-ring.

The TRANS bit puts the board in transparent mode which causes the V-ring data to pass through the board unchanged with the possible exception of the matrix.

The four inputs from the line store state machine (LSMQ 3-0) (Figure 11C) are used to override the selected input and enable the line store onto the V-ring during certain line store operations.

Provided in Appendix H is the CUPL programming code for the INBUF PAL.

j. Command Processor

Figure 12B is a block diagram showing the organization of the command processor represented in Figure 12A.

11. Ring Output Section

Figure 13 shows a detailed block diagram of the V-ring output section which is represented in Figure 7. The V-ring output section includes the PCDVMUX, the CDVA and CDVB output latches, the CDV blanking drivers, the matrix output bypass latch, the byte swap latches, and the V-ring output latch. Also shown are the various PALs that control the circuits in this section.

a. Pseudo CDV MUX

The Pseudo CDV MUX represented in Figure 13 consists of two 74F825 octal registers and three 74F374 octal latches whose inputs come from the matrix output. The outputs from the two registers both drive V-ring byte A while the inputs come from byte A for one register and byte C for the other.

In the normal operating mode, referred to as the component mode, the register whose input comes from byte A and the three latches are turned on, and the data passes through unchanged. The other register is turned off.

In the Pseudo CDV mode, Cr data on byte A and Cb data on byte C are latched into the registers at one-half the normal clock rate. The registers then alternately enabled onto ring byte A which in effect multiplexes Cr and Cb data onto one byte. The luminance (Y) signal passes through the latch on byte B and forms the other byte of the Pseudo CDV signal. Table C provides the relationship between the pseudo CDV MUX inputs and outputs. <tables id="tabl0008" num="0008"><img file="EP0367183B1_D0005.tif" /></tables>

b. PCDVM PAL

As represented in Figure 13 the inputs to the PCDVM PAL are obtained from the video IO control port and the ring sync generator.

The DLSM inputs are obtained from the line inputs of the line store state machine.

The SIN 2-0 and MTXON inputs are used to turn the latches off when in the matrix bypass mode.

The CMPT bit is used to put the MUX into Component or Pseudo CDV mode where CMPT = component digital video and CMPT* = psuedo component digital video.

The PSYNC* is derived from the ring sync generator and is used to synchronize the PSEUDO CDV MUX so that Cb is always on the first pixel.

Provided in Appendix I is the CUPL programming code for the PCDVM PAL device.

c. Byte Swap

In Figure 13, the byte swap section consists of eight 74F374 latches and the BYTSW PAL. The byte swap functions to steer the V-ring data in byte pairs (words) to other byte pairs prior to being sent to the V-ring output latch.

This data steering is controlled by the two BSC (Byte Swap Control) bits in the video IO control port. The relationship between the two BSC bits and the output of the byte swap section is shown in Table D. <tables id="tabl0009" num="0009"><table frame="all"><title>TABLE D</title><tgroup cols="3" colsep="1" rowsep="0"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row><entry namest="col1" nameend="col1" align="left"><u>BSC Bits</u></entry><entry namest="col2" nameend="col2" align="center"><u>Byte Swap In</u></entry><entry namest="col3" nameend="col3" align="center"><u>Byte Swap Out</u></entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="left">A</entry><entry namest="col3" nameend="col3" align="left">A</entry></row><row><entry namest="col1" nameend="col1" align="right">0 0</entry><entry namest="col2" nameend="col2" align="left">B</entry><entry namest="col3" nameend="col3" align="left">B</entry></row><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="left">C</entry><entry namest="col3" nameend="col3" align="left">C</entry></row><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="left">D</entry><entry namest="col3" nameend="col3" align="left">D</entry></row><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="left">A</entry><entry namest="col3" nameend="col3" align="left">A &amp; C</entry></row><row><entry namest="col1" nameend="col1" align="right">0 1</entry><entry namest="col2" nameend="col2" align="left">B</entry><entry namest="col3" nameend="col3" align="left">B &amp; D</entry></row><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="left">C</entry><entry namest="col3" nameend="col3" align="left">A &amp; C</entry></row><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="left">D</entry><entry namest="col3" nameend="col3" align="left">B &amp; D</entry></row><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="left">A</entry><entry namest="col3" nameend="col3" align="left">C</entry></row><row><entry namest="col1" nameend="col1" align="right">1 1</entry><entry namest="col2" nameend="col2" align="left">B</entry><entry namest="col3" nameend="col3" align="left">D</entry></row><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="left">C</entry><entry namest="col3" nameend="col3" align="left">A</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="left">D</entry><entry namest="col3" nameend="col3" align="left">B</entry></row></tbody></tgroup></table></tables>

d. BYTSW PAL

The BYTSW PAL represented in Figure 13 enables the appropriate byte swap latches and prevents contention with the command control stack or ring message section which drive the ring at the same point. Inputs to the BYTSW PAL come from the video IO control port, the line store state machine, and the ring sync generator. The BSC IO bits are derived from the video IO control port.

The SIN 2-0 bits enable the selected byte swap latches whenever any input except the V-ring is selected.

The LSMQ 3-0 bits enable the selected latches when the line store is inserting data onto the V-ring. The CMDAA (Command Area Active) and RMTP (Ring Message Timing Pulse) signals disable the byte swap latches so the control stack or ring message circuit can drive the V-ring.

The TRANS signal turns on the straight through latches and overrides all other inputs.

Appendix J provides the CUPL programming code for the BYTSW PAL.

e. V Ring Output Latch

The V-ring output latch and matrix bypass output latch represented in Figure 13 consists of four 74HCT374 latches driving the V-ring output through 33 ohm resistors. The resistors serve as source terminations which absorb reflections caused by the unterminated receivers at the input of the next board on the ring. The matrix bypass output latch consists of a pair of 74F374 latches. These latches route the data from bytes A and B of the MI bus directly to the CDV output, thus bypassing the matrix and Pseudo CDV MUX sections. Control of these latches is derived from the CDVOUT PALs. These latches are used in certain types of still store operations.

f. CDV Output Latch

There are two identical CDV output latches represented in Figure 13, one for each of the two CDV outputs. Each CDV output latch consists of four 74F374 latches and a control PAL. In normal operation, the CDV output section requires pseudo CDV data at its input, which can be on bytes A and B or bytes C and D. The CDV output latch circuit selects the byte pair, depending on the UWD (Upper Word Data) bit in the video IO control port (Figure 12). For output A, the UWDA signal selects bytes A and B while the UWDA* signal selects bytes C and D.

If the key output mode is selected (AKEYM or BKEYM in the video IO control port), byte C is sent to the luminance (PL) input of the CDV output section and the chroma (PC) input is driven to blanking, resulting in a luminance only CDV output.

g. CDVOUT PALs

The inputs to the two identical control PALS, both labeled CDVOUT in Figure 13 are obtained from the video IO control port, the output sync generator, and the line store state machine.

The CDVAON/CDVBON bits enables the pair of latches selected by the UWDA/UWDB bits while the CDVAON* signal disables the latches and allows the input to the CDV output section to be driven to by the CDV blanking drivers.

The UWDA/UWDB bits select data from bytes A and B while UWDA*/UWDB* select data from bytes C and D. The AKEYM/BKEYM bits enable the key output mode. The CCDVB* (Composite CDV Blanking) signal is obtained from the sync generator and disables the latches during blanking so the inputs to the CDV output section can be driven to blanking by the blanking drivers. The MTXON* and IN1 (from the SIN bits) signals turn on the matrix bypass output latch. The DLSM 3-0 bits from the line store state machine are used to insert ancillary data from the line store into the horizontal blanking interval.

Appendix K provides the CUPL programming code for the CDVOUT PAL devices represented in Figure 13.

h. CDV Banking Drivers

The CDV blanking drivers represented in Figure 13 consist of a pair of 74F244 buffers, for each of the two CDV outputs, and the CDVBLK PAL. The inputs to these buffers are hardwired to CDV blanking levels, 10h for luminance and 80h for chroma, and the outputs connect to the PL and PC buses. During blanking or when the CDV output is turned off, the buffers are turned on and drive the blanking levels onto these buses.

i. CDVBLK PAL

The inputs to the CDVBLK PAL represented in Figure 13 come from the video IO control port, the line store state machine, and the output sync generator. The CDVAON* and CDVBON* signals turn on the blanking drivers to their respective CDV output section. The AKEYM and BKEYM signals turn on the blanking drivers to their respective PC bus so only chroma is blanked.

The HCDVB (Horizontal CDV Blanking) and VCDVB (Vertical CDV Blanking) signals are anded together to form a Composite CDV Blanking signal which is used to enable the blanking drivers. The DLSM bits from the line store state machine are used to disable the blanking drivers during the insertion of ancillary data. Appendix L provides the CUPL programming code for the CDVBLK PAL device.

12. Matrix Module

Provided in Figure 14 is a block diagram of the matrix module represented in Figure 7. Those skilled in the art will readily recognize the structure of the matrix module. The matrix module represented in Figure 14 may be routinely fabricated by those having ordinary skill in the art.

Briefly, the matrix module functions to convert a component digital video signal found on bytes A, B, and C of the V-ring from one format to another, e.g., from RGB format to CbYCr format. This is accomplished by properly programming the insertion of the pixel bits into, and their removal from, the RAM devices. The outputs of the RAM devices are passed to adder circuits and the resulting signal is pinned to ensure that no value less than zero or greater than all 8 bits asserted onto bytes A, B, and C which is possible since the outputs of the adders provide 16 bits of precision.

F. The Presently Preferred Embodiment and Present Best Mode for Implementing the Frame Buffer: Figure 15.

Figure 15 provides a block diagram of a representative embodiment of the frame buffers included on the V-ring in the presently preferred embodiment. Each frame buffer is able to store a plurality of frames at video resolution. The video images contained in the frame buffer can be manipulated on a pixel-for-pixel basis by the computational subsystem connected to the frame buffer by way of the local bus. Any of the video images stored on the frame buffer can be viewed on an RGB monitor attached to the analog output.

Generally, the frame buffer serves as the picture-holding element for a general purpose graphics processing "slice" of the embodiment as explained earlier in connection with Figure 1B and 1C. Commonly, such a slice consists of a computational subsystem, a DRAM section, and the frame buffer.

The frame buffer receives instructions from a computational subsystem by way of the local bus ports and also from the V-ring controller by way of the V-ring. It will be appreciated that depending upon the complexity of the functions to be carried out by the frame buffer, the structure of the local bus will need to vary to accommodate the complexity of the commands given to the frame buffer by the computational subsystem. For example, the local bus ports may contain circuits to provide port dcodes, color map dcodes and video RAM decodes. Furthermore, it may contain various status ports.

The data transcievers (DATA XCVRS) provide a link between the video RAM modules and the data lines of the local bus. Preferably, the data transceiver section contains two complete 64 bit transceiver sets. One transceiver set is straight through while the other transciever set shuffles the data bits around in a certain way that is useful for high precision software color operations.

The address section represented in Figure 15 performs the function of taking the logical address (in the form of picture, scanline, pixel) and converting it to a physical or hardware address (in the form of bank, section, row, column). The address section may perform these functions whenever access to the video RAM modules is desired by way of the local bus or by way of the V-ring, or to output the data contained in the video RAM modules to the analog output.

The video RAM modules represented in Figure 15 preferably include RAM devices organized to store video data. Preferably, the video data is in the form of R, G, B, and K.

The ring command processor examines incoming ring commands (validated by the command bit input at CMDBI) to determine if the command is addressed to the particular frame buffer. The ring command processor then executes the command after the appropriate parameter words are received.

The color maps and analog section receives video data from the video RAM modules by way of the multiplexor system (MUX SYSTEM) (four channels, ten bits each). Each channel of data is passed through a separate 10 bit to 10 bit color map RAM look-up table. The output of the color map RAMs is fed to the analog section which produces an analog RGB output. The sync signal for the frame buffer is generated by the sync generator controlled by the timing and arbitration circuit.

G. Representative Software

Provided in Appendix M is a representative source code listing used for programming the devices included in the described embodiment of the V-ring. It is to be understood that the provided source code listing is just one of the many possible examples of source codes which could be used to program the V-ring devices.

H. Conclusion

From the foregoing, it will be appreciated that the present invention provides a high speed computer graphics image computation system and method which is particularly adapted for carrying out demanding computer graphics computation tasks. The components of the video processing ring (V-ring) synchronously operate to move the large amounts of data associated with digital video signals to locations within the graphics image computation system. Thus, the V-ring enhances the performance of the computational subsystems of the processor ring (P-ring) by providing a flexible structure used for transporting bulk data that might otherwise overwhelm and slow the operation of the P-ring.

The embodiments of the present invention may be configured into one or more logical machines to most efficiently handle a variety of graphics image computation tasks. Moreover, the embodiments of the present invention may be easily expanded to include additional computational subsystems on the P-ring and additional frame buffers on the V-ring. The described embodiments readily interface with external video and computing devices thus increasing the versatility of the embodiments. By the incorporation of the present invention, a high speed computer graphics image computation system is achieved which performs better than previously available systems.