SYSTEM AND METHOD FOR DATA PLANARIZATION

Abstract: A system and method for planarizing n-bit display data into m-bit data. The system includes a plurality of input terminals, a plurality of output terminals, and a first storage bank having a bit-depth less than m. In one embodiment, the first storage bank is a bi-directional shift register including a clock input terminal, for receiving a data shift signal, and a direction terminal for receiving a direction control signal. In a particular embodiment, the bi-directional shift register includes a plurality of flip-flops and a plurality of multiplexers, both arranged in a rectangular array of columns and rows. Optionally, the system includes a second storage bank, and data is shifted into one storage bank while data is being shifted out of the other storage bank.

Description: SPECIFICATION SYSTEM AND METHOD FOR DATA PLANARIZATION BACKGROUND OF THE INVENTION Field of the Invention This invention relates generally to electronic display drivers, and more particularly to an improved system and method for display data planarization. Description of the Background Art FIG. 1 shows a single pixel cell 100 of a typical liquid crystal display. Pixel cell 100 includes a liquid crystal layer 102, contained between a transparent common electrode 104 and pixel storage electrode 106, a storage element 108, and a switching transistor 110. Storage element 108 is coupled at node 112 to pixel storage electrode 106 and, via switching transistor 110, to a data input line 114. Storage element 108 is also coupled, as is common electrode 104 to a common voltage supply terminal 116 (e.g., ground). Responsive to a select signal on select line 118, which is coupled to the control terminal of switching transistor 110, storage element 108 reads a data signal in from data line 114, stores the signal, and asserts the signal on node 112, even after the select signal is no longer present. Liquid crystal layer 102 rotates the polarization of light passing through it, the degree of rotation depending on the root-mean-square (RMS) voltage across liquid crystal layer 102. The ability to rotate the polarization is exploited to modulate the intensity of reflected light as follows. An incident light beam 120 is polarized by polarizer 122. The polarized beam then passes through liquid crystal layer 102, is reflected off of pixel electrode 106, and passes again through liquid crystal layer 102. During this double pass through liquid crystal layer 102, the beam's polarization is rotated by an amount which depends on the data signal being asserted on pixel storage electrode 106. The beam then passes through polarizer 124, which passes only that portion of the beam having a specified polarity. Thus, the intensity of the reflected beam passing through polarizer 124 depends on the amount of polarization rotation induced in liquid crystal layer 102, which in turn depends on the data signal being asserted on pixel storage electrode 106. Storage element 108 can be either an analog storage element (e.g. capacitative) or a digital storage element (e.g., SRAM latch). In the case of a digital storage element, a common way to drive pixel storage electrode 106 is via pulse- width-modulation (PWM). In PWM, different gray scale levels are represented by multi-bit words (i.e., binary numbers). The multi- bit words are converted to a series of pulses, whose time-averaged root-mean-square (RMS) voltage corresponds to the analog voltage necessary to attain the desired gray scale value. For example, in a 4-bit PWM scheme, the frame time (time in which a gray scale value is written to every pixel) is divided into 15 time intervals. During each interval, a signal (high, e.g., 5V or low, e.g., 0V) is asserted on the pixel storage electrode 106. There are, therefore, 16 (0-15) different gray scale values possible, depending on the number of "high" pulses asserted during the frame time. The assertion of 0 high pulses corresponds to a gray scale value of 0 (RMS 0V), whereas the assertion of 15 high pulses corresponds to a gray scale value of 16 (RMS 5 V). Intermediate numbers of high pulses correspond to intermediate gray scale levels. A particular signal being applied during a time interval is referred to as a "state". For example, a high signal being asserted during one time interval is an "on" state. Similarly, a low signal being asserted during one time interval is referred to as an "off state. FIG. 2 shows a series of pulses corresponding to the 4-bit gray scale value (1010), where the most significant bit is the far left bit. The pulses are grouped to correspond to the bits of the binary gray scale value. Specifically, the first group B3 includes 8 intervals (23), and corresponds to the most significant bit of the value (1010). Similarly, group B2 includes 4 intervals (22) corresponding to the next most significant bit, group Bl includes 2 intervals (21) corresponding to the next most significant bit, and group B0 includes 1 interval (20) corresponding to the least significant bit. This grouping reduces the number of pulses required from 15 to 4, one for each bit of the binary gray scale value, with the width of each pulse corresponding to the significance of its associated bit. Thus, for the value (1010), the first pulse B3 (8 intervals wide) is high, the second pulse B2 (4 intervals wide) is low), the third pulse Bl (2 intervals wide) is high, and the last pulse B0 (1 interval wide) is low. This series of pulses results in an RMS voltage that is approximately J- (10 of 15 intervals) of the full value (5V), or approximately 4.1V. The resolution of the gray scale can be improved by adding additional bits to the binary gray scale value. For example, if 8 bits are used, the frame time is divided into 255 intervals, providing 256 possible gray scale values. In general, for (n) bits, the frame time is divided into (2n - 1) intervals, yielding (2n) possible gray scale values. Because the liquid crystal cells are susceptible to deterioration due to ionic migration resulting from a DC voltage being applied across them, the above described PWM scheme is modified as shown in FIG. 3. The frame time is divided in half. During the first half, the PWM data is asserted on the pixel storage electrode, while the common electrode is held low. During the second half of the frame time, the complement of the PWM data is asserted on the pixel storage electrode, while the common electrode is held high. This results in a net DC component of 0V, avoiding deterioration of the liquid crystal cell, without changing the RMS voltage across the cell, as is well known to those skilled in the art. FIG. 4 shows a response curve of an electrically controlled, birefringent liquid crystal cell. The vertical axis 402 indicates the percent of full brightness (i.e., maximum light reflection) of the cell, and the horizontal axis 404 indicates the RMS voltage across the cell. As shown, the minimum brightness (a dark pixel) is achieved at an RMS voltage Vtt. For some wavelengths of light, an RMS voltage less than Vtt results in a pixel that is not completely dark, as shown in FIG.4. For other wavelengths, all RMS voltages less than Vtt result in a dark pixel. In the portion of the curve between Vtt and Vsat, the percent brightness increases as the RMS voltage increases, until 100% full brightness is reached at Vsat. Once the RMS voltage exceeds Vsat, however, the percent brightness decreases as the RMS voltage increases. FIG. 5 shows an RMS voltage versus gray scale value curve, for an 8-bit (256 gray scale values) gray scale system. The RMS voltage for each gray scale value ("Gray-Value") is given by the following formula, where Von is the digital "on" value, typically Vdd: Vrms = J(l / 255)(GrayValue)(Von) 2 (Eq. 1) Gray scale value (x) corresponds to an RMS voltage equal to Vtt and, referring back to FIG. 4, to 0% brightness. Thus, the gray scale values less than value (x) are unusable, because for some wavelengths of light, they result in a brighter rather than a darker pixel, and for other wavelengths, the values result in 0% brightness and are, therefore, redundant. Similarly, value (y) corresponds to an RMS voltage equal to Vsat and, referring back to FIG. 4, to 100% full brightness. Thus, the gray scale values greater than value (y) are also unusable, because they result in a darker rather than a brighter pixel. The result of these wasted values is that true 8-bit gray scale resolution is not obtained. In order to avoid gray scale distortions, all gray scale values must be confined to the useful portion of the liquid crystal response curve (FIG. 4) between Vtt and Vsat. One way to accomplish this is to add an additional bit to the gray scale code (e.g., use a 9-bit gray scale system) and then map the 8-bit values to the values of the 9-bit system corresponding to the useful portion of the response curve. The addition of a single bit, however, increases the bandwidth requirements of the data interface by 100%, and is, therefore, undesirable. What is needed is a system and method for confining all of the available gray scale states to the useful portion of the liquid crystal response curve. Furthermore, because a display data stream is generally received pixel by pixel (one multi-bit gray scale value at a time) and is written to a display one bit (for every pixel) at a time, the incoming data must be reformatted (planarized). One method of reformatting the data is described in U.S. Patent No. 5,255,100, issued to Urbanus on October 19, 1993, which is incorporated herein by reference. Urbanus describes a system whereby an entire frame worth of data is stored in a random access memory (RAM), and then transferred to a frame memory one bit at a time. The entire frame worth of memory must be output from the RAM to the frame buffer before additional data can be received by the RAM. The system of Urbanus is, therefore, memory intensive and slow. What is needed is a fast, simple, and memory efficient system and method for planarizing a display data stream. SUMMARY A novel data planarizer is described. The data planarizer receives data words having a first number of bits (n-bit data) and outputs data words having a second number of bits (m-bit data). The planarizer includes a plurality of data input terminals for receiving the n-bit data words and a plurality of data output terminals for outputting the m-bit data words. The planarizer further includes a first storage bank having an input terminal set coupled to the plurality of data input terminals, an output terminal set coupled to the plurality of data output terminals, and a bit-depth less than the bit- width (m) of the reformatted data. In one embodiment, the storage bank is a bi-directional shift register, including a clock input terminal, for receiving a data shift signal, and a direction terminal, for receiving a direction control signal. In a particular embodiment, the bi-directional shift register includes a plurality of flip-flops and a plurality of multiplexers, each arranged in a rectangular array of columns and rows. Each of the flip-flops has a control terminal coupled to the clock terminal of the bidirectional shift register, an input terminal, and an output terminal. Each multiplexer has a first input terminal, a second input terminal, a control terminal coupled to the direction terminal of the bi-directional shift register, and an output terminal coupled to the input terminal of an associated one of the flip-flops. Each multiplexer in a first column of the array has its first input terminal coupled to an associated one of the data input terminals, and each flip-flop in a bottom row has its output terminal coupled to an associated one of the data output terminals. Additionally, each multiplexer of the other columns has its first input terminal coupled to the output terminal of an associated one of the flip-flops located in an adjacent column, and each multiplexer in the rows other than a top row has its has its second input terminal coupled to the output terminal of an associated one of the flip-flops located in an adjacent row. In a particular embodiment, the data planarizer includes a first storage bank and a second storage bank. In a more particular embodiment, the combined capacity of the first and the second storage banks is less than one frame of data. A novel method for planarizing n-bit data into m-bit planarized data is also described. The method includes the steps of receiving a first group of (p) n-bit data words (where p<m), storing the first group of (p) data words in a first storage bank, and transferring the first group of (p) data words into a device having (n) different memory locations, by transferring a p-bit data word including one bit from each of the first group of (p) n-bit data words into a first portion of each of the (n) different memory locations. The method further includes the steps of receiving a second group of (p) n-bit data words, storing the second group of (p) data words in the first storage bank, and transferring the second group of (p) data words into the memory device by transferring a p-bit data word including one bit from each of the second group of (p) n-bit data words into a second portion of each of the (n) different memory locations. Optionally, the second group of (p) n-bit data words are stored in and transferred from a second storage bank. In a particular method, the step of storing a group of (p) data words in a storage bank is performed by shifting the (p) data words into the storage bank along a first direction, (n) bits at a time, and the step of transferring the group of data words into the device comprising (n) different memory locations is performed by shifting the (p) data words out of the storage bank along a second direction, (p) bits at a time. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 shows a single pixel cell of a typical liquid crystal display; FIG. 2 shows one frame of 4-bit pulse- width modulation data; FIG. 3 shows a split frame of 4-bit pulse-width modulation data; FIG. 4 shows a brightness versus RMS voltage curve for a typical liquid crystal cell; FIG. 5 shows a gray scale value versus RMS voltage curve; FIG. 6 shows a split frame of pulse-width modulation data including additional forced on and forced off states, in accordance with the present invention; FIG. 7 shows a gray scale value versus RMS voltage curve, as modified by the addition of forced on and forced off states in accordance with the present invention; FIG. 8 shows a display driver in accordance with the present invention; FIG. 9 illustrates a data path through a data planarizer and a frame buffer in accordance with the present invention; FIG. 10 shows a bi-directional shift register of the data planarizer shown in FIG. 9; FIG. 1 1 shows a forced state controller of the driver shown in FIG. 8; FIG. 12 shows a timing diagram for data and certain control signals communicated between the driver and the uLCD shown in FIG. 8. DETAILED DESCRIPTION This patent application is related to the following co-pending U.S. patent applications, filed on even date herewith and assigned to a common assignee, each of which is incorporated herein by reference in its entirety: De-Centered Lens Group For Use In An Off-Axis Projector, U.S. Serial No. 08/970,887, Matthew F. Bone and Donald Griffin. Koch; System And Method For Reducing Peak Current And Bandwidth Requirements In A Display Driver Circuit, U.S. Serial No. 08/970,665, Raymond Pinkham, W. Spencer Worley, III, Edwin Lyle Hudson, and John Gray Campbell; System And Method For Using Forced State To Improve Gray Scale Performance Of A Display, U.S. Serial No. 08/970,878, W. Spencer Worley, III and Raymond Pinkham; and Internal Row Sequencer For Reducing Bandwidth And Peak Current Requirements In A Display Driver Circuit, U.S. Serial No. 08/970,443, Raymond Pinkham, W. Spencer Worley, III, Edwin Lyle Hudson, and John Gray Campbell. This patent application is also related to co-pending U.S. patent application U.S. Serial No. 08/901,059, entitled Replacing Defective Circuit Elements By Column And Row Shifting In A Flat Panel Display, by Raymond Pinkham, filed July 25, 1997, assigned to a common assignee, and is incorporated herein by reference in its entirety. The present invention overcomes the problems associated with the prior art, by confining the gray scale values to the useful portion of the liquid crystal response curve, without the use of additional data bits. Specifically, the present invention describes a system and method for planarizing n-bit data words, corresponding to a particular pixel, into m-bit, planarized data words, corresponding to a group of m pixels. In the following description, numerous specific details are set forth (e.g., the bit-width of the gray scale code and the bit width of the planarized data) in order to provide a thorough understanding of the invention. Those skilled in the art will recognize, however, that the invention may be practiced apart from these specific details. In other instances, details of well known display circuits and driving methods have been omitted, so as not to unnecessarily obscure the present invention. As shown in FIG. 6, additional forced "on" states 602 and additional forced "off states 604 are added to the PWM data 606 during the first half 608 of the frame time 610, to produce a modified display data stream. The extra "on" states 602 and "off states 604 correspond to extra time intervals in frame time 610, which are added in one of two different ways. In the first way, the time intervals of the PWM data 606 are shortened to make room for the additional states, without increasing the frame time. Alternatively, the frame time may be increased to make room for the new states, without changing the length of the individual time intervals of the PWM data. During the first half of the frame time, the common electrode of a driven liquid crystal cell (not shown) is held low (0V). In the second half 612 of frame time 610, however, the common electrode is held at 5V, and the PWM data as well as the added "on" and "off states are inverted. This inversion is necessary to maintain a net DC voltage of 0 V across the driven cell, and thus avoid degradation of the cell. Note that in FIG. 6, the forced on states 602 and forced off states 604 are added to the display data 606 contiguously (i.e., sequentially in a single block of time intervals). This advantageously reduces the number of times the signal to the display must be switched. Those skilled in the art will recognize, however, that the forced states may be intermingled amongst themselves, or with the display data,, as long as the resultant RMS voltage is not altered. FIG. 7 shows the effect of the added forced states on the gray scale value versus RMS voltage curve. Taking the added forced states into account, the modified RMS value is given by: (ForcedOn + Gray Value)( Von) 2 ,--, _ λ Vrms = , (Eq. 2) (255 + ForcedOn + ForcedOff) The added "on" states create a minimum RMS voltage floor 702, and the added "off states create a maximum RMS voltage ceiling 704. RMS voltage floor 702 is raised and lowered by increasing or decreasing the number of additional "on" states, respectively. Similarly, RMS voltage ceiling 704 is lowered or raised by increasing or decreasing the number of additional "off states, respectively. The number of added "on" and "off states is selected such that RMS voltage floor 702 is equal to Vtt, the RMS voltage corresponding to 0% brightness (FIG. 4), and RMS voltage ceiling 704 is equal to Vsat, the RMS voltage corresponding to 100% brightness. The optimum number of extra "on" and "off states may be determined mathematically, using the following variables: n = the number of bits of gray scale resolution; G = the gray scale value; Von = the digital "on" voltage; Voff = the digital "off voltage; Vtt = the liquid crystal minimum brightness RMS voltage; Vsat = the liquid crystal saturation RMS voltage; Fon = the optimum number of fixed "on" states; and Foff = the optimum number of fixed "off states. In general, the modified RMS voltage ("Vrms") is given by: Vm. - < 0 + F °°) < V °")' (BC.. 3) (2 n - 1) + Fon + Foff It is desirous that Vrms = Vtt, at G = 0. Substituting theses values into Eq. 3 yields: Fon(Von)' Vtt = (Eq. 4) (2 n - 1) + Fon + Foff Similarly, it is desirous that Vrms = Vsat, at G = 2n - 1. Substituting these values into Eq. 3 yields: Fon(Von) 2 Vtt = (Eq. 5) (2 n - 1) + Fon + Foff Solving Eq. 4 for Foff yields: Foff - Fθn(V ° 2 n)2 - Fon -(2" - l) (Eq. 6) (Vtt) 2 Substituting Eq. 6 into Eq. 5, and solving for Fon yields: (2" - l) (Vtt) 2 Fon = (Eq. 7) (Vsat) 2 - (Vtt) 2 Substituting Eq. 7 into Eq. 6, and solving for Foff yields: ((Von) 2 - (Vtt) 2 ) Foff = (2 n - 1) - 1 (Eq. 8) ((Vsat) 2 - (Vtt) 2 ) Finally, for given values of n, Vtt, Vsat, and Von, the optimum numbers of added "on" and "off states are calculated from Eq. 7 and Eq. 8, respectively. As indicated above, the required numbers of forced "on" and forced "off states can be determined empirically, by iterating Fon and Foff until a gray value of 0 results in an RMS value near Vtt, and a gray value of 2n-l results in an RMS value near Vsat. In one particular system, where n=8, Vtt=1.5V, Vsat=3.0V, and Vdd=3.3V, the iterating process yielded the following results: normal PWM states: 255 fixed "on" states: 86 fixed "off states: 82 total states: 423 % increase in states 66% Note that this number may differ from the calculated optimum number of forced states, and still provide an adequately modified LCD data stream. Clearly, the overhead for the addition of extra states (66%) is significantly less that the overhead required to adding a single bit to the gray scale code (100%)), and extremely less than adding two additional bits (200%). Furthermore, because the voltages of the forced "on" and "off states are known, the forced states can be written to the pixel storage electrode apart from receiving the LCD gray scale data stream, thus reducing the bandwidth requirements for the system interface. FIG. 8 shows an LCD driver 800 in accordance with the present invention. Driver 800 includes input controller 802, control selector 804, data planarizer 806, frame buffer A 808, frame buffer B 810, phase locked loop 812, and forced state generator 814. Driver 800 receives an 8-bit gray scale display data stream via data input bus 816, and receives horizontal synchronization (Hsync), vertical synchronization (Vsync), and pixel dot clock signals via input terminals 818, 820, and 822, respectively. After inserting forced states into the display data stream to improve gray scale performance, driver 800 transfers the modified display data, via 32- bit data output bus 824, along with control signals, via LCD control bus 826, to a micro-LCD 828, which includes an array of liquid crystal pixel cells, similar to the pixel cell shown in FIG.l. Input controller 802 uses the Hsync and Vsync signals to coordinate the transfer of data from data input bus 816 into data planarizer 806 and the transfer of data from data planarizer 806, via 32- bit data bus 830 into frame buffers A 808 and B 810. Responsive to the Vsync and Hsync signals indicating valid data on data input bus 816, input controller 802 asserts signals on control lines DIR 832 and CLK 834, causing data to be clocked into and out of data planarizer 806, as will be more fully described in conjunction with FIG. 10 below. Data planarizer 806 receives the gray scale data, via data input bus 816, in 8-bit data words, each 8-bits (Pm[0-7]) corresponding to a gray scale value to be written to a particular pixel (m) of micro-LCD 828. Data planarizer 806 accumulates the 8-bit gray scale data for 32 pixels and reformats the data into 32-bit data words, each 32-bit word containing one bit from each of the group of 32 8-bit gray scale data words. For example, the 32-bit word formed by bits P0[0] - P31 [0] includes the least significant bits of the gray scale values of pixels 0-31. This reformatting is necessary because each bit of gray scale data is written to micro-LCD 828 32 pixels at a time. The reformatting of data by data planarizer 806 is discussed in greater detail in conjunction with FIG. 9 below. Frame buffer A 808 and frame buffer B 810 are each 32-bit wide synchronous graphics random access memories (SGRAMs). Each of frame buffers 808 and 810 receives data, via 32- bit data bus 830, and stores the data in a memory location associated with a particular bit significance and a particular group of pixels of micro-LCD 828. Further, each of frame buffers 808 and 810 are of sufficient capacity to store 8 bits of gray scale data for each pixel in micro- LCD 828 (i.e., one frame worth of display data). For example, because micro-LCD 828 has 786,432 pixels (1024 X 768), frame buffers 808 and 810 each store 6,291,456 bits (one display screen worth) of data, or 196,608 32-bit words. The transfer of data from data bus 830 into frame buffers 808 and 810 is also controlled by input controller 802 in cooperation with control selector 804. Input controller 802 asserts frame buffer control signals on input control bus 836 and a frame buffer select signal on select (SEL) line 838. Input control bus 836 includes a write enable line and address lines for indicating the memory location into which data is to be written. Control selector 804 includes a first multiplexer 840 and a second multiplexer 842. First multiplexer 840 has two sets of input terminals, the first set being coupled to the lines of input control bus 836. Second multiplexer 842 also has two sets of input terminals, the second set being coupled to the lines of input control bus 836. The output of first multiplexer 840 is asserted on frame buffer A control bus 844, and the output of second multiplexer 842 is asserted on frame buffer B control bus 846. First multiplexer 840 and second multiplexer 842 are both controlled by the SEL signal being asserted on select line 838 by input controller 802. Responsive to a first (e.g. high) SEL signal being asserted on select line 838, first multiplexer 840 couples input control bus 836 with frame buffer A control bus 844, thus allowing input controller 802 to load data from data bus 830 into frame buffer A 808. The first SEL signal also causes second multiplexer 842 to decouple input control bus 836 from frame buffer B control bus 846, so that no data is loaded into frame buffer B 810 while frame buffer A is being loaded. Responsive to a second (e.g., low) SEL signal being asserted on select line 838, first multiplexer decouples input control bus 836 from frame buffer A control bus 844 and couples input control bus 836 with frame buffer B control bus 846, thus allowing input controller 802 to load data from data bus 830 into frame buffer B 810. Input controller 802 toggles the SEL signal each time a Vsync signal is received, such that one display screen worth of data is written into each frame buffer 808 and 810 in alternating order. Forced state generator 814 controls the output of data from frame buffer A 808 and frame buffer B 810, receives the display data via data bus 848, selectively inserts forced states into the display data stream, and outputs the modified display data stream via data output bus 824 to micro-LCD 828. Forced state generator 814 includes a forced state controller 850 and a multiplexer 852. Multiplexer 852 receives data from data bus 848, from 32-bit "force-on" bus 854, and from 32-bit "force-off bus 856. Each line of force-on bus 854 is maintained at a voltage (Von) corresponding to an "on" state, and each line of force-off bus 856 is maintained at a voltage (Voff) corresponding to an "off state. In one embodiment, the sources of the forced state data asserted on force-on bus 854 and force-off bus 856 are system voltage reference terminals (e.g., Vdd and Ground). Those skilled in the art will understand, however, that alternate sources of forced state data, for example registers, may be employed. Responsive to control signals received via 2-bit control bus 858, multiplexer 852 selectively couples either data bus 848, force- on bus 854, or force-off bus 856 to data output bus 824. As used herein, the term "multiplexer" is understood to include all selective coupling devices, including, but not limited to, shared bus structures. Forced state controller 850 receives the Vsync signal via line 860, and receives a clock input signal via line 862 from phase-locked loop 812. Phase-locked loop 812 is well known in the art, and serves to synchronize the pixel dot clock with an internal machine clock (not shown). Forced state controller 850 controls the output of data from frame buffer A 808 and frame buffer B 810 by asserting control signals on an output control bus 864, which is coupled to the second set of input terminals of first multiplexer 840 and to the first set of input terminals of second multiplexer 842. Thus, when the second SEL signal is asserted on select line 838 by input controller 802, first multiplexer 840 decouples input control bus 836 from and couples output control bus 864 to frame buffer A control bus 844, thus allowing forced state controller 850 to cause frame buffer A 808 to assert data onto data bus 848. On the other hand, when the first SEL signal is asserted on select line 838, second multiplexer 842 decouples input control bus 836 from and couples output control bus 864 to frame buffer B control bus 846, allowing forced state controller 850 to cause frame buffer B 810 to assert data onto data bus 848. Thus, while pixel data for one frame is being loaded into frame buffer A 808 by input controller 802, pixel data for the previous frame is being outputted from frame buffer B 810 by forced state controller 850, and vice versa. Forced state generator 814 inserts forced states (as shown in FIG. 6) into the display data stream as follows. First, a Vsync signal on line 860 indicates the start of a frame. Forced state controller 850 asserts a first control signal on 2-bit control bus 858, causing multiplexer 852 to couple force-on bus 854 to data output bus 824, thus asserting forced "on" states on data output bus 824. Then, forced state controller 850 asserts control signals on LCD control bus 826 causing forced on states to be loaded from data output bus 824 into micro-LCD 828. After the desired number of forced on states are loaded into micro-LCD 828, forced state controller 850 asserts a second control signal on 2-bit control bus 858, causing multiplexer 852 to couple data bus 848 to data output bus 824. Then, forced state controller 850 asserts frame buffer control signals on output control bus 864 and LCD control signals on LCD control bus 826, causing data to be transferred out of either frame buffer A 808 or frame buffer B 810 (depending on the current SEL signal), through multiplexer 852, and into micro-LCD 828. Data continues to be transferred from frame buffer A 808 or B 810 until an entire frame of display data has been transferred. Then, forced state controller 850 asserts a third control signal on 2-bit data bus 858, causing multiplexer 852 to couple force-off bus 856 to data output bus 824, and asserts LCD control signals on LCD control bus 826 causing the desired number of forced off states to be transferred into micro-LCD 828, thus completing the first half 608 of frame 610 (FIG. 6). The second half 612 of frame 610 (FIG. 6) is written to micro-LCD 828 substantially as described above, except that the forced on states, the data, the forced off states, and the common electrode are inverted. The inversion occurs within micro-LCD 828 under the control of forced state controller 850 as follows. LCD control bus 826 includes address lines, op code lines for communicating instructions (e.g., read, write, etc.), a data invert line, a common electrode signal line, and a clock signal line. At the beginning of the second half 612 of frame 610, forced state controller 850 switches the signal being asserted on the common electrode signal line from low to high, and asserts a control signal on the invert line causing micro-LCD 828 to invert all incoming data. The data and the forced states are then transferred out of driver 800 under the control of forced state controller 850 as described above. Alternatively, the inversion of the forced on states, the data, and the forced off states may be implemented within driver 800. For example, FIG. 8a shows an alternate embodiment of controller 800, including a selective inverter 870 interposed between data bus 848 and data input terminals 872 of multiplexer 852, to selectively invert the data stream. The invert line 874 is redirected from LCD control bus 826 to selective inverter 870. Responsive to a first signal on invert line 874, selective inverter 870 asserts the data received via data bus 848 onto data input terminals 872 of multiplexer 852. Responsive to an invert signal on invert line 874, selective inverter 870 inverts the data received via data bus 848, and asserts the inverted data onto data input terminals 872 of multiplexer 852. In this embodiment, forced state controller 850 controls the inversion of the forced on and forced off states, by controlling multiplexer 852 as described above, but reversing temporally, the couplings of bus 854 and bus 856 to bus 824. FIG. 8b shows another alternate embodiment of driver 800, wherein selective inverter 870 is coupled to receive and selectively invert the modified data stream, which includes the forced states. FIG. 9 shows an example of data flow through data planarizer 806 and into frame buffer A 808. Data planarizer 806 includes a first bi-directional shift register 902 and a second bidirectional shift register 904, each serving as a temporary storage bank. Each register 902 and 904 is 16 bits deep (16 columns) and 8 bits wide (8 rows). The bit depth corresponds to the number of incoming data words each register has the capacity to store, and the bit-width corresponds to the number of bits in each incoming data word, which in this particular embodiment is the number of bits per pixel. Data enters shift registers 902 and 904 via 8-bit data input bus 816, as previously described, and is organized within registers 902 and 904 as follows. First, the 8 bits of gray scale data for pixel 0 (P0[0-7]) enter, via data input bus 816, and are stored in the right most column of register 902. The next 8-bits PI [0-7] enter and are stored in the column to the left of bits P0[0-7]. The data continues to be loaded in this fashion until the bits P15[0-7] are loaded in the left most column of register 902. The 8-bit gray scale data for pixels PI 6 - P31 is then loaded into register 904 in like fashion, such that bits P16[0-7] are loaded in the right most column and bits P31 [0-7] are loaded in the left most column. Thus loaded, each row of register 902 and register 904 contains a 16-bit word, including one bit of similar significance from 16 sequential pixels. For example, the bottom row of register 904 includes the least significant bits from the gray scale data for pixels P16-P31. Furthermore, like numbered rows of registers 902 and 904 combine to form 32-bit words, each including one bit of similar significance from 32 sequential pixels. For example, the top rows of registers 902 and 904 include the most significant bits from the gray scale data for pixels POPS 1. These 32-bit words are written, via data bus 830, into frame buffers A 808 and B 810, to be stored for subsequent transfer to micro-LCD 828. Frame buffers A 808 and B 810 are able to read one-half of data bus 830 at a time. Additionally, an inverter 907, having an input terminal coupled to direction control line 832, provides register 902 with an inverted direction control signal. This allows planarizer 806 to write the contents of register 902 to frame buffer A 808 or frame buffer B 810 while register 904 is being loaded. For example, as data is being clocked into register 904 via data input bus 816, data is being clocked out of register 902 via a first half 906 of data bus 830. Similarly, when data is being clocked into register 902 via data input bus 816, data is being clocked out of register 904 via a second half 908 of data bus 830. Accordingly, a frame worth of data is formatted by data planarizer 806 and stored in either frame buffer A 808 or B 810 as follows. Each memory location in frame buffers A 808 and B 810 is divided into a first half 910 and a second half 912. The gray scale data for pixels P0-P15 is clocked into register 902, as described above. Then, as the next block of data for pixels P16-P31 is clocked into register 904, the data for pixels P0-P15 is clocked into first half 910 of a first memory block 914 (each block contains 8 32-bit memory locations). Next, as the data for pixels P32-P47 is clocked into register 902, the data for pixels P16-P31 is clocked into second half 912 of first memory block 914. Then, as the data for pixels P48-P63 is clocked into register 904, the data for pixels P32-P47 is clocked into first half 910 of a second memory block 916. This sequence continues until the data for the last pixels (P786,416-P786,431) is clocked from register 904 into second half 912 of a last memory block 918. Because registers 902 and 904 are able to planarize the data for groups of less than 32 pixels, data planarizer 806 need not receive an entire frame worth of data before the data can be output in its planarized form. Additionally, registers 902 and 904 are smaller and less expensive than the RAM employed in the prior art. Furthermore, those skilled in the art will recognize that additional bi-directional shift registers may be employed. For example, four registers, each 8- bits deep, could be used to write 8 bits to each of four different portions of each memory location, thus writing a 32-bit word to each memory location. Fig. 10 shows first bi-directional shift register 902 in greater detail. Second bidirectional shift register 904 is substantially identical. Register 902 includes 128 D-type flip- flops 1002 arranged in a rectangular array of 16 columns (0-15) and 8 rows (0-7), and an associated array of multiplexers 1004 also arranged in a rectangular array of 16 columns and 8 rows. To facilitate clear explanation, the notation (r,c) refers to the row and column location of a given device. For example, multiplexer 1004(6,14) refers to the multiplexer 1004 located in row 6 and column 14. The rows and columns are labeled in FIG. 10 to correspond to the bit numbers of data input bus 816 and first half 906 of data bus 830, respectively. All flip-flops 1002(r,c) receive a clock signal from input controller 802 (FIG. 8) via CLK line 834, and all the multiplexers 1004(r,c) receive control input from input controller 802 via DIR line 832. The input (D) of each flip-flop 1002(r,c) is coupled to the output of an associated multiplexer 1004(r,c) located in the same row and column. Each multiplexer 1004(r,c) has a first input terminal 1006 and a second input terminal 1008, which are selectively coupled to the input (D) of associated flip-flop 1002(r,c), depending on the control signal being asserted on DIR line 832. First input terminals 1006 of multiplexers 1004(r,15) (column 15) are coupled to associated bit lines of data input bus 816. In the remaining columns (c<15), first input terminals 1006 of multiplexers 1004(r,c) are coupled to the non-inverting output (Q) of associated flip-flops 1002(r,c+l) (left neighbors). Second input terminals 1008 of multiplexers 1004(7,c) (row 7) are not used. In the remaining rows (r<7), second input terminals 1008 of multiplexers 1004(r,c) are coupled to the non-inverting output (Q) of associated flip-flops 1002(r+l,c) (upper neighbors). Finally, the non-inverting (Q) output of flip-flops 1002(0,c) (row 0) are coupled to corresponding bit lines of first half 906 of data bus 830. Bi-directional shift register 902 operates as follows. When input controller 802 asserts a first signal on DIR control line 832, all multiplexers 1004(r,c) couple their first input terminals 1006 with the inputs (D) of flip-flops 1002(r,c). Then, when the first clock signal is received via CLK line 834, flip-flops 1002(r,15) latch the 8-bit data word present on data input bus 816 onto their non-inverting (Q) outputs. When the next clock signal is received, the first 8-bit word stored by flip-flops 1002(r,15) is shifted to the non-inverting outputs (Q) of flip-flops 1002(r,14), and flip-flops 1002(r,15) latch the next 8-bit data word present on data input bus 816 onto their non-inverting (Q) outputs. Upon receiving each subsequent clock signal, new data is received and the previously received data is shifted to the right. This continues until register 902 has loaded 16 8-bit words (one on each column of flip-flops). Input controller 802 shifts data out of register 902 by asserting a second signal on DIR line 832. Responsive to the second signal on DIR line 832, each multiplexer couples its second input terminal with its output terminal, thus changing the shift direction. Until the next clock signal is received, flip-flops 1002(0,c) are asserting bit 0 of each of the 16 stored 8-bit words on bit lines 0-15 of bus 906. When the next clock signal is received, the bit stored on the non- inverting outputs (Q) of each flip-flop 1002(r,c) is latched onto the non-inverting output of flip- flop 1002(r-l,c) (lower neighbor), thus asserting bit 1 of each of the 16 stored 8-bit words on bit lines 0-15 of bus 906. This process continues as each clock signal is received until all 8 bits (0- 7) of each of the 16 stored words have been sequentially asserted on bus 906. After register 904 is loaded (it takes longer to load than to unload registers 902 and 904, i.e., 16 cycles versus 8 cycles), input controller 802 reasserts the first signal on DIR line 832 so that register 902 can be reloaded. FIG. 11 shows forced state controller 850, in greater detail, to include a memory 1102, a processing unit 1104, a prescale 1106, and a transfer state machine 1108. Memory 1102 is a program storage device, which stores data and commands for access and execution by processing unit 1104. Prescale 1106 receives the dot clock signal via line 862, generates a lower frequency timing signal (e.g., 1/2 the frequency of the dot clock), and communicates the timing signal, via line 1110 to processing unit 1104. The lower frequency timing signal enables processing unit 1104 to employ smaller scale components, for example, smaller counters. Processing unit 1104 controls transfer state machine 1108 via a transfer request line 1112, transfer select bus 1114, force-on line 1116, and force-off line 1118. Responsive to the signals received from processing unit 1104, transfer state machine 1108 asserts control signals on LCD control bus 826 (FIG. 8), 2-bit control bus 858, and output control bus 864, as follows. Responsive to a signal on transfer request line 1112, transfer state machine 1108 asserts a control signal on 2-bit control bus 858 causing multiplexer 852 to couple data output bus 824, via data bus 848, to frame buffers A 808 and B 810. Transfer select line 1114 is a multi-bit line used to communicate the address of the memory block to be transferred out of frame buffer A 808 or frame buffer B 810. Transfer state machine 1108 uses the block address to initialize the memory address asserted on output control bus 864, and then sequentially increments the memory address while asserting a write signal on LCD control bus 826. Responsive to processing unit 1104 asserting a signal on force-on line 1116, transfer state machine 1108 asserts a signal on 2-bit control bus 858, causing multiplexer 852 to couple force-on bus 854 with data output bus 824. Then, transfer state machine 1108 asserts a write signal on LCD control bus 826, thus transferring forced on states into micro-LCD 828. Similarly, responsive to processing unit 1104 asserting a signal on force-of line 1118, transfer state machine 1108 asserts a signal on 2-bit control bus 858, causing data selector 852 to couple force-off bus 856 with data output bus 824, and asserts a write signal on LCD control bus 826, to transfer forced off states into micro-LCD 828. In one embodiment, forced state controller 850 is implemented with a programmable logic device part number EPF10K50 BC356-3, manufactured by Altera Corporation of Santa Clara, California. The verilog code for programming this device is provided at the end of this disclosure. FIG. 12 shows a timing diagram 1200 detailing the relationship, during one frame time 1201, between the Vsync signal 1202, the common micro-LCD electrode signal 1204, the data invert signal 1206, the pixel data 1208, the first pixel value 1210, the last pixel value 1212, the magnitude and direction of the voltage drop across the first pixel 1214, and the magnitude and direction of the voltage drop across the last pixel 1216. Timing diagram 1200 is useful to illustrate practical considerations which must be taken into account when implementing driver 800. Recall from the discussion of FIG. 3 that the net dc voltage over time across each liquid crystal cell must be zero, in order to avoid damage to the cell caused by ionic migration. Therefore, the common signal 1204 and the pixel data 1208 are inverted during a first half 1218 of frame 1201 and are not inverted during a second half 1220 of frame 1201. It does not matter whether the common signal 1204 and the data 1206 are inverted during the first 1218 or second 1220 half of frame 1201, as long as the net dc voltage across each cell is zero. Practical limitations arise because, while the single common electrode signal may be switched very rapidly at the mid point 1222 of frame 1201, it takes some finite amount of time (X) to write the first bit of LCD data to each of the pixels in micro-LCD display 828, as shown by the angled edges of micro-LCD data curve 1208. It is, therefore, desirable to switch the common electrode signal at a time when a forced on or a forced off state is being asserted on every pixel. This results in a very rapid, simultaneous switch of the signals on all of the pixels. Specifically, all forced on states become forced off states, and all forced off states become forced on states, as soon as the common electrode is switched. The time (X) that it takes to write data to all the pixels also effects the writing of forced states. Comparing first pixel value curve 1210 to last pixel value curve 1212, it is apparent that there is a time delay (X) between writing the first forced on state to the first pixel at 1224 and writing the first forced on state to the last pixel at 1226. In general, this delay is offset, because of the time delay (X) between writing data to the first pixel at 1228 and writing data to the last pixel at 1230. There must be, however, an adequate number of forced states to accommodate the offset. In particular, it is sufficient if the minimum forced-on time and the minimum forced-off time equals 2X, where X is the time required to write to each pixel once, as described above. Certain timing relationships are also necessary to maintain equal brightness across the display and to maintain a debiased (net dc voltage = 0) condition. The following timing relationships are sufficient, and refer to the voltage drops labeled in voltage drop magnitude/direction curves 1214 and 1216. First, in order to debias the first pixel, voltage drops A and B must be equal in magnitude and opposite in direction to voltage drop C, while the sum of the time intervals that voltage drops A and B are applied must equal the time interval voltage drop C is applied. Similarly, voltage drops D and E must be equal in magnitude and opposite in direction to voltage drop F, while the sum of the time intervals that voltage drops D and E are applied must equal the time interval voltage drop F is applied. The pixel data (Pixel Data) is, by definition, equal in magnitude and opposite in direction to the complementary pixel data (! Pixel Data). Next, in order to maintain equal brightness (RMS voltage offset), the sum of voltage drops A and B must be equal in magnitude and direction to the sum of voltage drops D and E, and voltage drop C must be equal in magnitude and direction to voltage drop F. Finally, the first half 1218 of frame 1201 should be equal in time duration to the second half 1220 of frame 1201. Those skilled in the art will understand, that the sequence of data and forced states, the division of the frame, and the switching of the common electrode may be altered without deviating from the scope of the invention, however the fundamental debias and RMS voltage offset conditions must be maintained. The above described timing diagram 1200 illustrates only one of many possible ways of accomplishing this. The description of particular embodiments of the present invention is now complete. Many of the described features may be substituted, altered or omitted without departing from the scope of the invention. For example, the invention may be used in a multi-color system by using a separate driver and display for each color, or by time multiplexing a single driver and display for more than one color. Additionally, the invention may employed with a wide variety of pulse modulation schemes including, but not limited to, pulse-amplitude modulation, pulse-width modulation, pulse-position modulation, and pulse-code modulation. Further, data planarizer 806 may include additional, smaller bi-directional shift registers to enable data reformatting in even smaller increments. VERILOG CODE / fileindata.v // target device Altera 1 OKxO // Copyright 1997 sVISION Inc. // Revision history // 6/10/97 in progress module format (reset_l, elk, pClk, red, green, blue, hSync, vSync, dEn, vAddr, vData, ras_l, cas_l, dsf, we_l, sc, dtoe, se_l, overlay, qsf, redOut, greenOut, blueOut, vSyncOut, valid, uAddr, uData, uWr l, uRd_l, memCS , ioCS , ale, ready); // Module I/O Definitions input elk; // 40 MHz clock from CPU // Inputs from gmZl input reset_l; input pClk; //pixel clock input [7:0] red; //red data from gmZl input [7:0] green; //green data from gmZl input [7:0] blue; / blue data from gmZl input hSync; //horizontal Sync from gmZl input vSync; //vertical sync from gmZl input dEn; //data enable from gmZl //VRAM signals output [8:0] vAddr; //VRAM address inout [15:0] vData; // RAM data output ras_l; //RAS output [1 :0] cas_l; //CAS (one for each bank) output dsf; //DSF output [1 :0] dtoe; //DT/OE output [1 :0] we_l; //Write Enables (High and low bytes) output [1 :0] sc; //serial clock (one for each bank) output [1 :0] se_l; //serial port output enables input [15:0] overlay; //serial data (used for overlay planes) input [1 :0] qsf; //serial ports status //microprocessor signals inout [7:0] uData; //uP data and address buss input uWr_l; //uP write strobe input uRd_l; //uP read strobe input [7:0] uAddr; //uP Address lines [15:8] input ioCS ; //cs for IO cycle input memCS_l; lies for memory (VRAM) access input ale; //address latch strobe output ready; //cycle end for uP //pixel output s output [7:0] redOut; //red pixel output output [7:0] greenOut; //green pixel output output [7:0] blueOut; //blue pixel output output vSyncOut; output valid; //Register definitions reg [7:0] redAddr; reg [7:0] greenAddr; reg [7:0] blueAddr; wire [7:0] redLUT; wire [7:0] blueLUT; wire [7:0] greenLUT; reg [7:0] redLUTout; reg [7:0] blueLUTout; reg [7:0] greenLUTout; reg [7:0] redOut; reg [7:0] greenOut; reg [7:0] blueOut; reg [7:0] redln; reg [7:0] greenln; reg [7:0] blueln; reg [7:0] redDl; reg [7:0] greenDl; reg [7:0] blueDl; reg [7:0] redDO; reg [7:0] greenDO; reg [7:0] blueDO reg [7:0] redDO 1 reg [7:0] redD02 reg [7:0] redD03 reg [7:0] redD04 reg [7:0] redD05 reg [7:0] redD06 reg [7:0] greenDO 1 ; reg [7:0] greenD02; reg [7:0] greenD03; reg [7:0] greenD04; reg [7:0] greenD05; reg [7:0] greenD06; reg [7:0] blueDO 1 reg [7:0] blueD02 reg [7:0] blueD03 reg [7:0] blueD04 reg [7:0] blueD05 reg [7:0] blueDOό reg [7:0] redOverlay; reg [7:0] greenOverlay; reg [7:0] blueOverlay; reg vSyncIn; reg vSyncInDl; reg hSyncIn; reg hSyndnDl; reg vSyncOut; reg vSyncl; reg hSyncl; reg dataValid; reg qsfDl; reg qsfD2; reg qsfD3; reg sClk; reg invert; reg useOverlay; reg enOverlay; reg wrRedLUT; reg wrGreenLUT; reg wrBlueLUT; reg [ . 15:0] overlayln; reg [7:0] olData; reg wrOverlay; reg [7:0] addrReg; //SW wire : [7:0] uDataIn = uData; reg [7:0] uDataOut; reg weRed; reg weGreen; reg weBlue; reg [1 :0] control; reg [1 :0] wrMode; reg [4:0] overlay Ctl; reg [3:0] outputCtl; reg [3:0] memPage; reg [6:0] blankLine; reg [3:0] outputCntl; reg [7:0] testRed; reg [7:0] testGreen; reg [7:0] testBlue; reg [7:0] readReg; reg [7:0] readLUT; reg [7:0] readOvly; reg [11 :0] hCount; reg [10:0] vCount; reg hSyncInt; reg vSyncInt; reg hValid; reg vValid; reg hSyncReal; reg vSyncReal, validReal; reg qsfMask; //These are all reged in the vram model //reg memDone; //reg cycleType; // 0 is uP access 1 is Xfer access reg [8:0] xferAddr; reg readyOut; wire endCycle; reg wrIOReq, rdlOReq, wrMemReq, rdMemReq; reg ioReq, ioReqDl, ioReqD2, ioReqD3, ioReqXl, ioReqX2, ioReqX3; reg memReq, memReqXl; reg redLUTReq, greenLUTReq, blueLUTReq; reg redOvlyReq, greenOvlyReq, blueOvlyReq; reg readReqLUT, readReqOvly; reg [7:0] redDx; reg [7:0] greenDx; reg [7:0] blueDx; reg colorDone, colorReq; reg vSyncMemD 1 , vSyncMemD2, vSyncMemD3 ; reg sClkL, sClkH, useLowVram, sClkD 1 , sClkD2, sClklnt; reg [7:0] olDataDl; reg [7:0] olDataD2 reg [7:0] olDataD3 reg [7:0] olRedAddr, olGreenAddr, olBlueAddr; reg useOverlayD 1 , useOverlayD2, useOverlayD3 ; reg splitReq, fullReq; reg weOverRed, weOverGreen, weOverBlue; reg [1 :0] sc; reg uPcolorReq, uPcbrReq, cbrReqXl , cbrReq, colorReqXl ; reg blockReq, blockReqX 1 ,uPblockReq ; reg [6:0] validDelay; reg ollnv; reg valid, blankData; reg armStartBlank, waitForLast, armLastBlank, goBlank, endBlank; reg freezeDl, freezeD2, freezeOut; //wires SW wire vramRdReq; //The pipelined request and uRd_l wire vramWrReq; //The pipelined request and uWr_l wire [7:0] memRdData; //output from vramsm //sw wire [7:0] overRed; wire [7:0] overGreen; wire [7:0] overBlue; //Real Code Start define CHIP ID 0 //SW 7-22 assign uData = (!uRd_l && (ϋoCS || ImemCS )) ? uDataOut : 8'bz; assign ready = (IreadyOut) ? I'bO : l'bz; // // uP interface // always @ (negedge ale) begin addrReg[7:0] <= #4 uData; end // always always @ (posedge uWr_l or negedge reset_l) begin if (!reset_l) begin control <= 2'bO; wrMode <= 2'bl l; overlayCtl <= 5'bO; outputCtl<=4'blllO; blankLine <= 7'bO; end // if else if (ϋoCS ) begin //SW if (uAddr[2:0] = 3'bl 11) begin case (addrReg[3:0]) 4'hl : control <= #4 uData[ 1:0]; 4'h2: memPage <= #4 uData[3 :0]; 4'h3: wrMode<=#4uData[l:0]; 4'h4: blankLine <= #4 uData[6:0]; 4'h5: overlayCtl<=#4uData[4:0]; 4'h6: outputCtl <= #4 uData[3 :0]; 4'h7: testRed <= #4 uData; 4 * h8: testGreen <= #4 uData; 4'h9: testBlue <= #4 uData; endcase end // if end // else end // always //Ready low for overlay VRAM and LUT always @ (negedge uRd_l or negedge uWr l or posedge endCycle) begin if (endCycle) readyOut<= I'M; else if (!memCS_l || (ϋoCSJ && (uAddr[2:0] != 3'blll))) readyOut<= I'bO; end // always //End Cycle //sw assign endCycle = clrMemReq || clrlOReq; //Generate requests always @ (negedge uWr_l or posedge clrlOReq) begin if (clrlOReq) begin wrIOReq <= #4 1'bO; end // if else begin if (ϋoCS ) wrIOReq <= (uAddr[2:0] != 3'bl 11); end// else end // always always @ (negedge uRd_l or posedge clrlOReq) begin if (clrlOReq) begin rdIOReq <= #4 1'bO; end // if else begin if(ϋoCS ) rdlOReq <= (uAddr[2:0] != 3'b000 && uAddr[2:0] != 3'bl l l); end// else end // always //generate VRAM req always @ (posedge clrMemReq or negedge uWr_l) begin if (clrMemReq) wrMemReq <= #4 I'bO; //SW added else else if (!memCS_l) wrMemReq <= #4 l'bl; end // always always @ (posedge clrMemReq or negedge uRd_l) begin if (clrMemReq) rdMemReq <= #4 I'bO; //SW added else else if (!memCS_l) rdMemReq <= #4 1'bl; end // always //uPcolor always @ (posedge clrMemReq or negedge uWr_l) begin if (clrMemReq) uPcolorReq <= #4 I'bO; else if (fioCS && (uAddr[2:0] = 3'bl 11) && (addrReg[3:0] = 4'ha)) uPcolorReq <= #4 l'bl ; end // always //up CBR always @ (posedge clrMemReq or negedge uWr_l) begin if (clrMemReq) uPcbrReq <= #4 I'bO; else if (ϋoCSJ && (uAddr[2:0] == 3'bl 11) && (addrReg[3:0] = 4'hb)) uPcbrReq <= #4 l'bl; end // always //up Block Req always @ (posedge clrMemReq or negedge uWr_l) begin if (clrMemReq) uPblockReq <= #4 I'bO; else if (ϋoCSJ && (uAddr[2:0] == 3'bl 11) && (addrReg[3:0] = 4'hc)) uPblockReq <= #4 l'bl; end // always //assign name to io register wire sourceExt = control [0] ; //wire clrVram = control[l]; // control 1 will be unused wire [2:0] overiaySel = overlayCtl[2:0]; wire testData = overlay Ctl [3]; wire invData = overlayCtl[4]; wire freeze = outputCtl[0]; wire enRed = outputCtl[l]; wire enBlue = outputCtl[2]; wire enGreen = outputCtl[3]; //syncronize freeze to pClk and vSync always @ (posedge pClk) begin freezeDl <= #4 freeze; freezeD2 <= #4 freezeD 1 ; end // always always @ (posedge pClk) begin if (vSyncReal) freezeOut <= #4 freezeD2; end // always //read data always @ (addrReg or control or memPage or wrMode or blankLine or overlay Ctl or outputCtl or test Red or testGreen or testBlue or uPcolorReq or uPcbrReq or uPblockReq) begin case (addrReg [3:0]) 4'h0: readReg <= #4 'CfflP D; 4'hl : readReg <= #4 {6'b0, control} ; 4'h2: readReg <= #4 {4'bO, memPage} ; 4'h3 : readReg <= #4 {6'bO, wrMode} ; 4'h4: readReg <= #4 { 1 'b0, blankLine} ; 4'h5: readReg <= #4 {3'bO, overlayCtl}; 4'h6: readReg <= #4 {4'bO, outputCtl} ; 4'h7: readReg <= #4 testRed; 4'h8: readReg <= #4 testGreen; 4'h9: readReg <= #4 testBlue; //SW 4'ha: readReg <= #4 {7'bO, uPcolorReq}; 4'hb: readReg <= #4 {7'bO,uPcbrReq}; 4'hc: readReg <= #4 {7'bO,uPblockReq}; endcase end // always always @ (uAddr or readLUT or readOvly or readReg or memCS_l or memRdData) begin if (!memCS_l) uDataOut <= #4 memRdData; else case (uAddr[2:0]) //synopsys parallel_case full_case 3'b000 uDataOut <= #4 8'bO; 3'b001 uDataOut <= #4 readLUT; 3'bOlO uDataOut <= #4 readLUT; 3'bθl l uDataOut <= #4 readLUT; 3'blOO uDataOut <= #4 readOvly 3'blθl uDataOut <= #4 readOvly 3'bl lO uDataOut <= #4 readOvly 3'bl l l uDataOut <= #4 readReg; endcase end //always //syncronize request to the proper clock //VRAM always @ (posedge elk or posedge clrMemReq) begin if (clrMemReq) begin memReqXl <= #4 I'bO; memReq <= #4 I'bO; cbrReqXl <= #4 1'b0; cbrReq <= #4 I'bO; colorReqXK= #4 1*bO; colorReq <= #4 I'bO; blockReq <= #4 1'bO; blockReqXl <= #4 1'b0; end // if else begin memReqXl <= #4 wrMemReq || rdMemReq; memReq <= #4 memReqXl ; cbrReqXl <= #4 uPcbrReq; cbrReq <= #4 cbrReqXl ; colorReqXl <= #4 uPcolorReq; colorReq <= #4 colorReqX 1 ; blockReq <= #4 blockReqXl ; blockReqXl <= #4 uPblockReq; end // else end // always // LUT and OVERLAY always @ (posedge pClk) begin ioReqXl <= #4 wrIOReq || rdlOReq; ioReqX2 <= #4 ioReqXl; ioReqX3 <= #4 ioReqX2; end // always // rising edges of reqs will generate access strobes and clear req the reqests always @ (posedge pClk) begin ioReq <= #4 !ioReqX3 && ioReqX2 ; redLUTReq <= #4 ioReq && (uAddr = 3'hl); greenLUTReq <= #4 ioReq && (uAddr = 3'h2); blueLUTReq <= #4 ioReq && (uAddr = 3'h3); redOvlyReq <= #4 ioReq && (uAddr == 3'h4); greenOvlyReq <= #4 ioReq && (uAddr == 3'h5); blueOvlyReq <= #4 ioReq && (uAddr == 3'h6); ioReqDl <= #4 ioReq; // delay strobe to capture read data ioReqD2 <= #4 ioReqDl ; // delay eqivalent to we strobe ioReqD3 <= #4 ioReqD2; // is this one needed readReqLUT <= #4 ioReqD3 && !uAddr[2]; readReqOvly <= #4 ioReqD2 && uAddr[2]; end // always wire clrlOReq = !reset_l || (!uRd_l && (readReqLUT|| (ioReqD2 && uAddr[2]))) II (!uWr_l && ioReqD2) ; wire clrMemReq = !reset_l || (memDone && IcycleType); //Internal timing generation //This will generate 70 Hz refresh with a 58.057Mhz pixel clock //create controls for adding blank lines wire doBlank = blankLine != 7'bO; //Note: this is probably clunky and could be made more efficient... always @ (posedge pClk) begin if (ldoBlank) armStartBlank <= I'bO; else begin if (vSyncl) armStartBlank <= #4 l'bl; if (startBlank) armStartBlank <= #4 I'bO; end // else end // always wire startBlank = armStartBlank && hSyncl || waitForLast && hSyncl ; always @ (posedge pClk) begin if (IvSyncl || IdoBlank) armLastBlank <= #4 I'bO; if (dataValid && doBlank) armLastBlank <= #4 l'bl; if (startBlank) armLastBlank <= #4 I'bO; end // always always @ (posedge pClk) begin if (! armLastBlank) waitForLast <= #4 I'bO; if (armLastBlank && hSyncl) waitForLast <= #4 l'bl; if (dataValid) waitForLast <= #4 I'bO; end // always always @ (posedge pClk) begin if (ldoBlank) goBlank <= #4 I'bO; if (startBlank) goBlank <= #4 l'bl ; if (endBlank) goBlank <= #4 I'bO; end // always //horizontal counter NOTE: == compares probably won't meet timing always @ (posedge pClk or negedge reset_l) begin if (!reset_l) hCount <= #4 11'b0; else if (doBlank && ! goBlank) hCount <= #4 11'bO; if (IsourceExt || goBlank) begin if (hCount = l l'h403) hCount <= #4 1 I'bO; else hCount <= hCount + l'bl ; end // else if end // always //Vertical Counter always @ (posedge pClk or negedge reset ) begin if (!reset_l) vCount <= 10'h000; else if (doBlank && IgoBlank) vCount <= 10'h000; if (('.sourceExt || doBlank) & hCount == 1 l'h403) begin if (vCount <= 10'h325) vCount <= 10'h000; else vCount = vCount +1 'bl ; end // else end // always always @ (posedge pClk) endBlank <= #4 vCount[6:0] == blankLine && hCount = l l'h403; //vSync Generation always @ (posedge pClk) begin hSyndnt <= #4 hCount == 1 l'h403; vSyndnt <= #4 hSyndnt && vCount == 10'h325; end // always //valid generation always @ (posedge pClk or negedge reset_l) begin if (!reset_l) vValid <= l'bO; else begin if (hSyndnt && vCount = 1 l*h002) vValid <= l'bl; if (hSyndnt && vCount = 1 l'h301) vValid <= #4 1'bO; end // else end // always always @ (posedge pClk or negedge reset_l) begin if (!reset_l) hValid <= #4 1'b0; else begin if (hCount == 11 'h002) hValid <= #4 1'bl ; if (hCount <= 11 Η401) hValid <= #4 1'bO; end // else end // always wire validlnt = hValid && (goBlank || vValid); //note that this is asynchronous. It is very long and will work... wire vSyncMem = (! sourceExt && vCount == 10'h325) || (sourceExt && vSyndn); always @ (posedge elk) begin vSyncMemDl <= #4 vSyncMem; vSyncMemD2 <= #4 vSyncMemDl; vSyncMemD3 <= #4 vSyncMemD2; end // always wire vSyncMemRise = !vSyncMemD3 && vSyncMemD2; //Change syncs to 1 clock pulses always @ (posedge pClk) begin vSyncIn <= #4 vSync; vSyndnDl <= #4 vSyncIn; hSyndn <= #4 hSync; hSyncInDl <= #4 hSyndn; vSyncl <= #4 IvSyncIn && vSyndnDl; hSyncl <= #4 hSyndn && IhSyncInDl; vSyncOut <= #4 vSyncReal; end // always always @ (posedge pClk) begin if (! sourceExt || goBlank) begin hSyncReal <= #4 hSyndnt; vSyncReal <= #4 vSyncInt; validReal <= #4 validlnt; end // begin else begin hSyncReal <= #4 hSyncl; vSyncReal <= #4 vSync 1 ; validReal <= #4 dataValid; end // else end // always //pipeline Valid always @ (posedge pClk) begin validDelay <= #4 {validDelay [5:0], validReal}; valid <= #4 validDelay [6] && IfreezeOut; end // always //Register Input RGB Data (use I/O Cells) always @ (posedge pClk) begin redln <= #4 red; greenln <= #4 green; blueln <= #4 blue; dataValid <= #4 dEn; end // always //Mux in test data registers always @ (posedge pClk) begin if (IsourceExt || testData || blankData) begin redDO <= #4 testRed; blueDO <= #4 testBlue; greenDO <= #4 testGreen; end // if else begin redDO <= #4 redln; greenDO <= #4 greenln; blueDO <= #4 blueln; end // else end // always //Add pipeline stages to sync up with overlay data always @ (posedge pClk) begin redDO 1 <= #4 redDO; redD02 <= #4 redD01; redD03 <= #4 redD02; redD04 <= #4 redD03; redD05 <= #4 redD04; redD06 <- #4 redD05; greenDO 1 <= #4 greenDO; greenD02 <= #4 greenDO 1; greenD03 <= #4 greenD02; greenD04 <= #4 greenD03; greenD05 <= #4 greenD04; greenDOό <= #4 greenD05; blueDO 1 <= #4 blueDO; blueD02 <= #4 blueDO 1; blueD03 <= #4 blueD02; blueD04 <= #4 blueD03 ; blueD05 <= #4 blueD04; blueD06 <= #4 blueD05; end // always //Mux in Negated data always @ (posedge pClk) begin if (invert || ollnv) begin redDl <= #4 ! redD06; greenDl <= #4 ! greenDOό; blueDl <= #4 ! blueDOό; end // if else begin redDl <= #4 redD06; greenDl <= #4 greenDOό; blueDl <= #4 blueDOό; end // else end // always //mux in uP address for read/writes to LUT always @ (posedge pClk) begin if(lredLUTReq ) redAddr <= #4 redDl ; else redAddr <= #4 addrReg[7:0]; end // always always @ (posedge pClk) begin if (! greenLUTReq) greenAddr <= #4 greenDl; else greenAddr <= #4 addrReg[7:0]; end // always always @ (posedge pClk) begin if (lblueLUTReq) blueAddr <= #4 blueDl ; else blueAddr <= #4 addrReg[7:0]; end // always //generate write strobes for LUTs always @ (posedge pClk) begin weRed <= redLUTReq && !uWr_l; weGreen <= greenLUTReq && !uWr_l; weBlue <= #4 blueLUTReq && !uWr_l; end // always //Data for lookup table, register @ //LUT syn_ram_256x8_iror ul (redLUT, uDataIn, weRed, redAddr, pClk,pClk); syn_ram_256x8_iror u2 (greenLUT, uDataIn, weGreen, greenAddr, pClk,pClk); syn_ram_256x8_iror u3 (blueLUT, uDataIn, weBlue, blueAddr, pClk,pClk); //Register LUT outputs (Maximize speed by no muxing here) always @ (posedge pClk) begin redLUTout <= #4 redLUT; greenLUTout <= #4 greenLUT; blueLUTout <= #4 blueLUT; enαV/always //get read data for uP at this stage (may need to decode some earier) always @ (posedge pClk) begin if (readReqLUT) begin if (uAddr[l :0] == 2'b01) readLUT <= #4 redLUTout; if (uAddr[l :0] = 2'blO) readLUT <= #4 greenLUTout; if (uAddr[l :0] = 2'bl l) readLUT <= #4 blueLUTout; end // if end // always //mux in overlay and use enRed signals always @ (posedge pClk) begin if (lenRed) redDx <= #4 8'bO; else if (useOverlay) redDx <= #4 redOverlay; else redDx <= #4 redLUTout; if (lenGreen) greenDx <= #4 8'bO; else if (useOverlay) greenDx <= #4 greenOverlay; else greenDx <= #4 greenLUTout; if (.enBlue) blueDx <= #4 8'bO; else if (useOverlay) blueDx <= #4 blueOverlay; else blueDx <= #4 blueLUTout; end // always //final IO register always @ (posedge pClk) begin redOut <= #1 redDx; greenOut <= #1 greenDx; blueOut <= #1 blueDx; end // always //Overlay Data path //Serial Clock always @ (posedge pClk) begin if (hSyncReal) begin sClkL <= #4 1'bO; sClkH <= #4 I'bO; end // if else if (validReal) begin if (useLowVram) sClkL <= #4 IsClkL; else sClkH <= #4 IsClkH; end //else if end // always always @ (posedge pClk) begin sc <= #4 {sClkH, sClkL}; sClklnt <= #4 sClkH || sClkL; sClkDl <= #4 sClklnt; sClkD2 <= #4 sClkDl; end // always //register VRAM serial data always @ (posedge pClk) begin if (sClkDl) overlayln <= #4 overlay; end // always always @ (posedge pClk) begin if (sClkD2) olData <= #4 overlayln[7:0]; else olData <= #4 overlayIn[15:8]; end // always //overlay select always @ (posedge pClk) begin casex (overiaySel) 3'bOOO: olDataDK= #4 8'b00; 3'b001: olDataDl <= #4 {4'bO, olData[3:0]}; 3'b010: olDataDl <= #4 {olData[7:4], 4'bO}; 3'b011 : begin if (olData[3:0] != 4'bO) olDataDK= #4 {4'bO, olData[3:0]}; else olDataD 1 <= #4 olData; end // begin 3'blxx: olDataDl <= #4 olData; endcase end // always //generate invert always @ (posedge pClk) ollnv <= #4 olDataDl[3:0] == 4'hf || olDataDl [7:4] 4'hf; //add pipline stages so that data will line up always @ (posedge pClk) begin olDataD2 <= #4 olDataDl ; olDataD3 <= #4 olDataD2; end // always //overlay masking (any 1 will use overlay data) //but not F which signifies invert data... //pipeline delay it for time through the EAB always @ (posedge pClk) begin useOverlay <= #4 (olDataD3 != 8'bO && olDataD3[3:0] != 4*hf && olDataD3[7:4] != 4'hf) || lenOverlay; useOverlayDl <= #4 useOverlay; useOverlay D2 <= #4 useOverlayDl; useOverlayD3 <= #4 useOverlayD2; end // always //mux in uP address for read writes to LUT always @ (posedge pClk) begin if (lredOvlyReq) olRedAddr <= #4 olDataD3; else olRedAddr <= #4 addrReg[7:0]; if ( ! greenOvlyReq) olGreenAddr <= #4 olDataD3; else olGreenAddr <= #4 addrReg[7:0]; if (lblueOvlyReq) olBlueAddr <= #4 olDataD3; else olBlueAddr <= #4 addrReg[7:0]; end // always always @ (posedge pClk) begin weOverRed <= redOvlyReq && !uWr_l; weOverGreen <= #4 greenOvlyReq && !uWr_l; weOverBlue <= #4 blueOvlyReq && !uWr_l; end // always //LUTs for Overlay syn_ram_256x8_iror u4 (overRed, uDataIn, weOverRed, olRedAddr, P Clk,pClk); syn_ram_256x8_iror u5 (overGreen, uDataIn, weOverGreen, olGreenAddr, pClk, P Clk); syn_ram_256x8_iror u6 (overBlue, uDataIn, weOverBlue, olBlueAddr, pClk,pClk); //register LUT output (for speed) always @ (posedge pClk) begin redOverlay <= #4 overRed; greenOverlay <- #4 overGreen; blueOverlay <= #4 overBlue; end // always //get read data for uP at this stage (may need to decode some earier) always @ (posedge pClk) begin if (readReqOvly) begin if (uAddr[l :0] == 2'b00) readOvly <= #4 overRed; if (uAddr[l :0] == 2'b01) readOvly <= #4 overGreen; if (uAddr[l :0] == 2'bl0) readOvly <= #4 overBlue; end // if end // always //VRAM IF //sync and edge detect QSF wire qsfln = useLowVram && qsf O] || luseLowVram && qsf[l]; always @ (posedge elk) begin qsfDl <= #4 qsfln; qsfD2 <= #4 qsfDl; qsfD3 <= #4 qsfD2; end // always wire qsfRise = qsfD2 && !qsfD3; wire qsfFall = !qsfD2 && qsfD3; //Mask off 1 st qsf fall (full read has already loaded SAM) always @ (posedge elk or negedge reset_l) begin if (!reset_l) qsfMask <= #4 1'bO; else begin if (vSyncMemRise) qsfMask <= #4 l'bl ; // set mask on vSync if (qsfRise && xferAddr = 9'hlFF) qsfMask <= #4 l'bl; // set mask when switching VRAMs if (qsfMask && qsfRise) qsfMask <= #4 I'bO; // clear mask after first rising edge of qsf end // else end // always //generate split read request always @ (posedge elk or posedge clrXferReq) begin if (clrXferReq) splitReq <= #4 1'bO; else begin if (qsfRise || (IqsfMask && qsfFall)) splitReq <= #4 1'bl; end // else end // always wire clrXferReq = !reset_l || (memDone && cycleType); //Keep up with which bank is currently used always @ (posedge elk or posedge vSyncMem) begin if (vSyncMem) useLowVram <= l'bl ; if (qsfFall && xferAddr == 8'hFF) useLowVram <= I'bO; end // always //generate Full read request (Note Should do both VRAM with the same cycle) always @ (posedge elk or posedge clrXferReq) begin if (clrXferReq) fullReq <= #4 1'bO; if (vSyncMemRise) fullReq <= #4 1'bl; end // always //combinatorial request assign vramWrReq = memReq && luWr l; assign vramRdReq = memReq && luRd l; //memory sequence vramsm vramsm (clk,reset_l,memPage,wrMode, { uAddr, addrReg} ,uData,memRdData, cbrReq, vramWrReq, vramRdReq,colorReq,splitReq,fullReq,blockReq, useLowVram, memDone,cycleType, vAddr,vData,ras_l,cas_l,dsf,dtoe,we_l[l], we_l[0]); // endmodule

Claims: CLAIMS We claim: 1. A data planarizer for receiving n-bit data words and outputting m-bit data words, said data planarizer comprising: a plurality of data input terminals; a plurality of data output terminals; and a first storage bank having an input terminal set coupled to said plurality of data input terminals, an output terminal set coupled to said plurality of data output terminals, and a bit-depth less than m. 2. A data planarizer according to Claim 1, wherein said first storage bank comprises a bi-directional shift register. 3. A data planarizer according to Claim 2, wherein said bi-directional shift register comprises: a clock-input terminal for receiving a data shift signal; and a direction terminal for receiving a direction control signal. 4. A data planarizer according to Claim 3, wherein said bi-directional shift register further comprises: a plurality of flip-flops arranged in a rectangular array of columns and rows, each of said flip- flops having a control terminal coupled to said clock input terminal, an input terminal, and an output terminal; and a plurality of multiplexers arranged in a rectangular array of columns and rows, each of said multiplexers having a control terminal coupled to said direction terminal, an output terminal coupled to said input terminal of an associated one of said flip-flops, a first input terminal, and a second input terminal. 5. A data planarizer according to Claim 4, wherein: said multiplexers of a first column of said array of multiplexers each has said first input terminal coupled to an associated one of said plurality of data input terminals; said multiplexers of other columns of said array of multiplexers each has said first input terminal coupled to said output terminal of an associated one of said flip-flops located in an adjacent column; said multiplexers of rows other than a top row of said array of multiplexers each has said second input terminal coupled to the output terminal of an associated one of said flip-flops of an adjacent row; and said flip-flops of a bottom row of said array of flip-flops each has said output terminal coupled to an associated one of said plurality of data output terminals. 6. A data planarizer in accordance with Claim 1, further comprising a second storage bank having an input terminal set coupled to said plurality of data input terminals, an output terminal set coupled to said plurality of data output terminals, and a bit-depth less than m. 7. A data planarizer in accordance with Claim 6, wherein said first storage bank and said second storage bank have a combined capacity of less than one frame of data. 8. A data planarizer in accordance with Claim 7, wherein: said first storage bank comprises a bi-directional shift register having a clock-input terminal for receiving a data shift signal, and a direction terminal for receiving a direction control signal; and said second storage bank comprises a bi-directional shift register having a clock-input terminal for receiving a data shift signal, and a direction terminal for receiving a direction control signal. 9. A data planarizer in accordance with Claim 8, further comprising an inverter having an input terminal coupled to said direction terminal of said first bi-directional shift register and an output terminal coupled to said direction terminal of said second bi-directional shift register. 10. A data planarizer according to Claim 9, wherein each of said bi-directional shift registers further comprises: a plurality of flip-flops arranged in a rectangular array of columns and rows, each of said flip- flops having a control terminal coupled to said clock input terminal, an input terminal, and an output terminal; and a plurality of multiplexers arranged in a rectangular array of columns and rows, each of said multiplexers having a control terminal coupled to said direction terminal, an output terminal coupled to said input terminal of an associated one of said flip-flops, a first input terminal, and a second input terminal. 11. A data planarizer according to Claim 10, wherein: said multiplexers of a first column of said array of multiplexers each has said first input terminal coupled to an associated one of said plurality of data input terminals; said multiplexers of other columns of said array of multiplexers each has said first input terminal coupled to said output terminal of an associated one of said flip-flops located in an adjacent column; said multiplexers of rows other than a top row of said array of multiplexers each has said second input terminal coupled to the output terminal of an associated one of said flip-flops of an adjacent row; and said flip-flops of a bottom row of said array of flip-flops each has said output terminal coupled to an associated one of said plurality of data output terminals. 12. A method for planarizing n-bit data into m-bit planarized data, said method comprising the steps of: receiving a first group of (p) n-bit data words, where p<m; storing said first group of (p) data words in a first storage bank; and transferring said first group of (p) data words into a device comprising (n) different memory locations, by transferring a p-bit data word comprising one bit from each of said first group of (p) n-bit data words into a first portion of each of said memory locations. 13. A method according to Claim 12, further comprising the steps of: receiving a second group of (p) n-bit data words; storing said second group of (p) data words in said first storage bank; and transferring said second group of (p) data words into said device by transferring a p-bit data word comprising one bit from each of said second group of (p) n-bit data words into a second portion of each of said memory locations. 14. A method according to Claim 13, further comprising the steps of: receiving subsequent groups of (p) n-bit data words; storing said subsequent groups of (p) data words in said first storage bank; and transferring said subsequent groups of (p) data words into said device by transferring a p-bit data word comprising one bit from each of said subsequent groups of (p) n-bit data words into subsequent portions of each of said memory locations, until each of said memory locations contains an m-bit data word. 15. A method according to Claim 12, further comprising the steps of: receiving a second group of (p) n-bit data words; storing said second group of (p) data words in a second storage bank; and transferring said second group of (p) data words into said device by transferring a p-bit data word comprising one bit from each of said second group of (p) n-bit data words into a second portion of each of said memory locations. 16. A method according to Claim 15, further comprising the steps of: receiving subsequent groups of (p) n-bit data words; storing said subsequent groups of (p) data words in one of said first and second storage banks; and transferring said subsequent groups of (p) data words into said device by transferring a p-bit data word comprising one bit from each of said subsequent groups of (p) n-bit data words into subsequent portions of each of said memory locations, until each of said memory locations contains an m-bit data word. 17. A method according to Claim 16, wherein said step of storing said subsequent groups of (p) data words in one of said first and second storage banks is performed in alternating fashion between said first and said second storage banks. 18. A method according to Claim 15, wherein said step of storing said second group of (p) data words in said second storage bank is performed while said step of transferring said first group of (p) data words is performed. 19. A method according to Claim 12, wherein said step of storing said first group of (p) data words in a first storage bank comprises the steps of shifting said (p) data words into said first storage bank along a first direction, (n) bits at a time. 20. A method according to Claim 19, wherein said step of transferring said first group of (p) data words into a device comprising (n) different memory locations comprises the steps of shifting said (p) data words out of said first storage bank along a second direction, (p) bits at a time. 21. A data planarizer for planarizing n-bit data into m-bit planarized data, said data planarizer comprising: receiving means for receiving a group of (p) n-bit data words, where p<m; storage means for storing said group of (p) data words; and transfer means for transferring said group of (p) data words into a device comprising (n) different memory locations, by transferring a p-bit data word comprising one bit from each of said group of (p) n-bit data words into a first portion of each of said memory locations. 22. A data planarizer according to Claim 21, wherein said first storage means comprises: first shifting means for shifting data into said first storage means (n) bits at a time; and second shifting means for shifting data out of said first storage means (p) bits at a time.

Inventors: CHOW WING HONG, WEATHERFORD WILLIAM THOMAS, WORLEY W SPENCER III, CHOW, WING, HONG, WEATHERFORD, WILLIAM, THOMAS, WORLEY, W., SPENCER, III
Applicants: SVISION, S-VISION, INC.
Application year: 1998
Main classification: G09G3
IPC codes: G09G3