Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use in single channel mode (instead 4) #1

Open
maa1370 opened this issue Aug 22, 2020 · 0 comments
Open

use in single channel mode (instead 4) #1

maa1370 opened this issue Aug 22, 2020 · 0 comments

Comments

@maa1370
Copy link

maa1370 commented Aug 22, 2020

Hi
I am trying to convert the project to single channel mode. I have already successfully converted and tested the project in dual channel mode with 1280*720 resolution and 1000/7 MHz clock and I'm aware of details on how to do that. Here are some changes I have made to the project to work in single channel mode:

-changed DRAM and PS HP ports count to 1.
-changed num_chan to 1.
-changes needed in striped_encoders.vhd for axi4lite_reg_file and and address set process.
-changed C_MAX_LINE_WIDTH to 2048 in JPEG_PKG.vhd (more than needed)
-changed res_x_nopad_ch calculate method in image_stripe.vhd, since it was correct for 2 channels or more. now it is set to res_x_nopad_ch(i) <= shift_right(unsigned(res_x_in), 0); or res_x_nopad_ch(i) <res_x_in; which is correct for 1 channel.
-in buffered_encoder I also changed RES_X_MAX to 2048 and JPEG_FIFO_DEPTH to 65536/ AXI_WORD_LEN; , although i think they are not needed, since i had correct output with default valeus (512 and 16384/ AXI_WORD_LEN) with 2 channels and 1280*720 input and buffers where enough. any way i changed them to larger values.

Now the problem is that for single channel mode simulation (output and picture size) is correct, but on hardware, when I peek image size from buffer, it is always equal to 2^32-1 (all bits one). I think image is captured from hdmi correctly (since RGB LED shows correct state), but jpg encoder has problem.

Do you have any idea why is this happening on hardware? may it be related to encoder clock frequency (1000/7) is not adequately high? simulation is using same clocks (74.25 for pixel clock and 1000/7 for encoder clock) and the result is correct! I have checked the code and have no idea what is going wrong.

Thanks for the great project :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant