| |
Datasheet Home \ Datasheet Details
Download
PDF Abstract Text:
ZR36060 INTEGRATED JPEG CODEC
s Desktop video editing subsystems s PCMCIA video capture cards s Digital still cameras s Digital video recording s JPEG-based video conferencing systems
ZR36060 INTEGRATED JPEG CODEC
FEATURES
s Single-chip JPEG processor that integrates all the modules needed for JPEG encoding and decoding: - Raster-to-block and block-to-raster converter - Strip buffer - JPEG codec s Motion video compression and expansion capability: - Up to 25 frames / sec, square pixel and CCIR PAL - Up to 30 frames / sec, square pixel and CCIR NTSC s Three modes of Bit Rate Control (BRC): - Auto Two Pass: for still image compression, produces tightly controlled compressed code volume - Single pass: for motion video compression, keeps the file size approximately fixed - No BRC: uses fixed quantization tables s Glueless interface to common video decoders (e.g., Philips, Brooktree, Samsung, ITT, Harris) s Supports 8- and 16-bit YUV video interfaces s Supports master and slave modes of video synchronization s Interfaces to a variety of host controllers, ranging from the dedicated high-performance ZR36057 PCI controller to generic low-cost microcontrollers s Two clock speed grades available: - ZR36060-27, 27 MHz, for CCIR video format - ZR36060-29.5, 29.5 MHz, for PAL and NTSC square pixel video formats s Flexible compressed data interface: - 8-bit master mode, supporting up to 29.5 Mbytes / sec - 16-bit slave mode, supporting up to 16.8 Mbytes / sec - 8-bit slave mode, supporting up to 9.8 Mbytes / sec ( peak data rates, with 29.5 MHz clock) s On-chip video processing, including: - Mixing of two video sources - Horizontal (1:2 and 1:4) and vertical (1:2) up and down scaling - Cropping in compression and programmable background color in decompression s 3.3V power supply with 5V-tolerant I / O s Low power consumption: - 675 mW (typical) at 27 MHz operating frequency - 725 mW (typical) at 29.5 MHz operating frequency - Power down mode for power saving s 100-pin PQFP package
APPLICATIONS
s Desktop video editing subsystems s PCMCIA video capture cards s Digital still cameras s Digital video recording s JPEG-based video conferencing systems
Video Decoder
Video Encoder
Audio Control Audio FIFO Graphics Sub-System
Audio Codec
ZR36057
ZR36060
PCI Bus
Figure 1. JPEG-Based Video Editing Subsystem For PCI Systems
ZORAN Corporation
3112 Scott Blvd
Santa Clara, CA 95054
FAX (408) 919-4122
January 1998
ZR36060 Integrated JPEG Codec Contents
Power Management and Power-up . . . . . . . . . . . . . 27 Register and Memory Description . . . . . . . . . . . . . . 28
Video Syncs - Master and Slave Modes . . . . . . . . . . . . . . . .8
Horizontal down-scaling in compression . . . . . . . . . . . . . . . . . . . 11 Vertical down-scaling in compression . . . . . . . . . . . . . . . . . . . . . 11 Horizontal up-scaling in decompression . . . . . . . . . . . . . . . . . . . 11 Vertical up-scaling in decompression . . . . . . . . . . . . . . . . . . . . . 12
Interrupt Request and Associated Registers . . . . . . . . . . . .15
Host abort of a code read or write cycle . . . . . . . . . . . . . . . . . . . 18 Data alignment in Code Slave mode. . . . . . . . . . . . . . . . . . . . . . 18 Transition between fields in compression . . . . . . . . . . . . . . . . . . 19 Transition between fields in decompression . . . . . . . . . . . . . . . . 20
Data corruption during compression . . . . . . . . . . . . . . . . . . . . . . 24
Data corruption during decompression . . . . . . . . . . . . . . . . . . . . 26
ZR36060 Integrated JPEG Codec
1.0 INTRODUCTION
1.1 The ZR36060
VSYNC HSYNC FI BLANK PVALID SUBIMG POE Y7:0 UV7:0 VCLK VCLKx2
The code interface of the ZR36060 can operate in 8-bit master, 8-bit slave or 16-bit slave modes. In slave mode, code transfer shares the host interface, which is generic enough to be able to interface gluelessly with a variety of host controllers, ranging from the dedicated, high performance ZR36057 to common microcontrollers. The ZR36060 is a CMOS device, requiring a 3.3 Volt power supply. Its inputs and outputs are 5 Volt tolerant. A power-down ("sleep") mode reduces current consumption to a very low level, while preserving the logic state of the device. A block diagram of the ZR36060 is shown in Figure 2.
1.2 The ZR36060 and the JPEG Standard
The JPEG standard, ISO / IEC 10918-1, defines a whole range of options for compressing continuous-tone images - a baseline lossy compression process, extended lossy processes, lossless compression, and hierarchical compression methods. The ZR36060 implements the baseline process. Even the baseline method is defined by the JPEG standard to provide maximal flexibility in choosing the color space in which an image is compressed - an image can have an almost unlimited number of color components, and these can be compressed in a single scan, or in multiple scans. Because its main targeted application is motion color video compression and decompression, the architecture of the ZR36060 supports one particular subset: Since the ZR36060 supports only the YUV 4:2:2 pixel format, it supports three color components, in a single interleaved scan.
PLL & Clocks
Video Interface Internal Configuration Memory (1K x 8 bits) (Registers, Markers, Tables)
1.2.1 JPEG baseline overview
The JPEG baseline compression method is based on the discrete cosine transform or DCT. The DCT is performed on 8x8 blocks of samples, of each color component, resulting in a set of 64 DCT coefficients for each block. Thus, in order for a normal raster-scanned image to be compressed, it must first be converted to block format This requires that an 8-line strip of the image (for YUV 4:2:2, containing 8 lines of each color component) be stored in a strip buffer, so that the samples can be re-ordered (see Figure 2). For subsequent stages of the compression, the 64 DCT coefficients of each block are further re-ordered by scanning the block in a zig-zag sequence. Each of the 64 coefficients is quantized using the appropriate value from a 64-entry quantization table. In the ZR36060, it is possible to define three different quantization tables, one per color component generally, however, two tables are sufficient, one for the luminance component and one for the chrominance components. The quantized DCT coefficients are passed to a Huffman encoder, for the final stage of the process. The Huffman coding is performed separately for the DC coefficient of each block (the
RTBSY DATERR
Strip Memory START FRAME END EOI COMP SLEEP RESET
JPEG CODEC Control CODE FIFO (512 x 8 bits)
CCS COE CWE CBUSY CODE 7:0
CODE and Host Interface
ADDR1:0 JIRQ ACK CS WR RD DATA7:0
Figure 2. ZR36060 Block Diagram
ZR36060 Integrated JPEG Codec
1.2.1.1 The Minimum Coded Unit
If the compressed image data is interleaved, as is the case in the ZR36060, the compression is performed in units of a Minimum Coded Unit, or MCU, which contains one or more blocks of each color component. For the 4:2:2 pixel format used by the ZR36060, where the chrominance (U and V) components are decimated by 2:1 horizontally relative to the luminance (Y), the MCU consists of 2 blocks of Y followed by one block each of U and V.
1.2.1.2 Restart Intervals
The ZR36060 supports compression and decompression of JPEG data that includes restart intervals. A restart interval is defined as an integral number of MCUs, which are processed as an "independent sequence", meaning that it is possible to identify and decode a restart interval within a JPEG data sequence, without the need to decode whatever data precedes it. In the context of baseline compression, this has significance because the DC coefficients of the DCT are differentially encoded. Note that the use of restarts is optional it is acceptable (and very common) to use no restart markers and encode the whole image as a single sequence.
1.2.2.1 Required markers and marker segments 1.2.2 JPEG markers
JPEG defines three data formats for the compressed bitstream, all of which are supported by the ZR36060: · The interchange format, which contains the specifications of all the tables required to decode the image. · the abbreviated format for compressed data, which can contain some or none of the tables, under the assumption that the remaining tables are known to the decoder and are already loaded in the decoder or can be loaded. This is commonly used for motion video, in order to save the time otherwise required to decode the tables from their specifications. · the abbreviated tables-only format, which contains no compressed data but only tables. It is one means by which it is possible to load tables into the decoder in the ZR36060 the other means is by specifying the tables to the device and issuing an explicit Load command. The required markers for baseline JPEG are: · Start-of-image, SOI (0xFFD8). This is the first marker in a JPEG image bitstream. · Start-of-frame marker segment, SOF0 (0xFFC0), followed by a variable number of bytes depending on the number of color components. For the ZR36060, there are always three components and the segment has a length of 17 bytes. The SOF segment is used to specify which quantization table to use for each color component, and the number of blocks of each color component in the MCU. · Start-of-scan marker segment, SOS (0xFFDA), followed by a variable number of bytes depending on the number of color components. The Huffman coded data follows immediately after the last byte of the SOS segment. In the case of the ZR36060, the length of the SOS segment is always 12 bytes. The SOS segment is used to specify which Huffman table to use for each color component.
ZR36060 Integrated JPEG Codec
· End-of-image, EOI (0xFFD9). This marker follows the last byte of the compressed data. In compression, the ZR36060 inserts optional marker segments, if programmed to do so, into the compressed data bitstream in a fixed order: APP, COM, DRI, DQT, DHT. These appear immediately after SOI, before SOF. In decompression, they can appear in any order or position allowed by the JPEG standard multiple marker segments of the same type are supported to the extent allowed by the standard.
1.2.2.2 Optional markers and marker segments
The ZR36060 supports the following optional markers and segments: · Application specific, APPn (0xFFE0-0xFFEF). The standard allows up to 16 different APP markers in a single image bitstream. The ZR36060 can insert one APP marker in compression. A ZR36060 APP marker can have a segment length of up to 62 bytes. In decompression, if the image bitstream contains a single APP marker with a segment length of 62 bytes or fewer, the host can retrieve it from the internal memory after the ZR36060 has finished decompressing the image if the segment is longer, the data is lost. If there are multiple APP segments, only the last one can be retrieved. · Comment, COM (0xFFFE). The restriction on the length (62 bytes) is the same as for the APP marker. · Define restart interval, DRI (0xFFDD). Specifies that restarts are to be used, and the size in MCUs of the restart interval. · Define quantization tables, DQT (0xFFDB). Specifies the quantization tables used to compress the image. · Define Huffman tables, DHT (0xFFC4). Specifies the Huffman tables used to compress the image. · Restart, RSTm (0xFFD0-0xFFD7). Marks the beginning of a restart interval in the compressed data. This marker is inserted by the ZR36060 only if the restart mechanism is enabled (see the description of the RST bit of the Markers Enable Register). There is no RSTm marker before the first restart interval. Note that when quantization and Huffman tables are loaded into the ZR36060 by the host controller, they are specified in exactly the same format as is used in the marker segments.
1.2.3 Motion JPEG
The JPEG standard defines a method for compression of a single ("still") image. It does not have any provision for motion video, and the term "motion JPEG" simply means that each field of a video sequence is compressed as a separate JPEG image bitstream, starting with SOI and ending with EOI. The ZR36060 includes features that make this procedure straightforward.
1.3 Notational Conventions
ZR36060 Integrated JPEG Codec
2.0 SIGNAL DESCRIPTION
Table 1: Signal Description
CBUSY
DATA7:0
ADDR1:0 CS WR RD
Video Port (25 pins) Y7:0 I / O In 16-bit video mode, these are the video luminance pins. In 8-bit mode, these are luminance / chrominance pins, multiplexed in time according to the CCIR656 component order. In compression these pins are inputs, while in decompression they are outputs. During and after RESET these pins are floating with internal pullups. In 16-bit video mode, these are the video chrominance pins. In compression these pins are inputs, while in decompression they are outputs. In 8-bit video mode, these pins are not used: in compression they are ignored (inputs), and in decompression they are floating. During and after RESET these pins are floating with internal pull-ups. Main Video Clock input. The video interface of the ZR36060 is synchronized by this clock.
UV7:0
VCLKx2
ZR36060 Integrated JPEG Codec
Table 1: Signal Description (Continued)
BLANK
PVALID
SUBIMG
Control & Status (10 pins) RESET SLEEP I I Reset. When this input is asserted the ZR36060 goes into its RESET state. When it is deasserted all state machines are in the IDLE state and registers contain their default values. RESET must be active for at least 8 VCLKx2 cycles. Power-down mode. When this input is active (low), the ZR36060 goes into its SLEEP (power-down) state, discontinuing all chip operation and consuming minimal supply current. This pin also initiates coarse locking of the internal PLL to the VCLKx2 frequency. It must be toggled at least once after the initial RESET applied after power-up. SLEEP must remain low for at least 8 VCLKx2 cycles. End of process indication. This active-low output signal indicates completion of a field compression / decompression process. During and after RESET this pin is logic low. End-of-image marker indication. In Code Slave mode, this active-low output signal indicates that the End-Of-Image code word FFD9 (16-bit code bus), or the second byte of this word (8-bit code bus), is being output or input. EOI is deasserted together with the deassertion (rising edge) of END at the beginning of the next field process. During and after RESET this pin is logic low. Start compression / decompression command input. When the ZR36060 is in the IDLE state, it waits for an active low level on this input in order to start compression or decompression. Once the active level is sampled, the ZR36060 will start compression or decompression with the next VSYNC or with the next odd VSYNC (depending on the FRAME input). To be detected correctly, START must remain low for at least 2 VCLK cycles. This input is sampled by the ZR36060 together with the START input. When START is sampled active, then if FRAME is also active the ZR36060 will start compressing / decompressing at the next odd field. Otherwise it will start with the next field. This output is asserted when there is a data corruption event. It is deasserted together with the deassertion (rising edge) of END upon beginning of the next field process. On deassertion, DATERR is floating (needs external pull-up). During and after RESET this pin is floating (logic high with pullup).
END EOI
START
FRAME DATERR
ZR36060 Integrated JPEG Codec
Table 1: Signal Description (Continued)
Symbol RTBSY Type O Description In compression this output signal indicates a "nearly full" condition in the internal raster-to-block memory (strip buffer). This condition occurs when the strip buffer is 16 (or fewer) pixels away from an overflow condition. In decompression RTBSY indicates that the strip buffer is near an underflow condition. In the IDLE state RTBSY is not asserted. If while RTBSY is asserted a data corruption event occurs (overflow or underflow), RTBSY continues to be asserted together with DATERR until the beginning of the next field process (deassertion of END). If no data corruption occurs, RTBSY is deasserted as soon as the almost-overflow / underflow condition is no longer true. If the ZR36060 is used with a ZR36057 / 67, RTBSY should be connected to the RTBSY input of the ZR36057 / 67. During and after RESET this pin is at logic high. Interrupt request (active low). This output signal requests an interrupt from the host controller, if an interrupt request is enabled and the event associated with interrupt request occurs. It is deasserted if the host responds to the interrupt by reading the interrupt status register, or if the host disables the interrupt, or upon a reset to the ZR36060. On deassertion JIRQ is floating (needs external pull-up). When JIRQ is active, the START signal is disregarded. During and after RESET this pin is floating (logic high with the pullup). Compression / Decompression. This output signal provides an indication of the current operating mode of the ZR36060. When it is high, the ZR36060 is in the compression mode when it is low, the ZR36060 is in the decompression mode. During and after RESET this pin is at logic high.
Power Signals GND VDD VDDPLL Ground Power supply (3.3V) Power pin of the PLL (3.3V). See page 41.
3.0 VIDEO INTERFACE
The video interface of the ZR36060 is highly configurable, to facilitate a glueless connection to most video decoders, encoders, MPEG decoders, frame memory controllers, graphics accelerators, etc. · Vtotal - Total number of lines per frame (e.g.- for NTSC, 525 video lines) · Htotal - Total number of VCLKs (pixels) per line (e.g.- for CCIR NTSC, 858 pixels) · VsyncSize - Length of the VSYNC pulse measured in lines · HsyncSize - Length of HSYNC pulse measured in VCLKs · BVstart - Length (in lines) from VSYNC to first non-BLANK line. · BVend - Length (in lines) from VSYNC to last non-BLANK line. · BHStart - Length (in pixels) from HSYNC to first non-BLANK pixel. · BHend - Length (in pixels) from HSYNC to last non-BLANK pixel. · VSPol - Polarity of the VSYNC signal · HSPol - Polarity of the HSYNC signal · FIPol - Polarity of the FI signal · BlPol - Polarity of the BLANK signal · FIVedge - Defines at which VSYNC edge the FI signal changes state (leading or trailing edge). This is also the reset point for the vertical counters, indicating the end of the previous field and the beginning of a new field. After the parameters are properly initialized and loaded (using the Load command), the sync generator is free running, and is not affected by the state of the JPEG codec. The SyncRst
3.1 Video Syncs - Master and Slave Modes
The ZR36060 supports two video sync source modes: · Sync Master - the ZR36060 internally generates all the video timing signals. · Sync Slave - the ZR36060 synchronizes itself with an external video source. The 1-bit SyncMstr parameter selects the mode. Normally, in compression the ZR36060 would be slaved to the output of a video decoder, but not necessarily for example, the ZR36060 could control a frame memory in Sync Master mode.
3.1.1 Master mode
When configured as a sync Master, the ZR36060 drives the following signals: · HSYNC - Horizontal sync · VSYNC - Vertical sync · FI - Even / Odd field indication · BLANK - Composite blanking The parameters that configure the sync generator when the ZR36060 is a sync master are (see Figure 3):
ZR36060 Integrated JPEG Codec
register bit resets the sync generator counters and the PVALID signal can temporarily freeze the counting and sync signals.
BHend BHstart
BLANK
edge (leading or trailing) used to latch the HSYNC signal can be programmed by means of the FIVedge parameter. Changing FIDet will change the even / odd interpretation. Note: the HSYNC edge must precede the latching VSYNC edge by at least 2 VCLKs for reliable latching.
HSYNC
HsyncSize
HSYNC
BVstart BVend
VsyncSize Htotal
ODD Field EVEN Field VSYNC FI ODD Field (Fields (1, 3, 5..)
Vtotal
BLANK
VSYNC
Figure 3. Video Sync Generation
FI EVEN Field (Fields (2, 4, 6..)
3.1.2 Slave mode
Figure 4. Field Detection Signal Relationships
3.2 Data Formats
ZR36060 Integrated JPEG Codec
Note that in both 16-bit and 8-bit modes, the ZR36060 does not output, nor expect to receive, control codes indicating timing information, on its YUV video bus.
1 VCLKx2 VCLK 8-Bit Video Interface Y7:0 BG U0 Y0 V0 Y1 U2 Y2 V2 Y3 U4 Y4 VSYNC 16-Bit Video Interface Y7:0 UV7:0 BG BG Y0 U0 Y1 V0 Y2 U2 Y3 V2 Y4 U4 Active Area
Vstart
VSYNC Active Area
Vstart
12 VSYNC Active Area
Vstart
VSYNC Active Area
Vstart
Figure 5. Video Data Formats, 8 and 16 bit
Notes: The active video area must not overlap the VSYNC pulse. In other words, the active area must always be contained between the trailing edge of VSYNC and the next leading edge. There are restrictions on the allowed values of VStart and VEnd. See page 32.
3.3 Video stream sampling and cropping
Only pixels within a rectangular active area are sampled and compressed (in compression) or output (in decompression), as shown in Figure 6. The VSYNC signal indicates the beginning of a new field (the VSYNC edge and polarity are configured by FIVedge and VSPol). The Vstart and Vend parameters determine the first and last lines to be sampled in a field. The leading edge of HSYNC indicates the beginning of a horizontal line (with HSYNC polarity according to HSPol ). The Hstart and Hend parameters determine the first and last pixels to be sampled in each line. Further processing such as formatting, scaling and compression is done only to pixels within the active rectangle. In decompression, the video bus outputs a background color, specified by the BackY, BackU, and BackV parameters, outside the processed active area rectangle. Figure 7 and Figure 8, and the associated notes, describe how the active area is aligned relative to VSYNC and HSYNC.
HSYNC
Figure 7. Relationship of VSYNC and Active Video Area
HSYNC Active Area
Hstart
HSYNC Active Area
Hstart
Notes: The line counting (for Vstart, Vend) always uses the leading edge of the HSYNC pulse. Hstart is specified from the leading edge of HSYNC. The active video area is allowed to partially overlap the HSYNC pulse. In other words, Hstart could be before or after the trailing edge of HSYNC. There are restrictions on the allowed values of HStart and HEnd. See page 32.
Figure 8. Relationship of HSYNC and Active Video Area
3.3.1 The PVALID control signal
Vstart
Background Color
VSYNC
Active Area (Rectangle)
Hend Hstart
Figure 6. Active Area of the Video
ZR36060 Integrated JPEG Codec
PVALID, and then samples pixels qualified by PVALID until Hend. The polarity of PVALID is programmable by means of the PValPol parameter.
1 VCLKx2 VCLK HSYNC
8-Bit Video Interface Y7:0 Input PVALID Y7:0 Output Horizontal Counter U0 0 Y0 V0 1 Y1 U2 2 Y2 V2 Y3 3 U0 Y0 V0 Y1 Min Width U2 Min Width Y2 V2 Y3
16-Bit Video Interface Y7:0 Input UV7:0 Input PVALID Y7:0 Output UV7:0 Output Horizontal Counter Y0 U0 0 Y1 V0 1 Y2 U2 2 Y3 V2 3 Y0 U0 Y1 V0 Min Width Y2 U2 Min Width Y3 V2
Figure 9. PVALID Operation, 8- and 16-bit Video Widths
3.4 Video Scaling
The ZR36060 incorporates a scaler, that can scale the video in the active area, horizontally and vertically, by simple ratios. It can down-scale the video before it is compressed, and up-scale it after it is decompressed. The result is to permit straightforward implementation of "half sc reen" and "quarter sc reen" compression. The horizontal down- and up-scaling are accompanied by filtering. Note that this filtering can not be disabled. Vertical downand up-scaling employ line dropping and line replication respectively.
This is specified by the 1-bit VScale parameter:
In the case of 2:1 vertical scaling, the second, fourth, ..etc. lines of the active area of the video field are dropped before the video is compressed.
3.4.1 Horizontal down-scaling in compression
This is specified by the 2-bit HScale parameter. There are three possible configurations:
3.4.3 Horizontal up-scaling in decompression
As in compression, this is specified by HScale:
ZR36060 Integrated JPEG Codec
The interpolated samples are created by averaging of the two neighboring samples, with weighting proportional to the distance of the interpolated point from the two samples used. where one image is outside and the other one is inside the rectangle (see Figure 10). In compression, this signal can be connected, for example, to two synchronized sources of live video to multiplex their outputs. Some digital video sources have a video bus which can be placed in a floating state (for example, the Philips SAA7110 video digitizer / decoder) SUBIMG can be used to float this bus while enabling a second video source. Some possible options are to multiplex two video decoders, one decoder and one field memory, one video decoder and one MPEG decoder, etc.
HSYNC
3.4.4 Vertical up-scaling in decompression
As in compression, this is specified by VScale:
3.5 Active Area Size Restrictions
The maximum allowed size for the active area rectangle is 768 pixels x 64K lines. The ZR36060 JPEG codec always processes an image with dimensions of 28x and 8y pixels (x, y integers 2). This is because of the YUV 4:2:2 format, where the MCU is 2 blocks of Y, 1 block of U and 1 block of V. The active area of the video interface must be configured to reflect the dimensions before down-scaling in compression, and after up-scaling in decompression. Tables 2 and 3 show the resulting restrictions imposed on the dimensions of the active area.
SVstart SVend
Source 1
Active Area Rectangle
VSYNC
Source 2
Sub-image Rectangle
SHend SHstart
Table 2: Active Area, Horizontal Dimension (HEnd HStart)
Horizontal scaling No scaling (1:1) 2:1 4:1 Multiple of 16 Multiple of 32 Multiple of 64 Restriction
Figure 10. Sub-image Parameters In Compression There are several inherent problems in mixing video that the system designer must bear in mind: · The two video sources must be synchronized. This means that pixel clocks, horizontal and vertical timing must come from only one source which is the sync master. · Both video sources must work in the same mode (16-bit or 8-bit width). · The SHstart and SHend parameters must be chosen so that the boundaries of the sub-image rectangle (where SUBIMG changes state) coincide with the boundaries between independent YUV 4:2:2 units (units of two VCLKs, containing related U and V samples) for both sources. To permit video mixing during decompression (playback), the SUBIMG output can be externally connected to the POE input. This way, the ZR36060 places its video data only within (or outside) the rectangle defined by SUBIMG, floating the output video bus outside (or inside) the boundaries (see Figure 11). The polarity of the SUBIMG signal is defined by the SImgPol parameter, and the polarity of the POE signal (to place ZR36060 data inside or outside the rectangle during playback) is defined by the PoePol parameter. In Figure 11, the polarity of SUBIMG has been chosen so as to float the video bus outside the subimage rectangle. Note that SUBIMG and POE operate independently of each other, so they can also be used separately.
Table 3: Active Area, Vertical Dimension (VEnd VStart)
Vertical Scaling No scaling (1:1) 2:1 Multiple of 8 Multiple of 16 Restriction
In the internal sampling scheme, the first chrominance sample is always assumed to be a U (Cb) sample. This is directly controlled by the Hstart parameter. In compression, Hstart must be programmed to an appropriate value (even or odd) in order for the ZR36060 to sample first the U (Cb) pixel, otherwise U-V inversion occurs.
3.6 Spatial Mix of Video Streams
The ZR36060 is capable of spatially mixing (multiplexing) two video sources for compression, and also of multiplexing the ZR36060 output video with another video source during decompression. The latter is a useful feature for video editing, e.g. to superimpose titles or subtitles onto the images. The SUBIMG output signal creates a sub-image rectangle defined by the SHstart, SHend, SVstart, SVend parameters,
ZR36060 Integrated JPEG Codec
HSYNC HSYNC
SVstart
SVend
Background Color Floating Video Bus Sub-image Rectangle
VSYNC
ZR36060 Image Display
VSYNC
Active Area Rectangle
SHend SHstart
Floating Video Bus
Figure 11. Sub-image Parameters (with SUBIMG Wired to POE) In Decompression During decompression, the SUBIMG rectangle is overlaid on the active rectangle. In other words, the video bus will be floating or active in all the areas indicated in Figure 11 regardless of whether the underlying pixels are active or background color (see also Figure 12). The example in Figure 13 shows the result of the spatial mixing of the decompressed video with another video source, as seen by the destination (such as a video encoder). Figure 14 shows the timing of the transitions at the sub-image boundaries, for the same typical example in which SUBIMG is used to control POE. The timing of the 16-bit external video source in the example is that of the Philips SAA7110.
Figure 12. Video Output from the ZR36060 in Decompression, Using SUBIMG with POE
HSYNC
Background Color ZR36060 Image Rectangle
VSYNC
Source 2
Other Source Area
Figure 13. ZR36060 Output Image Multiplexed with Another Source, as Seen by a Video Encoder
ZR36060 Integrated JPEG Codec
2 VCLKx2 Y7:0 from ZR36060 SUBIMG (POE) Y7:0 External u0 y0 U2 Y2
8-Bit Video Interface V2 Y3 U4 1 VCLKx2
3 VCLKx2 Y7:0 from ZR36060 UV7:0 from ZR36060 SUBIMG (POE) Y7:0 External (SAA7110) UV7:0 External (SAA7110) Notes: 1. 2. 3. 4. y0 u0
Sampled by SAA7110
16-Bit Video Interface Y2 U2 Y3 V2 1 VCLKx2
Sampled by SAA7110
Figure 14. SUBIMG and POE timing during decompression, shown for 8- and 16-bit video widths
4.0 HOST INTERFACE
The host interface is a generic interface with an 8-bit bidirectional data bus, 2-bit address bus (that indirectly maps a 1Kbyte internal memory space), RD, WR, CS, and ACK pins. It supports glueless or low-glue interface to many microprocessors and microcontrollers, and buses like the ISA. When the Code interface is configured in Slave mode (see section 5.0 "Code Interface") some of the ZR36060 Host interface pins have dual functions, as can be seen in Figure 15.
CODE7:0 CCS COE CWE CBUSY ZR36060 ACK CS WR RD DATA7:0 ADDR1:0
CODE7:0 Code Only CBUSY ZR36060 ACK CS WR RD DATA7:0 ADDR1:0 Code ZR36060 CBUSY ACK CS WR RD DATA7:0 ADDR1:0 Code (Data Bus Extension)
Host Only
Code / Host Shared
a) Code Master Mode, 8-Bit Code Bus
b) Code Slave Mode, 8-Bit Code Bus
c) Code Slave Mode, 16-Bit Code Bus
Figure 15. The Various Code Interface Modes and the Host Interface
ZR36060 Integrated JPEG Codec
The ADDR1:0 address pins map 4 direct access registers (Figure 16 and Figure 17):
DATA7:0
When accessing the Code FIFO (address 00b) in Code Slave mode, the ACK signal reflects also the CBUSY status (see section 5.0 "Code Interface" for more details). (But CBUSY is only to be used by the host in Code Slave mode and must be ignored in all other host accesses.) For a complete description of the internal memory and register mapping, refer to section 8.0 "Register and Memory Description".
Read Operation CS
ADDR1:0
MSB Host Address LSB Host Data
Host Address (10 Bits)
Figure 16. Address Space of ZR36060 in Code Master Mode
7 00 01 ADDR1:0 10 11
DATA7:0 CODE FIFO MSB Host Address LSB Host Data
0 R / W W W R / W + Host Address (10 Bits)
CODE7:0 () CODE FIFO
RD 0 WR ACK DATA7:0 Host Address 10 11 Host Data
() The Code FIFO register can be 8 or 16 bits wide, depending on the Code16 parameter. When in 16-bit Code Slave mode, the CODE7:0 bus is an extension of the DATA7:0 bus.
ADDR1:0
Figure 17. Address Space of ZR36060 in Code Slave Mode
Write Operation
CS RD WR ACK DATA7:0 ADDR1:0 Host Address 10 11 Host Data
Figure 18. Asynchronous Operation of the Host Interface
4.1 Interrupt Request and Associated Registers
The ZR36060 is capable of requesting an interrupt from the host controller by means of the JIRQ output signal. This section describes the protocol and registers associated with the interrupt request. An interrupt request can occur as a consequence of one or more of the following events: · Assertion of the DATERR output (a data corruption event). · Assertion of the END output. · Assertion of the EOI (end-of-image marker detection) output during decompression. · End of the active rectangle of the video field (EOAV) which is being processed by the ZR36060. Each one of the events has a dedicated bit (DATERR, END, EOI, and EOAV, respectively) in the Interrupt Mask Register that enables or disables it as an interrupt requesting event. Each of the events also has a status bit in the Interrupt Status Register.
ZR36060 Integrated JPEG Codec
The DATERR and END bits exactly reflect the levels of the DATERR and END output pins, respectively, but with positive logic (as opposed to the negative logic of the output pins). The EOI bit should only be used when decompressing in Code Slave mode in Code Master mode it is meaningless. It exactly reflects the state of the EOI signal (but with positive logic). The EOAV bit indicates that the last line of the active area (as defined by the active area parameters), has been sampled (or displayed) by the ZR36060. Note that in Auto Two-Pass Compression mode, the EOAV bit is asserted only in the first pass. The DATERR, END, EOI, and EOAV Interrupt Status bits are set when the respective event occurs, and cleared together with their respective pins (with the exception of EOAV, which does not have a pin associated with it) at the beginning of the next process, i.e.- at the next START. Note that the Interrupt Status Register bits always reflect valid status information without regard to whether their corresponding interrupts are enabled in the Interrupt Mask Register. When an interrupt-enabled event occurs, JIRQ is asserted, and once the ZR36060 asserts END (completion of the field process, i.e. compression or decompression of the current field) it moves to the WAIT-ISR state (see the state diagram in Figure 28). JIRQ remains asserted until the host reads the Interrupt Status Register (see Figure 19). When this happens JIRQ is deasserted and the ZR36060 completes the process and returns to the IDLE state, ready to sample START for the next field process. The Interrupt Status Request register includes another pair of bits, ProCount1:0, that are not related to interrupt requests, but are located in this register for convenience. ProCount1:0 is the output of a modulo-4 cyclic counter that advances with every start of a process (every rising edge of END). It is reset only by RESET which initializes the counter to 01b. It may be used by host controllers as an indication of a field dropped by the ZR36060 (e.g., when the ZR36060 outputs END of one field after the next one already started).
CS RD WR ACK DATA7:0 ADDR1:0 JIRQ
STATUS Address STATUS Data
Figure 19. Interrupt Acknowledgment by Reading the Interrupt Status Register
5.0 CODE INTERFACE
The code interface has two modes of operation: · Code Master mode · Code Slave mode The operating mode of the code port is selected through the CodeMstr register bit. After RESET the ZR36060 defaults to Code Master mode. With 29.5 MHz VCLKx2, the peak code throughput is 29.5 MByte / sec in Master mode, 16.8 MByte / sec in 16-bit Slave mode and 9.8 MByte / sec in 8-bit Slave mode. With 27 MHz VCLKx2, the peak code throughput is 27 MByte / sec in Master mode, 15.4 MByte / sec in 16-bit Slave mode and 9 MByte / sec in 8-bit Slave mode. The master mode is almost identical to the master mode of the ZR36050. It is compatible with the ZR36057 PCI JPEG controller and with the ZR36055 ISA JPEG controller. The slave mode is compatible with common microprocessors or microcontrollers. · The CFIS parameter, that determines the bus cycle time in this mode, is limited to the values 0b (one VCLKx2 per cycle) and 1b (2 VCLKx2 per cycle) · The CAEN signal of the ZR36050 does not exist in the ZR36060. A Master mode cycle starts with the activation of CCS, on the rising edge of VCLKx2. CCS remains active throughout the bus cycle and remains active continuously in back-to-back cycles. In a read cycle, executed during decompression, COE goes active 0.5 VCLKx2 period after the beginning of the cycle and remains active until the end of the cycle. Data is strobed in on the trailing edge of COE. Similarly, in a write cycle, executed during compression, CWE goes active 0.5 VCLKx2 period after the beginning of the cycle and remains active until the end of the cycle. Examples are shown in Figure 20 and Figure 21. CBUSY is sampled one VCLKx2 before the beginning of each bus cycle and if active, inhibits the bus cycle. If a bus cycle started at the same time CBUSY was sampled active it completes normally. Note: the CBUSY and EOI status bits are not valid in Code Master mode.
5.1 Master Mode
ZR36060 Integrated JPEG Codec
Code Write (Compression) CCS CWE CBUSY CODE7:0 (output)
1 VCLKx2 CCS COE CBUSY CODE7:0 (input)
Code Read (Decompression) 5 6 7 8 9 10 11
Code Read (Compression) CS ADDR1:0 RD ACK 00 00
Cannot perform a new strobe
1 VCLKx2 CCS COE CBUSY CODE7:0 (input)
Code Read (Decompression) 5 6 7 8 9 10 11
Code Write (Compression) CCS CWE CBUSY
CBUSY DATA7:0 (CODE7:0)
CFIFO Empty (Stall Access)
Code Write (Decompression) CS
CODE7:0 (output)
ADDR1:0 WR ACK CBUSY DATA7:0 (CODE7:0)
Strobe is held low
5.2 Slave Mode
CFIFO Empty (Stall Access)
Notes: 1. CS can be pulsed, or maintained active for burst of read or write pulses. 2. ACK is not granted when CBUSY is active, in both compression and decompression. 3. The top example (compression) shows a system using CBUSY to decide when to perform the next RD strobe. 4. The bottom example (decompression) shows a system using ACK to decide when to terminate the current strobe. Note the extension of the WR cycle when the FIFO is full.
Figure 22. Slave Mode Operation of the Code Bus
ZR36060 Integrated JPEG Codec
5.2.1 Host abort of a code read or write cycle
During the compression or decompression process the host must obey the handshake rules to create a valid code file. The host can safely abort (e.g.- due to a timeout) a RD or WR cycle only after the EOI signal is asserted. If a code transfer cycle is aborted by the host before this, the behavior of the ZR36060 will be unpredictable, and it must be reset to resume normal operation. Figure 23 shows an example of a code transfer abort after EOI is asserted.
5.2.2 Data alignment in Code Slave mode
In compression, in code slave mode, the ZR36060 always completes the compressed data file for each field so that it is 32-bit (double-word) aligned. This is true for both 8-bit and 16-bit interface modes. A variable number of padding bytes of value 0xFF is appended by the ZR36060 after the EOI marker, to complete the last double word. In decompression, such padding bytes constitute a legal preamble for the SOI marker code of the next field, and thus are ignored by the ZR36060.
This example shows status register reads interleaved with code FIFO write transactions. After the end-of-image code, instead of waiting too long (for the ACK signal) until the next field, the host can decide to abort the cycle.
Notes:
1. The host reads the status register, receives ACK normally. 2, 3. The host writes some code bytes (two in this example), and the ZR36060 asserts ACK normally. After the second code write cycle, the ZR36060 senses the end-of-image code indicating the last code byte of the current field and asserts CBUSY. 4. In this example the host reads a status register, and ACK is asserted, independently of CBUSY. 5. This is an access to the code FIFO while CBUSY is asserted. No ACK can be issued by the ZR36060, until after the beginning of the next field. The host is stalled for a while, then decides to abort the cycle, i.e.- release the WR strobe without ACK from the ZR36060. The ZR36060 senses this situation as an abort of the cycle and ignores the strobe. Again note, that this is only allowed while EOI is asserted, and not in the middle of the process. 6. The host now decides to read a status register. This operation is completed normally. 7. The host writes code into the ZR36060. The ZR36060 has already started decompressing a new field, so CBUSY and EOI are released and ACK can be issued.
Figure 23. Example of ZR36060 Interleaved Code / Data Accesses and Abort of Access
ZR36060 Integrated JPEG Codec
In 8-bit interface mode, the number of appended bytes can be 1, 2, 3 or 4. In 16-bit interface mode, the number of appended bytes can be 2, 3, 4 or 5. Note that in both cases, if the number of bytes from the first byte of SOI up to and including the second byte of EOI is an exact multiple of 4, the ZR36060 actually appends 4 more bytes. Note also that in 16-bit mode, if one byte is required to make the total a multiple of 4, the ZR36060 actually appends 5 bytes. between consecutive fields showing the behavior of the EOI, END and CBUSY signals. CBUSY is asserted after the last padding byte has been read out. It remains asserted continuously until the first code byte of the next field is available. A code read is shown in the figures while CBUSY is asserted, with the host access stalled. EOI is asserted as soon as the read cycle of last byte of the EOI marker code (0xD9) is complete. END is asserted only after the all the compressed data, including the padding bytes, was read out, and the post-compression calculations are completed and their results stored in the hostaccessible registers. At this time the ZR36060 returns to the IDLE state. Compression of the next field is started when the ZR36060 senses the START signal active.
5.2.3 Transition between fields in compression
For compression, Figure 24 shows code transfer with 8-bit interface and Figure 25 with 16-bit interface, at the transition
CS ADDR1:0 RD ACK CBUSY EOI END End-Of-Image marker DATA7:0 D9 FF FF FF FF
End of field process Start new field process due to START
Start-Of-Image marker D8
32-Bit Alignment (Worst Case Padding) CODE for Field N CODE for Field N+1
Figure 24. 8-Bit Code Slave Mode Compression, Transition Between Consecutive Fields
CS ADDR1:0 RD ACK CBUSY EOI END End-Of-Image marker DATA7:0 CODE7:0 XXXX XXFF D9FF FFFF FFFF
End of field process Start new field process due to START
FFD8 Start-Of-Image marker
32-Bit Alignment (Worst Case Padding) CODE for Field N
CODE for Field N+1
Figure 25. 16-Bit Code Slave Mode Compression, Transition Between Consecutive Fields
ZR36060 Integrated JPEG Codec
5.2.4 Transition between fields in decompression
For decompression, Figure 26 shows code transfer with 8-bit interface and Figure 27 with 16-bit interface, at the transition between consecutive fields, showing the behavior of the EOI, END and CBUSY signals. JPEG compressed files input to the ZR36060 can be any size, not required to be 32-bit (double-word) aligned. The ZR36060 detects the EOI marker (0xFFD9), asserting EOI and CBUSY at the next write strobe. Note that the host is allowed to write one additional byte after the EOI marker code in 8-bit mode, or one additional word after the word containing the second byte of the EOI marker code in 16-bit interface mode. This byte or word is discarded by the ZR36060. If this discarded code byte or word contained one or both bytes of the SOI marker of the next field, the ZR36060 automatically reconstructs the marker when it starts decompressing the next field. Note that EOI and CBUSY may remain unasserted until END is asserted, if the host has other means to detect the EOI marker code and therefore does not issue the additional write strobe. Attempts to access the code FIFO while CBUSY is asserted will be held off until the FIFO is available again, using the ACK signal. In this example, a WR pulse is shown being extended until the next field begins, when CBUSY is deasserted. END is asserted only after the whole decompressed field has been output from the video interface. At this time the ZR36060 sets the EOAV status bit and returns to the IDLE state. Decompression is started again when the ZR36060 senses the START signal active.
CS ADDR1:0 WR ACK CBUSY EOI END DATA7:0 XX XX FF End-Of-Image marker CODE for Field N D9 XX
End of field process Start new field process due to START
FF Start-Of-Image marker
CODE for Field N+1
Figure 26. 8-Bit Code Slave Mode Decompression, Transition Between Consecutive Fields
CS ADDR1:0 WR ACK CBUSY EOI END DATA7:0 CODE7:0 XXXX XXXX XXFF End-Of-Image marker CODE for Field N D9XX XXXX
End of field process Start new field process due to START
FFD8 Start-Of-Image marker
CODE for Field N+1
Figure 27. 16-Bit Code Slave Mode Decompression, Transition Between Consecutive Fields
ZR36060 Integrated JPEG Codec
6.0 OPERATION
6.1 ZR36060 Functional States
For the purposes of this description, the ZR36060 can be viewed as having 7 states: · RESET - In this state the RESET input is held active. · SLEEP - Power-down. The SLEEP input is held active in this state. · IDLE - END is asserted and the ZR36060 is waiting for START. · WAIT-ACTIVE - After the ZR36060 sensed START asserted, it waits for the beginning of the active area of the next field to be processed (this depends on the state of FRAME when START was sampled active). END is deasserted. · CMP - Compression of the active area. The video bus is input, and the code data bus is output. END is deasserted. · EXP - Decompression (expansion) of the active area. The video bus is output, and the code data bus is input. END is deasserted. · WAIT-ISR - After the ZR36060 finished the compression or decompression and asserted END while JIRQ is active (due to a non-masked interrupt), the ZR36060 waits in this state for the host to read the Interrupt Status Register.
Power-Up
RESET
SLEEP
WAIT ACTIVE
active area1 & decompression
END & JIRQ
END & JIRQ JIRQ
6.2 State Transitions
Figure 28 depicts the states and their transitions.
WAIT ISR
6.3 The SLEEP State
In this state, all the pins remain in the logic states they were in immediately before the transition to SLEEP. No host, video or code interface operation is allowed in the SLEEP state. When the ZR36060 leaves the SLEEP state it returns to IDLE, ready for the next compression or decompression operation. This state is also used to lock the internal PLL to the frequency of VCLKx2, so it is mandatory to go through the SLEEP state at least once after power-up and before operating the device (see section 7.0 "Power Management and Power-up").
1. Active area of the correct field, depending on the state of FRAME when START was sampled active.
6.4 Loading Parameters and Tables
Prior to a compression or decompression process the host must load the appropriate parameters and tables into the ZR36060. The parameters affect the compression / decompression mode, the video interface, and the operation of the code port. All parameters and tables may be loaded only when the ZR36060 is in the IDLE state. First, the host controller writes (via the host interface) the desired parameters and / or tables in their correct locations in the 1Kbyte internal memory (see section 8.0 "Register and Memory Description" for details).
ZR36060 Integrated JPEG Codec
System decides to compress the next field (pulls START low). START FRAME Tb END state IDLE WAIT ACTIVE RTBSY CBUSY CCS Video Bus System senses END deasserted, so deasserts START to compress next field only, then stop.
using the PVALID input. This may be useful, for example, when compressing still pictures.
Strip Memory
JPEG Codec
CODE FIFO CODE Bus
Figure 30. Data Flow in Compression, Code Master Mode When the code interface operates in slave mode (see Figure 31) the scenario is almost identical. The main difference is that CBUSY is now an output of the ZR36060, used to indicate that the code FIFO is "nearly empty", thus the host must stop reading code until CBUSY indicates that the FIFO occupancy is above its threshold.
Figure 29. IDLE to WAIT-ACTIVE state transition
6.5 Data Flow Overview
This section provides an overview of the data flow in the ZR36060 during compression and decompression. For this purpose it is useful to view the ZR36060 roughly as a JPEG engine with one dual port data buffer on each side: the code FIFO buffer on one side and the video buffer (strip buffer) on the other side (see Figure 30 through Figure 33).
Strip Memory Video Bus
JPEG Codec
CODE FIFO CODE Bus
6.5.1 Data flow in compression
The video input, after being processed in the video interface, is written to the strip buffer in raster format. The JPEG engine reads out the data in block format, and writes the JPEG code into the code FIFO on the other side. From the FIFO the data is transferred out either by the ZR36060 itself, if it is the code bus master, or by the host controller, if the ZR36060 is in code slave mode. When the ZR36060 is the code bus master (see Figure 30) it writes out the code as long as its CBUSY input is not asserted. When the code FIFO is empty the ZR36060 does not perform code write cycles. If the host controller is too slow and asserts CBUSY for too long, the code FIFO may fill up, and in order to prevent overflow, the ZR36060 stops reading data from the strip buffer. If this situation continues long enough, the strip buffer overflows, because video keeps flowing in. A strip buffer overflow is a data corruption event. At the system level this event may be prevented by two means: First, the host should be able to accept the code at the same rate it is generated by the ZR36060. Second, some system configurations may have the capability to halt the video input stream when the strip buffer is close to overflow (16 pixels, or less, from overflow). The ZR36060 indicates this "nearly full" condition with its RTBSY output. One configuration for implementing this is if the ZR36060 is the master of the video syncs, and the system stops the video
RTBSY
CBUSY
Figure 31. Data Flow in Compression, Code Slave Mode
6.5.2 Data flow in decompression
The JPEG code is transferred on the code bus into the code FIFO, either by the ZR36060, in Code Master mode, or by the host, in Code Slave mode. The JPEG engine writes the decoded video into the strip buffer in block format. The video interface reads the video out in raster format, executes the post-processing operations and outputs the video on the digital video bus. When the ZR36060 is the code bus master (see Figure 32) it reads in the code as long as its CBUSY input is not asserted. Whenever the code FIFO is full the ZR36060 stops reading code. If the host controller is too slow and asserts CBUSY for too long, the code FIFO may become empty. In order to prevent underflow the ZR36060 stops writing data into the strip buffer. If this situation continues long enough, the strip buffer underflows, because the video unit keeps reading out video from the strip buffer, to keep up with the timing of the digital video bus. A strip buffer underflow is a data corruption event. At the system level this event may be prevented by two means: First, the system should be able to provide the code at the rate it is required by the ZR36060 second, some system configurations may have the capability to stop the video output stream when the strip buffer is close to underflow (16 pixels, or less, away from underflow). The ZR36060 indicates this "nearly empty" condition with its RTBSY output. One configuration for implementing this is if the ZR36060 is the master of the video syncs, and the system stops the video
ZR36060 Integrated JPEG Codec
using the PVALID input. This may be useful, for example, when decompressing still pictures.
2 Processed Fields VSYNC Strip Memory Video Bus JPEG Codec CODE FIFO CODE Bus START FRAME RTBSY CBUSY CCS END state IDLE WAIT ACTIVE CMP IDLE WAIT ACTIVE CMP IDLE EVEN ODD EVEN ODD
Figure 32. Data Flow in Decompression, Code Master Mode When the code interface operates in slave mode (see Figure 33) the scenario is almost identical. The main difference is that CBUSY is now an output of the ZR36060, and it is used to indicate that the code FIFO is "nearly full", thus the host must temporarily stop writing code until CBUSY indicates that the FIFO occupancy is below its threshold.
Figure 34. Compression With START and FRAME Continuously Asserted If FRAME is not active when START is sampled (Figure 35), the ZR36060 always starts compressing the next field (i.e., at the next VSYNC).
3 Processed Fields
Strip Memory Video Bus
JPEG Codec
CODE FIFO CODE Bus VSYNC START
RTBSY
CBUSY
WR FRAME END
Figure 33. Data Flow in Decompression, Code Slave Mode
The ZR36060 has one decompression mode (called simply decompression), and four compression modes: · Compression Pass · Statistical Compression Pass · Auto Two-Pass Compression · Tables-Only Compression Pass The following sections describe these modes.
WAIT ACTIVE
6.6 Compression and Decompression Modes
state CMP IDLE
6.7 Compression Pass
When the ZR36060 is in the IDLE state, and after the correct initialization has been done by the host (loading parameters and / or tables), it waits for the command to start compressing (assertion of START). RTBSY is not asserted at this time. Once the ZR36060 senses an active (low) START, it checks the level of FRAME, and then, if FRAME is active (Figure 34), it starts compressing the next odd field (i.e., at the next odd VSYNC). Note: If FRAME is maintained active, and consequently will be detected active every time START is sampled active, the ZR36060 will compress only the odd fields. This is a convenient method for implementing field decimation by 2.
ZR36060 Integrated JPEG Codec
2) If DATERR is enabled as an interrupt requesting event, JIRQ is asserted together with the assertion of the DATERR output, and when the ZR36060 completes the current process it enters the WAIT-ISR state and remains there, ignoring START, until the host reads the Interrupt Status register. At this time the ZR36060 goes back to its IDLE state and is again ready to start a new process, as soon as it samples START active. In both cases, DATERR is deasserted at the beginning of the next process, i.e. simultaneously with the deassertion of END.
IDLE WAIT ACTIVE CMP IDLE WAIT CMP ACTIVE IDLE
Host decides to compress next field only VSYNC START FRAME END state
2 Processed Fields
In compression the ZR36060 identifies a data corruption condition if: a) the strip buffer overflows, or
b) the active edge of VSYNC (leading or trailing edge controlled by the FIVedge parameter) of the next video field arrives before END of the current field is asserted.
6.8 Statistical Compression Pass
In this mode the ZR36060 goes through all the calculations involved in encoding the input video, accumulating the code volume but without writing any code to the code FIFO. It does not assert CCS, COE, CWE as a code master, or CBUSY as a code slave. At the end of the process the ZR36060 calculates a new scale factor and allocation factor and writes them into their respective registers, and writes the accumulated ACV and ACT values into their respective registers. Then it asserts the END signal and returns to the IDLE state.
6.9 Auto Two-Pass Compression
In this mode the ZR36060 first executes a Statistical Compression Pass, then, without asserting END, it immediately starts a Compression Pass. Activation of START (and optionally FRAME) is required only for the first pass. The second pass follows immediately with the next VSYNC, without regard for START and FRAME. (Note that START and FRAME are only sampled when the ZR36060 is in IDLE, and in this mode the ZR36060 does not go into IDLE between the two passes). This mode only works correctly if exactly the same image data is fed to the ZR36060 in both passes.
6.10 Tables-Only Compression Pass
6.7.1 Data corruption during compression
If during the compression of a field the ZR36060 senses a data corruption event, it immediately asserts the DATERR output. However, the ZR36060 continues the process until it finishes compressing the field. At this time it asserts END and enters its IDLE state. 1) If DATERR is not enabled as an interrupt requesting event (i.e., it is cleared in the Interrupt Mask register), then the ZR36060 samples START again, and if START is asserted a new process begins. In this mode the ZR36060 produces only the "abbreviated format for table specification", that is, its code output contains no frame header, scan header, or Huffman-coded segments. The output includes the SOI marker, table marker segment(s), optional APP and / or COM marker segments, and the EOI marker. The process is activated by START (possibly with FRAME), and upon completion END is asserted and the ZR36060 returns to IDLE.
ZR36060 Integrated JPEG Codec
Note # VSYNC Active area State IDLE WAIT-ACT CMP iw CMP iw CMP (w / error) Wait-ISR iw CMP iw CMP (w / error) iw CMP iw CMP IDLE 1 ODD 2 EVEN 3 ODD 4 EVEN 5 ODD 6 EVEN 7 ODD 8 EVEN 9 ODD 10 EVEN 11 ODD 12 EVEN
START FRAME RTBSY DATERR CCS (code master) CBUSY (code slave) DATA Bus (CODE bus) END JIRQ Notes: 1. In field #1, START & FRAME asserted indicate to begin on next ODD VSYNC 2. Wait for next ODD field meanwhile START signal is ignored (END not asserted) 3. Field #3 is compressed, issue END and return to IDLE. At this point, START is sensed low and FRAME high, so compression starts at next VSYNC. 4. Field #4 is compressed. Again, after END the system asserts START but not FRAME, so the next field must be compressed too. 5. Begin field compression, but system is slow to read data out, so DATERR is asserted. END with DATERR informs the system of a corrupted field. Since interrupt request on data error is enabled, the ZR36060 asserts JIRQ and waits until the host acknowledges the JIRQ by reading the associated interrupt status register. 6. During this field, the host services the interrupt (ZR36060 de-asserts JIRQ) and asserts START to compress the next field. In this example, the host also disables interrupts after servicing this one. 7. Field #7 is compressed. After END, the host asserts START again. 8, 9. Field is compressed normally, but during the last lines of the active area, the system response is slow and the last part of the code is read out at a much slower rate. Next field (#9) begins (VSYNC is asserted) before the ZR36060 activates END. This is an error condition indicated by DATERR. No JIRQ here since interrupts are disabled. START is sensed low for the next field (the ZR36060 skips field #9). 10, 11. Fields are compressed normally. START is de-asserted during field #11, therefore after END the ZR36060 returns to IDLE and waits for next operation. 3 4 5 7 8 10 11
Figure 37. Examples of ZR36060 Compression (after the host loaded parameters and the Load command)
6.11 Decompression
Before starting decompression the ZR36060 is in the IDLE state. After the correct initialization has been done by the host (loading of parameters and / or tables), the ZR36060 is ready to receive a command to start decompression. The video bus already outputs the background color, and if the ZR36060 is a code slave, CBUSY is asserted, so the host cannot write compressed data to the ZR36060. After START is activated, the ZR36060 starts reading compressed data (if it is the code bus master), decoding it, and filling up the strip buffer with pixels. However, pixels will not start flowing out the video bus before the VSYNC that follows START (or the odd VSYNC, if FRAME was asserted together with START). Host controllers that are capable of synchronizing the start command to VSYNC may do so, providing the start command as soon as possible after a VSYNC. This makes sure that once VSYNC arrives, the ZR36060 has enough pixels in the strip buffer to avoid a condition of strip buffer underflow. In systems where the video sync signals can be controlled by the host, this
capability can be used to guarantee that START is asserted long enough before the next VSYNC. Once START is asserted, CBUSY is deasserted (if it is configured as output, i.e., in code slave mode), and RTBSY is asserted indicating that the strip memory is initially (close to) empty (underflow). The host should now provide compressed data to the ZR36060 as quickly as possible, and fill the strip memory. Deassertion of RTBSY is an indication that sufficient data is available in the strip buffer to start video output. Every time that the ZR36060 senses that the strip buffer is close to an overflow (full), it asserts an internal flag that stops the transfer of pixels into the strip buffer, and eventually might result in assertion of CBUSY (in code slave mode) or in stopping of compressed data acquisition (in code master mode). When the ZR36060 senses the EOI marker, or when the active portion of the video field is over (whichever occurs later), it asserts the END signal and returns to the IDLE state, waiting for a new start command. (As in compression, the host controller may choose to leave START asserted continuously, rather than asserting it after every END).
ZR36060 Integrated JPEG Codec
6.11.1 Data corruption during decompression
If during the decompression of a field the ZR36060 senses a data corruption event, it immediately asserts DATERR, then continues the decompression process until it senses the EOI (End Of Image) marker or the end of the active video area (whichever occurs later). At this time it asserts END and enters the IDLE state. The deassertion of END (upon START for the next field) deasserts the DATERR signal. 1) If DATERR is not enabled as an interrupt requesting event (i.e., it is cleared in the Interrupt Mask register), then the ZR36060 samples START again, and if START is asserted a new process begins. 2) If DATERR is enabled as an interrupt requesting event, JIRQ is asserted together with the assertion of DATERR, and when the ZR36060 completes the current process it enters the WAITISR state and remains there, ignoring START, until the host reads the Interrupt Status register. At this time the ZR36060 goes back to IDLE and is again ready to start a new process, waiting for START. In decompression the ZR36060 signals a data corruption condition if the strip buffer underflows.
Note # VSYNC Active area State
2 EVEN
4 EVEN
6 EVEN
8 EVEN
10 EVEN
11 ODD
12 EVEN
WAIT-ACT
EXP (w / error)
WAIT-ISR iw
EXP (w / error)
START FRAME RTBSY DATERR CCS (code master) CBUSY (code slave) DATA Bus (CODE bus) END JIRQ Notes: 1, 2. In field #1, START & FRAME asserted instruct the ZR36060 to decompress on next ODD VSYNC (field #3). Code can be input immediately after START is asserted, to decode and fill with 8 lines of video the first strip buffer before the beginning of the active area. After the first strip is decompressed, code is no longer fetched, and the ZR36060 waits for the active area of the next ODD field. 3. Field #3 decompression continues and when completed, the ZR36060 issues END and returns to IDLE. 4. Field #4 is decompressed normally. 5. Begin field decompression, but the system is slow to feed new data, so DATERR is asserted. END with DATERR informs the system of a corrupted field. Since interrupt request on data error is enabled, the ZR36060 asserts JIRQ and waits until the host acknowledges the JIRQ by reading the associated interrupt status register. 6. During this field, the host services the interrupt, the ZR36060 de-asserts JIRQ, and the host asserts START to decompress the next field. In this example, the host also disables interrupts after servicing this one. 7. Field #7 is decompressed. After END, the system asserts START for the next field. 8, 9. In Field #8 the ZR36060 starts to input code, but somewhere during the active area, code is unavailable long enough that the ZR36060 issues a DATERR (no JIRQ here since interrupts are disabled). Nevertheless, the system continues to feed new code to the ZR36060 until END which occurs only after the VSYNC of the next field (#9). Now START is sensed low meaning that the next decompression will happen on field #10 (field #9 is skipped). 10, 11. Fields are decompressed normally. START is not asserted during field #11, therefore after END the ZR36060 returns to IDLE and waits for the next operation. 3 3 4 5 7 8 8 10 11
Figure 38. Examples of ZR36060 Decompression (after the host loaded parameters and the Load command)
ZR36060 Integrated JPEG Codec
7.0 POWER MANAGEMENT AND POWER-UP
VCC RESET SLEEP state Power On RESET
(SLEEP must be inactive) (8 VCLKx2 min)
WAIT FOR VCLKx2 TO STABILIZE
SLEEP
(operational)
RESET Period: Minimum pulse width of 8 VCLKx2 cycles. WAIT Period: wait for VCLKx2 to stabilize at the correct operating frequency. SLEEP Pulse: Minimum pulse width of 8 VCLKx2 cycles. LOCK Period: After SLEEP was deasserted, the system must wait 5, 000 VCLKx2 cycles until the PLL is correctly locked to the clock frequency. IDLE: The ZR36060 is ready for operation.
Figure 39. Power-Up Sequence and SLEEP Operation
ZR36060 Integrated JPEG Codec
8.0 REGISTER AND MEMORY DESCRIPTION
The ZR36060 internal memory space is implemented as 1024 bytes of RAM, accessible by the host controller through the host interface. The contents of this RAM may be loaded into the working storage registers and tables using the Load command (refer to 6.4 "Loading Parameters and Tables"). Figure 40 depicts the partitioning of the RAM. A "default" is specified for each register bit. This is its value after reset.
8 Bits Data Host Address Host Data Host Interface 022h 024h 026h 030h 000h General Control Registers Identification Registers Test Control Registers Reserved Video Registers 1 KB RAM
be set before starting an operation every time a new parameter is written anywhere in the internal memory space. 0 - No effect 1 - Load parameters now
Code FIFO Status Register (Read only)
Address 0x001
1 0 CFIFO1 CFIFO0 R R 0 0
CFIFO1:0 : Indicates the fullness of the Code FIFO: 00 - less than 1 / 4 full. 01 - 1 / 4 or more but less than 1 / 2 full. 10 - 1 / 2 or more but less than 3 / 4 full. 11 - 3 / 4 full or more. These bits are valid only when EOI is not asserted. CBUSY: Indicates the full / empty condition of the code FIFO. Identical to the state of the CBUSY pin, but with inverse logic. 0 - code FIFO not full / not empty 1 - code FIFO full / empty This bit is valid only when CBUSY is an output i.e.- in code slave mode. Busy: Status of the Load operation. The host must poll this bit to determine when the ZR36060 is ready (not Busy) to load a new parameter set or start a compression / decompression process. 0 - ZR36060 is ready to operate, no Load operation in progress 1 - Load is in progress now, do not access any internal memory location while this bit is set
052h 060h
Reserved
JPEG Markers Array
Figure 40. Internal Memory Map
Code Interface Register Address 0x002
CodeMstr
8.1 General Control Registers
Load Parameters Register
0x002 type default
7 Code16 RW X
6 Endian RW X
Address 0x000
1 0 SyncRst RW 0
ZR36060 Integrated JPEG Codec
Codec Mode Register
0x003 type default 7 COMP RW 1 6 ATP RW X 5 PASS2 RW X 4 TLM RW X 3 0 X 2 BRC RW X
Address 0x003
Interrupt Mask Register
Address 0x007
1 END RW X 0 DATERR RW X
11000100 - Auto Two-Pass Compression 10000100 - Statistical Compression Pass 10100100 - Compression Pass with Variable Scale Factor 10100110 - Compression Pass with Fixed Scale Factor 10110000 - Tables-Only Compression Pass 00000000 - Decompression Pass All other combinations of the register bits are illegal
DATERR: Enable interrupt on assertion of DATERR during a process 0 - Interrupt disabled 1 - Interrupt enabled END: Enable interrupt on assertion of END at the end of a process 0 - Interrupt disabled 1 - Interrupt enabled EOI: Enable interrupt when EOI is asserted, i.e., when the EOI marker is being read or written at the code interface 0 - Interrupt disabled 1 - Interrupt enabled EOAV: Enable interrupt on End-Of-Active-Video area during the process 0 - Interrupt disabled 1 - Interrupt enabled
Reserved
Address 0x004
Must be programmed to 0x00 for correct operation.
Interrupt Status Register (Read Only) Maximum Block Code Volume Register
7 0x005 type default 6 5 4 MBCV RW X 3 2
Address 0x008
DATERR
Address 0x005
0x008 type default
7 6 ProCnt1 ProCnt0 R R 0 0
DATERR: Status of the DATERR output pin 0 - DATERR is not asserted (normal operation) 1 - DATERR is asserted (data corruption) END: Status of the END output pin 0 - END is not asserted (process in progress) 1 - END is asserted (process ended and in IDLE state) EOI: Status of the EOI output pin 0 - an EOI marker event did not occur 1 - an EOI marker has been read or written by the host EOAV: Latch an event upon End-Of-Active-Video area during the process 0 - an EOAV event did not occur (video is still being input or output) 1 - an EOAV event occurred (active area of video has finished) ProCnt1:0 : 2-bit cyclic process (compression or decompression) counter. It is incremented on START of each field process. Note: ProCnt appears here only as a status, it is not an interrupt-generating event.
Markers Enable Register
0x006 type default 7 APP RW X 6 COM RW X 5 DRI RW X 4 DQT RW X 3 DHT RW X 2 0 X
Address 0x006
In compression, this register specifies which of the optional marker segments to include in the compressed data. Not used in decompression. If a bit is programmed to 0, the respective marker segment is not included. If a bit is programmed to 1, the ZR36060 performs the following action: APP: Reads the Application segment from the Internal Memory and writes it to the compressed data during the Compression Pass. Also in Tables-only pass. COM: Reads the Comment segment from the Internal Memory and writes it to the compressed data during the Compression Pass. Also in Tables-only pass. DRI: Define Restart Interval. Enables the restart mechanism and writes the DRI marker segment to the compressed data during the Compression Pass. When the restart interval is zero, the restart function is disabled. DQT: Define Quantization Tables. Reads the base Quantization Tables defined in the DQT segment in the Internal Memory, multiplies the quantization values by the Scale Factor (SF), rounds to eight bits and writes the results together with the DQT marker and parameters in the compressed data during the Compression Pass or the Tables-Only Pass. The number of Quantization Tables to be processed is inferred from the LEN (segment length) parameter of the DQT segment. Note: the identical scaled tables are used to compress the data. DHT: Define Huffman Tables. Reads the Huffman Tables defined in the DHT segment of the Internal Memory, and writes the DHT segment in the compressed data during the Compression Pass or the Tables-only Pass.
Target Net Code Volume Register
Address 0x009 - 0x00C
ZR36060 Integrated JPEG Codec
Target Data Code Volume Register
Address 0x00D -
|