Software Design

The software controls the operation of the entire system, instructing the camera, and encoder, to capture and encode images, and transmitting the encoded im-ages using the ethernet media access controller. Due to the system architecture currently used the total size of the system software is restricted to 24 kilobytes.

An Internet Protocol (IP) stack is required in order to properly format the en-coded data for transmission over the ethernet media access controller. Although

it would be possible to develop a custom IP stack specifically for this system this would take a significant development effort, mitigating some of the benefit of using a platform design approach. There are a number of IP stack libraries compatible with the microblaze processor and ethernet media access controller.

Xilinx supply the open source lwIP library and also a custom Xilnet library.

There is also a port of the uclinux operating system available for the microblaze processor. Due to program size restrictions, the Xilnet library was used, as this is the only one capable of being implemented within the 24 kbytes available to store the system software. Although limited, the Xilnet IP stack is adequate for send-ing the UDP packets required by the RTP protocol. The Xilnet IP stack has very simple memory management. Two ethernet frame sized buffers are used, sendbuf for sending data and recvbuf for receiving data. These are mapped to the OPB embedded RAMs, with encoded data being loaded directly into sendbuf using the DMA controller shown in Figure 4.5.

Figure 4.6 shows a flow diagram of the software operation whilst encoding.

Due to the program size restriction, no operating system is used. Instead, a camera and encoder generated interrupt triggers the software operation. The Xilnet library does not fragment IP packets across ethernet frames and, in any case, there is not the program memory available to support this. Thus, each RTP packet must be limited to approximately 1500 bytes. Given that the size of one H.263 encoded image is generally greater than 1500 bytes, this restricts the RTP payload header which can be used. The RFC 2190 payload header [115] cannot be used because, with this protocol, the H.263 bitstream data must be fragmented at image, group of blocks, or macroblock boundaries. With the current encoder design, the processor is only aware of where each encoded image starts in external memory, not where each group of blocks (GOB) or macroblock starts. Therefore,

Figure 4.6: Flow diagram of software during encoding operation

the RFC 2429 payload header [116] was used as it allows each frame’s H.263 bitstream to be fragmented at random points.

4.1.4 Results

Table 4.1 shows the FPGA resource usage of the revised encoder, discounting the additional de-interlacer component. Compared to the original encoder [108], the embedded RAM usage has been reduced significantly. The slice usage, however, has increase significantly compared to the 3000 slices used in the previous imple-mentation. This is due to, the use of distributed RAM as opposed to embedded RAM, the addition of the OPB master and slave interfaces and the targeting of the encoder at lower cost Spartan series FPGAs as opposed to the more expensive

Slices 4813

Table 4.1: Encoder resource usage (Spartan-3 1500 FPGA)

Slices 10944 out of 13312

Block RAMs 32 out of 32

MULT18X18s 6 out of 32

Maximum Clock Frequency 60 MHz

Table 4.2: Usage of Spartan-3 1500 resources by Streaming System but higher performance Virtex series FPGAs.

The maximum clock rate the core is capable of operating at is just over 60 MHz in the lower speed grade Spartan-3 parts. In the higher speed grade parts it is capable of operating at over 69 MHz. Even using the lower speed grade parts, the encoder is capable of encoding D1 sized video at 30 frames per second. The minimum encoder clock frequency required for this throughput being 59 MHz.

Table 4.2 shows the resource usage for the overall system in the Spartan-3 1500 FPGA targeted. Using the lower speed grade part present on the Spartan-3 evaluation boards used, the system is capable of operating at 60 MHz and streaming D1 video at 30 frames per second. The size of the encoded data, however, is limited to approximately 1 MByte per second, due to the ethernet MAC only supporting 10 megabit operation at 60 mega-hertz.

The main limitation of the system is that, due to the software size constraint, the software has limited control functionality, only having a start streaming com-mand which is sent to the system using the ethernet controller. Ideally, the system should be able to accept various commands, to start/stop streaming, send intra

frames and control the video bitrate. As the current system software already occupies 23506 bytes out of the 24576 bytes available alterations to the system hardware are required if this functionality is to be supported. One option is to use the Spartan-3E 1600 FPGA, which has an additional 4 embedded RAMs and is available for comparable cost to the Spartan-3 1500 FPGA.

Another option is to use caches and store the software within the external memory used by the encoder and camera interface. Sharing the external memory between the processor, camera interface and encoder becomes more feasible if the Xilinx cachelink interface is used. This custom interface was developed by Xilinx to provide the microblaze processor with a lower latency interface to external memory than that provided through the OPB bus. The caches used with the cachelink interface also supports larger cache line sizes than the caches used when external memory is accessed through the OPB bus. Use of cachelink interfaces to provide the encoder and camera interface with access to external memory would also provide a performance improvement whilst still allowing the encoder and camera interface to be easily used in a variety of Xilinx platform based systems with different external memories.

4.2 H.264 Encoder System using the Altera