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

litedram_gen: Don't block user port with no CPU #292

Closed
wants to merge 1 commit into from

Conversation

mkj
Copy link
Contributor

@mkj mkj commented Jan 13, 2022

Change e52ece0 blocks access to user ports prior to dram init.
As noted in #286 (comment) this is a problem for cpu-less designs, since the initial memtest requires the user port.

Instead enable the user port unconditionally in that case.

Change e52ece0 blocks access to user ports prior to dram init.
As noted in
enjoy-digital#286 (comment)
this is a problem for cpu-less designs, since the initial memtest
requires the user port.

Instead enable the user port unconditionally in that case.
@enjoy-digital
Copy link
Owner

Thanks @mkj, this is indeed an issue with CPU-less controllers. But even in this case, blocking the other ports could be necessary so the fix was probably not flexible enough. This is fixed a bit differently with 62abf9c that introduces a block_until_ready parameter on ports that can use set to False for the port used by the CPU for memtest in the CPU-less case.

mkj added a commit to mkj/microwatt that referenced this pull request Jan 14, 2022
Recent litedram gets stuck at memtest unless block_until_ready=False.
(discussion in enjoy-digital/litedram#292)

This change regenerates with latest litedram and litex
62abf9c ("litedram_gen: Add block_until_ready port parameter to control blocking behaviour.")
add2746a ("tools/litex_cli: Rename wb to bus.")

Signed-off-by: Matt Johnston <matt@codeconstruct.com.au>
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.

None yet

2 participants