MPEG-4 Simple Profile Encoder v1 - Xilinx · 4 DS511 v1.8 April 14, 2008 Product Specification...

DS511 v1.8 April 14, 2008 www.xilinx.com 1Product Specification

© 2005-2008 Xilinx, Inc. All rights reserved. XILINX, the Xilinx logo, the Brand Window, and other designated brands included herein are trademarks of Xilinx, Inc. All other trademarks are the property of their respective owners.

IntroductionThe Xilinx® MPEG-4 Part 2 Simple Profile Encoder (MPEG-4 Encoder) core is a fully functional VHDL design implemented on a Xilinx FPGA. The MPEG-4 Encoder core accepts uncompressed video and gener-ates compressed bit streams based on the “Information Technology–Generic Coding of Audio Visual Objects-Part 2 Visual” section of the ISO/IEC 14496-2 standard.

This document describes the core functionality, its input/output structure, and how the core is used.

Features• Supported FPGA families: Virtex®-5, Virtex-4,

Virtex-II Pro, Virtex-II, Spartan®-3, and Spartan-3A

• MPEG-4 Part 2 Simple Profile Level 5 (Standard Definition)

• User-defined maximum frame size

• Directional squared motion estimation with early stop

• ½ pixel motion estimation

• 4:2:0: YUV processing

• Single external frame buffer; predicted frame processing

• Variable length coding in hardware

• Host interface for rate control algorithm

• Support for full MPEG-4 header

ApplicationsSome of the key applications for the MPEG-4 Encoder core are defined below.

Automotive

Today’s automobile makers are incorporating the latest technologies, including Global Positioning Systems (GPS) and collision avoidance systems, which require drivers to be able to see video sequences in real-time to make split-second decisions. Video compression tech-nology has become an important part of the auto

industry’s infrastructure, and the MPEG-4 technology enhances the overall product and data transmission requirements.

Medical Imaging

Medical imaging, processing, and archival benefit greatly from the use of MPEG-4 compression tech-niques for both still and video images in non-clinical application setting.

Industrial and Security

MPEG-4 compression algorithms are an excellent resource for applications that require video sequences from multiple locations to be sent to a central location for processing, for example, video sequences captured from a variety of locations within an office building or manufacturing plant to a security control room.

Broadcasting

MPEG-4 technology provides the broadcast commu-nity with an effective way to transmit information in a highly compressed format that can deliver various lev-els of high-quality video information both inside and outside the studio. In addition, the invention of HDTV required a way to compress video signals to be able to occupy the same analog channel that existed for SDTV.

Military

Video surveillance from military aircraft necessitates sending valuable video imagery over wireless commu-nication channels. These types of applications rely strongly on effective video compression techniques that can operate at different resolutions based on the accu-racy and image quality required.

Video Conferencing

MPEG-4 encoding and video compression allow for the transmission of high-quality video to multiple sites in real time, reducing travel time and overall costs.

MPEG-4 Simple Profile Encoder v1.2

DS511 v1.8 April 14, 2008 Product Specification

- THIS IS A DISCONTINUED IP CORE -

http://www.xilinx.com


2 www.xilinx.com DS511 v1.8 April 14, 2008Product Specification

Streaming Video

Delivering video information through streaming video is an important aspect of internet communica-tion, and combining MPEG-4 technology with the host of other internet technologies enhances the overall internet experience.

Video Messaging

Cellular telephone technology has gained a significant share of the consumer market over the last decade and continues to expand into other areas, including video. Because the MPEG4 Encoder has the capability to compress low-resolution images very effectively, the MPEG-4 algorithm is a natural fit for small-screen applications.

Feature Summary • MPEG-4 Simple Profile Encoder standard. The MPEG-4 Encoder core follows the International

Standards Organization document number ISO/IEC 14496-2:199/Amd.1:2000(E) from the ISO/IEC JTC 1/SC 29/WG 11 Coding of Moving Pictures and Audio group. This document may be purchased from the MPEG web site at http://www.iso.ch/iso/en/prods-services/ISOstore/store.html.

• User-defined maximum frame size. The MPEG-4 Encoder core can operate at different resolutions, from Standard Definition (720 by 576) to QCIF (176 by 144). The frame size directly affects the total amount of on-chip memory, or block RAMs, required.

• Directional squared motion estimation and compensation. The MPEG-4 Encoder has a motion estimation and motion compensation module in the design to produce motion vectors for the compressed bitstream. It also will use these vectors to access a locally stored memory containing macroblocks of the previously decoded frame. These macroblocks will be used as a reference to operate on the incoming residual processed data. The motion estimation used is a directed search with early stop condition.

• 1/2 pixel motion estimation. The MPEG-4 Encoder core uses 1/2 pixel motion estimation for motion vectors using integer pixel best match and then 1/2 pixel search to refine the best motion vector match.

• YUV processing. The structure of the macroblock demands that the processing used in an MPEG-4 system, or MPEG system, necessitates 4:2:0 YUV processing. The color channels sample at exactly half the rate in both the horizontal and vertical directions as they relate to the Y channel. Therefore, for every U and V pixel there are four Y pixels. The spatial relationship among the three channels has been documented in many MPEG articles.

• Single external frame buffer—predicted frame processing. The MPEG-4 Encoder structure uses frame differences to create the residual macroblocks of information. The Encoder adds back the expanded bitstream to the appropriate motion compensated macroblock previously stored in an external frame buffer.

• Variable length coding in hardware. The core receives the uncompressed bitstream from a source and proceeds to encode the information and present the information in a discernible manner to the appropriate modules. The encoding process involves an production of variable length code words for motion vectors and residual data.

• Rate control. The MPEG-4 Encoder uses statistics generated internally to the core to update the quantization on a frame by frame basis. This allows for external rate control algorithms to be executed by a host processor and adjust the quantization based on varying bandwidth conditions. In addition, scene complexity and motion will have an effect on the bits produced and can be changed on a frame basis.



http://www.iso.ch/iso/en/prods-services/ISOstore/store.html



• Support for full MPEG-4 header. The MPEG-4 Encoder core supports full MPEG-4 header for elementary stream; short header is not supported in this release.

• Discrete Cosine Transform. The core implements the standard compliant Discrete Cosine Transform (DCT) and Inverse Discrete Cosine Transform (IDCT), which is used to transform an eight-by-eight block of video information from the frequency domain to the spatial domain. The data is in the frequency domain and the coefficients or residual information can be quantized and efficiently encoded for low bandwidth channels. The encoder also performs the inverse quantization and IDCT to reconstruct the same reference frame as the decoder has.

• Macroblock processing. The MPEG-4 Encoder core operates on a macroblock structure, a basic and important data structure of the MPEG-4 algorithm. The macroblock structure contains YUV information for a particular sub-section of the image, namely a 16-pixel by 16-pixel square. Because the chroma data representation of that block of video information is reduced in spatial frequency in both the horizontal and vertical directions, there are less informational pixels needed for the UV components (1/4 of the luma channel information for both color channels). Therefore, a macroblock is comprised of 4 luma channel eight-by-eight blocks, one U channel eight-by-eight block, and one V channel eight-by-eight block representing a 16-pixel by 16-pixel portion of the image.

• Residual processing. Following the motion estimation process, the information that will be encoded consists of either motion compensation vectors or residual coefficient data. The residual coefficients are sent to the Texture_Coding module where DC and AC prediction processing occurs based on picture type and macroblock location. The resulting frequency domain pixels are processed by the inverse quantization and the inverse discrete coefficient transform to convert the information back to the spatial domain, this information is used to build the next reference frame. The frequency domain pixels together with the associated motion vectors are also sent to the entropy coder which generates the final encoded bitstream.

• 8-bit input data. For 8-bit data, the MPEG-4 Encoder requires 8-bit input data and produces 8-bit encoded bitstreams. A 32-bit pixel packed data interface is provided on the interface.

• 12-bit DTC coefficients. For DCT transformed coefficient data, 12-bit representation is used to maintain internal bit accuracy during the execution of the two-stage separable frequency conversion operation.

• AC/DC prediction. The MPEG-4 standard uses different prediction modes of operation in determining the DC and AC initial values or predicted values. The core determines which mode that has to be employed, then calculates the appropriate value with the result being added to the parsed coefficient.

• Local YUV buffer. During the motion compensation process, macroblocks from the previous frame will be used in the construction of the current video image. In fact, the same macroblock may be used in the construction of a number of current image macroblocks. Therefore, the core has a local buffer that will contain a number of macroblocks that may be used multiple times in the motion compensation process. The local buffer concept has been employed to minimize bus bandwidth traffic.

• Communication primitives. The MPEG-4 Encoder core uses a variety of communication primitives, hardware-based memories, to send variable blocks of data between the different functional modules. These primitives help create a smooth processing flow between the variable number clocks needed for each module inherent in a variable length encoding scheme.

• Bit-accurate testing. The data generated by the MPEG-4 Encoder core has been compared to a functional C-model program to ensure bit-accurate functionality of the hardware core.





MPEG-4 Simple Profile Encoder Core OverviewThe MPEG-4 Encoder provides a set of 15 precompiled configurations delivered as netlists to support specific modes of operation. The variations to the basic core involve changing the image resolution and the number of supporting bitstreams. All the configurations originate from the same VHDL file with different generic map settings. Table 1 defines the available configurations, all of which support 30 frames per second.

Input Interface

This interface accepts data from the acquiring in 4:2:0 YUV macroblock format. The incoming data is 32- bits wide. The data is put into the encoder through a write enable while monitoring a full flag. If the user wants to send a burst of data to the encoder, an empty flag can be polled and a burst of data can be sent to the encoder if the empty state is detected.

Table 1: Core Configuration

File Name (EDF) Resolution Description

MPEG4_SP_Encoder_V4_QCIF.edf QCIF Low resolution core operating at QCIF resolution for a Virtex-4 device.

MPEG4_SP_Encoder_V5_QCIF.edf QCIF Low Resolution Core operating at QCIF resolution for a Virtex-5 device.

MPEG4_SP_Encoder_V2P_QCIF.edf QCIF Low resolution core operating at QCIF resolution for a Virtex-II Pro device.

MPEG4_SP_Encoder_S3_QCIF.edf QCIF Low resolution core operating at QCIF resolution for a Spartan-3 device.

MPEG4_SP_Encoder_S3A_QCIF.edf QCIF Low Resolution Core operating at QCIF resolution for a Spartan-3A device.

MPEG4_SP_Encoder_V4_CIF.edf CIF Medium resolution core operating at CIF resolution for a Virtex-4 device.

MPEG4_SP_Encoder_V5_CIF.edf CIF Low Resolution Core operating at CIF resolution for a Virtex-5 device.

MPEG4_SP_Encoder_V2P_CIF.edf CIF Medium resolution core operating at CIF resolution for a Virtex-II Pro device.

MPEG4_SP_Encoder_S3_CIF.edf CIF Medium resolution core operating at CIF resolution for Spartan-3 device.

MPEG4_SP_Encoder_S3A_CIF.edf CIF Low Resolution Core operating at CIF resolution for a Spartan-3A device.

MPEG4_SP_Encoder_V4_4CIF.edf 4CIF High resolution core operating at 4CIF resolution for a Virtex-4 device.

MPEG4_SP_Encoder_V5_4CIF.edf 4CIF Low Resolution Core operating at 4CIF resolution for a Virtex-5 device.

MPEG4_SP_Encoder_V2P_4CIF.edf 4CIF High resolution core operating at 4CIF resolution for a Virtex-II Pro device.

MPEG4_SP_Encoder_S3_4CIF.edf 4CIF High-resolution core operating at 4CIF resolution for a Spartan-3 device.

MPEG4_SP_Encoder_S3A_4CIF.edf 4CIF Low Resolution Core operating at 4CIF resolution for a Spartan-3A device.





Memory Interface

There are two memory interface units within this design: one memory interface reads data from the memory controller to the locally stored memory used by the motion estimation and compensation modules, and a second one writes the reconstructed macroblock to the external memory for use on the next frame pass. Note that this MPEG-4 Encoder core needs an external memory controller to function properly.

Output Interfaces

The output interfaces are the output of the MPEG-4 Encoder core. It has two types of outputs, bitstream data and rate control information. The output of the encoder core is a bitstream in elementary stream format complete with VOL and VOP headers. Additionally, for each frame a parameter is read from the parameter FIFO to guide the rate control algorithm.

Host Interface

The host interface provides the user with the ability to read statistical data generated during the encod-ing process. This data is used by the user’s rate control algorithm to determine the q factor for the next frame of data.

MPEG-4 Simple Profile Encoder without Memory ControllerThe MPEG-4 Encoder core without a memory controller receives input samples in 4:2:0 YUV format and outputs the bitstream in elementary stream format. The input is macroblock by macroblock format progressing across the frame of video and sent the encoder input. The output includes packetization for complete elementary stream coming out of the output interface.

The MPEG-4 Encoder core uses half-pel resolution motion estimation and compensation from the pre-viously reconstructed frame. A 16x16 Macroblock (MB) is the basic memory unit used in an MPEG-4 system and is defined as a block of memory with 384 samples. For YUV 4:2:0 video data format, it con-tains four luma 8x8 pixel blocks, one U chroma channel 8x8 block, and one V chroma channel 8x8 block. This MPEG-4 Encoder supports 8-bit pixel inputs and 12-bit DCT coefficients (both before and after dequantization).

The memory interface section of the MPEG-4 Encoder attaches to an external memory controller via multiple ports on the core in either the read or the write mode. The memory controller module is the hardware that allocates which port has access to the memory at a given instance in time. The interface to/from the memory controller occurs in a burst mode to simplify interface considerations and speed up memory access times. This control information overhead is transmitted to the controller at power up and is a system-defined parameter.

The output interface delivers the compressed data from the core in elementary stream format. The vari-able length encoder and packetization is contained within the core and no external processing function is required before sending the data out to the transport protocol.

The host interface section allows an external processor or control unit to write to control registers or read status registers that are embedded in the encoder core.

The MPEG-4 Encoder processes a video frame’s worth of information at a time. This allows the encoder to operate and minimizes the amount of on-chip memory storage for state variables and dynamic reg-ister values.





Figure 1 illustrates the interfaces to the major functional blocks of the MPEG-4 Encoder core, as well as how they are internally connected. Notice that the major functions described in the MPEG standards document appear in the illustration. X-Ref Target - Figure 1

Figure 1: MPEG-4 Simple Profile Encoder without Memory Controller

Compensation

Search Area

Buffer YUV

Software Orchestrator(Rate Control and Parameters)

InputController

CopyController

Shared Memory

Motion Compensation

TextureCoding

VariableLengthCoding

BitstreamPacketization

Output Interface

TextureUpdate

Motion Estimation

Shared Memory





4CIF, CIF, and QCIF Interfaces

Figure 2 displays MPEG-4 Encoder interface signals without a memory controller. The difference between the 4CIF, CIF, and QCIF netlists is the amount of local memory necessary in the shared mem-ory block; however, all three netlists have the same pinouts and functionality.

The core input interface accepts signals from a storage source or camera source, which stores its raw data in memory and is read out in macroblock order. The user may burst the data by observing the empty signal and sending a 511 burst if empty. The user must ensure that the full flag is monitored so data sent to the encoder core is not lost.

The output interface is a FIFO-style interface with read enables used to read a word of data out of the encoder. The full flag can be monitored for burst reads of 511. The user must monitor the empty flag to be sure that valid data is present on the output interface.

X-Ref Target - Figure 2

Figure 2: MPEG-4 Simple Profile Encoder without Memory Controller

ENC_IN_D[31:0] ENC_IN_FULL ENC_IN_WE ENC_IN_EMPTY ENC_OUT_RE ENC_OUT_Q[31:0] ENC_OUT_FULL ENC_OUT_EMPTY ENC_PARAMS_RE ENC_PARAMS_Q[29:0] ENC_PARAMS_FULL ENC_PARAMS_EMPTY MEM_WQ_FULL MEM_WQ_WAD[31:0] MEM_WQ_AFULL MEM_WQ_WBX[4:0] MEM_WQ_WCNT[6:0] MEM_WQ_FLUSH MEM_WQ_WERR MEM_WQ_PUSH MEM_RQ_JOB_FULL MEM_RQ_POP MEM_RQ_JOB_ERR MEM_RQ_JOB_PUSH MEM_RQ_RCNT[6:0] MEM_RQ_FLUSH MEM_RQ_RD[31:0] MEM_RQ_JOB_AD[31:0] MEM_RQ_EMPTY MEM_RQ_AE MEM_RQ_RERR HOST_CE HOST_RE_ACK HOST_WE HOST_DOUT[31:0] HOST_RE HOST_ADDRESS[4:0] HOST_DIN[31:0] CLK RESET

MPEG-4 Simple Profile Encoderwithout Memory Controller

ENC_IN_EMPTY





The write to memory controller interface sends reconstructed video image information to a memory that will be used for the memory compensation portion of the design. The information is sent in small bursts to maximize memory bandwidth. The burst size is 16 32-bit words, equivalent with a block of 8x8 pixels. The information is preceded with a memory address as identified by the control bus associ-ated with the data bus.

The read from memory interface retrieves a portion of the reconstructed image that will be used in the motion compensation module. Once the starting address of the memory buffer is known, this section will determine what part of the memory it has to read in order to get the appropriate macroblock. It has a similar interface as the write to memory controller where the address is sent to the memory controller and the appropriate data is sent in burst to the core.

Note that this particular core has the external memory controller being supplied by the user allowing freedom to choose any memory as well as its interfaces needed. Later in this document is a description of a sub-core that has a memory controller built into the decoding process.

The host interface is used to update the quality factor for rate control operation. After the frame param-eter is read from the parameter output the rate control algorithm can calculate a new Q factor and update the register through the host interface.

The encoder core has a single system clock that is sent to all of the processing modules. Additionally a synchronous clear signal is available that will reset all modules.

All signals in this design use active HI signals unless stated otherwise in the signal description section of this document.

Common Interface

Table 2 defines the signals common to the MPEG-4 Encoder core.

Input Interface

Table 3 defines the MPEG-4 Encoder input interface signals. The input interface connects to storage or camera feed through memory. The input data is directed to a input FIFO internally which generates FIFO full and empty signals that have to be monitored by the user. The format of the input data is in YUV 4:2:0 macroblock format as shown in Figure 3. The input interface diagram is in Figure 4.

Table 2: Common Interface Signals

Name Direction Description

clk Input MPEG-4 Encoder Clock: All systems and interface operations are synchronous to this clock.

reset Input MPEG-4 Encoder Sync Clear: Clear signal that resets all internal states to a known state.





Table 3: Input Interface Signals


enc_in_d[31:0] Input Encoder Input Data Bus: 32-bit input supplying the raw macroblock data in little endian form (pixel 0 bits 7:0).

enc_in_we Input Encoder Input Write Enable: The write enable signal to the encoder loads a data value of information into the encoder at the next clock edge.

enc_in_full Output Encoder Input Full Signal: A signal that tells the source of the raw macroblock data that the encoder is no longer capable of accepting data.

enc_in_empty Output Encoder Input Empty Signal(1): A signal that tells the source of the raw macroblock data that the internal FIFO of the encoder is empty and can accept more data.

Notes: 1. The empty signal of the input FIFO is not strictly necessary to send the data to the encoder. However, it is provided

to enable burst-based transactions for increased transfer efficiency. The empty signal indicates that the input FIFO can accept up to a predetermined number of samples. The maximum number of accepted samples is 511.


Figure 3: Input Interface Signals


Figure 4: Input Interface Timing Diagram

0x000

0x0FF

0x100

0x13F

0x14F

0x17F

Y Component

V Component

U Component

0x00F





Output Interfaces

Table 4 defines the MPEG-4 Encoder output interface signals. The MPEG-4 Encoder outputs the com-pressed bitstream on the ENC_OUT_Q signal and the user can read this data through the read enable signal. Also the statistics needed for rate control can be read out of the ENC_PARAMS_Q bus using the parameter read enable signal. Each word present in the FIFO represents the number of bits produced for the frame processed. Each 30-bit word is generated after one frame has been processed. The ENC_PARAMS_EMPTY flag can be used as an interrupt or polled bit to signal that a frame has been completed and rate control calculations can be made with the parameter.

Figure 5 illustrates data being sent from the encoder to the output. Also, enc_params_* signals have similar FIFO behavior as represented in Figure 5 for the enc_out_* signals.

Table 4: Output Interface Signals


enc_out_q[31:0] Output Encoder Output: This bus contains the output bitstream.

enc_out_full(1) Output Encoder Output Full: This signal indicates the output is full.

enc_out_empty Output Encoder Output Empty: This signal indicates the output is empty and should not be read.

enc_out_re Input Encoder Output Read Enable: This signal is used to read data out of the encoder.

enc_params_q[29:0] Output Encoder Parameter Output: This bus contains the number of bits for a frame of video. Each word corresponds to a single frame with one word produced each frame.

enc_params_full(1) Output Encoder Parameter Output Full: This signal indicates that params output is full.

enc_params_empty Output Encoder Parameter Output Empty: This signal indicates the params output is empty and should not be read.

enc_params_re Input Encoder Parameter Output Read Enable: This signal is used to read params data out of the encoder.

Note: 1. The full signal of the output FIFOs are not strictly necessary to send the data out from the encoder. However, they

are provided to enable burst-based transactions for increased transfer efficiency. The full signals indicate that from the output FIFOs to a predetermined number of samples can be read. The maximum number that can be read in a single burst is 511. When using enc_param_full, the maximum read burst is 15 samples.


Figure 5: Output Timing Diagram





Memory Interface

Write Memory Controller Interface

This section defines the signals that interface the external memory controller to the section of the MPEG-4 Encoder that supplies an expanded video frame used by the motion compensation process. The address/data is sent to the memory controller in 32-bit words, along with a five-bit control bus. Table 5 identifies the significance of the control bus.

The control information indicates the presence of an address or data on the address/data bus, as well as the number and position of valid data bytes, and also allows a mechanism that aborts the current transfer. The information is sent in bursts in order for effective bus bandwidth architecture. The MPEG-4 SP Encoder core always generates write bursts of sixteen 32-bit words, corresponding to the size of one 8 x 8 block. The recommended write queue size is 512, corresponding with one block RAM. How-ever, the encoder uses strictly only the full and almost full flags; therefore, the user can set the write queue size to any desired size. Table 6 defines the MPEG-4 Encoder write memory controller interface signals.

Write requests by the user interface (the core) to the memory controller follow a queuing protocol. Each user write port, WQn, sends either a data or an address word to its queue via the set of WAD, WBX, and PUSH signals. Figure 6 illustrates a sample write transfer. To start a transfer to external memory, the user asserts the PUSH signal and then sets the address on WAD and the appropriate code in the WBX signals indicated by a highlighted segment. Each subsequent cycle that PUSH is asserted should have data words on the WAD bus and the appropriate byte enable settings in the WBX. The user can then issue data into the write queue at its own rate, taking wait states as necessary. While pushing data onto the queue, the user should be mindful of the queue status signals: FULL, AFULL, WCNT, and WERR. If data is pushed onto a full queue, the WERR flag asserts. WCNT updates to keep a count of the num-ber of 16-word bursts currently in the queue.

Table 5: Control Word (WBX) Definitions

4 3 2 1 0 WBX

0 0 0 0 0 Address present on WAD

1 X X X 0 Bits (7:0) Valid

1 X X 0 X Bits (15:8) Valid

1 X 0 X X Bits (23:16) Valid

1 0 X X X Bits (31:24) Valid

0 1 1 1 1 End of Data (short burst indicator)

Table 6: Write Memory Controller Interface Signals


mem_wq_full InputMemory Controller Write Full: Signal that tells the MPEG-4 Encoder that the write FIFO in the memory controller is full and cannot accept any more data.

mem_wq_afull Input

Memory Controller Write Almost Full: Signal that tells the MPEG-4 Encoder that the write FIFO in the memory controller is almost full. It has space available only to complete the current block. Not additional transactions should occur after the completion of the current block and the AFULL line goes inactive.





Read Memory Controller Interface

This section describes the signals that interface the external memory controller to the section of the MPEG-4 Encoder supplied with portions of the previous video frame needed in the motion compensa-tion process. The pre-determined macroblock address is derived and sent to the memory controller to gather the appropriate macroblock information in a 32-bit data word similar to the write process described in "Input Interface," page 18. Table 7 defines the MPEG-4 Encoder read memory controller interface signals.The MPEG-4 SP Encoder Core always generates read burst request of 16 words of 32-bit, corresponding to the size of one 8 x 8 block. The recommended burst request queue is 32 words of 32-bit. The recommended read queue size is 512, corresponding with one block RAM. However, because the encoder uses strictly only the empty and almost empty flags, the user can set the read queue size to any desired size.

mem_wq_wcnt[6:0](1) Input Memory Controller Write Count: Number of 16 words of 32- bit bursts currently in Write FIFO.

mem_wq_werr(1) Input Memory Controller Write Error: Write FIFO error.

mem_wq_wad[31:0] Output Memory Controller Write Data Bus: Write address / data multiplexed.

mem_wq_wbx[4:0] Output Memory Controller Write Control Bus: Write byte enables/address tag (see Table 5).

mem_wq_flush(1) Output Memory Controller Write Flush Signal: Flush write FIFO (asynchronous).

mem_wq_push Output Memory Controller Write Push Signal: Push contents of WAD onto write FIFO.

Note: 1. The current write interface is provided for compatibility with the existing Xilinx memory controller. However, the

MPEG-4 SP Encoder core does not require all the features available on the memory controller. Following is a list of unused signals from the write interface: mem_wq_wcnt[6:0] - Input not used; mem_wq_werr - Input not used; mem_wq_flush - Output always driven to 0. Users can treat these signals accordingly in their own implementation of the memory controller.


Figure 6: Write Memory Operation

Table 6: Write Memory Controller Interface Signals (Cont’d)


Address Data Data Data Data

00000

clk

mem_wq_push

mem_wq_wad[31:0]

mem_wq_wbx[4:0]

mem_wq_full

mem_wq_afull

mem_wq_werr

10000

ds511_06_031708





Read transfers are first initiated by issuing an address to the read port’s job queue. The user sets the address for the read request with JOB_AD and asserts the JOB_PUSH signal as shown in Figure 7. The user cannot push an address onto the job queue if the JOB_FULL flag is asserted. (The JOB_ERR signal asserts high in this case.) After a number of cycles the read queue’s EMPTY flag will deassert (logic zero) indicating data is now present in the read queue for retrieval. When the almost empty flag is deas-serted, it is an indication that there are at least the number of data words as the almost threshold was set to, present in the queue.

The RCNT signal also indicates the number of 8 word bursts available in the queue. When the user port asserts its POP signal, the number of data words as set in the read port’s burst length register from the start address will be delivered at each subsequent clock cycle while POP remains asserted. If the user deasserts POP, the FIFO does not deliver data to the next cycle. In this way, the user can control the rate at which data is taken from the FIFO. The user is responsible for keeping track of the length of the burst and popping the correct number of data words from the queue to reconstitute its memory request. The user may queue multiple job address requests, but must keep track of the words that are returned. The read queue does not flag data returned as being from different jobs. However, jobs are processed in order. The user must keep a running total of the returned data to determine the address range it belongs to. The user may not POP from an EMPTY queue; the RERR will be asserted in this event.

Table 7: Read Memory Controller Interface Signals


mem_rq_job_full Input Memory Controller Read Full: Read job queue full.

mem_rq_job_err(1) Input Memory Controller Read Error Signal: Read job queue error.

mem_rq_rcnt[6:0](1) Input Memory Controller Read Count: Number of 32-byte 8-word bursts in Read FIFO.

mem_rq_rd[31:0] Input Memory Controller Read Bus: Read data.

mem_rq_empty Input Memory Controller Read Empty: Read empty.

mem_rq_ae Input Memory Controller Read Almost Empty: Read almost empty (programmable threshold).

mem_rq_rerr(1) Input Memory Controller Read Error: Read error.

mem_rq_job_ad[31:0] Output Memory Controller Read Address Bus: Read job address.

mem_rq_job_push Output Memory Controller Read Data Signal: Push job onto read job queue.

mem_rq_flush(1) Output Memory Controller Read Flush Signal: Flush all read traffic.

mem_rq_pop Output Memory Controller Read Pop Signal: Pop read queue.

Note: 1. The current read interface is provided for compatibility with the existing Xilinx memory controller. However, the

MPEG-4 SP Encoder core does not require all the features available on the memory controller. Following is a list of unused signals from the read interface: mem_rq_rcnt[6:0] - Input not used; mem_rq_rerr - Input not used, mem_rq_job_rerr - Input not used; mem_rq_flush - Output always driven to 0. The user can treat these signals accordingly in its own implementation of the memory controller.





Host Interface

Table 8 defines the MPEG-4 Encoder host interface signals. The MPEG-4 Encoder host interface inter-faces with a host processor that can send and receive information to/from the encoder core. The data is transmitted synchronously with the encoder core clock. There are chip enable signals signifying the host interface is being accessed in either a write or read mode. Registers that exist with their respective addresses and bit definitions are also defined.


Figure 7: External Memory Data Read Timing Diagram

Table 8: Host Interface


host_ce Input Host Interface Chip Enable: The enable signal from an external host that informs the MPEG-4 Encoder host interface to prepare for a read or write operation.

host_we Input Host Interface Write Enable: The write-enable signal to the host interface that defines a write operation is taking place to the register addressed by the address bus.

host_re Input Host Interface Read Enable: The read-enable signal to the host interface that defines a read operation is taking place to the register addressed by the address bus. After a read has occurred, it is confirmed by a read acknowledgement signal.

host_address[4:0] Input Host Interface Address Bus: A 5-bit address bus that contains the address of the register being selected for the read or write operation. Used with the input or output data buses to write or read to a particular register.

host_din[31:0] Input Host Interface Data Input Bus: The 32-bit data bus used to deliver data to one of the host interfaces registers.

host_re_ack Output Host Interface Read Acknowledge: The signal from the host interface to the host that states that the read operation has been completed and the data is on the data output bus.

host_dout[31:0] Output Host Interface Data Output Bus: The 32-bit data bus used to send data to the host from one of the host interfaces registers.

Data Data Data Data

clk

mem_rq_ae

mem_rq_job_ad[31:0]

mem_rq_job_push

mem_rq_empty

mem_rq_pop

mem_rq_rd[31:0]

ds511_07_031808





The following diagrams show a user interfacing to the MPEG-4 Encoder core through the host inter-face. Figure 8 displays an example of a write to the internal encoder core registers. The registers are selected with the host address signal and delivered to the register via the data bus.

Figure 9 displays an example of a read operation between the host and the host interface. The host interface activates a read acknowledgement signal to transmit to the host that the read data has been placed on the output bus.

Table 9 defines all the registers in the host interface as well as their address, the ability for the user to either read or read and write the register and the number of bits located within the specified register.


Figure 8: Host Interface Register Write Timing Diagram


Figure 9: Host Interface Register Read Timing Diagram

Table 9: Host Interface Register File Mapping

ParamReg Address

Parameter Direction(1)

ParamReg_DataOut Bits Width Parameter Name Description

0 Input 22:19 4 maxSpiralNumb Maximum search range starting from predicted position; default is 2.

0 Input 18:14 5 QP Quantization parameter; default is 4. This parameter the same as the QP in register 6. The values need to be set the same.

0 Input 13 1 vopRoundingType Default is 1.

0 Input 12 1 vopType Default is 1.

clk

host_ce

host_we

host_address

host_din

valid data valid data

ds511_18_100506





0 Input 11:6 6 frameMBHeight Number of Macroblocks in a frame height; default is 9.

0 Input 5:0 6 frameMBwidth Number of Macroblocks in a frame width; default is 11.

1 Input 31:12 20 frameMemoryOffset Offset pointer to use for external memory; default is 0.

1 Input 11:0 12 SADref Reference SAD (Sum of Absolute Difference) value for Motion Estimation; default is 536.

2 Output 26:0 27 MAD Maximum Absolute Difference

3 Output 26:0 27 SAD_NoMotion Sum of Absolute Difference with no motion

4 Output 26:0 27 SAD_Motion Sum of Absolute Difference with motion

5 Input 20:5 16 targetPacketSize For VLC coding packet size, default is 2048.

5 Input 4:2 3 DCvlcThres DC Variable Length coding threshold; default is 0.

5 Input 1 1 dataPartitioning Data Partitioning for VLC operation, Set to 0 and not utilized.

5 Input 0 1 errorResilienceDisable Set to 1 as error resiliency is not supported.

6 Input 25 1 moduloTimeIndex Default is 0.

6 Input 24:21 4 timeIncrementWidth For header time insertion; default is 5. Use 5 for 30 fps, 6 for 60 fps.

6 Input 20:18 3 quantPrecision Quantization precision; default is 5.

6 Input 17:13 5 QP Quantization parameter; default is 4. This parameter is the same as the QP in Register 0.

6 Input 12:10 3 DCvlcThres Default is 0.

6 Input 9 1 roundingType Default is 0.

6 Input 8 1 dataPartitioningEnable Default is 0.

6 Input 7 1 errorResilienceDisable Default is 1.


Table 9: Host Interface Register File Mapping (Cont’d)

ParamReg Address







MPEG-4 Simple Profile Encoder with Memory ControllerThe MPEG-4 Encoder core with Memory Controller provides 15 precompiled configurations delivered as netlists with a built-in ZBT memory controller to support QCIF, CIF, and 4CIF image resolutions, as well as different product families. The variations to the basic core involve changing the image resolu-tion and the number of supporting bitstreams. All the configurations originate from the same VHDL file with different generic map settings. Table 10 defines the available configurations, all of which sup-port 30 frames per second.

6 Input 5:1 5 videoObjectID Video object ID; default is 0.

6 Input 0 1 generateVolHeader Default is 0.

7 Input 31:16 16 timeIncrementResolution Default is 30. Example: timeIncrementResolution = 30, timeIncrementWidth = 5, timeIncrement = 1, 2, 3 each frame

7 Input 15:0 16 timeIncrement Default is 0, then each frame is 1, 2, 3, 4, etc.

8 Input 15:12 4 MBsInVOPbitWidth Default is 7.

8 Input 11:6 6 frameMBheight Number of Macroblocks in frame height.

8 Input 5:0 6 frameMBwidth Number of Macroblocks in frame width.

Notes: 1. Input = Read/Write, Output = Read only.

Table 10: Core Configuration with Memory Controller


MPEG4_SP_Encoder_V4__QCIF_wMEM.edf QCIF Low-resolution core operating at QCIF resolution for a Virtex-4 device.

MPEG4_SP_Encoder_V5_QCIF_wMEM.edf QCIF Low Resolution Core operating at QCIF resolution for a Virtex-5 device.

MPEG4_SP_Encoder_V2P_QCIF._wMEMedf QCIF Low-resolution core operating at QCIF resolution for a Virtex-II Pro device.

MPEG4_SP_Encoder_S3_QCIF_wMEM.edf QCIF Low-resolution core operating at QCIF resolution for a Spartan-3 device.

MPEG4_SP_Encoder_S3A_QCIF_wMEM.edf QCIF Low-resolution core operating at QCIF resolution for a Spartan-3A device.

MPEG4_SP_Encoder_V4__CIF_wMEM.edf CIF Medium-resolution core operating at CIF resolution for a Virtex-4 device.

MPEG4_SP_Encoder_V5__CIF_wMEM.edf CIF Medium-resolution core operating at CIF resolution for a Virtex-5 device.

MPEG4_SP_Encoder_V2P_CIF_wMEM.edf CIF Medium-resolution core operating at CIF resolution for a Virtex-II Pro device.


ParamReg Address







Input Interface

The Input interface accepts data from the acquiring in 4:2:0 YUV macroblock format. The incoming data is 8- or 32-bits wide. The data is put into the encoder through a write enable while monitoring a full flag. If the user would like to send a burst of data to the encoder an empty flag can be polled and a burst of data can be sent to the encoder if the empty state is detected.

ZBT Memory Interface

This configuration of the MPEG-4 Encoder core includes memory controller, which is used to send and retrieve macroblock information used in the motion compensation process. The core supplies two data buses: one for input and another for output, along with an output enable signal that are connected to a bi-directional bus structure by the user at the highest most level of the system design. The TRI_State buffer resides in the IOB module of the design.

Output Interfaces

The output interfaces are the output of the MPEG-4 Encoder core. It has two types of outputs, bitstream data and rate control information. The output of the encoder core is a bitstream in elementary stream format complete with VOL and VOP headers. Additionally, each frame a parameter is read from the parameter FIFO to guide the rate control algorithm.

Host Interface

The host interface gives the user the ability to read statistical data generated during the encoding pro-cess. This data is used by the users rate control algorithm to determine the q factor for the next frame of data.

MPEG4_SP_Encoder_S3_CIF_wMEM.edf CIF Medium-resolution core operating at CIF resolution for a Spartan-3 device.

MPEG4_SP_Encoder_S3A_CIF_wMEM.edf CIF Medium-resolution core operating at CIF resolution for a Spartan-3A device.

MPEG4_SP_Encoder_V4_4CIF_wMEM.edf 4CIF High-resolution core operating at 4CIF resolution for a Virtex-4 device.

MPEG4_SP_Encoder_V5_4CIF_wMEM.edf 4CIF High-resolution core operating at 4CIF resolution for a Virtex-5 device.

MPEG4_SP_Encoder_V2P_4CIF_wMEM.edf 4CIF High-resolution core operating at 4CIF resolution for a Virtex-II Pro device.

MPEG4_SP_Encoder_S3_4CIF_wMEM.edf 4CIF High-resolution core operating at 4CIF resolution for a Spartan-3 device.

MPEG4_SP_Encoder_S3A_4CIF_wMEM.edf 4CIF High-resolution core operating at 4CIF resolution for a Spartan-3A device.

Table 10: Core Configuration with Memory Controller (Cont’d)






Functional DescriptionThe MPEG-4 Encoder core with a memory controller receives the input samples in 4:2:0 YUV format and outputs the bitstream in elementary stream format. The input is macroblock by macroblock format progressing across the frame of video and sent the encoder input. The output includes packetization for complete elementary stream coming out of the output interface.

The MPEG-4 Encoder core uses half-pel resolution motion estimation and compensation from the pre-viously reconstructed frame. A 16x16 macroblock (MB) is the basic memory unit used in an MPEG-4 system and is defined as a block of memory with 384 samples. For YUV 4:2:0 video data format, it con-tains four luma 8x8 pixel blocks, one U chroma channel 8x8 block, and one V chroma channel 8x8 block. This MPEG-4 Encoder supports 8-bit pixel inputs and 12-bit DCT coefficients (both before and after dequantization).

The ZBT memory interface section of the MPEG-4 encoder has a built-in memory controller. It will interface to an external ZBT memory with the host of control signals and the input and output buses. The core is supplying the output bus and the input bus as well as an output enable signal. The user will combine the two buses into a single bidirectional bs that the ZBT memory requires.

The output interface delivers the compressed data from the core in elementary stream format. The vari-able length encoder and packetization is contained within the core and no external processing function is required before sending the data out to the transport protocol.

The host interface section allows an external processor or control unit to write to control registers or read status registers that are embedded in the encoder core.

The MPEG-4 Encoder processes a video frame’s worth of information at a time. This allows the encoder to operate and minimizes the amount of on-chip memory storage for state variables and dynamic reg-ister values.

Figure 10 illustrates the interfaces to the major functional blocks of the MPEG-4 Encoder core, as well as how they are internally connected. Notice that the major functions described in the MPEG standards document are present with the diagram.






Figure 10: MPEG-4 Simple Profile Encoder with Memory Controller

Compensation

Search Area

Buffer YUV

Software Orchestrator(Rate Control and Parameters)

InputController

CopyController

MemoryController

ExternalSRAM

Shared Memory

Motion Compensation

TextureCoding

VariableLengthCoding

BitstreamPacketization

Output Interface

TextureUpdate

Motion Estimation

Shared Memory





4CIF, CIF, and QCIF InterfacesFigure 11 displays the MPEG-4 Encoder interface signals with a memory controller. The difference between the 4CIF, CIF, and QCIF netlists is the amount of local memory necessary in the shared mem-ory block; however, all three netlists have the same pinouts and functionality.

The input interface of the core accepts signals from a storage source or camera source which stores its raw data into memory and is read out in macroblock order. The user may burst the data by observing the empty signal and sending 511 burst if empty. The user must ensure that the full flag is monitored so that data sent to the encoder core is not lost.

The output interface is a FIFO style interface with read enables used to read a word of data out of the encoder. The full flag can be monitored for burst reads of 511. The user must monitor the empty flag to be sure that valid data is present on the output interface.


Figure 11: MPEG-4 Simple Profile Encoder with Memory Controller

ENC_IN_D[31:0] ENC_IN_FULL ENC_IN_WE ENC_IN_EMPTY ENC_OUT_RE ENC_OUT_Q[31:0] ENC_OUT_FULL ENC_OUT_EMPTY ENC_PARAMS_RE ENC_PARAMS_Q[29:0] ENC_PARAMS_FULL ENC_PARAMS_EMPTY SRAM_CLK_FB SRAM_CLK_EX SRAM_DIN[35:0] SRAM_CLK SRAM_CKE SRAM_ADDR SRAM_DOUT[35:0] WORD_FLUSH SRAM_OE SRAM_BE[3:0] SRAM_CS SRAM_WE SRAM_SLEEP HOST_CE HOST_RE_ACK HOST_WE HOST_DOUT[31:0] HOST_RE HOST_ADDRESS[4:0] HOST_DIN[31:0] CLK RESET

MPEG-4 Simple Profile Encoderwith Memory Controller





This core uses external ZBT memory for the reconstructed frame. The host interface is used to update the quality factor for rate control operation. Once the frame parameter is read from the parameter out-put the rate control algorithm can calculate a new Q factor and update the register through the host interface.

The encoder core has a single system clock that is sent to all of the processing modules. Additionally a synchronous clear signal is available that will reset all modules and a signal that will initiate the encod-ing process. All signals in this design use active high signals unless stated otherwise in the signal description section of this document.

Common InterfaceTable 11 defines the signals common to the MPEG-4 Encoder core.

Input InterfaceTable 12 defines the MPEG-4 Encoder input interface signals. The input interface connects to storage or camera feed through memory. The input data is directed to a input FIFO internally which generate FIFO full and empty signals which have to be monitored by the user. The format of the input data is in YUV 4:2:0 macroblock format as shown in Figure 12.

Table 11: Common Interface Signals


clk Input MPEG-4 Encoder Clock: All systems and interface operations are synchronous to this clock.

reset Input MPEG-4 Encoder Sync Clear: Clear signal that resets all internal states to a known state.

Table 12: Input Interface Signals


enc_in_d[31:0] Input Encoder Input Data Bus: 32-bit input supplying the raw macroblock data in little endian form (pixel 0 bits 7:0).

enc_in_we Input Encoder Input Write Enable: The write enable signal to the encoder loads a data value of information into the encoder at the next clock edge.

enc_in_full Output Encoder Input Full Signal: A signal that tells the source of the raw macroblock data that the encoder is no longer capable of accepting data.

enc_in_empty Output Encoder Input Empty Signal: A signal that tells the source of the raw macroblock data that the internal FIFO of the encoder is empty and can accept more data (burst of 511).





Figure 13 shows the input Interface Timing Diagram.


Figure 12: Input Interface Signals


Figure 13: Input Interface Timing Diagram

0x000

0x0FF

0x100

0x13F

0x14F

0x17F

Y Component

V Component

U Component

0x00F





Output InterfaceTable 13 defines the MPEG-4 Encoder output interface signals. The MPEG-4 Encoder outputs the com-pressed bitstream on the ENC_OUT_Q signal and the user can read this data through the read enable signal. Also the statistics needed for rate control can be read out of the ENC_PARAMS_Q bus using the parameter read enable signal. The ENC_PARAMS_EMPTY flag can be used as an interrupt or polled bit to signal that a frame has been completed and rate control calculations can be made with the param-eter.

Figure 14 illustrates data being sent from the encoder to the output. Also, enc_params_* signals have similar FIFO behavior as represented in Figure 14 for the enc_out_* signals.

Table 13: Output Interfaces


enc_out_q[31:0] Output Encoder Output: This bus contains the output bitstream.

enc_out_full Output Encoder Output Full: This signal indicates the output is full and the user can burst 511 samples if desired.

enc_out_empty Output Encoder Output Empty: This signal indicates the output is empty and should not be read.

enc_out_re Input Encoder Output Read Enable: This signal is used to read data out of the encoder.

enc_params_q[29:0] Output Encoder Parameter Output: This bus contains the number of bits for a frame of video. Each word corresponds to a single frame with one word produced each frame.

enc_params_full Output Encoder Parameter Output Full: This signal indicates that params output is full.

enc_params_empty Output Encoder Parameter Output Empty: This signal indicates that the params output is empty and should not be read.

enc_params_re Input Encoder Parameter Output Read Enable: This signal is used to read params data out of the encoder.


Figure 14: Output Timing Diagram





ZBT Memory InterfaceThis section defines the signals that interface the external ZBT memory to the section of the MPEG-4 Encoder that supplies a video frame used by the motion compensation process. The address and data are sent to the memory 36-bit words (using four parity check bits). The signals that interface to the ZBT memory are listed and described in the following table. The TRI-State bus must be derived at a higher level than the MPEG-4 Encoder core with memory controller. The interface has three clock signals that deal with compensating for any delays in the clock line. Two are output clock signals and one is an input clock line. One pair are used in a feedback arrangement to de-skew the ZBT main clock signal. There is an address bus associated with the data input and data output buses as well as clock enable signals that will allow activity to occur during the positive transitions of clock. The byte enable signal determines which of the bytes of a data word are valid for the write or read operation. Table 14 defines the write memory controller interface signals.

Table 14: Write Memory Controller Interface Signals


sram_clk Output SRAM Clock: The memory clock signal.

sram_clk _fb Input SRAM Feedback Clock: The internal clock trace feedback inbound signal.

sram_clk _ex Output SRAM External Clock: The external clock trace feedback outbound signal.

sram_cke Output SRAM Clock Enable: The clock enable signal to the memory from the core that disables the memory clock. It is an active LO signal. All memory clock edges should be active while data addresses are on the address and data buses.

sram_addr[20:0] Output SRAM Address Bus: The address bus that carries the memory address to the memory. The address should be on the bus two cycles before the associated data.

sram_dout[35:0] Output SRAM Data Output Bus: The output data bus that sends data to the memory over the bi-directional data bus. The SRAM output enable signal should be LO when data is generated by the encoder during a write operation.

sram_din[35:0] Input SRAM Data Input Bus: The input data bus that receives data from memory over the bi-directional data bus. The SRAM output enable signal should be HI when data is generated by the memory during a read operation.

sram_be[3:0] Output SRAM Byte-enable Signal: Active LO signal that identified which bytes are active in the current data word. Because the bus is 32-bits long, there are four bytes per word where the lowest byte corresponds to the least significant value in this control word.

sram_cs Output SRAM Chip Select Signal: Active LO signal that identifies when an address is placed on the address bus.

sram_we Output SRAM Write-enable Signal: Active LO signal that tells the memory that a write operation is being performed.

sram_sleep Output SRAM Sleep Signal: Active HI signal that puts the memory into a sleep state. The signal should be LO for normal memory operations.

sram_oe Output SRAM Output Enable Signal: The signal from the memory controller to the tri-state buffer input that selects the output bus from the memory controller to be placed on the bi-directional bus. This signal is inverted and then sent to the memory device.





Figure 15 displays the write to memory operation. The chip select line is active while address data exists on the address bus and the output enable signal is active while data information is on the data bus. The write enable signal is active for all write operations.

Figure 16 displays the read from memory operation. It is similar to the write operation with the write enable signal inactive for read operations.

Figure 17 shows how to make the bi-directional bus at the top level of the design using the input and output data buses from the encoder core with the output-enable signal. Note that the SRAM_OE_n sig-nal is used by the local tri-state device to place data on the data bus. It is then inverted and sent to the memory device so it can place data onto the bus at the appropriate time.


Figure 15: Write Memory Operation


Figure 16: Read Memory Operation


Figure 17: Tri-State Memory Interface

sram_clk

sram_cke_n

sram_addr[20..0]

sram_dout[35..0]

sram_oe_n

sram_cs_n

addr(A) addr(B) addr(C)

data(A) data(B) data(C)

sram_clk

sram_cke_n

sram_addr[20..0]

sram_dout[35:0]

sram_oe_n

sram_cs_n

addr(A) addr(B) addr(C)

data(A) data(B) data(C)

SRAM_OE_n SRAM_OE

SRAM_DATAOUT[31:0] MEMORY_BUS[31:0]

SRAM_DATAIN[31:0]





Host InterfaceTable 15 defines the MPEG-4 Encoder host interface signals. The MPEG-4 Encoder host interface inter-faces with a host processor that can send and receive information to/from the encoder core. The data is transmitted synchronously with the encoder core clock. There are chip enable signals signifying the host interface is being accessed in either a write or read mode. Registers that exist with their respective addresses and bit definitions are also defined.

The following diagrams illustrate a user interfacing to the MPEG-4 Encoder through the host interface. Figure 18 displays an example of a write to the internal encoder core registers. The registers are selected with the host address signal and delivered to the register via the data bus. Figure 19 displays an exam-ple of a read operation between the host and the host interface. The host interface activates a read acknowledgement signal to transmit to the host that the read data has been placed on the output.

Table 15: Host Interface


host_ce Input Host Interface Chip Enable: Enable signal from an external host that informs the MPEG-4 Encoder host interface section of the core to prepare for a read or write operation.

host_we Input Host Interface Write Enable: Write enable signal to the host interface that defines a write operation is occurring on the register addressed by the address bus.

host_re Input Host Interface Read Enable: Read enable signal to the host interface that defines a read operation is occurring on the register addressed by the address bus. After a read has occurred, it is confirmed by a read acknowledgement signal.

host_address[4:0] Input Host Interface Address Bus: A 5-bit address bus that contains the address of the register being selected for the read or write operation. It is used with the input or output data buses to write or read to a particular register.

host_din[31:0] Input Host Interface Data Input Bus: The 32-bit data bus used to deliver data to one of the host interfaces registers.

host_re_ack Output Host Interface Read Acknowledge: The signal from the host interface to the host that states that the read operation is complete and the data is on the data output bus.

host_out[31:0] Output Host Interface Data Output Bus: The 32-bit data bus used to send data to the host from one of the host interfaces registers.


Figure 18: Host Interface Register Write

clk

host_ce

host_we

host_address

host_din

valid data valid data

ds511_18_100506





Table 16 defines the registers in the host interface as well as their address, the ability for the user to either read or read and write the register, and the number of bits located in the specified register.

Figure Top x-ref 1

Figure 19: Host Interface Register Read

Table 16: Host Interface Register File Mapping

ParamReg Address

Parameter Direction


0 Input 22:19 4 maxSpiralNumber Maximum search range starting from predicted position; default is 2.

0 Input 18:14 5 QP Quantization parameter; default is 4. This parameter the same as the QP in register 6. The values need to be set the same.

0 Input 13 1 vopRoundingType Default is 1.


0 Input 11:6 6 frameMBHeight Number of Macroblocks in a frame height; default is 9.

0 Input 5:0 6 frameMBwidth Number of Macroblocks in a frame width; default is 11.

1 Input 31:12 20 frameMemoryOffset Offset pointer to use for external memory; default is 0.

1 Input 11:0 12 SADref Reference SAD (Sum of Absolute Difference) value for Motion Estimation; default is 536.

2 Output 26:0 27 MAD Maximum Absolute Difference

3 Output 26:0 27 SAD_NoMotion Sum of Absolute Difference with no motion

4 Output 26:0 27 SAD_Motion Sum of Absolute Difference with motion

5 Input 20:5 16 targetPacketSize For VLC coding packet size, default is 2048.





5 Input 4:2 3 DCvlcThres DC Variable Length coding threshold; default is 0.

5 Input 1 1 dataPartitioning Data Partitioning for VLC operation, Set to 0 and not utilized.

5 Input 0 1 errorResilienceDisable Set to 1 as error resiliency is not supported.

6 Input 25 1 moduloTimeIndex Default is 0.

6 Input 24:21 4 timeIncrementWidth For header time insertion; default is 5. Use 5 for 30 fps, 6 for 60 fps.

6 Input 20:18 3 quantPrecision Quantization precision; default is 5.

6 Input 17:13 5 QP Quantization parameter; default is 4. This parameter is the same as the QP in Register 0.

6 Input 12:10 3 DCvlcThres Default is 0.

6 Input 9 1 roundingType Default is 0.

6 Input 8 1 dataPartitioningEnable Default is 0.

6 Input 7 1 errorResilienceDisable Default is 1.


6 Input 5:1 5 videoObjectID Video object ID; default is 0.

6 Input 0 1 generateVolHeader Default is 0.

7 Input 31:16 16 timeIncrementResolution Default is 30. Example: timeIncrementResolution = 30, timeIncrementWidth = 5, timeIncrement = 1, 2, 3 each frame.

7 Input 15:0 16 timeIncrement Default is 0, then each frame is 1, 2, 3, 4, etc.

8 Input 15:12 4 MBsInVOPbitWidth Default is 7.

8 Input 11:6 6 frameMBheight Number of Macroblocks in frame height.

8 Input 5:0 6 frameMBwidth Number of Macroblocks in frame width.

Notes: 1. Input = Read/Write, Output = Read only.


ParamReg Address

Parameter Direction






Resource UtilizationSee Table 17 and Table 18 for the supported FPGA families’ resouce usage.

Table 19 defines the possible frame rate and resolution throughputs with the present encoder at a vari-ety of clock frequencies. These values were calculated based on the required throughput of the frame resolution and frame rate.

Design Tool RequirementsThe MPEG-4 decoder was implemented and tested and in the following software versions:

• Xilinx Implementation Tools - Xilinx ISE 8.2 SP2• Verification -

♦ ModelSim 5.8c SE

♦ Microsoft Studio v6.0♦ ActivePerl 5.8.3♦ Annapolis Micro Systems♦ Wildcard-II platform API 2.6♦ Driver 3.3 Firmware 1.6

• Simulation - ModelSim 5.8c SE• Synthesis - Synplicity Synplify 8.6.2

Table 17: Virtex-4, Virtex-II Pro, Virtex-II, Spartan-3, Spartan-3A FPGA Resource Usage

Resources Used Slices LUTs FFs Block RAMs

Mults/DSP48s

QCIF 8,303 12,630 6,093 16 17

CIF 9,019 12,778 6,335 23 174CIF 9,353 13,260 6,598 36 17

QCIF with Memory Controller 9,138 13,036 6,575 20 17

CIF with Memory Controller 9,251 13,085 6,650 27 174CIF with Memory Controller 9,639 13,592 6.944 40 17

Table 18: Virtex-5 FPGA Resource Usage

Resources Used LUTs FFs Block RAMs DSP48s

QCIF without Memory Controller 9,859 5,643 11 18

CIF without Memory Controller 9,848 5,780 13 18

4CIF without Memory Controller 10,050 6,067 20 18

QCIF with Memory Controller 10,148 6,021 14 18

CIF with Mem Controller 10,165 6,163 17 18

4CIF with Mem Controller 10,336 6,448 23 18

Table 19: Macroblock Throughputs

Clock Approximate Frames per Second

12.5 MHz 2 of QCIF @ 30 fps

25 MHz CIF @ 30 fps

50 MHz 2 of CIF @ 30 fps

75 MHz 3 of CIF @ 30 fps

100 MHz 4CIF @ 30 fps





Unsupported OptionsMPEG-4 Encoder v1.2 does not support the following options, as defined in the “Information Technology - Generic Coding of Audio Visual Objects-Part 2 Visual” section of the ISO/IEC 14496-2 standard:

• Group of VOP short headers

• Data partitioning

• Video packets

• Different quantization value per MB (MBtype = 1 or 4)

Related InformationXilinx provides technical support for this LogiCORE IP product when used as described in the product documentation. Xilinx cannot guarantee timing functionality, or support of product if implemented in devices not listed in the documentation, or if customized beyond that allowed in the product documen-tation, or if any changes are made in sections of the design marked DO NOT MODIFY.

Xilinx products are not intended for use in life-support appliances, devices, or systems. Use of a Xilinx product in such an application without the written consent of the appropriate Xilinx officer is prohib-ited.

Ordering InformationThe MPEG-4 Encoder core, sold as a netlist, is provided under the terms of the Xilinx LogiCORE Site License Agreement, which conforms to the terms of the SignOnce IP License standard defined by the Common License Consortium. A free evaluation version is available from Xilinx DSP marketing or from your local Xilinx sales representative. For part number information, go to the MPEG-4 Encoder product page at the Xilinx IP Center. To purchase the core, contact your local Xilinx sales representative.

Revision HistoryThe following table shows the revision history for this document.

Date Version Revision

10/24/05 1.1 Initial Xilinx release.

12/05/05 1.2 Minor edits to Figure 2 and Figure 11.

01/24/06 1.3 Minor edits to Table 9 and Table 16.

04/04/06 1.4 Changed ISO/IEC standard number to “14496-2.”

05/23/06 1.5 Added column for “Mults/DSP48s” in LogiCORE Facts table, page 1. Edits to Table 4 and Table 13.

07/25/06 1.6 Minor edits to Figure 2 and Figure 11. Minor edits to Table 4, Table 13, and Table 14.



http://www.xilinx.com/ipcenter/doc/xilinx_click_core_site_license.pdf

http://www.xilinx.com/ipcenter/doc/xilinx_click_core_site_license.pdf

http://www.xilinx.com/ipcenter/signonce.htm

http://www.xilinx.com/company/contact.htm

www.xilinx.com/ipcenter/index.htm



Notice of DisclaimerXilinx is providing this design, code, or information (collectively, the “Information”) to you “AS-IS” with no warranty of any kind, express or implied. Xilinx makes no representation that the Information, or any particular implementation thereof, is free from any claims of infringement. You are responsible for obtaining any rights you may require for any implementation based on the Information. XILINX EXPRESSLY DISCLAIMS ANY WARRANTY WHATSOEVER WITH RESPECT TO THE ADEQUACY OF THE INFORMATION OR ANY IMPLEMENTATION BASED THEREON, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OR REPRESENTATIONS THAT THIS IMPLEMENTATION IS FREE FROM CLAIMS OF INFRINGEMENT AND ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Except as stated herein, none of the Information may be copied, reproduced, distributed, republished, downloaded, displayed, posted, or transmitted in any form or by any means including, but not limited to, electronic, mechanical, photocopying, recording, or otherwise, without the prior written consent of Xilinx.

10/05/06 1.7 Updated LogiCORE Facts table, page 1. Added new Table 18 and modified Table 1 and Table 10. Made edits to signal names in timing diagrams: Figure 4, Figure 6, Figure 7, Figure 9, Figure 13, Figure 14, Figure 18.

12/15/06 1.7.1 Edits to some "Feature Summary" descriptions. Edited Figure 9.

04/18/07 1.7.2 Edits to first and fifth paragraphs on page 9.

04/14/08 1.8 Updated for version 1.2. Added Description column to Table 9 and Table 16. Minor edits throughout.



MPEG-4 Simple Profile Encoder v1 - Xilinx · 4 DS511 v1.8 April 14, 2008 Product Specification...

Documents

Transcript of MPEG-4 Simple Profile Encoder v1 - Xilinx · 4 DS511 v1.8 April 14, 2008 Product Specification...