Efficient pixel packing

Information

  • Patent Grant
  • 6271867
  • Patent Number
    6,271,867
  • Date Filed
    Saturday, October 31, 1998
    26 years ago
  • Date Issued
    Tuesday, August 7, 2001
    23 years ago
Abstract
In storing data for display, traditionally twenty-four bit video pixels have required extra video memory to store the video pixels on double word boundaries or extensive hardware to fully utilize video memory. Eight twenty-four bit video pixels are stored within three quad words in a manner that reduces the required hardware from prior approaches and fully utilizes video memory.
Description




CROSS-REFERENCE TO RELATED APPLICATIONS




Not applicable.




STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH




Not applicable.




BACKGROUND OF THE INVENTION




1. Field of the Invention




This invention relates to storing pixel data in video memory and more specifically to storing eight twenty-four bit pixels within three quad words of video memory.




2. Description of the Related Art




The amount of video memory required to hold an image depends on the resolution of the image and color depth used per pixel. To display a true color image generally uses twenty-four bits of data per pixel. The twenty-four bits that make-up a true color pixel include eight bits for each of a red, green, and blue (RGB) signal. Most addressing schemes address video memory eight, sixteen, or thirty-two bits at a time.




Traditionally, when twenty-four bit pixel data was stored in video memory (that was addressed thirty-two bits at a time) eight bits of video memory per pixel were unused. This was because it was desirable (to avoid the addition of hardware to reorient the pixel data) to store the twenty-four bit pixel data on a double word boundary. In an effort to fully utilize video memory, various schemes were devised which allowed data for an individual pixel to possibly be stored in a different double word (thirty-two bits) within video memory. One such scheme stored twenty-four bit RBG pixel data sequentially in video memory. Utilizing this scheme, a twenty-four bit RGB pixel was stored on an upper and lower boundary of every three double words (ninety-six bits) of video memory. This scheme required the implementation of extensive hardware to reorient the RGB pixel data when read from video memory, before display.




SUMMARY OF THE INVENTION




A system according to the present invention provides a technique that efficiently packs eight twenty-four bit pixels into three quad words of video memory. This is accomplished by dividing two of the eight twenty-four bit pixels into constituent eight bit representations of each of three primary pixel colors. Two undivided pixels and two of the constituent eight bit representations of the divided pixels are stored within each of the quad words. In one embodiment, each of the two undivided pixels is stored on a double word boundary.




An advantage of the disclosed embodiment is that it simplifies the hardware required to reorient the pixel data, before display, while maintaining efficient packing of twenty-four bit pixel data.











BRIEF DESCRIPTION OF THE DRAWINGS




A better understanding of the present invention can be obtained when the following detailed description of the preferred embodiment is considered in conjunction with the following drawings, in which:





FIG. 1

illustrates a display controller coupled to a display according to an embodiment of the present invention;





FIG. 2A

illustrates a display and display screen according to an embodiment of the present invention;





FIG. 2B

illustrates a display controller incorporated within a display according to an embodiment of the present invention;





FIG. 3

further illustrates a display controller according to an embodiment of the present invention;





FIG. 4

is a block diagram of a workstation W that implements an embodiment of the present invention;





FIG. 5

illustrates the storage of eight (twenty-four bit) pixels in three quad words of video memory according to an embodiment of the present invention;





FIG. 6

illustrates the storage of twelve (16 bit) pixels in three quad words of video memory according to an embodiment of the present invention;





FIG. 7

illustrates addressing for frame buffers (video memory) of a display controller according to an embodiment of the present invention;





FIG. 8

depicts hardware located within a vertical scale section of the display controller that orients twenty-four bit RGB data for storage in video memory (frame buffer) according to an embodiment of the present invention;





FIGS. 9A-9B

depict the hardware of

FIG. 8

in greater detail;





FIG. 10

illustrates the temporary storage of pixel data in registers prior to storage in video memory;





FIG. 11

is a state diagram associated with the storage of pixel data; and





FIG. 12

is a diagram illustrating the storage of six quad words of pixel data in video memory.











DETAILED DESCRIPTION OF INVENTION




The present invention provides a technique that efficiently packs eight twenty-four bit pixels into three quad words of video memory. This is accomplished by dividing two of the eight twenty-four bit pixels into constituent eight bit representations of each of three primary pixel colors. Two undivided pixels and two of the constituent eight bit representations of the divided pixels are stored within each of the quad words. In one embodiment, each of the two undivided pixels is stored on a double word boundary of each of the quad words.




Display/Display Controller





FIG. 1

depicts a display controller


122


coupled to a display


130


by a bus


132


. The bus


132


is an eight, sixteen, or thirty-two bit bus or otherwise. The display


130


, in the preferred embodiment, is a liquid crystal display (LCD). The display controller


122


supplies pixel data to the display screen


131


(see FIGS.


2


A and


2


B). While the display controller


122


is depicted separately from the display


130


in

FIG. 1

, in the preferred embodiment the display controller


122


is incorporated within the display


130


(see FIG.


2


B).




Moving to

FIG. 2A

, a display screen


131


of the display


130


is further illustrated. Similar to a cathode ray tube (CRT), an LCD is normally considered to consist of a number of lines


134


. For example, a monochrome 1280×1024 LCD display screen includes 1024 lines and each line includes 1280 pixels (approximately 1.3 million cells). Updating the display screen at sixty frames per second results in each line being updated in less than 16.3 microseconds.

FIG. 2B

depicts the display controller


122


incorporated within the display


130


. As before, the display controller


122


supplies pixel data to the display screen


131


.





FIG. 3

illustrates the display controller


122


in greater detail. A graphics card


106


(see

FIG. 5

) provides pixel data (a RGB signal) to the display controller


122


. In this embodiment, the pixel data originates from the graphics card


106


and is typically an analog signal. The display controller


122


employs a digital input signal. As such, the pixel data (RGB signal), if analog, is converted (not shown) to digital prior to being transmitted to the display controller


122


. This pixel data (PD [


23


:


0


]) is initially fed to a multiplexer (GRDMUX)


136


. The pixel data from the multiplexer


136


is coupled to a first-in first-out (FIFO) buffer (FIFO


1


)


138


. The pixel data is clocked into the buffer


138


by a 110 MHz clock signal (PCLK). Pixel data is clocked out of the buffer


138


by a 92 MHz clock signal (SCLK).




The pixel data (PIXDATA [


23


:


0


]), which comes from the buffer


138


, is coupled to a horizontal scale section


140


. The display controller


122


includes support for horizontal resolutions of


1280


,


1024


,


800


,


720


,


704


,


640


,


512


,


400


,


360


, and


320


. Various control registers (not shown) on the display controller


122


enable an incoming image (the pixel data) to be scaled, if desired. Pixel data (DATAINA [


23


:


0


]) is coupled to a FIFO buffer (FIFO


2


)


142


. Pixel data (DATAINB [


23


:


0


]) is coupled to a FIFO buffer (FIFO


3


)


144


. This pixel data is clocked into the FIFO buffers


142


and


144


at the SCLK frequency. This pixel data is clocked out of the FIFO buffers


142


and


144


(at the SCLK frequency) and into a vertical scale section (VSCALE)


146


of the display controller


122


.




If vertical scaling is enabled, the vertical scale section


146


scales the pixel data as set by certain registers (not shown). The scaled or non-scaled pixel data is then output as memory data MEMDAT [


63


:


0


]. The vertical scale section


146


also functions to reorient pixel data for efficient storage. MEMDAT[


63


:


0


] is a sixty-four bit signal which is coupled to a FIFO buffer (FIFO


4


)


148


. That pixel data is clocked into the FIFO buffer


148


at the SCLK frequency. The pixel data is then clocked out of the FIFO buffer


148


and into a data multiplexer (DATAMUX)


150


. The pixel data can then be routed through the data multiplexer


150


and into frame buffers (MEMORY A and MEMORY B)


160


and


164


. The frame buffer


160


is controlled by a memory controller (MEMORY CONTROLLER A)


162


. The frame buffer


164


is controlled by a memory controller (MEMORY CONTROLLER B)


166


. The data multiplexer


150


also routes the pixel data (MDATA[


63


:


0


] and MDATB[


63


:


0


]) from the frame buffers


160


and


164


to a FIFO buffer (FIFO


5


)


152


(as RDDAT[


63


:


0


]). The pixel data (IMGDAT [


65


:


0


]) is clocked out of the FIFO buffer


152


by a 92 MHz clock signal (ICLK). The pixel data is then coupled to an imager interface


154


. The imager interface


154


supplies pixel data (RGB DATE[


8


:


0


] and RGB DATO[


8


:


0


]) to the display


130


. The imager interface


154


also functions to reorient pixel data for display.




Computer System




Turning to

FIG. 4

, illustrated is a block diagram of a workstation W according to an embodiment of the present invention. While a workstation is shown, it is contemplated that various other computer systems such as a personal computer or a mainframe could implement the present invention. Processors


100


and


102


are coupled to a host bus


104


. The processors


100


and


102


in the preferred embodiment are Pentium II processors manufactured by the Intel Corporation. Also coupled to the host bus


104


is a chipset


108


and a chipset


112


. The chipset


108


provides a memory controller for controlling memory


110


, a host-PCI bus bridge for coupling a PCI bus


116


to the host bus


104


, and an AGP connector for connecting a graphics card


106


. The display controller


122


is coupled to the graphics card


106


and the display


130


. The display


130


, in one embodiment, is a liquid crystal display (LCD) used in projection-based imagers.




Coupled to the PCI bus


116


is a small computer system interface (SCSI) controller


124


and a network interface card (NIC)


128


. The NIC


128


can provide an Ethernet connection for coupling the workstation W to a local area network (LAN). Coupled to the SCSI controller


124


is a disk subsystem


126


. The SCSI controller


124


can potentially control various disk subsystems


126


which can include: tape drives, WORM, CD-ROM, DVD, and optical storage devices.




The chipset


112


provides a memory controller for controlling memory


114


, and a host-PCI bus bridge for coupling a PCI bus


118


to the host bus


104


. Coupled to the PCI bus


118


is a ServerNet card


120


. The ServerNet card


120


can provide for a high speed communication link between multiple workstations.




The Pentium II processors


102


and


104


could be replaced with different processors other than the Pentium II without detracting from the spirit of the invention. The processors


102


and


104


are capable of running any of a number of operating systems, such as Windows 95®, Windows NT®, or a Unix based operating system.




Again, it should be understood that a wide variety of systems could be used instead of the disclosed workstation W without detracting from the spirit of the invention. Further, other current and future operating systems could also be utilized.




Pixel Packing




Turning to

FIG. 5

, depicted is a snap-shot of three quad words of red, green, and blue (RGB) pixel data as stored within video memory according to an embodiment of the present invention. The pixel data can be stored within either of two frame buffers (Frame


1


or Frame


2


), which in the disclosed embodiment are located on the display controller


122


. Moving to a first row of the video memory snap-shot (which corresponds to video memory address


0


), a green portion of a third pixel (G


3


) is stored at data location [


7


:


0


]. A red portion of the third pixel (R


3


) is stored at data location [


39


:


32


]. A first pixel (RGB


1


) is stored at data location [


31


:


8


]. A second pixel (RGB


2


) is stored at data location [


63


:


40


].




Moving to a second row of the memory snap-shot (which corresponds to video memory address


1


) a blue portion of the third pixel (B


3


) is stored at data location [


7


:


0


]. A red portion of a sixth pixel (R


6


) is stored at data location [


39


:


32


]. A fourth pixel (RGB


4


) is stored at data location [


31


:


8


] and a fifth pixel (RGB


5


) is stored at data location [


63


:


40


].




Moving to a third row of the memory snap-shot (which corresponds to video memory address


2


), a blue portion of the sixth pixel (B


6


) is stored in data location [


7


:


0


]. A green portion of the sixth pixel (G


6


) is stored at data location [


39


:


32


]. A seventh pixel (RGB


7


) is stored at data location [


31


:


8


] and an eighth pixel (RGB


8


) is stored at data location [


63


:


40


]. The above process is repeated (that is—every third pixel is partitioned) until a frame of pixel data has been stored within a frame buffer. This process is further illustrated in

FIGS. 10 and 12

.





FIG. 6

illustrates a snap-shot of video memory and how ‘on screen display’ (OSD) pixel data is stored within a frame buffer. The OSD allows for information display within a reduced portion of a display that utilizes a 1280×1024 display screen. The dimension of the OSD is 384×((16*n)+12), where n ranges from 0 to 18, and can be positioned horizontally within the 1280×1024 display screen. Each OSD pixel includes sixteen bits. The sixteen bits are made-up of five red bits, six green bits, and five blue bits. Since the data consists of sixteen bits, it can be sequentially stored such that four pixels fit within one quad word and twelve pixels fit within three quad words. As such extensive hardware is not required to reorient pixel data for storage within video memory or display.




Turning to

FIG. 7

, illustrated are address locations of the frame buffers


160


and


164


(see

FIG. 3

) where red, green, and blue (RGB) pixel data is stored. In the disclosed embodiment, the frame buffers


160


and


164


are located on the display controller


122


. Frame or pixel data for a normal display is alternatively stored within a Frame


1


buffer and a Frame


2


buffer at addresses


000000


h through


3


BFFFFh. OSD pixel data is stored within the Frame


2


buffer at addresses


3


C


0000


h through


3


C


707


Fh. The OSD pixel data is routed from microcontroller


158


through an interface


156


to the data multiplexer


150


(see FIG.


3


).




Moving to

FIG. 8

, a portion of the vertical scale (VSCALE) section


146


(see

FIG. 3

) of the display controller


122


is illustrated. The pixel data is routed through four different pipes: Pipe A, Pipe B, Pipe C and Pipe D. Each of these pipes is twenty-four bits wide. These pipes are multiplexed such that pixel data can be stored in video (frame buffer) memory in accordance with FIG.


5


. The pixel data is temporarily stored in registers as quad words (64 bits) MEMDAT


1


, MEMDAT


2


, and MEMDAT


3


. For timing reasons, that data is then fed through the buffer


148


(see

FIG. 3

) for storage within the Frame


1


or Frame


2


buffers (


160


and


164


).





FIG. 9A

further illustrates multiplexing that is performed on the various pixel pipes. The video data (VD) that is routed through Pipe A, Pipe B, Pipe C, and Pipe D is respectively denominated as VDA, VDB, VDC, and VDD. Referring now to the Verilog code of Appendix A: VDA corresponds to VDATREGA, VDB corresponds to VDATREGB, VDC corresponds to VDATREGC, and VDD corresponds to VDATREGD. Each of the VDA, VDB, VDC, and VDD are made up of twenty-four bit RGB pixel data. Returning to

FIG. 9A

, VDA is either stored on an upper boundary of an upper double word of a quad word or on an upper boundary of a lower double word of a quad word. When VDB is stored as a complete pixel, it is stored on an upper boundary of an upper double word of a quad word. When VDC is stored as a complete pixel, it is stored on an upper boundary of a lower double word of a quad word. VDD, like VDA, can be stored on an upper boundary of a lower double word or a higher double word of a quad word.




Turning to

FIG. 9B

illustrated is the multiplexing of pixels VDC and VDB. A blue portion of VDB and VDC are multiplexed to a lower byte of a lower double word of a quad word. Also multiplexed to a lower byte of a lower double word of a quad word is a green portion of VDC. The red and green portion of VDB are multiplexed to a lower byte of an upper double word of a quad word. Also multiplexed to a lower byte of an upper double word of a quad word is a red portion of VDC.




The temporary storage of pixels corresponding to VDA, VDB, VDC, and VDD is further illustrated in FIG.


10


. When clock enable low (CLKENL) is asserted, VDA


1


(a first pixel) is stored in registers corresponding to video memory location [


8


:


31


]. When clock enable high (CLKENH) is asserted, VDB


2


(a second pixel) is stored in a register corresponding to video memory location [


63


:


40


]. When MUXEQ


2


is asserted, VDC


3


-R (a red portion of a third pixel) is stored in a register corresponding to video memory location [


32


:


39


]. Also, VDC


3


-G (a green portion of the third pixel) is stored in a register corresponding to video memory location [


0


:


7


]. Upon receiving a MEMWR signal a quad word (MEMDAT


1


)is transferred to the FIFO buffer.




When MUXEQ


3


is asserted, VDD


4


(a fourth pixel) is stored in the register corresponding to the video memory location [


8


:


31


]. Also, VDC


3


-B (a blue portion of the third pixel) is stored in the register corresponding to the video memory location [


0


:


7


]. When MUXEQ


4


is asserted, VDA


5


(a fifth pixel) is stored in the register corresponding to the video memory locations [


63


:


40


]. When MUXEQ


5


is asserted, VDB


6


-R (a red portion of a sixth pixel) is stored in the register corresponding to the video memory locations [


39


:


32


]. Upon receipt of a MEMWR signal, a quad word (MEMDAT


2


) is transferred to the FIFO buffer.




When MUXEQ


6


is asserted, VDC


7


(a seventh pixel) is stored in the register corresponding video memory locations [


8


:


31


]. Also, VDB


6


-B (a blue portion of the sixth pixel) is stored in the register corresponding to the video memory location [


0


:


7


] and VDB


6


-G (a green portion of the sixth pixel) is stored in the register corresponding to video memory locations [


32


:


39


]. When MUXEQ


7


is asserted, VDD


8


(an eighth pixel) is stored in the register corresponding to the video memory locations [


40


:


63


]. Upon receipt of a MEMWR signal, a quad word (MEMDAT


3


) is transferred to the FIFO buffer.




Turning to

FIG. 11

, the flow of

FIG. 10

is further illustrated in a state machine. The state machine is entered through step


800


. From step


800


control transfers to step


802


. After CLKENL is asserted, control transfers to step


804


. In step


804


, after CLKENH is asserted, control transfers to the next state in step


806


. In step


806


, after MUXEQ


2


is asserted, control transfers to step


808


. In step


808


, after MUXEQ


3


is asserted control transfers to step


810


. In step


810


, after MUXEQ


4


is asserted control transfers to step


812


. In step


812


, after MUXEQ


5


is asserted control transfers to step


814


. In step


814


, after MUXEQ


6


is asserted control transfers to step


816


. In step


816


, after MUXEQ is asserted control returns to step


802


. Thus, when CLKENL is asserted again (in step


802


) the flow of the state machine is repeated.





FIG. 12

illustrates the sequencing of six quad words for storage within a frame buffer. Each video data (VD) represents a pixel and includes twenty-four bits of pixel data. Each of the primary colors, red, green, and blue (RGB), is made up of eight bits. A green portion of a third pixel (VD


3


-G) is stored in a register corresponding to a first byte of a first quad word. A first pixel (VD


1


) is stored on an upper boundary of a lower double word of the first quad word. A red portion of the third pixel (VD


3


-R) is stored in a lower byte of an upper double word of the first quad word. A second pixel (VD


2


) is stored on an upper boundary of the upper double word of the first quad word.




A blue portion of the third pixel (VD


3


-B) is stored in a lower byte of a second quad word. A fourth pixel (VD


4


) is stored on an upper boundary of a lower double word of the second quad word. A red portion of a sixth pixel (VD


6


-R) is stored as a lower byte of an upper double word of the second quad word. A fifth pixel (VD


5


) is stored on an upper boundary of the upper double word of the second quad word.




A blue portion of the sixth pixel (VD


6


-B) is stored as a lower byte of a third quad word. A seventh pixel (VD


7


) is stored on an upper boundary of a lower double word of the third quad word. A green portion of the sixth pixel (VD


6


-G) is stored as a lower byte of an upper double word of the third quad word. An eighth pixel (VD


8


) is stored on an upper boundary of the upper double word of the third quad word.




A green portion of an eleventh pixel (VD


11


-G) is stored in a register corresponding to a first byte of a first quad word. A ninth pixel (VD


9


) is stored on an upper boundary of a lower double word of the first quad word. A red portion of the eleventh pixel (VD


11


-R) is stored as a lower byte of an upper double word of the first quad word. A tenth pixel (VD


10


) is stored on an upper boundary of the upper double word of the first quad word.




A blue portion of the eleventh pixel (VD


11


-B) is stored as a lower byte of a second quad word. A twelfth pixel (VD


12


) is stored on an upper boundary of a lower double word of the second quad word. A red portion of a fourteenth pixel (VD


14


-R) is stored as a lower byte of an upper double word of the second quad word. A thirteenth pixel (VD


13


) is stored on an upper boundary of the upper double word of the second quad word.




A blue portion of the fourteenth pixel (VD


14


-B) is stored as a lower byte of a third quad word. A fifteenth pixel (VD


15


) is stored on an upper boundary of a lower double word of the third quad word. A green portion of the fourteenth pixel (VD


14


-G) is stored as a lower byte of an upper double word of the third quad word. A sixteenth pixel (VD


16


) is stored on an upper boundary of the upper double word of the third quad word. Using the same technique, any remaining pixels are stored in registers and coupled to the appropriate frame buffer through the FIFO buffer.




An advantage of the disclosed embodiment is that it simplifies the hardware required to reorient the pixel data, before display, while maintaining efficient packing of twenty-four bit pixel data into video memory. In the disclosed embodiment, two 8-bit multiplexers and two 24-bit multiplexers perform all the routing necessary to pack eight 24-bit pixels into three 64-bit quad words. To “linearly” pack the pixels would typically employ a greater number of multiplexers.




The foregoing disclosure and description of the invention are illustrative and explanatory thereof, and various changes in the size, shape, materials, components, circuit elements, wiring connections and contacts, as well as in the details of the illustrated circuitry and construction and method of operation may be made without departing from the spirit of the invention.












APPENDIX A











/********************************************************************/













/*




VSCALE Module




*/













/*




functional description: Request state machine front end.




*/











/********************************************************************/






module vscale (aready_, bready_, veraren_, verbren_, memren_ , imagwen_,













clrhrowardy]hd ]13 ]l , clrhrowbrdy]hd ]13 ]l , memwe]hd ]13 ]l , memdat[63:0]9 ,







startadd[17:5], endadd[17:5], clrframecnt,







dataouta[23:0], dataoutb[23:0],







clraready_ , clrbready_ , hrowardy_ , hrowbrdy_







onemode, loadmode_ , vres[10;0], multreg[13:0],







memrena_ , memrenb_ , imagwena_ , imagwenb_ , reset_ ,







vclk1, vclk2, vclk3, vclk4, phase, sclk);












output




aready_ , bready_, veraren_ , verbren_ , memren_ , imagwen_,













clrhrowardy_ , clrhrowbrdy_ , memwe_ , clrframecnt;












output[63:0]




memdat;






output[17:5]




startadd, endadd;












input




clraready_ , clrbready_ , hrowardy_ , hrowbrdy_ , onemode, loadmode_ ,













memrena_ , memrenb_ , imagwena_ , imagwenb_ , reset_ ,







vclk1, vclk2, vclk3, vclk4, phase, sclk;












input[23:0]




dataouta, dataoutb,






input[13:0]




multreg;






input[10:0]




vres;






wire [23:0]




nreg1, preg1, nreg2, preg2, nreg3, preg3, nreg4, preg4,













vdatreg1, vdatreg2, vdatreg3, vdatreg4;












wire [3:0]




nvctrl, pvctrl;












wire [13:11]




mult;












wire [10:0]




invert;






wire [7:0]




vbufregc;






wire [15:0]




vbufregb;











vextcnt vextcnt1x(nregl[23:0], preg1[23:0],













dataouta[23:0], dataoutb[23:0], aprev, vclk1, sclk);











vextcnt vextcnt2x(nreg2[23:0], preg2[23:0],













dataouta[23:0], dataoutb[23:0], aprev, vclk2, sclk);











vextcnt vextcnt3x(nreg3[23:0], preg3[23:0],













dataouta[23:0], dataoutb[23:0], aprev, vclk3, sclk);











vextcnt vextcnt4x(nreg4[23:0]; preg4[23:0],













dataouta[23:0], dataoutb[23:0], aprev, vclk4, sclk);











vextrap vextrap1x(vdatreg1[23:0],













nreg1[23:0], preg1[23:0], nvctrl[3:0], pvctrl[3:0]);











vextrap vextrap2x(vdatreg2[23:0],













nreg2[23:0], preg2[23:0], nvctrl[3:0], pvctrl[3:0]);











vextrap vextrap3x(vdatreg3[23:0],













nreg3[23:0], preg3[23:0], nvctrl[3:0], pvctrl[3:0]);











vextrap vextrap4x(vdatreg4[23:0],













nreg4[23:0], preg4[23:0], nvctrl[3:0], pvctrl[3:0]):











vrencon vrenconx(nvctrl[3:0], pvctrl[3:0], aready_ , bready_,













veraren_ , verbren_ , vwenable_ , clrhrowardy_ , clrhrowbrdy_ ,







clrmult, incmult, clrframecnt, incrframecnt,







vclrcnt, vincrcnt, incadder, decadder, aprev,







vres[10], vcnt8, clraready_ , clrbready_, hrowardy_,







mult[13:11], hrowbrdy_, onemode, loadmode_ , adder10,







addgrt0, framecnt10, vclk4, sclk);











vrenadd vrenaddx (adder10, addgrt0,













invert[10:0], vres[10:0], clrframecnt, incadder, decadder,







onemode, phase, sclk);











vrfram vrframx(framecnt10, invert[10:0],













vres[10:0], clrframecnt, incrframecnt, onemode, sclk);











vrmult vrmultx(mult[13:11],













multreg[13:0], clrmult, incmult, onemode, sclk);











vrstart vrstartx(startadd[17:5], endadd[17:5],













invert[9:1]);











vrvcnt vrvcntx(vcnt8,













vclrcnt, vincrcnt, sclk);











exttmcnt exttmcntx(memwe_ , clkenl, clkenh, muxeq2, muxeq5, muxeq3,






muxeq6,













muxeq4, muxeq7,







vwenable_ , reset_ , vclk1, vclk4, sclk);











vdatreg vdatregx(vbufregc[7:0], vbufregb[15:0], memren_ , imagwen_ ,













vdatreg2[15:0], vdatreg3[7:0], memrena_ , memrenb_ ,







imagwena_ , imagwenb_ , sclk);











exttmem1 exttmem1x(memdat[31:0],













vdatreg1[23:0], vdatreg3[23:0], vdatreg4[23:0],







vbufregb[7:0], vbufregc[7:0], clkenl,







muxeq2, muxeq3, muxeq6, sclk);











exttmem2 exttmem2x(memdat[63:32],













vdatreg1[23:0], vdatreg2[23:0], vdatreg3[23:16],







vdatreg4[23:0], vbufregb[15:8], clkenh,







muxeq2, muxeq5, muxeq6, muxeq4, muxeq7, sclk);











endmodule






/*-------------------------------------------------------------------*/












/*  end of module: vscale




*/











/*********************************************************************/













/*********************************************************************/













/*




VDATREG Module




*/













/*




functional description: Request state machine front end.




*/











/*-------------------------------------------------------------------*/






module vdatreg (vbufregc, vbufregb, memren_, imagwen_ ,













vdatreg2, vdatreg3, memrena_ , memrenb_ , imagwena_ ,







imagwenb_ , clk);











input memrena_, memrenb_, imagwena_ , imagwenb_, clk;












input[15:0]




vdatreg2;






input[7:0]




vdatreg3;






output




memren_ , imagwen_ ;






output [7:0]




vbufregc;












output [15:0]




vbufregb;












reg[7:0]




vbufregc;






reg[15:0]




vbufregb;











wire memren_ = memrena_ && memrenb_ ;






wire imagwen_ = imagwena_ && imagwenb_ ;






always @(posedge clk)






begin













vbufregc[7:0] <= vdatreg3[7:0];







vbufregb[15:0] <= vdatreg2[15:0];











end






endmodule






/*-------------------------------------------------------------------*/












/*    end of module: vdatreg




*/











/*********************************************************************/













/*********************************************************************/













/*




EXTTMCNT Module




*/













/*




functional description: Request state machine front end.




*/











/*-------------------------------------------------------------------*/






module exttmcnt (memwe_ , clkenl, clkenh, muxeq2, muxeq5, muxeg3,













muxeq6, muxeq4, muxeq7,







vwenable_ , reset_ , vclk1, vclk4, clk);











input vwenable_ , reset_ , vclk1, vclk4, clk;












output




memwe_ , clkenl, clkenh, muxeq2, muxeq5, muxeq3, muxeq6,













muxeq4, muxeq7;












reg[2:0]




muxcnt;












reg




d_clrmux, clrmux, d_ incrmux, incrmux, d_state, state, memwe_ ,







clkenl, clkenh, muxeq2, muxeq3, muxeq4, muxeq5, muxeq6,







muxeq7, clkenwe;












parameter




IDLE = 0;






parameter




RUN = 1;











always @(posedge clk)






begin













clrmux <= d_ clrmux;







incrmux <= d_ incrmux;











end






always @(posedge clk or negedge reset_ )






begin













if (!reset_ )













state <= IDLE;













else













state <= d_ state;











end






wire [2:0] muxcntp1 = muxcnt[2:0] + 1;






always @(posedge clk)






begin













if (clrmux)







begin













muxcnt[2:0] <= 3′h0;







clkenl <= 1;







clkenh <= 0;







clkenwe <= 0;







muxeq2 <= 0;







muxeq5 <= 0;







muxeq3 <= 0;







muxeq6 <= 0;







muxeq4 <= 0;







muxeq7 <= 0;













end







else if (incrmux)







begin













muxcnt[2:0] <= muxcntp1[2:0];







clkenl <= (muxcnt[2:0] == 3′h7);







clkenh <= (muxcnt[2:0] == 3′h0);







clkenwe <= (muxcnt[2:0] == 3′h1) ∥ (muxcnt[2:0] == 3′h4)

























(muxcnt[2:0] == 3′h6);







muxeq2 <= (muxcnt[2:0] == 3′h1);







muxeq5 <= (muxcnt[2:0] == 3′h4);







muxeq3 <= (muxcnt[2:0] == 3′h2);







muxeq6 <= (muxcnt[2:0] == 3′h5);







muxeq4 <= (muxcnt[2:0] == 3′h3);







muxeq7 <= (muxcnt[2:0] == 3′h6);













end











end






always @(posedge clk)






begin













if (clkenwe)













memwe_ <= 0;













else













memwe_ <= 1;











end






always @(state or incrmux or vwenable_ or vclk1 or vclk4 or clrmux or muxcnt)






begin













d_ state = state;







d_ incrmux = incrmux;







d_ clrmux = clrmux;












case (state)




//synopsys parallel_ case full_ case






IDLE:






begin













d_ clrmux = 1;







d_ incrmux = 0;







if (!vwenable_ && vclk1 && vclk4)







begin













d_ state = RUN;







d_ incrmux = 1;







d_ clrmux = 0;













end











end






RUN:






begin













if (vwenable_ && vclk1 && vclk4 && muxcnt[2])













d_ state = IDLE;











end






endcase






end






endmodule






/*-------------------------------------------------------------------*/












/*   end of module: exttmcnt




*/











/*********************************************************************/













/*********************************************************************/













/*




EXTTMEM1 Module




*/













/*




functional description: Request state machine front end.




*/











/*********************************************************************/






module exttmem1 (memdat,













vdatrega, vdatregc, vdatregd, vbufregb, vbufregc, clkenl,







muxeq2, muxeq3, muxeq6, clk);











input clkenl, muxeq2, muxeq3, muxeq6, clk;












input[23:0]




vdatrega, vdatregc, vdatregd;






input[7:0]




vbufregb, vbufregc;












output[31:0]




memdat;












reg[31:0]




memdat;











always @(posedge clk)






begin













if (clkenl)













memdat[31:8] <= vdatrega[23:0];













if (muxeq2)













memdat[7:0] <= vdatregc[15:8];













if (muxeq3)







begin













memdat[7:0] <= vbufregc[7:0];







memdat[31:8] <= vdatregd[23:0];













end







if (muxeq6)







begin













memdat[7:0] <= vbufregb[7:0];







memdat[31:8] <= vdatregc[23:0];













end











end






endmodule






/*-------------------------------------------------------------------*/












/*    end of module: exttmem1




*/











/*********************************************************************/













/*********************************************************************/













/*




EXTTMEM2 Module




*/













/*




functional description: Request state machine front end.




*/











/*********************************************************************/






module exttmem2 (memdat,













vdatrega, vdatregb, vdatregc, vdatregd, vbufregb, clkenh,







muxeq2, muxeq5, muxeq6, muxeq4, muxeq7, clk);











input clkenh, muxeq2, muxeq5, muxeq6, muxeq4, muxeq7, clk;












input[23:0]




vdatrega, vdatregb, vdatregd;












input[23:16]




vdatregc;












input[15:8]




vbufregb;












output[63:32]




memdat;












reg[63:32]




memdat;











always @(posedge clk)






begin













if (clkenh)













memdat[63:40] <= vdatregb[23:0];













if (muxeq4)













memdat[63:40] <= vdatrega[23:0];













if (muxeq7)













memdat[63:40] <= vdatregd[23:0];













if (muxeq2)













memdat[39:32] <= vdatregc[23:16];













if (muxeq5)













memdat[39:32] <= vdatregb[23:16];













if (muxeq6)













memdat[39:32] <= vbufregb[15:8];











end






endmodule






/*-------------------------------------------------------------------*/












/*   end of module: exttmem2




*/











/*********************************************************************/













Claims
  • 1. A method of storing eight twenty-four bit pixels into three quad words of video memory, the method comprising the steps of:dividing two of the eight twenty-four bit pixels into constituent eight bit representations of each of three primary pixel colors; and storing two undivided pixels and two of the constituent eight bit representations of the divided pixels within each of the quad words.
  • 2. The method of claim 1, wherein each of the two undivided pixels are stored on a double word boundary.
  • 3. The method of claim 1, wherein each of the twenty-four bit pixels are comprised of eight red bits, eight green bits, and eight blue bits.
  • 4. The method of claim 1, wherein the two undivided pixels are stored on an upper boundary of each double word of each of the quad words.
  • 5. The method of claim 1, wherein the eight twenty-four bit pixels are transmitted through four twenty-four bit pixel pipes, and wherein the four twenty-four bit pixel pipes are coupled to multiplexing hardware which provides for storage within one of the quad words.
  • 6. The method of claim 5, wherein the four twenty-four bit pixel pipes are provided asynchronously.
  • 7. The method of claim 5, wherein the multiplexing hardware further includes:a first multiplexer that multiplexes a first pixel pipe, a third pixel pipe, and a fourth pixel pipe to a lower double word of each of the quad words; a second multiplexer that multiplexes the first pixel pipe, a second pixel pipe, and the fourth pixel pipe to an upper double word of each of the quad words; a third multiplexer that multiplexes a blue portion of the second pixel pipe, a blue portion of the third pixel pipe, and a green portion of the third pixel pipe to a byte of the lower double word of one of the quad words; and a fourth multiplexer that multiplexes a green portion of the second pixel pipe, a red portion of the second pixel pipe, and a red portion of the third pixel pipe to a byte of the upper double word of one of the quad words.
  • 8. A display controller with the capability of storing eight twenty-four bit pixels into three quad words of video memory, the display controller including:logic for dividing two of the eight twenty-four bit pixels into constituent eight bit representations of each of three primary pixel colors; and logic for storing two undivided pixels and two of the constituent eight bit representations of the divided pixels within each of the quad words.
  • 9. The display controller of claim 8, wherein each of the two undivided pixels are stored on a double word boundary.
  • 10. The display controller of claim 8, wherein each of the twenty-four bit pixels are comprised of eight red bits, eight green bits, and eight blue bits.
  • 11. The display controller of claim 8, wherein the two undivided pixels are stored on an upper boundary of each double word of each of the quad words.
  • 12. The display controller of claim 1, wherein the eight twenty-four bit pixels are transmitted through four twenty-four bit pixel pipes, and wherein the four twenty-four bit pixel pipes are coupled to multiplexing hardware which provides for storage within one of the quad words.
  • 13. The display controller of claim 12, wherein the four twenty-four bit pixel pipes are provided asynchronously.
  • 14. The display controller of claim 12, wherein the multiplexing hardware further includes:a first multiplexer that multiplexes a first pixel pipe, a third pixel pipe, and a fourth pixel pipe to a lower double word of each of the quad words; a second multiplexer that multiplexes the first pixel pipe, a second pixel pipe, and the fourth pixel pipe to an upper double word of each of the quad words; a third multiplexer that multiplexes a blue portion of the second pixel pipe, a blue portion of the third pixel pipe, and a green portion of the third pixel pipe to a byte of the lower double word of one of the quad words; and a fourth multiplexer that multiplexes a green portion of the second pixel pipe, a red portion of the second pixel pipe, and a red portion of the third pixel pipe to a byte of the upper double word of one of the quad words.
  • 15. A computer system with the capability of storing eight twenty-four bit pixels into three quad words of video memory, the computer system comprising:a bus; a processor coupled to the bus; and a display controller coupled to the bus, the display controller including: logic for dividing two of the eight twenty-four bit pixels into constituent eight bit representations of each primary pixel color; and logic for storing two undivided pixels and two of the constituent eight bit representations of the divided pixels within each of the quad words.
  • 16. The computer system of claim 15, wherein each of the two undivided pixels are stored on a double word boundary.
  • 17. The computer system of claim 15, wherein each of the twenty-four bit pixels are comprised of eight red bits, eight green bits, and eight blue bits.
  • 18. The computer system of claim 15, wherein the undivided pixels are stored on an upper boundary of each double word of each of the quad words.
  • 19. The computer system of claim 15, wherein the eight twenty-four bit pixels are transmitted through four twenty-four bit pixel pipes, and wherein the four twenty-four bit pixel pipes are coupled to multiplexing hardware which provides for storage within one of the quad words.
  • 20. The computer system of claim 19, wherein the four twenty-four bit pixel pipes are provided asynchronously.
  • 21. The computer system of claim 19, wherein the multiplexing hardware further includes:a first multiplexer that multiplexes a first pixel pipe, a third pixel pipe, and a fourth pixel pipe to a lower double word of each of the quad words; a second multiplexer that multiplexes the first pixel pipe, a second pixel pipe, and the fourth pixel pipe to an upper double word of each of the quad words; a third multiplexer that multiplexes a blue portion of the second pixel pipe, a blue portion of the third pixel pipe, and a green portion of the third pixel pipe to a byte of the lower double word of one of the quad words; and a fourth multiplexer that multiplexes a green portion of the second pixel pipe, a red portion of the second pixel pipe, and a red portion of the third pixel pipe to a byte of the upper double word of one of the quad words.
  • 22. A display with the capability of storing eight twenty-four bit pixels into three quad words of video memory, the display including:a display screen; and a display controller, the display controller further including: logic for dividing two of the eight twenty-four bit pixels into constituent eight bit representations of each of three primary pixel colors; and logic for storing two undivided pixels and two of the constituent eight bit representations of the divided pixels within each of the quad words.
  • 23. The display of claim 22, wherein each of the two undivided pixels are stored on a double word boundary.
  • 24. The display of claim 22, wherein each of the twenty-four bit pixels are comprised of eight red bits, eight green bits, and eight blue bits.
  • 25. The display of claim 22, wherein the two undivided pixels are stored on an upper boundary of each double word of each of the quad words.
  • 26. The display of claim 22, wherein the eight twenty-four bit pixels are transmitted through four twenty-four bit pixel pipes, and wherein the four twenty-four bit pixel pipes are coupled to multiplexing hardware which provides for storage within one of the quad words.
  • 27. The display of claim 26, wherein the four twenty-four bit pixel pipes are provided asynchronously.
  • 28. The display of claim 26, wherein the multiplexing hardware further includes:a first multiplexer that multiplexes a first pixel pipe, a third pixel pipe, and a fourth pixel pipe to a lower double word of each of the quad words; a second multiplexer that multiplexes the first pixel pipe, a second pixel pipe, and the fourth pixel pipe to an upper double word of each of the quad words; a third multiplexer that multiplexes a blue portion of the second pixel pipe, a blue portion of the third pixel pipe, and a green portion of the third pixel pipe to a byte of the lower double word of one of the quad words; and a fourth multiplexer that multiplexes a green portion of the second pixel pipe, a red portion of the second pixel pipe, and a red portion of the third pixel pipe to a byte of the upper double word of one of the quad words.
US Referenced Citations (3)
Number Name Date Kind
5696945 Seiler et al. Dec 1997
5742298 Bril et al. Apr 1998
5812147 Hook et al. Sep 1998