Digital television data format conversion with automatic parity detection

[0002] 1. Field of the Invention

[0003] The present invention relates to digital television data reception by computer systems, and more particularly to digital television data format conversion with automatic parity detection.

[0004] 2. Description of the Related Art

[0005] The advent of digital television technology has presented significant opportunities for the computer industry. Computer systems are expected by many to join traditional consumer television products as mainstream devices for receiving digital television (DTV) signals. A DTV-enabled computer system will likely include a DTV receiver for receiving DTV signals.

[0006] While analog television signals have generally been homogeneous in data format, digital television has permitted various data formats of DTV signals. In industry today, for example, some equipment transmits a DTV data stream in a serial data format. Certain other equipment though has expected to receive a DTV data stream in a parallel data format. Also, serial DTV data streams outputted by equipment may or may not include parity data for error correction.

[0007] DTV data broadcasters will soon provide DTV data streams to DTV decoders within computer systems. A DTV data broadcaster may directly provide a serial DTV data stream to the DTV decoder. Alternatively, the DTV data broadcaster may provide a serial DTV data stream to a television tuner which then provides the serial DTV data stream to the DTV decoder. If the DTV data broadcaster intended a serial DTV data stream to be delivered directly to the DTV decoder, then the serial DTV data stream has not included parity data. If the DTV data broadcaster intended a serial DTV data stream to be transmitted over the air to a television tuner, then the serial DTV data stream has included parity data. The television tuner has used the parity data to perform the necessary error correction. The tuner typically provided an 8-bit parallel DTV data stream to the DTV decoder. While the DTV decoder has not utilized the parity data, the DTV decoder has expected the size of the DTV data stream to reflect inclusion of parity data. A DTV data stream without parity data has typically occupied 188 bytes, and a DTV data stream with parity data has typically occupied 204 bytes. If a DTV data stream including no parity data has been provided directly to the DTV decoder, the DTV decoder has not operated properly.

[0008] When a DTV data stream has been provided to a DTV decoder of a computer system, it has not been known beforehand whether the DTV data stream contained parity data.

[0009] Briefly, in accordance with the present invention, a digital television (DTV) data format converter of a system automatically detects whether a serial DTV data stream includes parity data and converts the serial DTV data stream to a parallel DTV data stream. The DTV data format converter provides one transmission protocol if the serial DTV data stream includes parity data and provides a different transmission protocol if the serial DTV data stream does not include parity data. In this way, the system accommodates a serial DTV data stream with or without parity data. The DTV data format converter may be implemented in the form of a peripheral component interconnect (PCI) card, permitting compatibility with computer systems and other PCI-based systems.

[0010] A disclosed embodiment of the DTV data format converter includes a DTV data format converter receiver block for receiving a serial DTV data stream and detecting whether the serial DTV data stream includes parity. The converter also includes a DTV data format converter buffer for loading the serial DTV data stream from the receiver block. The converter further includes a DTV data format converter transmitter block for reading the serial DTV data stream out of the buffer and transmitting a parallel DTV data stream corresponding to the serial DTV data stream. If the serial DTV data stream includes parity data, the transmitter block transmits the parallel DTV data stream converted from the serial DTV data stream in accordance with a first conversion protocol. If the serial DTV data stream does not include parity data, the transmitter block transmits the parallel DTV data stream converted from the serial DTV data stream in accordance with a second conversion protocol.

[0011] 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:

[0012] FIG. 1 is a block diagram of a computer system incorporating a DTV data format converter in accordance with the present invention;

[0013] FIG. 2 is a schematic block diagram of an exemplary embodiment of the converter of FIG. 1;

[0014] FIG. 3 is an exemplary illustration of a parity serial DTV data stream and a non-parity serial DTV data stream received by the converter of FIG. 2;

[0015] FIG. 4 is an exemplary state diagram of the DTV data format converter transmitter block of FIG. 2;

[0016] FIG. 5 is an exemplary flow chart for the WRT state of FIG. 4;

[0017] FIG. 6 is an exemplary flow chart for the WRT2 state of FIG. 4;

[0018] FIG. 7 is an exemplary state diagram of the receiver block of FIG. 2;

[0019] FIG. 8 is an exemplary flow chart for the IDLER state of FIG. 7;

[0020] FIG. 9 is an exemplary flow chart for the READ state of FIG. 7;

[0021] FIG. 10 is an exemplary flow chart for the READ2 state of FIG. 7; and

[0022] FIG. 11 is an exemplary flow chart for the WAIT state of FIG. 7.

[0023] Turning now to the drawings, FIG. 1 shows a computer system C incorporating a digital television (DTV) data format converter 18 in accordance with the present invention. The computer system C includes a peripheral component interconnect (PCI) bus 12 coupled to a graphics subsystem 15, a hard drive 17, and a core logic 16. The microprocessor 10, the system memory 14, and the core logic 16 are of a conventional type. An example of suitable core logic is Intel's 440BX. The core logic 16 is coupled upstream to a memory 14 and a microprocessor (CPU) 10. The core logic 16 is coupled through a PCI interface 11 to the converter 18. The converter 18 receives a serial DTV data stream from a video server or other DTV data transmitter and converts the serial DTV data stream to a parallel DTV data stream. An example of a suitable video server is a MTS 100 system available from Tektronix, Inc. for providing MPEG transport streams. The converter 18 accomplishes automatic parity detection and playback of the serial DTV data stream provided by the video server. The converter 18 also receives a serial clock from the video server. In the disclosed embodiment, the converter 18 is implemented in a programmable logic device (PLD) on a PCI card. An example of a suitable PLD is Altera's EPM7064. The converter 18 provides the parallel DTV data stream to a DTV decoder 20. The DTV decoder 20 is preferably a MPEG-2 video decoder, but may be of other types, such as an MPEG-1 video decoder. An example of a suitable video decoder is the SAA7111 available from Phillips Semiconductor. The DTV decoder 20 provides decoded DTV data to the graphics subsystem 15 which provides the DTV data to a monitor (not shown).

[0024] Referring to FIG. 2, an exemplary DTV data format converter 18 is shown. The DTV data format converter 18 is designed to accomplish DTV data format conversion with automatic parity detection for serial DTV data streams. The converter 18 includes a DTV converter receiver block 22 for receiving a serial DTV data stream. The receiver block 22 includes a serial data capture register 28 for holding a portion of the serial DTV data stream. In the disclosed embodiment, the capture register 28 is a byte wide register. The receiver block 22 provides the serial DTV data stream to a DTV data format converter buffer 26. In the disclosed embodiment, the buffer 26 is implemented as a byte wide FIFO. A byte of DTV data is loaded to the buffer 26 after 8 bits have been shifted into the capture register 28. The buffer 26 allows a transmission DTV data rate to be decoupled from a reception DTV data rate. The serial DTV data stream may be provided from the DTV converter buffer 26 to a DTV converter transmitter block 24. Although the converter buffer 26 is shown separately from the receiver block 22 and the transmitter block 24, it should be understood that the converter buffer 26 may be integrated within either the receiver block 22 or the transmitter block 24. It should further be understood that a serial to parallel load register (not shown) may be provided between the capture register 28 and the buffer 26.

[0025] When the receiver block 22 is ready to provide a serial DTV data stream to the converter buffer 26, the receiver block 22 asserts a write enable signal WEN_ to the converter buffer 26. When the transmitter block 24 is ready to read the serial DTV data stream from the converter buffer 26, the transmitter block asserts a read enable signal REN_ to the converter buffer 26. As explained below, the receiver block 22 is able to detect whether parity data is present in the serial DTV data stream. Also as explained below, the transmitter block 24 transmits a parallel DTV data stream converted from the serial DTV data stream in accordance with one conversion protocol if a serial DTV data stream includes parity data. If a serial DTV data stream does not include parity data, the transmitter block 24 transmits a parallel DTV data stream converted from the serial DTV data stream in accordance with another conversion protocol. The converter 18 thus may handle a serial DTV data stream with or without parity data.

[0026] The converter 18 further includes a serial clock 30 and an oscillator 32. If a serial DTV data stream does not include parity, the oscillator 32 serves as the clock for providing the transmission frequency of the parallel DTV data stream. In such a non-parity mode, the transmission frequency of the parallel DTV data streams including parity data may be synchronized with the reception frequency of serial DTV data streams. In the disclosed embodiment, the reception frequency of a serial DTV data stream is 19.3 MHz, and the transmission frequency for the parity mode is 2.4125 MHz (⅛th of the reception frequency). If a serial DTV data stream does include parity, then the serial clock 30 serves as the clock for providing the transmission frequency for the parallel DTV data stream. During such a parity mode of the transmitter block 24, the transmitter block can send DTV data at any frequency the decoder 20 needs. A system clock BCK combines the functions of the two clocks 30 and 32. Although shown outside the transmitter block 24, the clocks 30 and 32 may be incorporated into the transmitter block 24. It should be understood that configurations of the converter 18 other than that represented in FIG. 2 are possible.

[0027] Referring to FIG. 3, a parity serial DTV data stream 36 and a non-parity serial DTV data stream 34 are shown. In the disclosed embodiment, a packet of parity serial DTV data includes 187 frames or bytes, and a packet of non-parity serial DTV data includes at least 204 frames. For the first 187 frames, a parity serial DTV data stream and a non-parity serial DTV data stream have an identical data format. The first byte, or byte 0, of both data streams represents the start byte. Frames 1-187 of both streams represent serial DTV data. In the disclosed embodiment, the start byte is ‘47’ in decimal or ‘01000111’ in binary.

[0028] The receiver block 22 (FIG. 2) distinguishes between the parity serial DTV data stream 36 and a non-parity serial DTV data stream 34 based on a test frame 188. If a serial DTV data stream provides a start byte in frame 188, then the serial DTV data stream does not include parity data. If a serial DTV data stream does not provide a start byte in frame 188, then the serial DTV data stream includes parity data. It should be understood that the packet size, start byte representation, and test frame for detecting parity shown in FIG. 3 are exemplary and illustrative.

[0029] Referring to FIG. 4, an exemplary state diagram for the receiver block 22 (FIG. 2) is shown. The receiver block 22, or receiver state machine, begins in an IDLE state. Upon detection of a start byte, the receiver block 22 transitions from the IDLE state to a WRT state. If another start byte is detected directly after an end of a packet (EOP), which would indicate that the serial DTV data stream includes parity (PARITY), then the receiver block 22 transitions from the WRT state to the WRT2 state. If a start byte is not detected directly after an end of a packet (EOP), indicating a serial DTV data stream does not include parity data (NON-PARITY), then the receiver block 22 transitions from the WRT state back to the IDLE state. For a non-parity serial DTV data stream, the receiver block 22 transitions back and forth between the IDLE state and the WRT state.

[0030] Once the receiver block 22 enters the WRT2 state, then the receiver block 22 remains in the WRT2 state, with the exception of a hard reset signal RESET described below. Within both the WRT state and the WRT2 state, serial DTV data is captured in the capture register 28 (FIG. 2). The WRT2 state represents a parity mode of the receiver block 22.

[0031] In the disclosed embodiment, the converter 18 supports a hard reset signal RESET for resetting the converter 18 to a known state when an input clock to the converter 18 stops. An assertion of the reset signal RESET in either the WRT state or the WRT2 state transitions the receiver block 22 to the IDLE state.

[0032] Referring to FIG. 5, an exemplary flow chart for the WRT state is shown. Beginning in step 38, it is determined if a byte is ready to be stored. If a byte is ready to be stored, then control proceeds to step 40. In step 40, the serial DTV data stream is loaded to the capture register 28 (FIG. 2). Serial DTV data is thus captured byte-by-byte. Next, control proceeds to step 42 where the write enable signal WR_ is asserted to the buffer 26. Control then proceeds to step 44 where the DTV data is written from the capture register 28 to the buffer 26. Next, in step 46, the write enable signal WR_ is deasserted. In step 38, if a byte is not ready to be stored, then control remains at step 38.

[0033] From step 46, control proceeds to step 48 where it is determined if an end of a packet (EOP) has been reached. If the end of a packet (EOP) is detected, then control proceeds to step 50. In step 50, it is determined if a start byte is detected. If a start byte is detected, indicating non-parity serial DTV data, then control proceeds to step 52 where a GO signal is strobed. The use of the GO signal is explained below. If an end of a packet (EOP) is not detected in step 48, then control returns to step 38 to wait for a next byte. From step 52, control also proceeds to step 53 where the WRT state is completed. If a start byte is not detected in step 50, then control proceeds to the WRT2 state (FIG. 6).

[0034] Referring to FIG. 6, an exemplary flow chart for the WRT2 state is shown. Beginning at step 54, it is determined if a byte is detected. If it is determined that a byte is not detected, then control remains at step 54. If a byte is detected, then control proceeds to step 56 where serial DTV data is loaded to the capture register 28 (FIG. 2). As noted above, the WRT2 state represents the parity mode of the receiver block 22. Next, control proceeds to step 58 where the write enable signal WEN_ is asserted to the buffer 26. From step 58, control passes to step 60 where the DTV data is written from the capture register 28 to the buffer 26. Next, in step 62, the write enable signal WEN_ is deasserted to the buffer 26. From step 62, control proceeds to step 64. In step 64, it is determined if an end of a packet (EOP) has been reached. If an end of a packet (EOP) is detected, then control proceeds to step 66 where the GO signal is strobed. If an end of a packet (EOP) is not detected in step 64, then control proceeds to step 68 to await a next captured byte. From step 66, control returns to step 54.

[0035] Referring to FIG. 7, an exemplary state diagram of the transmitter block 24 (FIG. 2), or transmitter state machine, is shown. The transmitter block 24 begins in an IDLER state. The transmitter block 24 determines whether the converter 18 is in a parity mode or a non-parity mode based on a parity enable signal (PARITY ENABLE). The state of the parity enable signal is set based on detection of a start byte by the receiver block 22. If the converter 18 is in a parity mode (PARITY ENABLE), then the transmitter block 24 transitions from the IDLER state to a READ2 state. If the converter 18 is in a non-parity mode (NO PARITY ENABLE), then the transmitter block 24 transitions from the IDLER state to a READ state. Within both the READ and the READ2 state, DTV data is read out of the buffer 26. In the disclosed embodiment, on each falling edge of the system clock BCK, a next byte is read out of the buffer 26 until a full packet is transmitted.

[0036] For the READ2 state, when an end of a packet (EOP) is reached, the transmitter block 24 transitions from the READ2 state to a WAIT state. During the WAIT state, the transmitter block 24 prepares for another packet of data. After the WAIT state, the transmitter block 24 transitions back and forth between the READ2 state and the WAIT state.

[0037] During the READ state, a predetermined number of non-enable clocks are generated as dead time. This dead time ensures that a parallel DTV data stream includes the appropriate number of clocks. The dead time, in effect, serves as fake parity. When an end of packet (EOP) and an end of the dead time (EODT) is reached in the READ state, the transmitter block 24 transitions from the READ state back to the IDLER state. Thus, during a non-parity mode of the converter 18, the transmitter block 24 transitions back and forth between the IDLER state and the READ state. Referring to FIG. 8, an exemplary flow chart for the IDLER state is shown. Beginning at step 70, the read enable signal REN_ to the buffer 26 is deasserted. Control next passes to step 74 where it is determined if the GO signal from the receiver block 22 is asserted. The GO signal informs the transmitter block 24 to begin transmission of the DTV data in the buffer 26. If the GO signal is asserted, then control proceeds to step 76 where a CLEAR signal is asserted. The CLEAR signal when asserted clears the GO signal. If it is determined in step 74 that the GO signal is deasserted, then control proceeds to step 78 where the IDLER state is completed. Control also terminates through step 78 from step 76.

[0038] Referring to FIG. 9, an exemplary flow chart for the READ state is shown. The READ state represents the non-parity mode of the transmitter block 24. Beginning in step 80, the “ENABLE” signal is asserted to the decoder 20. The “ENABLE” signal notifies the decoder 20 of valid data. From step 80, control proceeds to step 81 where the read enable signal REN_ is asserted. Next, in step 82, the CLEAR signal is deasserted. Control then passes to step 84 where the DTV data is read from the buffer 26 by the transmitter block 24. Next, in step 86 it is determined if an end of a packet (EOP) is detected. If an end of a packet (EOP) is not detected, then control returns to step 84. In step 86, if an end of a packet (EOP) is detected, then control proceeds to step 88 where the “ENABLE” signal to the decoder 20 is deasserted. From step 88, control proceeds to step 90 where the read enable signal REN_is deasserted. From step 90, control proceeds to step 94 where the READ state is completed.

[0039] Referring to FIG. 10, an exemplary flow chart for the READ2 state is shown. The READ2 state represents the parity mode of the transmitter block 24. Beginning at step 96, the READ enable signal REN_ is asserted. Next, control proceeds to step 98 where the “ENABLE” signal to the decoder 20 is asserted. Control then passes to step 100 where the CLEAR signal is deasserted. From step 100, control passes to step 106. In step 106, DTV data in the form of valid data and parity bytes is read out of the buffer 26. Next, in step 108, it is determined if an end of a packet (EOP) is detected. If an end of a packet (EOP) is not detected, then control jumps back to step 106. If an end of a packet (EOP) is detected, then control proceeds to step 110 where the “ENABLE” signal is deasserted to the decoder 20. From step 110, control proceeds to step 112 where the READ2 state is completed.

[0040] Referring to FIG. 11, an exemplary flow chart for the WAIT state is shown. Beginning at step 114, the read enable signal REN_ to the buffer 26 is kept asserted. Control then proceeds to step 116 where the “ENABLE” signal to the decoder 20 is asserted. In this way, the decoder 20 is informed that any data which follows is valid. From step 116, control proceeds to step 120 where the WAIT state is completed. It should be understood that the order of the operational steps for the flow charts described herein may vary. The state machines 22 and 24 described herein represent the conversion protocols for converting a serial DTV data stream with or without parity to a parallel DTV data stream.

[0041] Provided below is exemplary hardware description code (in this case, Verilog) for the transmitter block 24 and the receiver block 22 along with a table providing general descriptions for the variables within the code. Those skilled in the art will readily relate and correlate the table and code below with the other disclosure provided herein. It should be apparent to those skilled in the art that other implementations of the converter 18 are possible.

[0042] Although a computer system in accordance with the present invention is illustrated, it should be understood that the present invention is applicable to other DTV data handling systems, particularly PCI-based systems. It should further be understood that other circuitry and techniques of accomplishing DTV data format conversion with automatic parity detection according to the invention are possible.

[0043] The disclosure and description of the preferred embodiment are illustrative and explanatory thereof, and various changes in the variables, parameters, steps, fields, data types, code elements, code size, buffer size, register size, packet size, connections, components, logic, and signals, 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.