ࡱ > = ? < 7 p bjbjUU "2 7| 7| p l ( : : : : : : : @ B B B B B B $ w f : : : : : f 4 : : { 4 4 4 : : : @ 4 : @ 4 4
@ : `f d @ 0 , m 4 m @ 4 This document defines the interface to the JPEG Encoder Verilog IP Core at HYPERLINK "http://www.opencores.org" www.opencores.org.
The core was written in generic, regular Verilog code that can be targeted to any FPGA. The core does not rely on any proprietary IP cores, instead all of the functions required to implement the JPEG encoder are written in Verilog and the code is entirely self-contained. This core has been simulated on many raw images with different quantization and Huffman tables.
The input to the Encoder core is a 24-bit data bus with 8 bits each for the Red pixel, Green pixel, and Blue pixel. The signal data_in contains the Red pixel value in bits [7:0], Green in bits [15:8], and Blue in bits [23:16]. Each clock cycle should have 24 bits of data for a new pixel. The inputs should start with the top left 8x8 block of the image, starting with the top left pixel, going to the right, then down to the second row, etc. After the first 8x8 block of the image, there needs to be a delay of at least 33 clock cycles before inputting the next block. Then after this delay, the enable signal should go low for one clock cycle, then enable should go high on the next clock cycle as the next 8x8 block is input. The second 8x8 block of the image should be input in the same format as the first block. This second 8x8 block will be to the right of the first block. You should go from the top left of the image to the right until the right edge of the image is reached. Then go down to the second row and continue until the last row of the image. Make sure to insert the delay of 33 or more clock cycles between each block. This is required or else the calculations from the previous block will not have been completed yet.
The image data will need to be input in full 8x8 blocks. If for example your image is 90 x 90 pixels, you will need to extend the pixel data to 96 x 96 pixels. This is usually accomplished by repeating the edge pixel value onto the extra pixels for each row or column.
When inputting the last 8x8 block of pixel data, assert the signal end_of_file_signal at the beginning of the block. This lets the code know there are no more blocks to be input, and the remaining bits will be output, even if they do not fill a full set of 32 bits. If the final JPEG bits are not a full set of 32 bits, the signal eof_data_partial_ready will be high for one clock cycle, and the bits in the signal JPEG_bitstream will be valid for one clock cycle. The value in the signal end_of_file_bitstream_count indicates how many of the bits in the signal JPEG_bitstream are valid at the end of the image file.
The output is the signal JPEG_bitstream, which is a 32-bit width bus. The bits are aligned Big Endian, so the bits occupying places 31-24 are the first 8 bits to be output, followed by 23-16, etc. The data in the signal JPEG_bitstream is valid when the signal data_ready goes high. The bitstream data will be output shortly after the first block is input, and will continue to be output as the pixel data is being input to the core.
There is an example testbench file, jpeg_top_TB.v, included in the opencores project. This gives an example of the timing needed to run the core. The data from the image file, ja.tif is used as the pixel data input in the testbench. The output from the core is in the file ja_bits_out.v. These bits were used to create the jpeg image, ja.jpg. The header for the file needs to be created separately. The JPEG encoder core does not create the jpeg header file. Also, the FFD9, end of scan marker, needs to be added after the JPEG bits to complete the JPEG file. This core outputs the JPEG bits created from the Huffman codes only. I used a matlab program to create the ja.jpg image from a separate header and from the jpeg bits created from this JPEG encoder core.
The quantization table can be changed by changing the values in the y_quantizer, cb_quantizer, and cr_quantizer modules. The Huffman table can be changed in the y_huff, cb_huff, and cr_huff modules. These quantization and Huffman values have to be compiled into the code that is written to the FPGA - they are not programmable from an external processor. Youll have to modify the code if you want to change these values on the fly. One important note you should create a full Huffman table, even if you are expecting not to use every possible Huffman value. The calculations are not performed with floating point precision, and so the values calculated by this core will be slightly different than the exact values calculated with better precision. Therefore, you will end up with slightly different Huffman amplitude values, and if you do not use a full Huffman table, it is possible the core will need a Huffman value that is not encoded. This will result in an unusable output. There are no error signals so the core will not alert you to this situation. Your only indicator will be a garbage jpeg bitstream.
If you want to encode more than one image, you will need to set reset, rst, high then low between images. The signal rst is active high.
The order in which the verilog files should be compiled is below. The top module is jpeg_out, so it should be compiled last after all of its dependencies have been compiled.
y_dct.v
cb_dct.v
cr_dct.v
y_quantizer.v
cb_quantizer.v
cr_quantizer.v
y_huff.v
cb_huff.v
cr_huff.v
yd_q_h.v
cbd_q_h.v
crd_q_h.v
rgb2ycbcr.v
sync_fifo_32.v
pre_fifo.v
fifo_out.v
sync_fifo_ff.v
ff_checker.v
jpeg_top.v (top level)
Synthesis Results:
The maximum clock speed supported in a Virtex-5 device for this core is 290 MHz. I synthesized the core in blocks, as there were not enough resources in a single Virtex-5 device to efficiently synthesize the core. The resource utilization statistics for the entire core are below:
Total Resource Utilization for Virtex-5:
DSP48E 224 uses
FD 266 uses
FDE 732 uses
FDR 802 uses
FDRE 19806 uses
FDRSE 7 uses
MUXCY 6 uses
MUXCY_L 4749 uses
RAM32M 30 uses
RAM32X1D 7 uses
RAMB36 3 uses
XORCY 4668 uses
XORCY_L 3 uses
LUT1 2491 uses
LUT2 3057 uses
LUT3 5791 uses
LUT4 702 uses
LUT5 796 uses
LUT6 1122 uses
If you have any questions, please email me at HYPERLINK "mailto:davidklun@gmail.com" davidklun@gmail.com
David Lundgren
K L r s t ! I J K ^ _ p j U0J j U j U
|
ࡱ > : < 9 7 p bjbjUU ", 7| 7| p l / ( : : : : : : : $ : : : : : b : : b b b : : : b : b b : b : p j z 0 / , : ( b This document defines the interface to the JPEG Encoder Verilog IP Core at HYPERLINK "http://www.opencores.org" www.opencores.org.
The core was written in generic, regular Verilog code that can be targeted to any FPGA. The core does not rely on any proprietary IP cores, instead all of the functions required to implement the JPEG encoder are written in Verilog and the code is entirely self-contained. This core has been simulated on many raw images with different quantization and Huffman tables.
The input to the Encoder core is a 24-bit data bus with 8 bits each for the Red pixel, Green pixel, and Blue pixel. The signal data_in contains the Red pixel value in bits [7:0], Green in bits [15:8], and Blue in bits [23:16]. Each clock cycle should have 24 bits of data for a new pixel. The inputs should start with the top left 8x8 block of the image, starting with the top left pixel, going to the right, then down to the second row, etc. After the first 8x8 block of the image, there needs to be a delay of at least 13 clock cycles before inputting the next block. Then after this delay, the enable signal should go low for one clock cycle, then enable should go high on the next clock cycle as the next 8x8 block is input. The second 8x8 block of the image should be input in the same format as the first block. This second 8x8 block will be to the right of the first block. You should go from the top left of the image to the right until the right edge of the image is reached. Then go down to the second row and continue until the last row of the image. Make sure to insert the delay of 13 or more clock cycles between each block. This is required or else the calculations from the previous block will not have been completed yet.
The image data will need to be input in full 8x8 blocks. If for example your image is 90 x 90 pixels, you will need to extend the pixel data to 96 x 96 pixels. This is usually accomplished by repeating the edge pixel value onto the extra pixels for each row or column.
When inputting the last 8x8 block of pixel data, assert the signal end_of_file_signal at the beginning of the block. This lets the code know there are no more blocks to be input, and the remaining bits will be output, even if they do not fill a full set of 32 bits. If the final JPEG bits are not a full set of 32 bits, the signal eof_data_partial_ready will be high for one clock cycle, and the bits in the signal JPEG_bitstream will be valid for one clock cycle. The value in the signal end_of_file_bitstream_count indicates how many of the bits in the signal JPEG_bitstream are valid at the end of the image file.
The output is the signal JPEG_bitstream, which is a 32-bit width bus. The bits are aligned Big Endian, so the bits occupying places 31-24 are the first 8 bits to be output, followed by 23-16, etc. The data in the signal JPEG_bitstream is valid when the signal data_ready goes high. The bitstream data will be output shortly after the first block is input, and will continue to be output as the pixel data is being input to the core.
There is an example testbench file, jpeg_top_TB.v, included in the opencores project. This gives an example of the timing needed to run the core. The data from the image file, ja.tif is used as the pixel data input in the testbench. The output from the core is in the file ja_bits_out.v. These bits were used to create the jpeg image, ja.jpg. The header for the file needs to be created separately. The JPEG encoder core does not create the jpeg header file. Also, the FFD9, end of scan marker, needs to be added after the JPEG bits to complete the JPEG file. This core outputs the JPEG bits created from the Huffman codes only. I used a matlab program to create the ja.jpg image from a separate header and from the jpeg bits created from this JPEG encoder core.
The quantization table can be changed by changing the values in the y_quantizer, cb_quantizer, and cr_quantizer modules. The Huffman table can be changed in the y_huff, cb_huff, and cr_huff modules. These quantization and Huffman values have to be compiled into the code that is written to the FPGA - they are not programmable from an external processor. Youll have to modify the code if you want to change these values on the fly. One important note you should create a full Huffman table, even if you are expecting not to use every possible Huffman value. The calculations are not performed with floating point precision, and so the values calculated by this core will be slightly different than the exact values calculated with better precision. Therefore, you will end up with slightly different Huffman amplitude values, and if you do not use a full Huffman table, it is possible the core will need a Huffman value that is not encoded. This will result in an unusable output. There are no error signals so the core will not alert you to this situation. Your only indicator will be a garbage jpeg bitstream.
If you want to encode more than one image, you will need to set reset, rst, high then low between images. The signal rst is active high.
The order in which the verilog files should be compiled is below. The top module is jpeg_out, so it should be compiled last after all of its dependencies have been compiled.
y_dct.v
cb_dct.v
cr_dct.v
y_quantizer.v
cb_quantizer.v
cr_quantizer.v
y_huff.v
cb_huff.v
cr_huff.v
yd_q_h.v
cbd_q_h.v
crd_q_h.v
rgb2ycbcr.v
sync_fifo_32.v
pre_fifo.v
fifo_out.v
sync_fifo_ff.v
ff_checker.v
jpeg_top.v (top level)
Synthesis Results:
The maximum clock speed supported in a Virtex-5 device for this core is 290 MHz. I synthesized the core in blocks, as there were not enough resources in a single Virtex-5 device to efficiently synthesize the core. The resource utilization statistics for the entire core are below:
Total Resource Utilization for Virtex-5:
DSP48E 224 uses
FD 266 uses
FDE 732 uses
FDR 802 uses
FDRE 19806 uses
FDRSE 7 uses
MUXCY 6 uses
MUXCY_L 4749 uses
RAM32M 30 uses
RAM32X1D 7 uses
RAMB36 3 uses
XORCY 4668 uses
XORCY_L 3 uses
LUT1 2491 uses
LUT2 3057 uses
LUT3 5791 uses
LUT4 702 uses
LUT5 796 uses
LUT6 1122 uses
If you have any questions, please email me at HYPERLINK "mailto:davidklun@gmail.com" davidklun@gmail.com
David Lundgren
K L r s t ! I J K ^ _ p j U0J j U j U
|
