 |
Claims  |
|
|
What is claimed is:
1. A method for managing digital transport packet distribution in a
transport packet demultiplexing system, wherein the transport packet
demultiplexing system receives a transport stream including digital
transport packets each identified by a packet identifier (PID), the method
comprising:
generating an address index for each of the transport packets based on the
PID, wherein the address index corresponds to a memory queue address;
generating a local header incorporating the address index for each of the
transport packets;
adding the local headers to their corresponding transport packets; and
distributing the modified transport packet to corresponding memory queues
based on their associated one of the memory queue addresses in the local
header.
2. A method for managing digital transport packet distribution in a
transport packet demultiplexing system, wherein the transport packet
demultiplexing system receives a transport stream including digital
transport packets each identified by a packet identifier (PID), the method
comprising:
generating an address index for each of the transport packets based on the
PID, wherein the address index corresponds to a memory queue address;
generating a local header incorporating the address index for each of the
transport packets;
adding the local headers to their corresponding transport packets; and
distributing the modified transport packet to corresponding memory queues
based on their associated one of the memory queue addresses in the local
header, including
reading the local headers of the transport packets,
generating direct memory access (DMA) instructions indicating where the
transport packet is to be distributed,
storing the DMA instructions in memory, and
transferring the transport packets using a DMA transport engine which
executes the DMA instructions directly from memory.
3. The method according to claim 2, wherein the DMA transport engine
transfers the transport packets as a memory-to-memory operation.
4. The method according to claim 3, wherein the memory-to-memory operation
is specified using an absolute source address.
5. The method according to claim 3, wherein the memory-to-memory operation
is specified using an absolute destination address.
6. The method according to claim 3, wherein the memory-to-memory operation
is specified using a queue number to specify a source address.
7. The method according to claim 3, wherein the memory-to-memory operation
is specified using a queue number to specify a destination address.
8. The method according to claim 3, wherein the memory-to-memory operation
comprises a de-scrambling operation as the data transfer occurs.
9. The method according to claim 8, wherein the memory-to-memory operation
is specified using an absolute source address.
10. The method according to claim 8, wherein the memory-to-memory operation
is specified using an absolute destination address.
11. The method according to claim 8, wherein the memory-to-memory operation
is specified using a queue number to specify a source address.
12. The method according to claim 8, wherein the memory-to-memory operation
is specified using a queue number to specify a destination address.
13. The method according to claim 8, wherein the de-scrambling operation
uses a key stored within a key table.
14. The method according to claim 13, wherein the key used in a
de-scrambling operation is selected by a key pointer.
15. The method according to claim 3, wherein the memory-to memory operation
comprises:
a memory read operation from a source address;
a first memory write to a first destination address; and
a second memory write to a Sky Queue using a second destination address.
16. The method according to claim 15, wherein the memory-to-memory
operation further comprises a de-scrambling as the data transfer occurs
using a key stored in a key table, the key is selected using a key
pointer.
17. The method according to claim 16, wherein the source address is an
absolute memory address.
18. The method according to claim 16, wherein the source address is a queue
number.
19. The method according to claim 16, wherein the first destination address
is an absolute memory address.
20. The method according to claim 16, wherein the first destination address
is a queue number.
21. The method according to claim 16, wherein the second destination
address is an absolute memory address.
22. The method according to claim 16, wherein the second destination
address is a queue number.
23. The method according to claim 3, wherein the completion of the
memory-to-memory operation comprises a interrupt service request be sent
to a host processor.
24. A method for managing digital transport packet distribution in a
transport packet demultiplexing system, wherein the transport packet
demultiplexing system receives a transport stream including digital
transport packets each identified by a packet identifier (PID), the method
comprising:
generating an address index for each of the transport packets based on the
PID, wherein the address index corresponds to a memory queue address;
generating a local header incorporating the address index for each of the
transport packets;
adding the local headers to their corresponding transport packets; and
distributing the modified transport packet to corresponding memory queues
based on their associated one of the memory queue addresses in the local
header;
wherein the distributing step comprises:
reading the local headers of the transport packets;
generating direct memory access (DMA) instructions indicating where the
transport packet is to be distributed;
storing the DMA instructions in memory; and
transferring the transport packets using a DMA transport engine which
executes the DMA instructions directly from memory; and
the DMA transport engine transfers the transport packets as a
memory-to-memory operation, the memory-to-memory operation selectively
comprises a de-scrambling as the data transfer occurs using a key stored
in a key table, the key is selected using a key pointer.
25. An apparatus for managing digital transport packet distribution in a
transport packet demultiplexing system, wherein the transport packet
demultiplexing system receives a transport stream including digital
transport packets each identified by a packet identifier (PID), the
apparatus comprising:
means for generating an address index for each of the transport packets
based on the PID, wherein the address index corresponds to a memory queue
address;
means for generating a local header incorporating the address index for
each of the transport packets;
means for adding the local headers to their corresponding transport
packets; and
means for distributing the modified transport packet to corresponding
memory queues based on their associated one of the memory queue addresses
in the local header;
wherein the distributing means comprises:
means for reading the local headers of the transport packets;
means for generating direct memory access (DMA) instructions indicating
where the transport packet is to be distributed;
means for storing the DMA instructions in memory; and
means for transferring the transport packets using a DMA transport engine
which executes the DMA instructions directly from memory; and
the DMA transport engine transfers the transport packets as a
memory-to-memory operation and the memory-to-memory operation selectively
comprises a de-scrambling means using a key stored in a key table. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
FIELD OF THE INVENTION
The present invention relates generally to digital audio/video program and
transport stream demultiplexing. More particularly, this invention relates
to a system and method for demultiplexing and distributing transport
packets, such as MPEG-2 transport packets, by generating and associating a
locally-generated header with each of the transport packets to create a
self-contained modified packet which incorporates essential distribution
information therein.
BACKGROUND OF THE INVENTION
The development of digital video technology has made possible a variety of
telecommunication applications, including video conferencing, video
telephony, high-definition television (HDTV), and motion pictures at our
desktops to name but a few. The multi-media explosion, including still
pictures, moving video, and audio, is already proliferating the threads of
the World Wide Web. Technological advances in digital video are presenting
new opportunities as well, such as for existing quality television
distribution, interactive television, and movies and news on demand.
In order to reduce the high cost of video compression codecs and resolve
manufacturer equipment interoperability issues, standardization of digital
video techniques has been a high priority. Furthermore, as the computer,
telecommunications, and consumer electronics industries continue to
amalgamate, the need for standardization becomes more prevalent. To
address these and other issues, the International Organization for
Standardization (ISO) has undertaken efforts to provide standards for
various multimedia technologies, including digital video and audio. The
expert group of the ISO that has undertaken this obligation is the Moving
Picture Experts Group (MPEG). While the MPEG-1 standards addressed many of
the issues facing digital video transmission today, they were not suited
for broadcast environments or television applications. Therefore, the ISO
developed the MPEG-2 standard (ISO/IEC 13818) to respond to these needs.
The MPEG-2 standard does not, however, define each part of the digital
link. This allows for expansion and enhancement of the market via the
technology industry. For example, while the MPEG-2 defines a format that
can be used to describe a coded video bitstream, it does not specify the
encoding method. Instead, it defines only the resulting bit stream.
The MPEG-2 standard is often associated with the video compression aspect
of digital video. While video compression is an important part of the MPEG
standards, MPEG-2 includes a family of standards involving different
aspects of digital video and audio transmission and representation. The
general MPEG-2 standard is currently divided into eight parts, including
systems, video, audio, compliance, software simulation, digital storage
media, real-time interface for system decoders, and DSM reference script
format.
The video portion of the MPEG-2 standard (ISO/IEC 13818-2) sets forth the
manner in which pictures and frames are defined, how video data is
compressed, various syntax elements, the video decoding process, and other
information related to the format of a coded video bitstream. The audio
portion of the MPEG-2 standard (ISO/IEC 13818-3) similarly describes the
audio compression and coding techniques utilized in MPEG-2. The video and
audio portions of the MPEG-2 standard therefore define the format with
which audio or video information is represented.
Another important part of the MPEG-2 standard is the MPEG-2 Systems portion
(ISO/IEC 13818-1). At some point, the video, audio, and other digital
information must be multiplexed together to provide encoded bitstreams for
delivery to the target destination. The Systems portion of the standard
defines how these bitstreams are synchronized and multiplexed together.
Typically, video and audio data are encoded at respective video and audio
encoders, and the resulting encoded video and audio data is input to an
MPEG-2 Systems encoder/multiplexer. This Systems multiplexer can also
receive other inputs, such as control and management information, private
data bitstreams, and time stamp information. The resulting coded,
multiplexed signal is referred to as the MPEG-2 transport stream. More
specifically, it is referred to as the transport stream where the digital
information is delivered via a network to be displayed in real time, and
is referred to as a program stream where a local media-based system is
used (e.g., CD-ROM, local hard disk, etc.).
The video and audio encoders provide encoded information to the Systems
multiplexer provide this information in the form of an "elementary
stream". The encoded output of a video encoder provides a video elementary
stream, and the encoded output of an audio encoder provides an audio
elementary stream. In each of these cases, the elementary stream can be
organized into "access units", which can represent a picture or an audio
frame depending on whether it is part of the video or audio elementary
stream. These elementary streams are "packetized" into packetized
elementary streams (PES) which are comprised of many PES packets. Each PES
packet is size-variable, and includes a packet payload corresponding to
the data to be sent within the packet, and a PES packet header that
includes information relating to the type, size, and other characteristics
of the packet payload. The PES packet payloads are not fixed-length, which
allows the packet payload to correspond to the access unit of its
particular elementary stream.
PES packets from the video and audio encoders are mapped into transport
stream packets (TSP) at the Systems encoder/multiplexor. Each TSP includes
a payload portion which corresponds to a fixed-length portion of the PES
packet stream, and further includes a TSP header. The transport stream
packet header provides information used to transport and deliver the
information stream, as compared to the PES packet header that provides
information directly related to the elementary stream. Although one PES
packet may occupy multiple transport packets, byte "stuffing" is used to
fill the remainder of a transport packet payload which was not completely
filled by a PES packet, thereby allowing each PES header to be positioned
at the beginning of the transport packet payload. This allows the PES
header to be more easily synchronized at the decoder.
The consecutive flow of transport stream packets form the MPEG transport
stream. MPEG-2 Systems provide for two types of transport streams. The
first is the single program transport stream (SPTS), which contain
different PES streams, but share a common time base. The multi-program
transport stream (MPTS) is a multiplex of various single program transport
streams, which in turn may be multiplexed into various network channels
for multi-channel delivery to the media user.
The challenge then becomes determining an efficient manner to extract the
desired information from the program or transport stream for decoding at
the video, audio, or other decoders. Before the transport stream is
decoded, the transport packets must undergo analysis, synchronization,
demultiplexing, as well as other packet manipulating functions. These
functions can be managed by devices such as a MPEG transport
demultiplexor, and must be managed properly to execute the functions in
the most efficient manner possible to enhance packet transport speed and
ease. Due to the extraordinarily high data transfer requirements
associated with motion video, packet throughput time is a paramount
concern.
One problem affecting the efficiency of such transport demultiplexors is
high overhead associated with a host processor transferring the large
amount of data contained within the data packets. Accordingly, there is a
need for a system and method for enhancing transport packet demultiplexing
and distribution in a digital transport demultiplexing system. The present
invention allows the transport packet demultiplexing system to manage
packet storage and packet attribute information in an efficient and
organized manner. The present invention therefore offers advantages and
provides solutions to shortcomings of the prior art.
SUMMARY OF THE INVENTION
The present invention is directed to a system and method for demultiplexing
and distributing transport packets, such as MPEG-2 transport packets, by
generating and associating a locally-generated header with each of the
transport packets to create a self-contained modified packet which
incorporates essential distribution information therein.
In accordance with one embodiment of the invention, a method for enhancing
transport packet demultiplexing and distribution in a digital transport
demultiplexing system that inputs a stream of digital multimedia transport
packets is provided. Each of the transport packets includes a packet
identifier (PID) to identify the digital program or elementary stream to
which it corresponds. Local packet information is generated for each of
the transport packets, which is used in identifying and distributing the
transport packets. A local header is created that includes the generated
local packet information, and the local header is linked to its
corresponding transport packet to create a modified transport packet. In
this manner, each of the modified transport packets represents a
self-contained digital transport packet having local distribution
information contained therein.
In accordance with another aspect of the invention, a transport stream
demultiplexing apparatus for use in a digital transmission system capable
of providing a plurality of digital transport packets to a digital program
presentation device is provided. The demulitplexing apparatus performs the
demultiplexing operation by creating a set of direct memory access (DMA)
instructions for a DMA engine to execute when transferring the transport
packets to one or more output queues. The DMA engine is also configured to
de-scramble the contents of the transport packets while the DMA operation
occurs.
The above summary of the present invention is not intended to describe each
illustrated embodiment or implementation of the present invention. This is
the purpose of the figures and the associated discussion which follows.
BRIEF DESCRIPTION OF THE DRAWINGS
Other aspects and advantages of the present invention will become apparent
upon reading the following detailed description and upon reference to the
drawings in which:
FIG. 1 is a block diagram of an illustrative set-top box system
implementation incorporating a digital video transport system in
accordance with the present invention;
FIG. 2 is a block diagram of one embodiment of an MPEG transport
demultiplexor in accordance with the present invention;
FIG. 3 is a block diagram of one embodiment of a transport packet
management circuit in accordance with the present invention;
FIG. 4 illustrates the format in which predetermined PID values are stored
in the PID match table;
FIG. 5 is a block diagram of one embodiment of a PID match unit;
FIG. 6 is a block diagram generally illustrating the operation of the local
header unit in the transport demultiplexing system;
FIGS. 7A and 7B illustrate a modified transport packet, including the
transport packet and its associated local header, for DVB and DSS system
streams respectively;
FIG. 8 is a logic block diagram illustrating a transport stream data
transfer system utilizing a Direct Memory Access Controller according to
one example embodiment of the present invention; and
FIG. 9 is a logic block diagram illustrating an embodiment of a transport
data function showing the transport data transfer logic in more detail
according to one example embodiment of the present invention.
FIG. 10 is a logic block diagram illustrating the de-scrambler data
functional organization according to another example embodiment of the
present invention.
FIG. 11 is a logic block diagram illustrating the de-scrambler interfaces
according to another example embodiment of the present invention.
While the invention is susceptible to various modifications and alternative
forms, specific embodiments thereof have been shown by way of example in
the drawings and will herein be described in detail. It should be
understood, however, that it is not intended to limit the invention to the
particular forms disclosed, but on the contrary, the intention is to cover
all modifications, equivalents, and alternatives falling within the spirit
and scope of the invention as defined by the appended claims.
DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENTS
The present invention is particularly advantageous in digital multimedia
communications systems implementing the MPEG (Moving Pictures Experts
Group) standards such as the MPEG-1 (ISO/IEC 11172-X) and MPEG-2 (ISO/IEC
13818-X) standards, and in transport stream applications relating to
digital video in broadband networks. While the present invention may be
applicable to many digital communication environments, an appreciation of
the invention is best obtained in the context of the following diagrams,
in which an MPEG-2 transport stream demultiplexing system is shown
according to the present invention.
FIG. 1 is a block diagram of an illustrative set-top box 100 system
implementation incorporating a digital video transport system 102 in
accordance with the present invention. A set-top box is one of the key
components of the modem information superhighway, and is the module that
can turn an ordinary television into a sophisticated, interactive,
video/audio system. The set-top box can take on a variety of roles,
including: serving as a gateway to subscription and pay-per-view services
digitally delivered by satellite, cable or terrestrial links;
information-on-demand and other interactive services; low cost entrance to
the Internet; games console for advanced 3-D video games, and more.
The input of the set-top box 100 includes the front end interface 104. The
front end interface 104 which includes satellite, cable and terrestrial
demodulators to receive the transport packets. The transport packets are
provided to the digital video transport system 102, which in the present
embodiment is an MPEG-2 transport system. The MPEG-2 transport system 102
of the present invention provides various functions, including transport
stream synchronization and demultiplexing, cached processing capabilities
for transport and application processing, dynamic random access memory
(DRAM) control for the transport memory 106, external system interfacing
via the external bus interface 108 to various external components such as
the flash read only memory (ROM) 110, the font ROM 112 and the static RAM
(SRAM) 114, and various set-top box peripheral input/output (I/O)
functions via the I/O interfaces 116.
The MPEG-2 transport demultiplexor 102 is also coupled to a digital
decoding unit 118, which includes the video and audio decoders, which
utilizes the decoder memory 120. The decoded information can then be used
by consumer devices, such as television 122.
FIG. 2 is a block diagram of one embodiment of an MPEG transport
demultiplexor 200 in accordance with the present invention. In the
embodiment described herein, the description will discuss the MPEG-2
standard. However, as will be appreciated by those skilled in the art from
the following description, the principles described herein are applicable
to other packet- based technologies. While some of the general functions
of the MPEG-2 transport demultiplexor 200 are described in connection with
FIG. 2, more specific implementations and functions are described in
greater detail in connection with the ensuing diagrams.
The MPEG-2 transport demultiplexor 200 utilizes three internal buses,
including the system bus 202, peripheral bus 204, and the transport stream
bus 206. The system bus 202 is the transport demultiplexor processor bus
for the processor, which in one embodiment is a 32-bit bus coupled to an
advanced RISC machine (ARM). The peripheral bus 204 is oriented to slow
speed devices, and supports all I/O interfaces to the MPEG-2 transport
demultiplexor 200. The transport stream bus 206 essentially carries all
transport stream data to and from the transport memory.
The packet management module 208 receives the MPEG-2 transport packets from
the front end interface demodulators. The transport packets may be input
serially or in parallel bytes. The packet management module 208 provides
functionality including synchronization byte detection with programmable
synchronization values, synchronization byte lock and unlock hysteresis,
packet alignment with programmable packet lengths, hardware packet
identifier (PID) comparison, and packet discard capabilities.
A memory controller 210 includes a queue manager, arbiter, and DRAM
controller. The memory controller 210 supports both EDO-DRAM and SDRAM.
The queue manager provides rate buffer control for the transport stream
data, while the memory controller supports a host interface for the ARM
processor code and associated data space.
The transport DMA controller 212 is a scatter-gather DMA engine controlled
by memory-resident data structures which establish a control program. This
multi-channel DMA, together with the memory controller queue manager,
provides a mechanism for memory-to-memory or I/O transfers while achieving
effective rate buffering and performing associated functions for the
transport stream. The transport DMA controller 212 works in conjunction
with the de-scrambler 214 to decrypt the data during these memory or I/O
transfers.
The processor 216 is the host processor for the MPEG-2 transport
demultiplexor 200. In one embodiment of the invention, the processor 216
is an ARM having on-chip caching functionality to reduce the bandwidth
requirements of the on-board memory.
The peripheral bus bridge 218 interfaces the system bus 202 to the
peripheral I/O devices 220, the central services module 222, and other
data registers. This bus provides connectivity to slave devices. A
representative sample of many of the peripheral devices supported by the
MPEG-2 transport demultiplexor 200, which includes serial 1/0224, smart
card interfaces 226, I.sup.2 C interfaces 228, IEEE-1284 and IEEE-1394
interfaces 230, 232, codec interfaces 234 for modems, and infrared
interfaces 236.
The central services module 222 provides the maintenance functions for the
system. The functions handled by the central services unit include reset
and power-up control, interrupt control, timer counters, bus arbitration,
watch dog timers, bus timeout functions, and Joint Test Action Group
(JTAG) capabilities for ARM emulation and test functionality.
The external bus bridge interfaces the system bus 202 to the external bus
interface 240, and provides connectivity for external ROM, RAM, and
external MPEG decoders. The external bus interface supports master and
slave interfaces. The ARM 216 is the master on the external bus interface
240. The external master device can then access all of the on-chip
resources of the MPEG-2 transport demultiplexor 200.
FIG. 3 is a block diagram of one embodiment of a transport packet
management circuit 300 in accordance with the present invention. The
packet management circuit 300 represents the transport front end, where
transport packets are received at the MPEG-2 transport demultiplexor from
an input channel or demodulator unit.
Generally, the packet framer 302 performs packet framing and byte
alignment, as well as synchronization detection. The packet framer 302
continuously searches for the MPEG synchronization byte in the header of
the incoming transport data stream. For MPEG-2 applications, the
synchronization byte is used to locate the start of a transport packet,
and has a hexadecimal value of 0.times.47. The packet framer 302 locates
the synchronization byte among the rest of the transport data byte stream
by tracking the arrival of synchronization bytes every transport packet
interval. This is controlled by registers which establish the conditions
under which the framer enters and exits a synchronization lock condition.
The framer 302 forwards the data to the PID match unit 304 when an entire
transport packet has been delineated from the transport data stream. For
example, in a digital video broadcasting (DVB) application, the DVB
transport stream is a 188-byte stream having a byte value 0.times.47 in
the first byte of the transport header. When this value is detected a
SYNC_LOCK signal is asserted, and the packet framer 302 outputs the
transport packet to the PID match unit 304.
The packet framer 302 can receive inputs of various types, including serial
and parallel input, as seen on channel input line 306. Where serial input
is received, the serial-to-parallel converter 308 converts the input to a
parallel 8-bit input to the multiplexor 310. Other interfaces, such as the
IEEE-1394 standard, may also serve as inputs to the packet framer 302. A
control signal coupled to the multiplexor 310 selects which input to
accept to provide the transport stream at the output of the packet framer
302, which in one embodiment is provided in 8-bit bytes as shown on output
bus 312. A PACKET_START signal shown on line 314 is asserted coincident
with recognition of the synchronization byte to indicate the first byte of
a transport packet. The PACKET_START signal triggers processing of the
transport packet header information. The transport stream output on bus
312, the PACKET_START signal on line 314, and a SHIFT_CLOCK signal on line
316 are provided by the packet framer 302 to the transport stream pipeline
318, which is described more fully in connection with FIG. 5.
A transport packet is generally a fixed-length packet having a transport
packet header and a packet payload that includes the PES packets. MPEG-2
transport packets include a transport packet header, an adaptation field,
and a payload field containing the PES packets. Within the transport
packet header is a packet identifier (PID), which is a 13-bit field used
to identify transport packets which carry PES data from the same
elementary stream, and to define the type of payload in the transport
packet payload.
MPEG-2 allows for multiple audio/video programs to be provided per carrier,
resulting in a multi-program transport stream (MPTS) which is a multiplex
of a number of single program transport streams (SPTS). Each SPTS may
contain different PES streams, each of which carries different video,
audio and possibly data information all corresponding to a common program.
Time division multiplexing (TDM) is used to concurrently transmit the
multiple programs in an MPTS. Because the MPEG-2 transport stream can
include a multiplex of audio/video programs, the MPEG transport
demultiplexor 200 must determine which transport packets are part of the
desired program in order to pass them on to the external MPEG decoders for
further processing. The transport packets that are not part of the desired
program can be discarded. The PID match unit 304 makes the determination
of which PIDs are part of the desired program.
The PID match unit 304 plays an important role in multi-program transport
stream management. The PID match unit 304 locates transport packets with
matching PIDs, and forwards them to the local header unit 320. One aspect
of the present invention is the generation of a local header by the local
header unit 320. The local header is concatenated with the transport
stream at the output of the transport stream pipeline 318 shown on output
bus 318, and is used to distribute information throughout the transport
demultiplexer. The transport packets, along with the associated local
header, are forwarded to a FIFO 322 to eventually be stored to memory,
which in one embodiment of the invention is a DRAM. The PID match unit 304
also includes program clock reference (PCR) PID matching, and
corresponding PCR recovery circuitry 324.
In one embodiment of the invention, the PID match unit 304 includes a PID
table of 32 PID entries. This table is organized as a 32-bit wide RAM with
16 locations (each location provides 2 PID entries). The table is updated
by the host processor, such as processor 216 of FIG. 2. The PID table is
updated when the system is first powered up and when the view changes the
channel being viewed. Upon every power up sequence, the PID table is
expressly updated by the host. Similarly, the host updates the PID table
when a viewer performs a change channel operation. Both of these updates
to the PID table are performed by the host using an alternate path to the
PID match table address. A hardware interlock mechanism within the PID
match unit forces the host to wait if updates are made when the PID match
logic is active.
FIG. 4 illustrates the format in which the PID values are stored in the PID
match table. Table location 330 includes two PID values, shown as 13-bit
PID.sub.(n) 332 and 13-bit PID.sub.(n+1) 334. Associated with each PID
value is one or more attribute bits, which in one embodiment includes
three attribute bits. PID.sub.(N) 332 is associated with attribute bits
29, 30 and 31, represented by attribute block 336. PID.sub.(n+1) 334 is
associated with attribute bits 13, 14 and 15, represented by attribute
block 338. The PID attribute details are described in Table 1 below.
TABLE 1
PID Attributes
Bits [15:13]; [31:29] Description
0 X X Invalid PID
1 0 0 Valid PID - Transport Stream
1 0 1 Valid PID - Transport Stream (1394 Enable)
Each of the bit patterns of the attribute block can be used to represent a
particular characteristic of the PID that was received. For example, where
bit 15 is binary 0, it indicates an invalid PID whether it is a PCR packet
or not. Where bits 15, 14 and 13 are binary 100, it indicates a valid
transport stream PID.
FIG. 5 is a block diagram of one embodiment of a PID match unit 350. The
objective of the PID match unit 350 is to extract the PID information from
the transport packets of the transport stream, for comparison with known
PID table entries. The packet framer provides the transport packets to the
PID match unit 350 via path 352 upon the occurrence of the SYNC_LOCK
signal. The data is shifted into the transport stream pipeline 354 upon
each occurrence of a shift clock after the PACKET_START signal has been
detected as illustrated on line 356. The PACKET_START signal is propagated
through the transport stream pipeline 354 as the transport packet
propagates through the pipeline to signify the start of the transport
packet. The transport stream pipeline allows the transport packets to be
passed to the local header unit at the proper time. This time delay allows
various functions to be performed, including locating a PID match in the
PID match table, and computing the local header. For example, at a channel
rate of 7.5 MB/sec (megabytes per second) and a system clock rate of 54
Mhz, it can be estimated that the PID capture time is 2 channel clock
cycles for DSS and 3 channel clock cycles for DVB, which requires 3 stages
of the pipeline. The PID compare time under this system clock frequency
would be approximately 16 clock cycles (2 PIDs per clock cycle and 32 PIDs
total), synchronization and pipeline delays of approximately 4 clock
cycles, control state machine delays of approximately 4 clock cycles, and
a local header computation of 4 clock cycles for a total of approximately
28 clock cycles or another 4 pipeline stages. This results in at least 7
pipeline stages, and therefore in one embodiment of the invention as shown
in FIG. 5 an 8-stage transport stream pipeline provides timing assurance.
The PID capture latch 358 captures the PID information after a
predetermined number of bytes past the PACKET_START signal as determined
by the byte counter 360. This 16-bit value is masked using the PID mask
register 362 and the AND block 364, where the result compared to the data
from the PID table 366 two PIDs at a time. This masking operation is
needed to obtain only the relevant bits for the comparison. The header
constitutes 4 bytes of the 188 byte MPEG packet, where 2 bytes of the 130
bytes in the DSS are called pre-fix. The PID is contained within the 13
bits of information that straddles bytes 2 and 3 of a standard MPEG
packet; and in the DSS format, the PID consists of 12 bits of the 2 byte
pre-fix data. The PID capture latch collects a total of 16 bits. During
the comparison, the non-PID bits must be ignored where the upper 3 bits
are masked within the DVB and the upper 4 bits are masked within the DSS.
The compare operation is accomplished by providing a counter 368 which
counts through each of the 16 locations in the PID match table 366, which
enables the two PIDs at the current PID match table location to enter the
pipeline latch 370, and to enter the compare unit 372 after masking by the
AND block 374. The compare unit 372 includes two comparators 376 and 378
to concurrently compare the current PID value in the PID capture latch 358
to each of the PID values from the PID match table 366 at the location
designated by the counter 368. Upon recognition of a match, the match
capture latch 380 is updated via its clock input by the match signal shown
on line 382. The match capture latch 380 provides the current counter
value on path 384, as well as the PID attribute bits on paths 386 that
correspond to the matched PID. Multiplexing unit 388 selects the matching
PID attributes according to the state of the match bit on line 390. The
match logic operates as follows: line 390 indicates that the second entry
is matched. If the match 382 is true and line 390 is true, the system
recognizes that the second entry is matched. If the match 382 is true and
line 390 is false, the system recognizes that the first entry is matched.
The line 390 also is used to select which of the two entries are to be
captured into the match capture latch 380.
The PID match unit 350 stalls on the detection of a match. The match
detection time for a particular entry in the PID table is deterministic,
which allows for precis | | |
