MITEL VP2614 Datasheet
VP2614
VP2614
H.261 Video De-Multiplexer
Supersedes version in June 1995 Digital Video & DSP IC Handbook, HB3923-2 DS3735 - 3.2 October 1996
FEATURES
■ Fully integrated H.261 video de-multiplexer
■ Inputs an H.261 bitstream. Outputs error corrected run
length coded coefficients.
■ Interfaces directly to the VP2615 H.261 decoder
■ Extracts side information and status for transfer to a
System Controller
■ User definable system level options for proprietary ap-
plications
■ Average input rates between 40 Kbit /sec and 2Mbit /
sec. Maximum peak input rates of 4 Mbit / sec.
■ 100 pin quad flatpack
ASSOCIATED PRODUCTS
■ VP2611 H.261 Encoder
■ VP2612 H.261 Video Multiplexer
■ VP2615 H.261 Decoder
DESCRIPTION
The VP2614 Video De-Multiplexer forms part of the Mitel
Semiconductor chip set for video conferencing, video telephony, and multimedia applications. It extracts video parameters and run length coded DCT coefficients from an
H.261 bitstream. Elements of the data which have been
variable length coded according to the specification are decoded within the device. It produces tagged data, aligned to a
macroblock timing structure, in the format needed by the
VP2615 Decoder. Side information and status bits are separately made available for the system controller.
The VP2614 will accept data up to a peak rate of 4 Mbits
per second, but with an average rate up to 2 Mbits per second.
The bursty nature of the input, together with the fact that each
coded picture does not use the same number of bits, requires
the provision of a received data buffer. Since the VP2615
Decoder accepts macroblock data as it becomes available, it
is not necessary to provide storage for a complete coded
picture. Worst case analysis has shown that a buffer size of
256K bits is adequate in practice for bit rates up to 2Mb/sec.
The incoming sequence is coded with a strict syntax, and
the VP2614 must identify and align with this sequence before
correct decoding is possible. Storage for this alignment is
contained within the external buffer. The device monitors that
lock is always valid, and reports to the system controller. Error
correction bits are ignored.
■ VP520S CIF / QCIF Converter
■ VP510 Colour Space Converter
DATA
STROBE
DATA
VALID
NOT
READY
RECEIVE
BUFFER
32K X 8
CNTRL
DATA
ADDR
BUFFER
INTERFACE
HD7:0 HA3:0 CEN WR RD VMUX ERROR VMUX EVENT
HOST INTERFACE
SIDE INFORMATION
FRAME
ALIGNMENT
VALIDITY
CHECK
VARIABLE
LENGTH
DECODE
Fig 1 : Simplified Block Diagram
VP2615
INTER
FACE
VP2614
PMD
2:0
D7:0
DM3:0
DCLK
1
VP2614
PIN DESCRIPTION
SIG TYPE FUNCTION
LD I Line input data
LEN I When low, the line input data is valid.
LCLK I Line input strobe
LRED O When low, line data cannot be ac
cepted.
DBUS7:0 O Data and control bus to the VP2615.
DMODE3:0 O These outputs identify the data on
DBUS7:0.
PM2:0 O Identifiers for the additional information
on DBUS7:0 .Not used by the VP2615.
DCLK O Continuous O/P strobe for the DBUS7:0
bus which is derived from SCLK.
SCLK I System clock. Must be 27 MHz for 30 Hz
frame rates.
HD7:0 I/O Bi-directional data bus.
HA3:0 I Four system controller address bits.
WR I An active low write strobe from the
system controller.
RD I An active low read strobe from the
system controller.
CEN I An active low chip select from the sys
tem controller.
ERR O An active low output which Indicates
framing and decoding errors.
EVT O An active low output which Indicates
that new picture status data is available.
B7:0 I/O Bi-directional data bus to the receive
buffer.
A14:0 O Address bus to the receive buffer.
WS O An active low write strobe for the receive
buffer.
BCS O An active low select for the receive
buffer.
BEN O An active low output enable for the
buffer.
TCK I JTAG test clock
TMS I JTAG mode select
TDI I JTAG I/P data
TDO O JTAG O/P data
TRST I JTAG reset
TOE I When low all outputs are high imped-
ance
RES I An active low power on reset
OPERATION OF THE MAJOR BLOCKS
FRAME ALIGNMENT
The H.261 continuous bitstream is split into frames of 512
bits the first bit in each frame being part of an 8 bit frame
alignment pattern. Only the sequence in the pattern is important and detection can start from any bit. To avoid false
detection within the actual data, this pattern must be repeated
at least three times before " frame lock " can be considered to
have been achieved.
The detection of frame lock thus requires data from 24
consecutive 512 bit frames, and a section of the Received
Data Buffer is reserved for this purpose. This external RAM is
supported by a small internal buffer which allows eight consecutive bits ( obtained from reading a byte ) to be simultaneously checked for alignment with the corresponding bits in
seven other bytes spaced apart by complete frames. The
search for alignment over 512 bits takes less than 250
microseconds with a 27 MHz clock, this being less than the
time taken to receive 512 bits at the maximum rate of 2Mb/
second. Thus the buffer area for frame lock does not overflow.
Once frame lock has been achieved it is continually
monitored using the appropriate bit in each frame. If a mismatch occurs then the next four frame alignment bits will be
checked for errors. If any one of these four bits is also in error
then loss of frame alignment is declared by setting a Status
Register Bit, and a search for a new alignment position will
commence. If none are in error then a random bit error is
assumed and no further action is taken.
The check done on loss of alignment is a compromise
between falsely believing that alignment has been lost and not
detecting that frame alignment has been lost. The probability
of two random bit errors in the five frames used in the check
is dependent on the bit rate and also the error rate. With a high
error rate of 1:100000, and a bit rate of 2Mb/sec, false
detection is possible once per week. The probability of detecting a change in the frame alignment ( caused by switching in
a new bitstream ) is 46.9% in the first five frames, but this rises
to 97.4% after 12 frames have been processed.
Control Bits allow H261 framing to be either identified or
ignored. In the latter case Frame Lock will always be indicated
and data is still buffered and processed. The datastream is
then expected to contain pure data and a search will be made
to find picture start codes. When framing is enabled the 18
parity bits are extracted from the data, but single bits in error
can still go un-detected in some circumstances.
NOTE:
"Barred" active low signals do not appear with a bar in the
main body of the text.
2
VP2614
VIDEO LOCK
Once the VP2614 has locked to the H261 frames it will
begin searching for the 20 bit unique Picture Start Code. Once
this has been identified the "Video Lock" status bit will be set,
and the bitstream will be translated on a code by code basis.
Video lock will be lost and translation process interrupted
under the following conditions:
1) A Picture Start Code or Group of Blocks ( GOB ) Start
Code is not present when expected.
2) The codeword is not valid for its context, causing no
match to be obtained. Each variable length code in the
bitstream is analysed by the VP2614, and invalid patterns will
force Video Lock to be lost.
3) Too many coefficients are transferred for the current
macroblock because the End of Block code was missing.
4) GOB number is not in the correct range for the operating mode.
5) A GOB number not in sequence will cause lock to be
lost and then regained.
Note that only the most frequently occurring coefficients
are variable length coded, the others being represented by an
escape sequence followed by a fixed length code. The Intra
DC coefficient is also a fixed length code. These fixed length
codes have bit patterns which are forbidden in the H.261
specification, but they could appear due to bit errors. These
invalid codes are trapped by the VP2614, but do not cause
Video Lock to be lost. Instead the run length coefficient is
replaced by a default value of magnitude 1. When video lock
has been lost the DMODE 3:0 outputs indicate a WAIT state.
When lock is regained any missing macroblocks are replaced
with Fixed Macroblocks.
A count is maintained of up 256 occurrences of faults 1 3, and a status bit is set when lock is lost ( the Video Lock
Achieved bit is also cleared ). An output signal is also provided
which can, if required, be used to interrupt the system controller. This indicates any of the above errors which cause Video
Lock to be lost and also frame alignment errors; alternatively
it can be used to just indicate framing errors.
When Video Lock has been achieved, the detection of a
Picture or GOB start code when it is not expected will not
cause lock to be lost. Instead the VP2614 will resynchronize
to the new start code, and dummy macroblocks will be
generated for the missing GOB's. These dummy blocks will be
Fixed Macroblocks, and will cause the VP2615 Decoder to
use data from the previously decoded picture. Note that Video
LINE
STROBE I/P
(LCLK)
LINE I/P
DATA
DATA
ENABLE (LEN)
NOT
READY O/P
(LRED)
Fig 2 : Line Interface Timing
0ns
2Ø +10ns
min
Note. Ø is the system clock period
min
DATA VALID
Asynchronous
Lock is actually lost and re-gained under these conditions. The
status bit will momentarily be set and then reset, and the Video
Lock Lost Counter will be incremented.
Similarly any errors in the actual GOB number will not
cause lock to be lost and then gained again. Since sequential
GOB numbers are always produced by the encoder, then the
Decoder generates its own GOB numbers and ignores those
in the bitstream.
A Control Bit allows the system controller to take one of two
actions when Video Lock is lost. Either the VP2614 can be
forced to re-initialize to the next Picture Start Code, or it can
abandon the decoding operation until the next GOB Start
Code is detected. When lock has been lost, and a new start
code has been found, the VP2614 assumes its number to be
initially correct and starts its own sequence from that number.
If, however, the next number in the bitstream is not in sequence then this new number is used to start a new sequence.
This process continues until two sequential numbers are
obtained, and then no further checks on the GOB numbers are
made until Video Lock is again lost. The VP2614 will generate
"Fixed Macroblocks " for the missing GOB numbers since
Video Lock was lost, and will output these to the VP2615
decoder. This then uses data from the previous decoded
picture for those macroblocks.
A Video Hold bit is provided in one of the System Control
Registers which forces Video Lock to be lost immediately. No
further data is passed to the VP2615 whilst this bit is set, but
the Received Data Buffer is not allowed to fill unnecessarily.
Incoming data will be flushed out and lost. When the hold bit
is cleared a Picture Start Code must be detected to re-gain
Video Lock. The VP2615 will then be provided with any
missing GOB's as described above, before GOB's in the new
picture are processed.
A Freeze Frame Control Bit is also provided. This has a
similar action to the Video Hold Bit, except that it is only
actioned when PTYPE has been decoded in the picture layer,
and it also sets a Freeze Frame status bit. If Video Lock is lost
before the start of a new frame then Freeze Frame will become
active and a search will commence for a picture start code.
Even though Freeze Frame causes Video Lock to be lost, the
VP2614 will still search for picture start codes and will extract
PTYPE and Temporal Reference values.
If clear, a Release Mode Control Register Bit will allow the
freeze condition to be released when the Freeze Bit is cleared,
but is only actioned when the next Picture Header is decoded.
If the Release Mode Bit is set, then the freeze condition is only
released when the PTYPE bit in the H.261 stream specifies
that this is to occur. Even when automatic release has been
selected the system controller can still monitor the length of
time that the freeze has been in effect. It can then force a
release after a time out period by setting the Release Mode Bit
and clearing the Freeze Bit.
DE-MUX CORE
Once Video Lock has been achieved, the core of the
VP2615 will convert the H.261 bitstream into video parameters and run length coded coefficients. A state machine,
which is a hardware manifestation of the H.261 coding structure, maintains the current position in the bitstream. When
necessary variable length de-coding is performed, and side
information such as temporal reference and Picture Type
Information is stored in registers.
3
VP2614
SCLK
ADDRESS
O/P
CHIP ENABLE/
O/P ENEBALE
DATA I/P
ADDRESS
O/P
CHIP
ENABLE
DATA
O/P
WRITE
ENABLE
20ns
max
20ns max
ADDRESS VALID
Tac
READ CYCLE
WRITE CYCLE
20ns
max
10ns
min
DATA VALID
VALID
20ns
max
0ns
min
20ns
max
Fig 3 : External Buffer Timing
Not all this side information is used by the VP2615 Decoder, but is still made available on the data output bus
DBUS7:0. This is described in the section on Additional
Information. In addition the side information can be examined
by the system controller.
Requirements for the complete decoder system are such
that it is desirable for the VP2614 /15 pair to free run, and to
ignore the Temporal References embedded in the video
bitstream. The pair then always process the bitstream, whenever code bits are available, using the processing rate needed
for the full 30 Hz frame rate. Operating in this manner allows
the de-mux core to be closely coupled to the VP2615 Interface
circuitry, and no additional buffering is necessary. The demultiplexing process is then locked to the macroblock timing
structure needed by the VP2615.
LINE INTERFACE
Bitstream inputs to the device are controlled by an asynchronous line input strobe, which when data is valid is enabled
by a Data Valid signal. Detailed timing information is given in
Figure 2.
Maximum input frequency is 4 MHz and the rising edge of
the strobe is used to internally latch the data. The VP2614
generates a Ready signal which goes invalid when data
cannot be accepted. This, for example, occurs during system
reset or if the Received Data Buffer overflows.
EXTERNAL BUFFER REQUIREMENTS
The external buffer must be a 32K x 8 bit static RAM, and
must comply with the timing requirements given in Figure 3.
Under normal operating conditions the buffer will not overflow,
however it is conceivable that under some unforseen condition the buffer may fill and then overflow. For this reason a
Buffer Full Flag is provided in one of the Status Registers. This
is asserted when the buffer is 90% full, and is not itself an error
condition. If the buffer continues to fill and eventually overflows, then the Ready Signal to the line interface goes invalid.
The effect of overflow is to also clear the buffer and the Buffer
Empty Flag will be raised. There is no status bit to indicate
overflow, but an extended period of Buffer Full followed by
Buffer Empty can be used to infer the condition.
4
DMODE3:0 FUNCTION
0000
0001
0010
0011
0100
0101
0110
0111
1000
1001
1010
1011
1100
1101
1110
1111
GOB Number
MB Number
Control Decisions
Quant Value
Horizontal MV
Vertical MV
Coded Blk Pattern
Sub-Block No
Zero Run Count
RLC Coefficient
Not used
Not used
Not used
Not used
Not used
Wait State
Table 1. Output Codes
VP2615 INTERFACE
The VP2614 provides a glueless interface to the VP2615
Decoder. Run length coded coefficients and control information are transmitted over the DBUS7:0 bus, and are identified
by the code on the DMODE3:0 bus given in Table 1. The
VP2614 produces a continuous DCLK which is used to strobe
data into the VP2615. This is derived by dividing the system
clock by two, and when no data is actually available the
DMODE3:0 bus will indicate a wait state. Timing is shown in
Figure 4.
The VP2615 expects a macroblock and its control information to be transferred over a minimum period, nominally
equivalent to 2048 system clock cycles but with allowance for
the asynchronous DCLK. Wait states are thus inserted as
necessary by the VP2614 in order to enforce this macroblock
period. Under normal circumstances the VP2614 will not take
longer than 2048 clock periods to produce a macroblock, but
some 10% extra time is available for each macroblock before
the 30 Hz frame rate becomes impossible to maintain.
The start of a macroblock transfer is identified by the
presence of the Control Decisions Byte ( DMODE3:0 = 0010).
Each macroblock slot must at least consist of this Control
Decisions Byte, followed by the GOB number and then the
Macroblock number. No further bytes are mandatory.
When high, Bit 0 in the Control Decisions Byte indicates a
Fixed Macroblock, and a high on Bit 1 indicates Inter Mode
coding. A high on Bit 2 indicates that the macroblock was
filtered, and a high on Bit 3 indicates that Motion Compensa-
SCLK
DCLK
O/P
25ns max
25ns max
DATA FROM
VP2614
DMODE
3:0
25ns max
DATA VALID
DATA VALID
Fig 4 : Output Timing
Loading...