D ESIGN F LOW

The traditional hardware design flow is depicted in Fig. 4-1. In the first instance, the module specification is determined and the computational complexity of each algorithm are investigated and analyzed by the C model. The C model adopted for our architecture is the XviD [19] MPEG-4 video encoder/decoder, which is a free software developed by the XviD organization. The designers can modify or redistribute the XviD MPEG-4 software in accordance with their requirements respectively. Some processes in C model are rewritten in hardware-like format consisting bit-width precision and data flow. It helps us to verify the hardware designs and find out the bugs. For instance, both the DCT and the IDCT have the same precision in the software and hardware model. The hardware architectures are implemented by using Hardware Description Language such as Verilog or VHDL. HDL simulation procedure is used to confirm that the results meet our requirement. The waveform simulation using Modelsim can analyze the timing and the signal values to correct the errors in the hardware model. When the function of the hardware model is correct, we can use Synopsys to synthesize these gate-level HDL codes. Then, the post-synthesis simulation is provided to check the timing specification. If the timing is not satisfied, the more tight constraints may be used or the hardware architecture may be modified and verified again.

Before achieving our specification, these steps are repeated.

Figure 4-1 Module design flow

4.2 Functional Verification

Generally speaking, the design and the simulation in the software model are faster than that in the hardware model. Because the original DCT and IDCT algorithms in the XviD MPEG-4 video codec are not suitable for the hardware implementation, the C models of DCT and IDCT are required to be developed. When the C models of DCT and IDCT are implemented to emulate our DCT/IDCT hardware architecture, it makes the testing and verification of our proposed architecture more efficient. By decoding the encoded files, it is very easy to verify whether the C models of DCT and IDCT is correct or not. After the verification of the C models completely, the flowchart as shown in Fig. 4-2 is adopted to verify the architecture of the MPEG-4 texture coding. The testing patterns for functional verification of each module are obtained from the MPEG-4 C model. The hardware model is simulated with Modelsim developed by Mentor Graphics. Some information such as the waveform and the signal values can be displayed on the screen during the simulation. Dumping the information of the I/O signals to the text files will be efficient to check the errors. The output values of each module

Module Spec

C Model Simulation

HDL Simulation

Synthesis

Design Flow Revise Flow

compared by using UltraEditor. If it encounters any mismatch in the hardware model and the software model, the HDL codes will be modified and then simulated again. The iteration continues until the comparison of the text file from hardware model and that from the software model is equivalent.

Figure 4-2 Flow chart of functional verification

‹ Design For Testability

After the logic synthesis of the MPEG-4 texture coding module is complete, design-for-testability is required to make an IC be testable. It involves inserting or modifying logic, and adding pins. The design-for-testability technique will reduce field returns, the complexity of test generation, the cost of testing, and improve yield. We can use the DFT complier to achieve the design-for-testability. An overview of the DFT complier flow is shown in Fig. 4-3. First, your scan style supported by vender’s library must be selected. The scan style will tell the DFTC what type of scan-equivalent flip-flop is used in synthesizing the

Equal?

.txt

.txt Compare ( UltraEdit )

Modify HDL Codes Yes

No Software

dump text file

Hardware output text file

Result File MPEG-4 C Model

Simulation

Dump text file

Test pattern File (.txt)

Hardware Testbench

Hardware Model Simulation

logic. Second, Pre-scan DRC is to check gate-level scan design rule before the scan chain synthesis. We must fix the DFT violations if necessary. Third, scan-chain is inserted. Fourth, post-scan DRC is required to confirm that there are no new DFT problems. Besides, it can verify the scan chains synthesized operates properly, and create an ATPG-ready database.

Finally, the TetraMAX is used to estimate Fault Coverage. The fault coverage of our design with DFT consideration can achieve 95.80%.

Figure 4-3 Overview of DFT compiler flow

Because the memory is regarded as a black-box model and unobservable for testing, the shadow wrapper is required to insert around the memory. SynTest SRAMBIST is adopted to support the memory testing. The memory BIST architecture is depicted in Fig. 4-4. The BistMode signal chooses testing or working mode in our design. When testing mode is provided, the data of the memory are obtained from the BIST controller. Since there are six memory modules in the MPEG-4 texture coding architecture, both the BistFail and ErrorMap have six bits to express all memories respectively. If any error occurs, it will be easily detected from these signals. When the chip is in the working configuration, these memories

HDL Insert Scan

Preview Coverage Scan

Ready Synthesis

Pre-scan DRC

Post-scan DRC

Technology Library：

Gates, flip-flops, Scan equivalents

Constraint-based Scan Synthesis：

Routing, balancing, Gate-level optimization Constraints：

Scan style, Speed, area

Figure 4-4 Memory Built-In Self-Test Architecture

‹ IEEE IDCT accuracy measurement

Fig. 4-5 shows the setup for measuring the accuracy of a proposed 8x8 IDCT. IEEE Std 1180-1990 specifies the numerical characteristic of 8x8 IDCT for visual telephony and similar applications where the 8x8 IDCT results are used in the reconstructed loop. For each 8x8 block, round the 64 resulting transformed coefficients to the nearest integer values and clip them to the range -2048 to 2047. For each of the output pixels of the 8x8 IDCT and for each of data sets of the 10,000 block generated for the definition, measuring the peak, mean, and mean square errors between the “reference” data and the “test” data. The random data from range (-300, 300), (-255, 256), (-5, 5) is input and the rates are generated in 5 items which are peak error (PE), mean square error (MSE), overall mean square error (OMSE), mean error (ME),and overall mean error (OME). Table 4-1 shows the results.

Figure 4-5 Setup for measuring the accuracy of a proposed 8x8 IDCT

Table 4-1 Accuracy Test result of the IDCT Test

Parameter

H:300 L:-300

H：255 L:-256

H：5 L：-5

Sign invert 300

Sign invert 255

Sign invert 5

L=H=0 IDCT Spec.

OMSE 0.0145 0.0151 0.0095 0.0142 0.0153 0.0095 0.0000 <0.02 OME 0.0002 0.0001 0.0002 0.0002 0.0004 0.0002 0.0000 <0.0015 PE 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 0.0000 = 1 MSE 0.0175 0.0180 0.0130 0.0167 0.0180 0.0127 0.0000 <0.06 ME 0.0074 0.0094 0.0090 0.0083 0.0086 0.0093 0.0000 <0.015