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

Upconverter rewrite #279

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

mtdudek
Copy link

@mtdudek mtdudek commented Sep 24, 2021

This series of commits improve frontend adapter bandwidth.

@mtdudek
Copy link
Author

mtdudek commented Sep 24, 2021

@enjoy-digital what do you think?

@enjoy-digital
Copy link
Owner

Thanks @mtdudek, I'm not able to review it now but will try to do so in the next days.

@mtdudek
Copy link
Author

mtdudek commented Sep 29, 2021

So it failed on picolibc, and not on this upconverter, it states that meson is not installed

@enjoy-digital enjoy-digital force-pushed the master branch 2 times, most recently from 1f94deb to feee435 Compare October 1, 2021 12:48
@enjoy-digital
Copy link
Owner

Thanks @mtdudek, I've been able to have a first look. The new code is becoming really complex to follow and I'm not sure it will be possible to maintain it, so I'm not able to merge it now and will have to spend time understanding the previous limitations.

The primary issue is in fact coming from LiteVideo that should not require the use of an UpConverter and should directly handle access to the DRAM port with native data-width. This allows using a very simple specific UpConverter vs the generic (but complex) UpConverter here. The new VideoFramebuffer (now recommended vs LiteVideo VideoOut core) does not have this limitation and directly runs with native data-width: https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/video.py#L618.

Maciej Dudek added 2 commits June 27, 2022 17:49
…dwidth

This change is necessary to run litevideo, as old up converter was too slow to support
high bandwidth requirements of HDMI core.
Also old upconverter had two bugs:
* reading sequentially and non-sequentially would return data in the same order
* writing sequentailly and non-sequentially would return different memory state

test/test_adapter.py add new up converter test: test_up_converter_writes_not_sequential
This test checks if non-sequential writes to one dram word will create the same result as sequential writes
Add parameters for rx_buffer, tx_buffer and cmd_buffer depths

Signed-off-by: Maciej Dudek <[email protected]>
LiteDRAM controler does not check if wdata stream has valid signal set,
it assumes that wdata has valid data when cmd is send.

Signed-off-by: Maciej Dudek <[email protected]>
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

Successfully merging this pull request may close these issues.

2 participants